SEO實踐(1)——開展SEO前的資料準備

　　回首發現SEMWATCH已經許久沒有更新了，雖然部落格流量愈下，但作為一個非盈利性的群博，當它給予真正需要的人一點點切實有用的文章時，那就足夠了。作為編輯的一員，我想有必要把這樣的精神以自己的微薄之力延續下去。

　　當我們開始開展一項SEO工作時，第一件要做的事情是要保證我們做的任何事情都可以有資料的支撐——而不是自己的直覺。SEO的主要資料來源來自兩塊：網站的伺服器日誌、第三方流量分析工具。

　　網站伺服器日誌

　　Apache，Nginx等常用伺服器的內建日誌配置格式Combine已經可以滿足大多數SEO分析需求。它看上去類似是這樣的：

　　111.111.111.111 – - “[20/Feb/2012:18:09:25 +0800]” “GET / HTTP/1.1″ 200 3121 “http://semwatch.org/” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

　　必須記錄的資訊諸如：訪問來源IP、訪問時間、訪問頁面、HTTP響應狀態代碼、訪問來源及用戶端標識等，這些在Combine日誌格式裡面都有。

　　在確保伺服器日誌可以滿足其他部門的分析需求下，至少要確保上面提到的幾項被記錄在伺服器日誌裡面。但也不要將任何可以記錄的資料都記錄下來，只選擇實際需要的部分，不然會使得網站日誌體積非常大，不利於分析起來的效率。這些內容可能需要和營運進行溝通解決。

　　然後關於日誌的分析，我認為沒太多固定的準備工作可做，因為它的資料來源是原始的(raw似乎聽上去會更有感覺?)，所以可選擇的資料維度幾乎是無限的。因此尤其要按實際需求進行相應的處理與分析。

　　對於一些要求並不是特別高的日誌分析需求，可以嘗試使用光年日誌分析系統。雖然我個人對所有圖形介面的實用類程式都不帶好感，但它提供了一些很不錯的資料維度的思路。

　　聽說有一家大型的旅遊網站是採用MongoDB結合Map/Reduce進行日誌分析的，我個人也用過MongoDB實現過前面提到的光年日誌分析的一部分重要功能。所以感覺MongoDB是個可以考慮的選擇。

　　第三方流量分析工具

　　Google Analytics的安裝

　　對於免費流量分析工具，Google Analytics絕對是其中的佼佼者(以下簡稱GA)。不過如果網站的月瀏覽量大於500W的話，只有Google Adwords的使用者，才能繼續免費使用GA進行流量的記錄與分析。下面都以它為例。

　　在GA添加需要追蹤流量的網站以後，它會提示你添加一段JavaScript代碼，到每一個你需要追蹤頁面的標記之前。代碼的添加可能是一件很輕鬆的工作，但也可能非常麻煩，主要取決於網站的模板層。

　　先提下常見開源部落格程式WordPress的方法，它採用了包含的模板處理方式，比如網站首頁、列表頁、文章頁等自身的模板，都是只有當中一部分的。而包含網頁LOGO等的網頁頭部，都使用WordPress的get_header方法來載入另一個獨立的模板檔案(get_header方法本質上是PHP裡面的include函數)。簡言之，只要在header.php那個檔案上面添加代碼，包含它的所有網頁都會跟著改，很快就可以把GA代碼添加好。

　　但情況並不總是理想的，尤其對於使用網站架構自己進行開發的網站，有時並沒有將包含這樣的方式很好的運用。這可能是網站的建設規範不完善的關係，也可能是網站需求導致了確實無法使用和WordPress類似的包含方式。那麼，至少要在每個網頁的頭部，額外包含一小段載入全域JavaScript的區塊，以方便的添加全域性的JavaScript代碼。

　　雖然未必在添加GA代碼時，對可能糟糕的網站模板結構去變更，最多到幾十個不同的模板檔案裡面去分別加下代碼就是了(當然也要花些時間去保證沒有漏過哪些頁面)。但一次性搞定一些本質性的問題會帶來很多日後的便利性——比如又要換一套統計代碼。

　　相對最麻煩的事情或許是如何說服程式員為了一些看似小的需求而修改模板結構，這邊就略過了。

　　一些基礎的Google Analytics設定

　　對於SEO而言，一項最基礎的設定，就是要把網站上對SEO有價值的頁面進行歸類。對頁面進行區分，並以此掌握了它們的流量現狀及趨勢以後，才能把握SEO的側重點，及更好的分析網站上每次SEO修改的成效等等。

