狀態碼與 SEO，200、301、404、410、503 各自送出什麼訊號

本文重點

• 每一個網址被 Googlebot 抓取時都會拿到一個 HTTP 狀態碼，這個三位數字直接決定該頁面會被索引、被丟棄、還是被暫時擱置，是技術 SEO 最底層的訊號。
• 最危險的不是明確的 404，而是「回 200 卻沒有內容」的 Soft 404、以及把暫時故障設成永久狀態碼的誤用——它們會悄悄吃掉爬取預算又不報錯。
• 404 與 410 的差別、503 維護模式的 Retry-After、307 與 308 的「不可竄改」特性，都是中階實務者最常設錯的地方，本文用對照表逐一拆解。
• 整站健檢要先用工具批次抓全站狀態碼，再依「流量 × 連入連結 × 重要性」三軸排序修復順位，而不是看到紅字就埋頭亂修。

當你打開 Google Search Console 看到一堆「找不到（404）」「軟性 404」「伺服器錯誤（5xx）」的報表，卻不知道哪個該優先處理時，問題的根源往往在於沒搞懂 HTTP 狀態碼 在 SEO 裡到底代表什麼訊號。狀態碼是瀏覽器與 Googlebot 每抓一個網址就會收到的一組三位數回應，它不只是給工程師看的除錯訊息，更是搜尋引擎判斷「這頁要不要收進索引、要不要繼續來爬」的第一手依據。這篇文章會把 2xx、3xx、4xx、5xx 四大類一次講完，幫你建立一張完整的狀態碼地圖，知道每個數字背後 Google 會怎麼反應、你該怎麼處置。

一、HTTP 狀態碼是什麼，Google 怎麼用它決定爬取與索引

結論先說：HTTP 狀態碼是伺服器對每一次請求回傳的三位數字訊號，Googlebot 把它當成「這個網址現在的狀態」的權威宣告，並據此決定要不要索引、要不要保留、要不要再回來。換句話說，同樣一篇文章，回 200 會被收錄、回 404 會被移除、回 503 會被暫時擱置——內容沒變，狀態碼變了，命運就完全不同。

（一）狀態碼的五大分類與 SEO 速查表

HTTP 狀態碼（HTTP Status Code）依開頭數字分成五大類，每一類對搜尋引擎的意義截然不同。先用一張速查表建立全貌，後面各段再深入：

類別	範圍	中文意義	對 SEO 的核心影響
1xx	100–199	資訊回應（Informational）	過渡訊號，SEO 上幾乎不用管
2xx	200–299	成功（Success）	200 才會被正常索引，這是你想要的狀態
3xx	300–399	轉址（Redirection）	301/308 傳遞權重、302/307 暫時導向
4xx	400–499	用戶端錯誤（Client Error）	404/410 會讓頁面退出索引
5xx	500–599	伺服器錯誤（Server Error）	持續 5xx 會拖慢爬取、最終移除索引

可以看出，只有 2xx 是你希望正式內容頁長期維持的狀態；3xx 是搬家時的橋樑；4xx 與 5xx 則是要嘛刻意設定、要嘛盡快搶修的訊號。根據 MDN Web Docs 的 HTTP 狀態碼總表，完整的標準狀態碼有數十個，但對 SEO 真正有決定性影響的，集中在本文後面要拆解的那十來個。

（二）Google 看狀態碼的三個層次，索引、爬取、再訪頻率

Googlebot 拿到狀態碼後，不是只做「收或不收」的二元判斷，而是分三個層次反應：

• 索引決策：只有回 200（且內容可被算繪、未被 noindex 擋住）的頁面才有資格進入索引。回 4xx 會讓既有頁面被移出索引；回 3xx 則把索引訊號導去目標網址。
• 爬取行為：5xx 與大量逾時會讓 Googlebot 判定伺服器吃力，主動「踩煞車」放慢抓取速度，以免把你的站壓垮。這直接牽動爬取預算的分配。
• 再訪頻率：明確的 410（Gone）會讓 Google 比 404 更快停止回訪該網址；而長期穩定回 200 的重要頁面，則會被更頻繁地重新抓取。

