這是一個血淋淋的教訓，這么說一點也不過分。因為最近發生了一個重大問題，網站流量大幅下跌，跌了近80%了。由于事件發生之前做過一些工作，加了大量友鏈，而且外站權重都相當高，在那天還發生了一次掛馬事件，當然也即時解決了。還做了其它一些關鍵字內、外鏈優化等等。這樣使得查找問題的原因就變的難上加難。偶然的原因發現，百度收錄的鏈接開始出現錯誤，由于網站URL方式采用的目錄式結構，最后一個字符都是/，然而百度收錄的頁面卻無緣無故把這個線去掉了，而這種訪問方式，我并沒有做兼容。當時也查看了網站頁面上的重寫結果，沒有發現哪里頁面的鏈接出現過這種錯誤，那么百度里收錄的這些頁面從何而來？真的不得而知了。可能是外鏈里有些地址把那個目錄后的斜線去掉了？不管它怎么收錄的了，盡快做了一下兼容性工作，因為那種錯誤鏈接會被轉到404頁面上去。剛剛又查了一下，發現了一點蹊蹺。

以下摘自百度百科：

搜索引擎蜘蛛在請求某個URL時得到“404”狀態回應時，即知道該URL已經失效，便不再索引該網頁，并向數據中心反饋將該URL表示的網頁從索引數據庫中刪除，當然，刪除過程有可能需要很長時間；而當搜索引擎得到“200”狀態碼時，則會認為該url是有效的，便會去索引，并會將其收錄到索引數據庫，這樣的結果便是這兩個不同的url具有完全相同的內容：自定義404錯誤頁面的內容，這會導致出現復制網頁問題。輕則被搜索引擎降權，重則會K掉網站。

而恰恰我發現這里服務器上nginx里404的配置就有這樣一個問題，訪問到無效地址的時候，跳轉到的404頁面返回狀態碼是200，汗了。怎么會這樣？

一個等號引發的血案

最后發現問題的原因是配置里多余的一個“=”導致的這個狀態碼錯誤。

現在網上大多數nginx的404配置寫法還是error_page 404 = /404.html; 注意這是個錯誤的寫法，正確的寫法是沒有這個等號的，就是由于這個等號的指引讓nginx將404的的錯誤進入鏈接都以200正常狀態碼顯示了自定義的404頁面，而這對普通用戶來說看上去無差異，然而給搜索引擎發出的信號卻是致命的。切忌切忌。因為此前的服務器，我一直都是用apache來做的，也是第一次遇到這個問題。改完后用工具檢查一下，已經正常了。

其實這個錯誤如果更好的利用起來的話，還可以將錯就錯，也是跟業內人交流得知的，當然這就是一個偏門左道的事了，不在這里教壞大家。當然如果外鏈流量小，或者沒有大流量的錯誤鏈接流入的話，這個也就不成立了。

最后可以通過這個工具進行檢測：

http://www.seochat.com/seo-tools/check-server-headers/

輸入一個你網站下的錯誤的路徑，檢測出有“HTTP/1.1 404 Not Found”就可以了。

或者使用下面的方法檢查更方便，在命令行下輸入：