　　如最簡單的例子，對於一個網站，如果手頭有1000條外鏈，應該給網站的欄目頁還是產品頁?這主要取決於哪類頁面有更高的轉化率與更大的SEO流量提升空間。

　　對於每個網站而言，都存在不同的情況。比如一個書籍類的電商網站，它列表頁不會有太多流量，沒多少人搜尋什麼“電腦書籍”，但會更多人搜尋《喬布希自傳》之類，因為使用者有很明確的需求。而對於一個服飾電商，相應更多人會搜尋“襯衫”之類，而非“2012年春季新款白色襯衫”等，因為使用者只是想到網站上挑衣服，他們只有需求的意向，但具體需求是模糊的。

　　以上兩個是比較典型的例子，但有更多情況我們無法用自己的直覺做出準確的判斷，那就需要用流量資料來收集事實。

　　儘管部落格的流量資料分析起來沒太大價值，出色的文章是部落格的一切，但這裡還是以SEMWATCH為例來簡單介紹下方法。假設我們需要把SEMWATCH的欄目頁和文章頁流量進行區分，它們的URL分別是類似這樣的：/category/seo/，/2012/02/post/

　　首先要到GA的資料頁面內，找到進階細分一項，點擊右側新自訂細分。然後進行類似下圖的設定：

　　

 

　　通常情況下，將頁面的URL匹配相應的正則以後，就可以把它們區分開來。注意，如果網站的初期URL規劃不完善，可能會導致無法用URL來區分頁面類型的非常非常糟糕的情況，務必保證每一類頁面擁有其獨立的URL標識。

　　在該例中，SEMWATCH的欄目頁匹配Regex是：^/category/.*?/$，文章頁是：^/2[0-9]{3}/[0-9]{2}/.*?/$

　　盡量用最嚴格的Regex寫法，這樣可能可以在無形中規避很多不必要的錯亂。還需要注意的是，老版本的GA預設情況下篩選器的“包含”即使用Regex，新版GA一定要選擇“匹配Regex”這項。

　　關於Regex，篇幅所限不可能進行解釋，如果你不懂的話，可以考慮去尋找程式員求助。但我的個人建議是儘可能的要自己掌握它，這是一個比較基礎的技術要求，SEO不應該被它所難倒。Regex雖然看上去很噁心——至少我從來看不懂自己寫出來的正則，但其實挺容易學的。

　　總之通過上面的步驟，我們就簡單的把頁面類型區分開來了。回到最初的例子，如果有1000外鏈給SEMWATCH隨便分配，現在應該把外鏈給予哪些頁面呢?可以發現的是欄目頁幾乎沒流量、而文章頁天生流量就很高。多數情況下這證明了文章頁具有更大的流量發展空間，此時把外鏈分配給文章頁就是最明智的做法。(但也不能武斷的說，不能排除欄目頁的SEO有巨大問題的可能性，這問題一點都不罕見。所以還要結合我們的常識及其他方面的分析來綜合判斷。)

　　限於篇幅就告一段落了。另外關於Google Analytics的各類經驗在SEMWATCH上面有過較多的分享，大家可以擅用搜尋功能。

　　最後的總結

　　實際可能要面臨的問題還有很多很多，當然不可能是一篇文章所能涵蓋的。前面提到的只是兩個主要資料，實際SEO過程中，還或許需要用到的資料如網站級的Google Webmaster Tool，估算流量的愛站、SEMRush、Google Adplanner、HitWise，關鍵詞的Google Keyword Tool、百度司南，連結類的MajesticSEO、Ahrefs等等。

　　最近我在看《麥肯錫方法》，提到：“以事實為基礎，嚴格的結構化，以假設為導向”，類似的稍總結下SEO的話：“以資料為基礎，嚴格的邏輯化，以效果為目標、技術為手段”。本文是為了作為根基的資料墊下基礎而已，它本身是沒任何價值的——光看資料的話，它只不過是死板的數字罷了。

　　如何藉由資料的輔助，在最需要的地方進行SEO的更改，使得流量獲得大的突破並給網站產生價值，這是我們要真正關注的部分，之後再慢慢分解。

　　p.s. 我平常寫文章比較隨便，文風散亂、語句不通、中心不明，但如果認為這樣也可以接受的話，不妨也可以看下我的個人部落格：http://tech-field.org/。當然該系列文章只在SEMWATCH連載，不能反過來搶它流量嘛。