一個等號引發(fā)的血案（談Nginx正確的404配置）

更新時間：2014年08月26日 10:34:29 投稿：junjie

這篇文章主要介紹了Nginx正確的404配置方法,本文根據實際案例總結而來,可以說是一個等號引發(fā)的血案！需要的朋友可以參考下

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

以下摘自百度百科：

復制代碼代碼如下:

404對seo的影響

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

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

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

一個等號引發(fā)的血案

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

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

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

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

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

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

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

復制代碼代碼如下:

# curl -I http://www.yourdomain.com/testurl.html

HTTP/1.1 404 Not Found

Server: nginx/1.4.4

Date: Fri, 10 Jan 2014 02:36:39 GMT

Content-Type: text/html

Content-Length: 1782

Connection: keep-alive

Vary: Accept-Encoding

ETag: “5018ffe4-6f6″

您可能感興趣的文章: