HTTP 狀態碼完整指南：SEO 必懂 7 個代碼與 404 處理

HTTP 狀態碼是什麼？五大類別怎麼分

HTTP 狀態碼是伺服器回應每一次請求時附帶的三位數代碼，定義在 IETF 的 HTTP 標準（目前版本為 RFC 9110）。第一個數字代表類別，後兩碼是細項。對一般使用者來說，只有 404 這種錯誤頁面才會被看到；但對 Googlebot、Bingbot 以及 OAI-SearchBot 這類 AI 爬蟲來說，每一個網址的每一次抓取都會先讀狀態碼，再決定後續動作。

五大類別記住之後，日常維運真正會碰到的其實只有一小撮。下一節先把 SEO 人員必懂的 7 個狀態碼列成一張總表，後面再逐一說明判斷邏輯。狀態碼與網址結構、轉址、Canonical 三者環環相扣，若您想先建立整體框架，可以先讀本站的〈技術 SEO 完整指南〉，再回來看本文的細節。

SEO 必懂的 7 個狀態碼總覽

以下 7 個狀態碼涵蓋了 Search Console「網頁索引」報告裡九成以上的問題來源。先分清楚每個代碼「對使用者」與「對搜尋引擎」分別代表什麼，才不會把該用 301 的地方寫成 302，或把該回 404 的頁面硬撐成 200。

200 與 304：正常回應也有 SEO 細節

200 是最單純的狀態碼，代表伺服器順利回傳內容。但「回 200」不等於「內容沒問題」：如果一個網址回 200，頁面上卻只有「查無資料」「此商品已下架」這類文字，或是整頁幾乎空白，Google 會把它判定為軟性 404（Soft 404），效果跟真的 404 一樣會被移出索引，卻更難在報表裡被發現。這部分在第六節詳談。

304 則是常被忽略的效率工具。Googlebot 再次抓取已收錄的網頁時，會帶著 If-Modified-Since 標頭詢問「上次抓取之後有沒有改過」；如果伺服器判斷內容未變，直接回 304 並且不傳內容，爬蟲就沿用舊版本。對於文章數量多、更新頻率低的網站，正確支援 304 可以把有限的檢索預算留給真正有更新的頁面。多數主機與 CMS 預設就會處理，您只需要確認沒有被快取外掛或 CDN 設定破壞。

301 與 302：永久搬家還是暫時外出

兩者都是把使用者與爬蟲送到另一個網址，差別在「原網址還會不會回來」。依 Google 官方〈重新導向與 Google 搜尋〉文件，301 與 308 屬於永久重新導向，是很強的訊號，告訴 Google 新網址才是規範網址（canonical），應該把索引與排名訊號集中到新網址；302、303、307 屬於暫時重新導向，訊號較弱，Google 通常會繼續把原網址視為規範網址。

• 原網址永久退役，用 301 HTTP 升級 HTTPS、更換網域、拿掉網址結尾的 .html、把兩篇重複內容合併成一篇，這些情境的原網址都不會再用，應該用 301 把權重完整交給新網址。
• 原網址還會恢復，用 302 週年慶活動頁在活動結束後暫時導回分類頁、A/B 測試期間把部分流量導到測試版、依使用者地區暫時導向不同語系頁，這些情境結束後原網址會恢復服務，才用 302。
• 保留 301 至少一年 Google 建議永久重新導向至少維持一年，讓所有訊號完成轉移；實務上只要舊網址還有外部連結指向，就不要拆掉。

最常見的錯誤是「保守起見先用 302」。工程師擔心 301 會被瀏覽器永久快取、日後改不回來，於是一律用 302；結果網站升級 HTTPS 幾個月後，Search Console 裡規範網址還是 HTTP 版本，新版排名遲遲上不去。另一個常見錯誤是轉址鏈：舊網址 A 轉到 B，B 又轉到 C。Googlebot 最多追蹤 10 跳，超過就在 Search Console 顯示「重新導向錯誤」；即使沒超過，每多一跳都是額外延遲。改版時請直接把 A 指到最終目標 C。轉址的實作方式與 .htaccess 寫法，請見本站的〈301、302 轉址完整教學〉。

404 與 410：不必全部修掉，但要分類處理

每個經營超過一年的網站都會有 404，這是正常現象，Google 也明確表示 404 本身不會拉低整個網站的評價。真正的問題不是「有 404」，而是有價值的網址在回 404：過去有排名、有外部連結、有流量的頁面，因為改版、換系統或商品下架而消失，卻沒有把訪客與權重接住。

處理 404 的步驟很固定，重點在分類，不在數量：

• 列出清單 到 Google Search Console 的「網頁索引」報告，篩選「找不到（404）」，匯出所有網址；再對照 GA4 的過往流量與反向連結工具的外部連結資料。
• 有價值的網址用 301 導向最相關的頁面 舊商品頁導向同系列的新商品或該分類頁，舊文章導向改寫後的新文章。關鍵是「主題相關」，不是「隨便找一頁接住」。
• 沒有價值的網址讓它維持 404 機器人亂掃的網址、從未存在過的路徑、測試用網址，保留 404 即可。把這些也拿去 301，只是製造更多無意義的轉址。
• 做一個真正有用的 404 頁 放搜尋框、熱門文章、主要分類入口與回首頁按鈕，並且確認這個頁面本身回的是 404 狀態碼，不是 200。

410 與 404 的差別在語意：404 是「找不到」，沒有說明原因；410 是「曾經存在，現已永久移除」。Google 官方文件把兩者的處理方式列為相同，都會把網址移出索引，所以不用擔心選錯會被扣分。410 的價值在於意圖明確：確定不會再上架的商品、已停辦的活動、決定永久刪除的舊文，用 410 可以清楚告訴所有爬蟲不必再回來確認。電商網站的下架商品該用 301 還是 410，本站另有專文〈缺貨與下架商品的 SEO 處理〉討論判斷流程。

軟性 404：回 200 卻沒有內容的隱形問題

軟性 404 是 Google 自己定義的狀態：伺服器回傳 200，但 Google 判斷頁面實際上是「找不到內容」。三種最常見的成因：

• CMS 或購物車系統把不存在的商品、文章網址都渲染成一個「查無資料」的正常頁面，狀態碼仍是 200。
• 為了「不要有 404」，把所有失效網址一律 301 導回首頁。Google 文件明確把「導向無關頁面（例如首頁）」列為軟性 404 的成因之一。
• 頁面主要內容載入失敗或幾乎空白，只剩導覽列與頁尾。

軟性 404 的傷害在於它不會出現在伺服器日誌的錯誤裡，工程師看不到、監控工具也不會警示，只有 Search Console 的「網頁索引」報告會標出「軟性 404」。修法很直接：讓不存在的網址真的回 404 或 410；有替代內容的網址才做 301，而且要導到主題相關的頁面。如果同一份內容因為參數、大小寫或結尾斜線產生多個網址版本，那不是 404 的問題，而是重複內容與 Canonical 標記要處理的範圍。

5xx 與 429：伺服器出錯時 Google 怎麼反應

5xx 代表問題在伺服器端。500 是通用的內部錯誤，502 與 504 通常是反向代理或後端逾時，503 則是「暫時無法服務」。Google 對 5xx 的反應分兩段：短期內 Googlebot 會自動放慢檢索速度，避免加重伺服器負擔；若同一批網址持續多日都回 5xx，Google 會開始把它們從索引移除，直到重新抓到 200 才會回來。

所以網站維護時，正確做法是回 503 並附上 Retry-After 標頭，告訴爬蟲「幾秒或幾小時後再來」。千萬不要在維護期間回 200 加一頁「系統維護中」，那會讓 Google 把維護頁當成每一個網址的新內容；也不要回 404，那等於宣告全站內容不存在。維護頁本身應該是一個獨立的 503 回應，而不是把所有網址 302 到某個 /maintenance 頁。

429 Too Many Requests 屬於 4xx，但 Google 把它視為伺服器負載過重的訊號，處理方式跟 5xx 一樣是放慢檢索。如果您的主機商或防火牆對爬蟲設了過嚴的頻率限制，Search Console 的「檢索統計資料」會看到大量 429，這時該調整的是防火牆規則，而不是 robots.txt。主機穩定度與回應時間對狀態碼的影響，可以參考本站〈網站主機選擇指南〉。

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600"

上面的範例讓維護人員自己的 IP 仍可正常瀏覽，其他所有請求回 503 並建議一小時後重試。維護結束記得移除規則，並在 Search Console 用「網址檢查」抽測幾個重要頁面確認回到 200。

AI 搜尋時代：狀態碼如何影響被 AI 引用

ChatGPT 搜尋、Perplexity、Google AI Overviews 這些 AI 引擎，取得網頁內容的方式和傳統搜尋引擎沒有本質差異：都是 HTTP 客戶端，發出請求、讀狀態碼、再決定要不要處理內容。差別在於它們對錯誤的容忍度更低，而且沒有像 Google 那樣長達多年的歷史索引可以「先撐一下」。

• 404 與 5xx 直接等於零：AI 引擎在回答問題的當下即時抓取來源，抓不到內容就換下一個網站，您的頁面不會出現在引用清單裡。
• 轉址鏈會被放棄：使用者觸發型的 AI 抓取通常有嚴格的時間限制，多跳轉址或慢速回應很容易讓它放棄，即使 Google 那邊排名正常。
• 誤把 AI 爬蟲當攻擊：不少主機的防火牆會對 OAI-SearchBot、PerplexityBot 這類新爬蟲回 403 或 429。這不是 robots.txt 的問題，要從主機或 CDN 的存取規則解決。哪些 AI 爬蟲該放行、哪些該擋，請見〈AI 爬蟲完整清單與 robots.txt 設定〉。
• 軟性 404 同樣有效：回 200 但內容是「查無資料」的頁面，AI 引擎讀進去只會得到一句沒有意義的文字，自然不會拿來引用。

如何檢查網站的狀態碼：4 種免費工具

• Google Search Console 「網頁索引」報告依狀態碼分類列出未收錄原因（404、軟性 404、重新導向錯誤、伺服器錯誤），「網址檢查」可以即時抓取單一網址看 Google 實際拿到什麼。這是唯一能看到「Google 怎麼判定」的工具，其他工具只能看到伺服器回了什麼。
• 瀏覽器開發者工具 在 Chrome 按 F12 開啟 Network 分頁後重新整理，第一列就是該網址的狀態碼；勾選「Preserve log」可以看到轉址鏈的每一跳。適合單頁除錯。
• 命令列 curl 最不受快取干擾的方法。curl -I 只取標頭不下載內容，-L 會跟著轉址走，搭配起來可以一次看完整條轉址鏈。
• 網站爬蟲工具 Screaming Frog SEO Spider 免費版可抓 500 個網址，會列出全站每個內部連結的目標狀態碼與轉址鏈，是改版前後最有效率的全站檢查方式。線上工具如 httpstatus.io 則適合一次貼上幾十個網址快速批次檢查。

curl -sIL https://newscan.com.tw/all-seo/seo-guide.htm | grep -i "^HTTP\|^location"

HTTP/1.1 301 Moved Permanently
Location: https://www.newscan.com.tw/all-seo/seo-guide.htm
HTTP/1.1 301 Moved Permanently
Location: https://www.newscan.com.tw/seo/seo-guide.htm
HTTP/1.1 200 OK

上面這條實際指令示範了一個「兩跳」轉址：沒有 www 的舊網址先被導到 www 版本，再被導到新資料夾。兩跳在 Google 的 10 跳上限之內，可以運作，但如果外部連結大量指向舊網址，把第一條規則直接指到最終網址會更乾淨。

本站實例：三個從連結盤點裡抓出來的狀態碼問題

