http返回碼

1、HTTP狀態碼

 

若是某項請求發送到您的服務器要求顯示您網站上的某個網頁（例如，用戶經過瀏覽器訪問您的網頁或 Googlebot 抓取網頁時），服務器將會返回 HTTP 狀態代碼以響應請求。

 

此狀態代碼提供關於請求狀態的信息， 告訴 Googlebot 關於您的網站和請求的網頁的信息。

一些常見的狀態代碼包括：

• 200 – 服務器成功返回網頁
• 404 – 請求的網頁不存在
• 503 – 服務器暫時不可用

 

下面提供 HTTP 狀態代碼的完整列表。 點擊連接可瞭解詳情。 您也能夠訪問有關 HTTP 狀態代碼的 W3C 網頁以得到更多信息 。

 

1xx：請求收到，繼續處理
2xx：操做成功收到，分析、接受
3xx：完成此請求必須進一步處理
4xx：請求包含一個錯誤語法或不能完成
5xx：服務器執行一個徹底有效請求失敗

1xx （臨時響應） 
表示臨時響應並須要請求者繼續執行操做的狀態代碼。

 

 

代碼 說明

100（繼續）	請求者應當繼續提出請求。 服務器返回此代碼表示已收到請求的第一部分，正在等待其他部分。
101（切換協議）	請求者已要求服務器切換協議，服務器已確認並準備切換。

 

 

2xx （成功）

表示服務器成功處理了請求的狀態代碼。

 

 

代碼 說明

200（成功）	服務器已成功處理了請求。 一般，這表示服務器提供了請求的網頁。 若是針對您的 robots.txt 文件顯示此狀態，則表示 Googlebot 已成功檢索到該文件。
201（已建立）	請求成功而且服務器建立了新的資源。
202（已接受）	服務器已接受請求，但還沒有處理。
203（非受權信息）	服務器已成功處理了請求，但返回的信息可能來自另外一來源。
204（無內容）	服務器成功處理了請求，但沒有返回任何內容。
205（重置內容）	服務器成功處理了請求，但沒有返回任何內容。 與 204 響應不一樣，此響應要求請求者重置文檔視圖（例如，清除表單內容以輸入新內容）。
206（部份內容）	服務器成功處理了部分 GET 請求。

 

 

3xx （重定向） 
要完成請求，須要進一步操做。 一般，這些狀態代碼用來重定向。 Google 建議您在每次請求中使用重定向不要超過 5 次。 您可使用網站管理員工具查看一下 Googlebot 在抓取重定向網頁時是否遇到問題。 診斷 下的網 絡抓取 頁面列出了因爲重定向錯誤而致使 Googlebot 沒法抓取的網址。

 

 

代碼 說明

300（多種選擇）	針對請求，服務器可執行多種操做。 服務器可根據請求者（用戶代理）選擇一項操做，或提供操做列表供請求者選擇。
301（永久移動）	請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。 您應使用此代碼告訴 Googlebot 某個網頁或網站已永久移動到新位置。
302（暫時移動）	服 務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。 此代碼與響應 GET 或 HEAD 請求的 301 代碼相似，會自動將請求者轉到不一樣的位置，但您不該使用此代碼來告訴 Googlebot 某個網頁或網站已經移動，由於 Googlebot 會繼續抓取原有位置並編入索引。
303（查看其餘位置）	請求者應當對不一樣的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。 對於除 HEAD 以外的全部請求，服務器會自動轉到其餘位置。
304（未修改）	自從上次請求後，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。若是網頁自請求者上次請求後再也沒有更改 過，您應當將服務器配置爲返回此響應（稱爲 If-Modified-Since HTTP 標頭）。 因爲服務器能夠告訴 Googlebot 自從上次抓取後網頁沒有更改過，所以可節省帶寬和開銷 。
305（使用代理）	請求者只能使用代理訪問請求的網頁。 若是服務器返回此響應，還表示請求者應使用代理。
307（暫時重定向）	服 務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。 此代碼與響應 GET 和 HEAD 請求的 301 代碼相似，會自動將請求者轉到不一樣的位置，但您不該使用此代碼來告訴 Googlebot 某個頁面或網站已經移動，由於 Googlebot 會繼續抓取原有位置並編入索引。

 

 

4xx（請求錯誤） 
這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。

 

 

代碼 說明

