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

以下摘自百度百科：

自定義404錯誤頁面是增強用戶體驗的很好的做法，但在應用過程中往往并未注意到對搜索引擎的影響，譬如：錯誤的服務器端配置導致返回“200”狀態碼或自定義404錯誤頁面使用Meta Refresh導致返回“302”狀態碼。正確設置的自定義404錯誤頁面，不僅應當能夠正確地顯示，同時，應該返回“404”錯誤代碼，而不是 “200”或“302”。雖然對訪問的用戶而言，HTTP狀態碼究竟是“404”還是“200”來說并沒有什么區別，但對搜索引擎這則是相當重要的。

而恰恰我發現這里服務器上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”就可以了。

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