以下是我們在 2026 年維護本站時實際處理過的三個案例。它們都不是伺服器故障，而是網址與連結管理上的疏忽，也正是多數中小企業網站最常見的狀態碼問題型態。

• 資料夾改名後的 301 接手 2026 年 5 月我們把 SEO 專欄的實體資料夾從 all-seo 改名為 seo，所有文章網址跟著改變。處理方式是在 .htaccess 用一條規則把整個 /all-seo/ 路徑 301 到 /seo/，並保留至今；同年 6 月又把幾篇與 SEO 專欄同題的舊部落格短文 301 到對應的正本，讓重複主題的權重收斂到一頁。這兩批規則必須放在 CMS 的萬用改寫規則之前，否則舊網址會先被 CMS 接走而回 404。
• 大小寫不同的網址變體 2026 年 9 月盤點全站內部連結時，我們發現有兩篇文章連到同一個網址，但其中一個網址的路徑帶了一個大寫字母。因為 Apache 改寫規則設了不分大小寫，兩個網址都回 200，等於同一份內容有兩個網址版本。Canonical 標記讓 Google 沒有把它們當成重複頁，但我們仍把連結統一為小寫，避免日後在其他工具中被視為兩個網址。
• 從未存在的目標網址 同一次盤點也抓到兩篇演算法更新文章的「延伸閱讀」指向一個從沒建立過的網址，回 404 已有兩個月。這種 404 不會出現在伺服器錯誤日誌，因為對伺服器來說它只是一個正常的「找不到」；只有把內部連結整批比對資料庫才會浮現。修法是把連結改到實際存在的文章，並把「內部連結目標全部回 200」列入每季檢查。

三個案例的共同點：狀態碼問題多半不是主機出事，而是網址搬動、改名、寫錯之後沒有人回頭檢查。把檢查動作制度化，比事後補救便宜太多。完整的檢查項目可以併入本站的〈SEO 檢核清單與長期維運〉一起執行。

限制與例外

• 狀態碼不是排名因素：正確的狀態碼只是讓網頁「有資格」被索引與引用，不會直接提升排名。把 302 全改成 301 不會讓網站變強，只會讓權重不再流失。
• Google 的處理有時間差：404 網址從索引消失、301 目標網址取代舊網址，都需要多次重新抓取才會完成，快則數天、慢則數週，視網站的檢索頻率而定。
• 本文以 Google 官方文件為主：Bing、以及各 AI 引擎對 3xx 與 5xx 的細部處理可能不同，也未必公開文件；本文對 AI 引擎的說明以「它們同為 HTTP 客戶端」的一般原則為基礎。
• CDN 與快取層可能改寫狀態碼：Cloudflare 等服務在來源伺服器出錯時可能回自己的 5xx 錯誤頁，或在快取命中時回 200 而隱藏來源的問題。檢查時請同時看來源伺服器與 CDN 兩端。

結論與行動清單

HTTP 狀態碼是搜尋引擎與 AI 引擎認識您網站的第一句話。說對了，內容才有機會被讀、被收錄、被引用；說錯了，再好的內容都到不了對方手上。以下清單可以直接拿去執行：

• 在 Search Console「網頁索引」報告確認沒有「重新導向錯誤」「伺服器錯誤」與「軟性 404」三類問題。
• 所有永久搬移的網址使用 301，並且直接指向最終目標，不留轉址鏈。
• 有流量、有外部連結的 404 網址導向主題相關頁面；其餘 404 保留，並確認 404 頁本身回 404。
• 確定永久移除的內容改回 410。
• 維護期間回 503 加 Retry-After，不回 200 或 404。
• 檢查主機或 CDN 防火牆沒有對主要 AI 爬蟲回 403 或 429。
• 改版或搬移後一週內，用 curl 或爬蟲工具抽測重要網址的完整轉址鏈。

狀態碼只是技術 SEO 的其中一環。網址結構、Sitemap、robots.txt 與 Canonical 如何一起運作，請回到本站的〈搜尋引擎優化完整指南〉，從整體架構往下看。

常見問答 FAQ