400（錯誤請求）	服務器不理解請求的語法。
401（未受權）	請求要求身份驗證。 對於須要登陸的網頁，服務器可能返回此響應。
403（禁止）	服務器拒絕請求。 若是您看到 Googlebot 在嘗試抓取您網站上的有效網頁時收到此狀態代碼（能夠在 Google 網站管理員工具診 斷 下的網絡抓取 頁面上看到此信息），多是您的服務器或主機拒絕 Googlebot 訪問。
404（未找到）	服務器找不到請求的網頁。 例如，若是請求服務器上不存在的網頁，服務器一般會返回此代碼。若是您的網站上沒有 robots.txt 文件，而您在 Google 網站管理員工具」診斷」標籤的 robots.txt 頁 上看到此狀態，那麼這是正確的狀態。 可是，若是您有 robots.txt 文件而又看到此狀態，則說明您的 robots.txt 文件可能命名錯誤或位於錯誤的位置 （該文件應當位於頂級域名，名爲 robots.txt）。 若是您看到有關 Googlebot 嘗試抓取的網址的此狀態（在」診斷」標籤的 HTTP 錯誤頁上），則表示 Googlebot 追蹤的多是另外一個頁面的無效連接（是舊連接或輸入有誤的連接）。
405（禁用的方法）	禁用請求中指定的方法。
406（不可接受）	沒法使用請求的內容特性響應請求的網頁。
407（須要代理受權）	此狀態代碼與 401（未受權）相似，但指定請求者應當受權使用代理。 若是服務器返回此響應，還會指明請求者應當使用的代理。
408（請求超時）	服務器等候請求時發生超時。
409（衝突）	服務器在完成請求時發生衝突。 服務器必須在響應中包含有關衝突的信息。 服務器在響應與前一個請求相沖突的 PUT 請求時可能會返回此代碼，同時會附上兩個請求的差別列表。
410（已刪除）	若是請求的資源已永久刪除，服務器就會返回此響應。 該代碼與 404（未找到）代碼類似，但在資源之前存在而如今不存在的狀況下，有時會用來替代 404 代碼。 若是資源已永久刪除，您應當使用 301 指定資源的新位置。
411（須要有效長度）	服務器不接受不含有效內容長度標頭字段的請求。
412（未知足前提條件）	服務器未知足請求者在請求中設置的其中一個前提條件。
413（請求實體過大）	服務器沒法處理請求，由於請求實體過大，超出服務器的處理能力。
414（請求的 URI 過長）	請求的 URI（一般爲網址）過長，服務器沒法處理。
415（不支持的媒體類型）	請求的格式不受請求頁面的支持。
416（請求範圍不符合要求）	若是頁面沒法提供請求的範圍，則服務器會返回此狀態代碼。
417（未知足指望要求）	服務器未知足」指望」請求標頭字段的要求。

 

 

5xx （服務器錯誤） 
這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤多是服務器自己的錯誤，而不是請求出錯。

 

 

代碼 說明

500（服務器內部錯誤）	服務器遇到錯誤，沒法完成請求。
501（還沒有實施）	服務器不具有完成請求的功能。 例如，服務器沒法識別請求方法時可能會返回此代碼。
502（錯誤網關）	服務器充當網關或代理，從上游服務器收到無效響應。
503（服務不可用）	服務器目前沒法使用（因爲超載或停機維護）。 一般，這只是暫時狀態。
504（網關超時）	服務器充當網關或代理，但沒有及時從上游服務器收到請求。
505（HTTP 版本不受支持）	服務器不支持請求中所用的 HTTP 協議版本。

 

 

英文版：

100：Continue
101：Switching Protocols
102：Processing

200：OK
201：Created
202：Accepted
203：Non-Authoriative Information
204：No Content
205：Reset Content
206：Partial Content
207：Multi-Status

300：Multiple Choices
301：Moved Permanently
302：Found
303：See Other
304：Not Modified
305：Use Proxy
306：(Unused)
307：Temporary Redirect

400：Bad Request
401：Unauthorized
402：Payment Granted
403：Forbidden
404：File Not Found
405：Method Not Allowed
406：Not Acceptable
407：Proxy Authentication Required
408：Request Time-out
409：Conflict
410：Gone
411：Length Required
412：Precondition Failed
413：Request Entity Too Large
414：Request-URI Too Large
415：Unsupported Media Type
416：Requested range not satisfiable
417：Expectation Failed
422：Unprocessable Entity
423：Locked
424：Failed Dependency

500：Internal Server Error
501：Not Implemented
502：Bad Gateway
503：Service Unavailable
504：Gateway Timeout
505：HTTP Version Not Supported
507：Insufficient Storage

200號狀態碼

220.181.32.30 - - [02/Sep/2008:00:01:23 +0800] "GET /article/0572/72570.shtml HTTP/1.1" 200 28361 "-" "Baiduspider+(+http://www.baidu.com/search/spider.htm)"

服務器日誌中的200表示使用GET傳遞方式網頁72570.shtml下載成功。即：當用戶或爬蟲程序向網站服務器發出瀏覽請求時，服務器返回 HTTP 數據流裏包含某種狀態碼，200響應號即狀態碼中的一種，表示本網頁被成功下載。

301號狀態碼

220.181.32.30 - - [02/Sep/2008:00:01:31 +0800] "GET /my/view.php?aid=14183 HTTP/1.1" 301 - "-" "Baiduspider+(+http://www.baidu.com/search/spider.htm)"

服務器日誌中的301表示使用GET傳遞方式動態網頁aid=14183成功跳轉。即：當用戶或爬蟲程序向網站服務器發出瀏覽請求時，服務器返回 HTTP 數據流包含某種狀態碼，301 重定向即狀態碼中的一種，表示本網頁永久性轉移到另外一個地址。實際操做中咱們能夠將多個域名指向同一個網址，這也是搜索引擎惟一承認的一種網站轉向的方式。

 

 