理解這三層，你才不會把所有紅字一視同仁。Google 官方在 HTTP 與網路錯誤處理說明 中，正是依「成功、轉址、用戶端錯誤、伺服器錯誤」這個結構來定義 Googlebot 的反應，這份文件是本文最核心的官方依據。

（三）狀態碼從哪裡來，伺服器、CDN 與應用層都可能改寫

很多人以為狀態碼是「網頁設定的」，其實它可能在三個位置被決定或改寫，這也是排查問題時最容易忽略的盲點：

1. 伺服器層（Apache、Nginx）：透過 .htaccess、nginx.conf 的 rewrite 規則直接回傳。
2. CDN／反向代理層（Cloudflare 等）：邊緣節點可能在請求到達源站前就回應，例如快取命中、WAF 攔截、或源站掛掉時回 502/521。
3. 應用層（PHP、Node、CMS 外掛）：程式邏輯動態決定，例如商品下架後由後端判斷回 404 還是 200。

同一個網址在不同層被改寫，最終 Googlebot 看到的可能跟你在後台設定的不一樣。 這就是為什麼下一步驗證一定要用「實際抓取」的工具去看真實回應碼，而不是憑印象。

二、2xx 成功類，200 正常與 Soft 404 的隱形陷阱

結論先說：2xx 代表請求成功，其中你唯一需要在意的是 200 OK——它是所有想被收錄的內容頁應該回的狀態。但 2xx 真正的危險不在 200 本身，而在「明明該是錯誤頁、卻硬回 200」所造成的 Soft 404，這是 GSC 報表裡最常見也最難察覺的隱形陷阱。

（一）200 OK 是內容頁的標準狀態

200 OK 表示伺服器成功處理請求並回傳了內容。對 SEO 而言，這是文章頁、產品頁、分類頁、首頁等所有「希望被搜尋到」的網址應該長期維持的狀態。檢查重點很單純：用 GSC 的「網址檢查」工具，確認重要頁面回的是 200、而且「網頁可供索引」。

其他 2xx 在一般網站較少見：204 No Content（成功但沒內容）不該用在內容頁；206 Partial Content 多用於影音串流的分段下載，跟一般 SEO 無關。實務上你 99% 的注意力放在「該回 200 的有沒有回 200」即可。

（二）Soft 404 是什麼，為什麼比真 404 更麻煩

Soft 404（軟性 404）指的是頁面內容已經不存在或空洞，伺服器卻回傳 200 狀態碼。 最典型的就是「查無此商品，請返回首頁」這種頁面，視覺上是錯誤訊息，HTTP 卻說「一切成功」。

它比真正的 404 更麻煩，原因有三：

• 訊號自相矛盾：你告訴 Google「這頁成功（200）」，但內容卻是空的，Google 得自己猜，判斷可能出錯。
• 吃掉爬取預算：因為回 200，Googlebot 會把它當正常頁反覆回訪，等於拿你寶貴的爬取資源去抓垃圾頁。
• 稀釋網站品質訊號：大量空洞的 Soft 404 被收錄，會拉低整站的內容品質評價。

Google 在官方文件中明確指出，當系統偵測到頁面「看起來像錯誤頁但回 200」時，會在 GSC 標記為「軟性 404」並拒絕索引。常見成因包括：空的搜尋結果頁、已售完仍保留的商品頁、缺少主要內容的占位頁、以及 JavaScript 算繪失敗導致主體內容沒出來的頁面（這類問題可參考 JavaScript SEO 與算繪）。

（三）Soft 404 的正確處置決策

遇到 Soft 404，不要只是「把錯誤訊息藏起來」，而要根據頁面該有的真實命運選擇正確狀態碼：

情境	錯誤做法（造成 Soft 404）	正確處置
內容永久消失、不會再有	回 200 顯示「找不到」	回 404 或 410
內容搬到新網址	回 200 顯示「請點此」	回 301 指向新網址
商品暫時缺貨、未來補貨	回 200 但頁面空白	維持 200，保留商品資訊並標示缺貨
分頁／篩選產生的空結果頁	回 200 的空清單	回 404，或用 noindex 並檢討該頁是否該存在

關鍵心法：狀態碼要忠實反映內容的真實狀態。 內容沒了就大方回 4xx，內容搬了就回 3xx，別用 200 來「粉飾太平」。

