看了眾多文章，都是關於服務器日記的，仿佛好象沒有確定的評論。通過我對服務器日記的剖析和理解，做一下子論斷：

　　1、服務器回返200 0 0 ，代表著baiduspider對服務器施行了煩請，獲得了回答，抓取了新的數值。此種事情狀況下，搜索引擎網站的處置流程是，若是新宣布的文章內部實質意義，百度抓取並放出的有可能性大於70百分之百。若是很早之前宣布的文章，普通不會抓取往後立刻就開釋，普通到大更新，還是是施行數值相比較，確認不是垃圾內部實質意義往後，再施行開釋。

　　2、服seo務器回返200 0 64 ,眾多人覺得這是被百度K掉的先兆。也有不少SEOer站出來詮釋，這種事情狀況不一定是K站，普通有三種詮釋。

　　到現在為止，對於 200 0 64 的觀點大概分為以下幾種：

　　對話故障，煩請不可以到了，並非百度封站晴雨表

　　百度封站、撥毛或放入沙盒

　　64位操作系統

　　樂思蜀參照了數量多有關文章，雖未得出最後論斷，但感到第1種觀點最合理，現剖析如下所述。

　　首先來看 200 0 64 狀況碼的構成

　　200 0 64：sc-status(協議狀況) sc-substatus(協議子狀況) sc-win32-status(Win32狀況碼)

　　sc-status(協議狀況)：200 連署成功

　　sc-win32-status(Win32狀況碼)：64 指定的網絡名不再可用

　　顯露出來200 0 64代碼，普通事情狀況下，代表著baiduspider以前在此途徑下抓取過內部實質意義。經過相比較，搜索引擎網站覺得該網頁沒有不可缺少再從新施行抓取。這途徑下的頁面，可能之前已經抓取過，不過未開釋，也可能是抓取過，已經開釋。

　　一般事情狀況下，我們可以經過服務器日記的剖析，列出200 0 64的頁面，對此類頁面，施行簡單的改動還是是處置，這麼的話，應當可以引動搜索引擎網站的被觸動引發，從新對頁面施行收錄，有可能會當初開釋。

　　已經被收錄的頁面萌生64代碼，應當是百度記錄此頁面被用戶次數多過訪還是是經過搜索引擎網站獲得搜索最後結果後點擊網站，導致baiduspider跟蹤用戶行徑，對頁面施行從新過訪。

　　所以，我們可以針對服務器日記，研發一個適應seo的服務器日記剖析工具，經過此工具，可以真實記錄蛛蛛或機器人的過訪，並對過訪回返的最後結果施行剖析。可以通不為己甚析，獲得怎麼樣讓更多的頁面讓蛛蛛抓取並取得令人滿意名次的方案。

　　額外經過日記剖析工具，從引申的角度講，可以制造一個蛛蛛香餌，主動指導baiduspider施行爬動和抓取，並取得令人滿意的名次。我說的可不僅是網站地圖。