2、404狀態碼

 

220.181.32.30 - - [02/Sep/2008:00:01:51 +0800] "GET /writing HTTP/1.1" 404 4459 "-" "Baiduspider+(+http://www.baidu.com/search/spider.htm)"

 

出現404狀態碼就證 明有URL地址的網頁瀏覽不到。不少時候因爲網站的改版，使不少舊版網站url地址失效。這是你須要創建404狀態頁來保證你網站通暢，可以達到一種迴路 的效果。切記404狀態頁須要單獨設計，不能直接在服務器端直接跳轉回首頁。不然，搜索引擎會大量抓取網站首頁失誤當成404頁處理。

 

對HTTP404狀態碼的深度理解

 

HTTP 404 錯誤意味着連接指向的網頁不存在，即原始網頁的URL失效，這種狀況常常會發生，很難避免，好比說：網頁URL生成規則改變、網頁文件改名或移動位置、導 入連接拼寫錯誤等，致使原來的URL地址沒法訪問；當Web 服務器接到相似請求時，會返回一個404 狀態碼，告訴瀏覽器要請求的資源並不存在。可是，Web服務器默認的404錯誤頁面，不管Apache仍是IIS，均十分簡陋、呆板且對用戶不友好，沒法 給用戶提供必要的信息以獲取更多線索，無疑這會形成用戶的流失。

 

所以，不少網站均使用自定義404錯誤的方式以提供用戶體驗避免用戶流失。通常而言，自定義404頁面通用的作法是在頁面中放置網站快速導航連接、搜索框以及網站提供的特點服務，這樣能夠有效的幫助用戶訪問站點並獲取須要的信息。

HTTP404對SEO的影響

 

自 定義404錯誤頁面是提供用戶體驗的很好的作法，但在應用過程當中每每並未注意到對搜索引擎的影響，譬如：錯誤的服務器端配置致使返回「200」狀態碼或自 定義404錯誤頁面使用Meta Refresh致使返回「302」狀態碼。正確設置的自定義404錯誤頁面，不只應當可以正確地顯示，同時，應該返回「404」錯誤代碼，而不是 「200」或「302」。雖然對訪問的用戶而言，HTTP狀態碼到底是「404」仍是「200」來講並無什麼區別，但對搜索引擎而言，這則是至關重要 的。

 

1.自定義404錯誤頁返回「200」狀態碼

 

當搜索引擎蜘蛛在請求某個URL地址獲得「404」狀態迴應時，即知道該 URL地址已經失效，便再也不索引該網頁，並向數據中心反饋將該URL地址表示的網頁從索引數據庫中刪除，固然，刪除過程有可能須要很長時間；而當搜索引擎 獲得「200」狀態迴應時，則會認爲該url地址是有效的，便會去索引，並會將其收錄到索引數據庫，這樣的結果即是這兩個不一樣的url地址具備徹底相同的 內容：自定義404錯誤頁面的內容，這會致使出現複製網頁問題。對搜索引擎而言，特別是Google，不但很難得到信任指數TrustRank，也會大大 下降Google對網站質量的評定。

 

在使用Google Sitemap，當提交XML格式網站地圖文件時，谷歌管理員工具會驗證網站的身份以確保是網站合法的管理者。驗證方式有兩種：上傳指定名稱的html頁 到網站根目錄或者在網頁meta區域添加一個標識身份的meta標籤。一般是使用上傳html網頁的方式，但谷歌管理員工具卻提示網站根目錄下找不到這個 網頁，這是一個很可怕的問題。

 

 

2.自定義404錯誤頁使用Meta Refresh返回「302」狀態碼

 

經常看到許多網站的 自定義404錯誤頁面採起相似這樣的形式：首先顯示一段錯誤信息，而後，經過Meta Refresh將頁面跳轉到網站首頁、網頁地圖或其餘相似頁。根據具體實現方式不一樣，這類404頁面可能返回「200」狀態碼，也可能返回「302」，但 不論哪一種，從SEO技術角度看，均不是一種合適的選擇。

 

對「200」狀態的狀況咱們上面已經談過，那麼，當404頁面返回「302」時，搜 索引擎會怎麼對待呢?從理論上說，對「302」錯誤，搜索引擎認爲該網頁是存在的，只不過臨時改變了地址，仍然會索引收錄該頁，這樣，一樣會出現相似於 「200」狀態碼時的重複文本問題；其次，以谷歌爲表明的主流搜索引擎對302重定向的適用範圍要求愈來愈嚴格，這類不當使用302重定向的狀況存在很大 的風險。

 

確保自定義404錯誤頁面可以返回「404」狀態碼

 

在自定義404錯誤頁面設置完畢後，必定要檢查一下其是否是可以正確地返回「404」狀態碼。可使用Server Header檢查工具，輸入一個不存在網頁的url，查看一下HTTP Header的返回狀況，確信其返回的是「404 Not found」。