最近和朋友聊天，我們都感到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左右。