最近和朋友聊天，我们都感到SEO行业有个很致命的问题，就是没有一个固定的规范和标准。不像python，PHP等程序语言，有个很完善的官方手册，实在不行就直接做个小程序跑下，马上就有准确的答案。而SEO，毛标准都没有，所以就经常出现这样的情况：两个人为关键词密度争得面红耳赤，一个说3~7%好，一个说4~9%好，两个人差点打起来，但结果还是谁也说服不了谁（而且通常都是扯淡问题）。
WHY
在规模较大的公司里，这样的SEO是很危险的。因为在大公司里，任何一点资源都需要去争取，都有一定的成本，比如要说服领导，得到产品和研发的配合，BI和搜索的支持。好不容易各种流程走完了，大家翘首以待等待流量提升，结果运气好的会有点效果，大多数是毛都没有，甚至倒退都很有可能。就比如往厨房送了一只鸡，大伙等着做成鸡汤或大盘鸡，结果出来一盘鸡屁股，或者直接出来一盘炒青菜。问厨师是怎么回事，厨师也挠了挠脑袋，也不知道哪里出了问题。
这样不可控的SEO是危险的，在大公司会逐渐失去地位。（这也是为什么都说SEO的ROI高，但大多数老板还是偏爱SEM的原因，很多SEO都做不到可控，无法保证投入一定有产出）因此，一定要让SEO可控。投入一分钱，就要见到一分钱的效果，不能听天由命，看天吃饭。
WHAT
那怎样才能让SEO做到可控呢，不那么坑爹呢？
首先，要以科学的思路为指导。什么叫科学的思路，有3个方面：1、一切结论都有据可循，有数据支持，或出自搜索引擎基础理论或官方文档（这里的基础理论可不是什么关键词密度等）；2、一切方案都要考虑清楚预期效果及风险（不要求完全精确，但至少对效果的预判方向一致）；3、监控最终效果，与之前结论和方案进行实际对照（失败不要紧，要紧的是不管成功或失败）。
HOW
其次，SEO项目可以参考卫哲3+1的产品思考法。卫哲的3+1产品思考法是我之前看到的一个很完整，符合逻辑的产品思路，后来发现SEO也同样适用（产品经理是从用户角度改善网站，而SEO是从搜索引擎角度改善网站，两者有很多相同点的。）。下面是3+1思考法的SEO：
第一问：需求从哪里来，目标客户是谁
需求从哪里来，目标客户是谁，我认为这是最重要的一个问题。SEO通常这样，没有数据和理论支持，完全是出于自己感性的考虑，就对网站进行调整，比如看这个URL不爽，就重新做一套。这类需求通常没有明确的目标，或者目标不清晰，只是为了做而做。这些需求是需要直接砍掉的。
还有一类需求，看起来很有逻辑但最底层的理论却有问题。比如认为自己排名不高，原因是关键词密度过低，于是就提出需求增加关键词密度。但问题是排名低是否确实是由于关键词密度低引起，增加关键词密度是否真的会提高排名？从nlp角度来说，不仅要考虑关键词词频TF，还要考虑逆文档频率IDF，并没有那么简单；其次，从搜索引擎博弈角度出发，关键词密度如此容易操作，而且一直被SEO拿来控制排名的因素，恐怕早就被搜索引擎打入冷宫了。
其次，SEO需求应该是来自搜索引擎或用户，即针对搜索引擎或用户的某些问题进行优化。比如生成并提交sitemap，提高搜索引擎爬虫的抓取效率，或将主要内容放在首屏，提高用户体验。如果某个需求，对搜索引擎没有益处，对用户也没有益处，只从SEO角度考虑，那通常是没有作用的，再比如之前提到的关键词密度。
第二问：如果不做会有什么后果？这个需求紧迫吗？
上一问是考察需求是否必要，这一问是考察需求的重要和迫切程度。这个需求是紧急处理，还是排在队列中慢慢来，都需要通过这一问来确定。
第三问：他们的痛是什么？场景是什么（优化之前/之后）
这一问是考察需求能否解决之前问题。原来的问题是什么，那需求实施后能否解决问题。
+1：解决之后在网站数据上会有什么表现
这一问是考察需求的效果。不管最终结果成功与否，都要考察其结果，符合预期效果那太好了，如果跟预期差距较大，或没有任何效果，则需要自我分析，找出其中症结，就是“死也要死个明白”，作为以后的教训。
EXAMPLE
之前做过一个性能优化的需求，虽说效果不明显，而且严格意义上跟SEO没直接关系，不过仍然可以用产品思维去思考下。大致情况是这样的：
背景
有同事刚听了什么搜索大会，某砖家在会上提到了网站速度对SEO的影响，回来后就用某工具跑了下，果然比竞争对手网站速度要慢，于是交给我去分析。我主要是用PageSpeed，Yslow和WebPagetest对网页几个重点页面进行测试（这几个工具在谷歌网站站长指南中有推荐），并出了个初步方案，列了12项优化items。不过由于这些items涉及网站架构，并且我本身专业度不够，就只算是给研发同事的优化建议。
第一问：需求从哪里来，目标客户是谁
需求表面上是同事让我分析，但总归是网站自身存在的问题。
对于速度优化的受益方，一般是搜索引擎和用户。因为随着网站速度的提升，搜索引擎爬虫的抓取效率会提高，用户方面就不必说了，必然会提高用户体验。不过跟前端和开发同事讨论后，考虑到实现难度，第一期就先对静态文件缓存，CSS与JS的合并进行优化，所以就跟搜索引擎爬虫没有关系了（搜索引擎爬虫只是向搜索引擎发送请求，并保存返回的结果。对于返回网页代码中的静态文件，包括JS和CSS，并加载和保存。这一点可以参考谷歌管理员工具中的谷歌抓取方式来试验。）。
第二问：如果不做会有什么后果？这个需求紧迫吗？
速度优化如果不做就会影响网页打开速度，这个需求算比较重要，但不算紧迫。这个需求算是优化类，而不算是纠错类。（我将SEO需求按照目的简单分为两类：纠错类和优化类。纠错类是网站本身的SEO基础优化，比如多个栏目未单独设置title，而优化类则是加分项，比如这个速度优化。）
第三问：他们的痛是什么？场景是什么（优化之前/之后）
由于是优化类需求，所以也不算很痛。就是优化前，用户每次打开网页都要重新下载静态文件，并且JS和CSS都要一个个下载，JS还是单线下载。而优化之后，老用户打开网页时部分静态文件就直接从缓存中取，而不用重新下载，再加上合并后JS和CSS文件数量的减少，都大大降低了HTTP请求的数量，这样用户打开网页时，速度就快了100+毫秒。
另外，前端还在列表页进行了懒加载，这样就不用等到32个图片全部加载后网页才显示，而是先显示首屏，随着鼠标下滚才加载并显示下面图片。
+1：解决之后在网站数据上会有什么表现
以下是某个页面优化后的数据：
某栏目主要做了图片懒加载以及背景图合并，css合并等。
JS文件增加3个（业务需要），体积减少30KB；CSS文件减少3个，减少幅度为50%；CSS背景图减少11个，减少幅度 61.1%；首屏图片减少27张，减少幅度56.25%，首屏图片体积减少200KB左右。
整体请求减少38个，幅度为41.3%；体积减少 277KB， 幅度为30.1%。下面是优化前后的瀑布图：
注：这个结果是前端同事提供，是优化后的直接数据，可能还有后续的数据，比如GA的网页打开速度，用户停留时间，跳出率等，这些后续数据暂未记录。
PLUS
- 很早之前就想写这个文章了，但老觉得太过理论，写出来就像是忽悠的，于是就拖着没写。一直到最近，实在不堪一些拍脑门需求，就写出来，请随意拍砖。
- 文中那个需求是我刚来公司时候做的，记得那时早上等班车都要看会那本性能优化的动物书，现在就像个老油条一样，不思进取，真不喜欢这样。
- 图注。漫画台词：“简单的说，这样做就能提高网站排名了”。漫画来自SearchEngineJournal.com。