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

網站服務器日志

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

111.111.111.111 – - "[20/Feb/2012:18:09:25 +0800]""GET / HTTP/1.1″ 200 3121"http://***.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為例來簡單介紹下方法。假設我們需要把網站的欄目頁和文章頁流量進行區分，它們的URL分別是類似這樣的：/category/seo/，/2012/02/post/

首先要到GA的數據頁面內，找到高級細分一項，點擊右側新自定義細分。然后進行類似下圖的設置：

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

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

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

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

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

最后的總結

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

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

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