三、3xx 轉址類，301、302、307、308 對 SEO 的差別

結論先說：3xx 是「這個網址請改去別處」的訊號。SEO 上最關鍵的是分清楚「永久 vs 暫時」與「會不會傳遞權重」——301／308 是永久、傳遞排名訊號；302／307 是暫時、原網址保留索引。本段帶過核心差異即可，轉址鏈、權重折損、跨網域 canonical 等深入實作，已另有專文，請直接參考 301、302、Canonical 怎麼選。

（一）四種轉址碼的核心差異對照

狀態碼	性質	是否傳遞權重	是否允許改 HTTP 方法	典型用途
301 Moved Permanently	永久	是（完整傳遞）	允許（POST 可變 GET）	網域搬家、HTTPS 升級、改 slug
302 Found	暫時	訊號暫留原網址	允許	短期活動導流、A/B 測試
307 Temporary Redirect	暫時	訊號暫留原網址	不允許（方法不變）	需保留請求方法的暫時導向
308 Permanent Redirect	永久	是（完整傳遞）	不允許（方法不變）	等同 301 但嚴格保留方法

簡單記法：第一位 30、看「個位數」奇偶——1（301）跟 2（302）是「舊式、允許方法改寫」；7（307）跟 8（308）是「新式、嚴格保留方法」。而判斷權重要看「永久 or 暫時」：301、308 永久，傳遞排名；302、307 暫時，Google 通常仍把原網址當主要索引對象。

（二）SEO 最常見的兩個轉址誤用

兩個踩雷高頻區，這裡先點出，細節交給專文：

• 該用 301 卻長期掛 302：網站永久搬家卻用 302，Google 會持續把舊網址留在索引、遲遲不把權重轉到新站，導致改版後排名長期不穩。
• 轉址鏈太長（A→B→C→D）：每多一跳就多一次爬取成本與權重稀釋風險，應盡量「一步到位」把所有舊網址直接指向最終目標。

Google 官方在 301 轉址與網站搬遷指南 中對永久轉址的設定與最佳實務有完整說明；若你正面臨整站改版，務必搭配 網站搬遷 SEO 檢查清單 一起規劃。

（三）3xx 與爬取預算的關係

每一次轉址都是一次額外的請求往返。當站上累積大量轉址、又疊成多層鏈時，Googlebot 抓取一個有效頁面要繞好幾圈，等於變相壓縮了真正內容頁能分到的爬取預算。因此 3xx 的健檢重點，除了「方向對不對」，還要看「有沒有可以拉直的鏈」。

四、4xx 用戶端錯誤，404 與 410 該怎麼選與處理

結論先說：4xx 代表「請求方有問題」，SEO 上最常碰到的是 404（Not Found） 與 410（Gone）。兩者都會讓頁面退出索引，差別在於 410 是更斬釘截鐵的「永久消失」訊號，Google 通常會比 404 更快停止回訪。並非所有 404 都要修，重點是分清楚「該救的」與「該讓它死的」。

（一）404 與 410 的差別與選擇

維度	404 Not Found	410 Gone
語意	找不到（原因不明，可能暫時）	確定永久消失、刻意移除
Google 反應	退出索引，但會持續回訪一段時間	退出索引，且更快停止回訪
設定成本	預設行為，幾乎免設定	需主動設定回傳 410
適用情境	一般失效網址、誤刪、未知狀況	確定永久下架且不會復活的頁面

實務上 Google 對 404 與 410 的處理結果非常接近，不必為了「410 比較快」而大費周章把所有 404 改成 410。真正值得設 410 的，是你「百分之百確定永遠不會回來」的網址，例如已停業的活動頁、確定不再販售的商品。其餘維持 404 即可。Ahrefs 在 HTTP 狀態碼與 SEO 影響的完整指南 中也整理了各狀態碼的處置建議，可作為對照參考。

（二）404 不一定是壞事，哪些該修哪些該放

一個常見誤解是「404 越少越好、看到就要修」。事實上，404 是網路的正常組成，Google 官方明確表示大量 404 本身不會傷害排名。真正該做的是分類處置：

