前些天在百度站長club裡看見某站長的帖子，稱網站三次被K,首次是發垃圾鏈太甚，第二次是堆積網站關鍵詞，第三次是全站搜集，沒有原創。被K在這以後，該站長在檢查之前iis日記時，發覺百度蛛蛛在爬動局部頁面後狀況碼回返200 0 64。大禹在網上查尋了有關問題，發覺顯露出來大致相似事情狀況的還不少。眾多SEOer更是祭出了200 0 64是被K的先兆一說。

　　

　　而百度LEE給出的辦復是我們也沒有辦法確認顯露出來這種狀況代碼時是否會影響抓取，但可以確認和Baisuspider的抓取行徑無關。提議查緝一下子iis配備布置和自個兒網站的手續有無問題。

　　連LEE都沒法給出一個正確的解答，更是為200 0 64披上了一層高深莫測的的掩蓋真相的東西。難不成200 0 64真是災殃前的序幕。

　　大禹攜帶這個疑問，查尋了有關資料。在MSDN的《Win32狀況碼周密解釋明白》中，對64的詮釋是指定的網絡名不再可用。而造成該問題的有可能性有眾多，以下大禹總結概括了一點常見的。

　　1、服務器開啟了GZIP壓縮，關閉後回返正常。

　　2、服務器Computer Browser服態、server服務、workstation服務那裡面之一運行不正常。

　　3、Apache配備布置不正確，引動Apache與WinSock v2相沖突，顯露出來64不正確。

　　4、常發生在ASP.NET研發的網站，在手續取得一個響應流在這以後，未讀出內部實質意義便被關閉，這種事情狀況也是萌生64的一個端由。

　　5、大致相似第四種事情狀況，IIS在等待客戶端ACK時，客戶端挑選重置或斷裂鏈接，因此狀況碼回返64。

　　

　　無論是以上哪種有可能，都可以確認和Baisuspider的抓取無關。因為這個，也就擯除了200 0 64是網站被K的先兆一說。前3者因為服務器、IIS、Apache配備布置問題，造成網絡不可以達，因此引動Baisuspider沒有辦法管用抓取。然後兩種有可能歸屬客服端行徑所致，服務端未獲得ACK響應，造成Baisuspider沒有辦法成功抓取。這也就詮釋了，為什麼網站被K及200 0 64在網絡高峰期顯露出來頻率更高。

　　顯露出來200 0 64後，大禹提議立刻自行查緝或結合空間商查緝服務器、IIS或Apache的配備布置及網絡狀態。在擯除以上有可能後，仔細查看200 0 64顯露出來的頻率並做連續不斷監視檢測，假如長時期沒有辦法解決，可向baidu反映此問題。文章原創，過載請注明來源 788中國戶牖幕牆人材網 http://www.788job.net,謝謝。