一、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 重定向即狀態碼中的一種，表示本網頁永久性轉移到另一個地址。實際操作中我們可以將多個域名指向同一個網址，這也是搜索引擎唯一認可的一種網站轉向的方式。
二、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”。