• 該 301 救回來：有外部連結指向、或仍有自然流量的失效網址 → 301 轉到最相關的現存頁面，把權重與使用者一起接住。
• 該維持 404／410：沒人連、沒流量、內容也確實該消失的網址 → 大方讓它回 404 或 410，不要硬轉到首頁（那會被當成 Soft 404）。
• 該排查根因：站內連結自己連到 404（壞掉的內部連結）→ 這才是該優先修的，因為它浪費爬取又傷使用者體驗，可搭配 內部連結進階策略 一起盤點。

判斷「哪些 404 有外部連結」可借助 Google Search Console 的「網頁」報表與連結報表，先看哪些失效頁仍帶著價值，再決定救或不救。

（三）其他常見 4xx，403、401、429 的 SEO 意義

除了 404／410，還有幾個 4xx 偶爾會影響 SEO，整理如下：

狀態碼	意義	對 SEO 的風險
401 Unauthorized	需要驗證才能存取	正常用於後台；若誤擋公開頁會導致無法索引
403 Forbidden	禁止存取	若 WAF／防火牆誤把 Googlebot 當壞爬蟲擋掉，會讓整站無法被抓
429 Too Many Requests	請求過於頻繁	對 Googlebot 回 429 等於叫它放慢，過度觸發會壓低爬取頻率

其中 403 對 Googlebot 的誤擋最致命：當伺服器安全設定或 CDN 規則把 Googlebot 的 User-Agent 或 IP 當成惡意流量封鎖，頁面對使用者正常、對 Google 卻全回 403，會導致大面積掉索引卻找不到原因。驗證方式是用 GSC「網址檢查」的即時測試，看 Google 實際抓到的回應碼。若需要精準控制哪些路徑開放給爬蟲，請參考 robots.txt 完整指南 與 封鎖索引的正確方法。

五、5xx 伺服器錯誤，503 維護模式與爬取預算的關係

結論先說：5xx 代表「伺服器自己出問題」，對 SEO 最危險的是它會讓 Googlebot 判定你的站不穩，主動放慢甚至暫停抓取。短暫 5xx 影響不大，但持續數天的 5xx 會讓頁面陸續掉出索引。其中 503（Service Unavailable）是唯一你應該「主動、刻意」使用的 5xx——它是維護或暫時超載時的正確姿勢。

（一）500、502、503、504 的差異與 Google 反應

狀態碼	意義	典型成因	Googlebot 反應
500 Internal Server Error	伺服器內部錯誤	程式 bug、設定錯誤	視為臨時錯誤，放慢爬取；持續則移除索引
502 Bad Gateway	閘道收到無效回應	反向代理／源站溝通失敗	同上，判定伺服器不穩
503 Service Unavailable	服務暫時無法使用	維護中、流量超載	理解為「暫時」，會稍後重試（建議搭配 Retry-After）
504 Gateway Timeout	閘道逾時	源站回應太慢	視為效能問題，放慢爬取

關鍵差別：500／502／504 是「非預期故障」，要當緊急事件搶修；而 503 是「我知道，這是暫時的」，是唯一可以「計畫性」回傳的 5xx。Google 官方在 HTTP 與網路錯誤說明 中明確指出，遇到 5xx 時 Googlebot 會暫時降低抓取速度，若錯誤持續才會逐步將網址移出索引。

（二）維護模式的正確做法，503 加上 Retry-After

當你要進行網站維護、改版部署、或預期短時間大流量時，正確做法是讓全站（或受影響頁面）回傳 503，並加上 Retry-After 標頭告訴 Googlebot 多久後再來：

• 回 503 而非 200：千萬別在維護時讓 Googlebot 抓到一個「維護中」卻回 200 的頁面，那會被當成正式內容索引，或變成 Soft 404。
• 加上 Retry-After：可填秒數（如 Retry-After: 3600）或明確時間，讓 Google 知道這是暫時的、稍後再回訪，避免它急著把你的頁面移出索引。
• 維護要短：503 適合「幾小時到一兩天」的短期維護。若一個重要頁面連續多天回 503，Google 仍會開始將它降級、移出索引。

這套「503 + Retry-After」是業界公認的維護期 SEO 標準動作，能讓你安全地停機而不傷排名。

（三）5xx 與爬取預算、索引穩定度的連鎖反應

5xx 對 SEO 的傷害往往是「連鎖」而非「單點」：

1. 爬取速度被踩煞車：Googlebot 偵測到 5xx 增加，會主動降低抓取頻率以免壓垮伺服器，於是新內容被發現得更慢。
2. 爬取預算被浪費：本來該拿去抓有效頁的請求，撞上一堆 5xx 等於空轉，對大型站尤其傷，這也是 爬取預算優化 一定要監控伺服器穩定度的原因。
3. 索引逐步流失：短暫 5xx 無妨，但持續性 5xx 會讓 Google 認定頁面長期不可用，分批移出索引，等伺服器恢復後還要花時間重新被收錄。

因此 5xx 的監控重點不只是「現在有沒有」，而是「持續多久、涵蓋多廣」。偶發的單頁 5xx 可以排程修，但「全站 5xx 飆升」必須當成 P0 事故立刻處理。

六、用工具批次檢查整站狀態碼並排序修復優先順序

結論先說：別靠人工一頁頁點。整站狀態碼健檢的正確流程是「批次抓全站回應碼 → 分類 → 依價值排序 → 依優先序修復」。看到一堆紅字先不要慌，修復順序應由「流量 × 連入連結 × 頁面重要性」決定，而不是由錯誤數量決定。

（一）抓取整站狀態碼的三種資料來源

要拿到「全站每個網址現在回什麼碼」，主要有三種互補的來源：

資料來源	能看到什麼	適合場景
Google Search Console「網頁」索引報表	Google 實際遇到的 404／Soft 404／5xx／已排除原因	最權威，反映 Google 視角，免費首選
桌面型爬蟲（如 Screaming Frog）	全站每個 URL 的即時回應碼、轉址鏈、連入連結	主動全站健檢、找轉址鏈與內部壞連結
伺服器日誌（Log File）	Googlebot 真實抓到的每一筆回應碼與頻率	進階分析爬取預算與 5xx 實際衝擊

最佳組合是「GSC 看 Google 觀點 + 爬蟲做主動全站掃描 + Log 驗證真實爬取」。一般網站先把前兩者做好就能解決九成問題；大型站才需要動用 Log 分析。GSC 的設定與報表判讀，可參考 Google Search Console 完整指南；而 Sitemap 實作與提交 則能幫你確保提交給 Google 的網址清單本身就乾淨、回正確狀態碼。

（二）狀態碼分類與處置決策矩陣

抓到全站資料後，套用這張決策矩陣快速分流，避免逐頁糾結：

抓到的狀態	第一步判斷	處置
200 但內容空洞	是否 Soft 404？	補內容、改 404/410、或 noindex
301／302	永久還暫時？鏈太長？	永久搬家改 301、拉直轉址鏈
404	有外部連結／流量嗎？	有→301 接住；無→維持 404
410	確定永久消失？	是→保持；否→應為 404
403／401	是否誤擋 Googlebot？	是→放行爬蟲；否→正常後台略過
5xx	單頁偶發 vs 全站持續？	全站→P0 搶修；維護→改 503+Retry-After

這張矩陣的價值在於「把模糊的紅字變成明確的動作」——每個狀態碼都對應一個清楚的下一步，不再憑感覺亂修。

（三）排序修復優先順序的三軸法則

當清單上有幾百個待處理項目，用這三軸決定誰先誰後：

1. 頁面重要性（業務價值）：首頁、主力產品頁、高轉換頁、核心 pillar 文章出問題，永遠最優先。
2. 連入連結（外部與內部）：被很多外部網站連、或站內被大量連的失效頁，修好能立刻挽回權重與流量。
3. 流量規模：曾經帶來可觀自然流量、近期才掉的網址，CP 值最高。

把三軸交叉，最該先修的是「高重要性 × 有連入連結 × 曾有流量」的頁面；而「沒人連、沒流量、本來就該死」的 404 則可以放到最後、甚至不處理。修復不是把報表清成零，而是把資源投到最有回報的地方。

完成首輪修復後，記得回 GSC 的對應報表點「驗證修正」，讓 Google 重新檢查；並把整站狀態碼健檢排進固定的技術 SEO 巡檢週期，而不是等出事才看。

七、常見問題 FAQ

（一）網站維護時應該回 503 還是直接讓頁面變成 404？

維護時應該回 503（Service Unavailable）並搭配 Retry-After 標頭，絕對不要讓頁面變 404 或維持 200。503 是在告訴 Googlebot「服務暫時無法使用、稍後請再來」，它會暫緩抓取而不急著把頁面移出索引；Retry-After 則進一步告知大約多久後恢復。反觀若回 404，Google 會以為頁面已不存在而開始移除索引；若維護頁回 200，又會被當成正式內容索引或被判為 Soft 404。記得 503 只適合短期維護，連續多天回 503 一樣會傷到索引。

（二）Soft 404 要怎麼找出來並修掉？

最快的方式是在 Google Search Console 的「網頁」索引報表中，篩選「軟性 404（Soft 404）」這個排除原因，Google 會列出所有它判定為 Soft 404 的網址。找到後逐一判斷該頁的真實命運：內容永久消失就改回真正的 404 或 410；內容已搬家就設 301 指向新網址；若是商品暫時缺貨，則保留商品資訊、維持 200 並標示缺貨，而不是顯示空白或「查無資料」。核心原則是讓狀態碼忠實反映內容狀態，不要用 200 去掩蓋一個其實沒有內容的頁面。

（三）301 和 308、302 和 307 到底差在哪，我該用哪個？

差別在兩個維度：「永久 vs 暫時」和「是否允許改變 HTTP 請求方法」。301 與 308 都是永久轉址、會完整傳遞排名訊號，差別只在 308 嚴格保留原本的請求方法（POST 仍是 POST），301 則允許轉成 GET。302 與 307 都是暫時轉址、原網址保留索引，同樣差在 307 嚴格保留方法。對一般網頁 SEO 來說，永久搬家用 301、短期導流用 302 就足夠；只有在處理表單提交、API 等「方法不能被竄改」的情境，才需要特別用 308 或 307。轉址鏈拉直、跨網域權重等深入細節，請見 301、302、Canonical 怎麼選。

（四）站上有幾百個 404，會不會害我排名下降？

單純存在大量 404 不會直接害排名下降，Google 官方多次說明 404 是網路的正常現象，沒人連、沒流量的失效頁回 404 完全沒問題，不必硬轉到首頁（硬轉反而會製造 Soft 404）。真正要處理的是兩種 404：一是「有外部連結或仍有自然流量」的失效頁，應該 301 轉到最相關的現存頁面把價值接住；二是「站內自己連到 404」的壞掉內部連結，它浪費爬取又傷使用者體驗，應優先修正。換句話說，重點不是把 404 數字清成零，而是分辨哪些 404 帶著價值、哪些單純是雜訊。

（五）為什麼我的頁面對使用者正常，Google 卻說抓到 403 或 5xx？

最常見的原因是「使用者與 Googlebot 拿到的回應不一樣」。403 多半是伺服器安全設定、CDN 或防火牆（WAF）把 Googlebot 的 User-Agent 或 IP 誤判為惡意爬蟲而封鎖；5xx 則可能是 Googlebot 集中抓取時段觸發了源站超載或逾時，而你人工瀏覽時剛好沒撞上。驗證方法是用 GSC「網址檢查」的即時測試，看 Google 實際抓到的狀態碼與算繪結果，而不是只用自己的瀏覽器判斷。確認是誤擋後，請在伺服器或 CDN 規則中放行 Googlebot，並用 robots.txt 完整指南 檢查是否有路徑被錯誤封鎖。

（六）整站狀態碼多久該檢查一次？

建議把整站狀態碼健檢排進「固定週期 + 事件觸發」兩種節奏。固定週期上，一般中小型網站每季用爬蟲做一次全站掃描、每月看一次 GSC 的「網頁」索引報表變化即可；流量大或更新頻繁的站可拉高到每月全站掃描。事件觸發上，只要遇到網站改版、搬遷、CMS 升級、更換 CDN 或伺服器、或 GSC 突然出現 5xx／Soft 404 飆升，就要立刻做一次針對性檢查。關鍵不是檢查得多勤，而是在大改動前後務必驗證，因為狀態碼問題最常在這些時間點被引入。