404 頁面設計：狀態碼、轉址與錯誤頁導覽指南
分清正常下架、網址搬移、設定錯誤與 Soft 404，選擇適當狀態碼及轉址，再按網站任務配置錯誤頁導覽與 WordPress 範本。
本頁目錄
- 把 404 想成臨時櫃台，不是一道死巷
- 先盤點，再動手：你的網站到底藏了多少 404
- 四種 404，四種完全不同的處方
- 第一種：網址改過了（URL 結構變更）
- 第二種：頁面真的刪掉了（內容下架）
- 第三種：外部連結打錯或舊連結失效
- 第四種：程式或設定錯誤
- Soft 404：畫面與回應狀態不一致時怎麼查
- 404 頁面可評估的五種元件
- 元件一：一句清楚的說明，承認發生了什麼
- 元件二：一條回家的路
- 元件三：少量相關的下一步
- 元件四：一個不破壞氣氛的行動呼籲
- 元件五：品牌一致性，不要讓訪客覺得走錯了站
- 狀態碼要符合資源的實際情況
- 轉址、重建還是放生？一張決策表幫你果斷抉擇
- WordPress 與常見架站平台的 404 實作清單
- 五步行動方案，本週就能上手的 404 搶救計畫
404 頁面設計要同時處理兩件事：讓訪客知道原本的內容找不到，並讓伺服器回傳符合資源情況的 HTTP 狀態。畫面可以保留網站識別、搜尋或相關導覽，狀態碼則應與網址的實際用途一致。
先確認失效網址屬於搬移、下架、外部錯連或系統設定問題，再決定恢復內容、永久轉址或保留 404。完成這一步，才安排錯誤頁上的下一個操作入口。
本文依序整理 404 的盤點方式、轉址判斷、Soft 404 檢查與 WordPress 範本設定，最後提供手機與鍵盤操作的驗收清單。
把 404 想成臨時櫃台，不是一道死巷
404 表示伺服器沒有找到該資源，並不一定代表程式壞掉；已移除且沒有替代內容的網址也可能正確回傳 404。處理時先分清應恢復的內容與應保留的錯誤回應。
可以把錯誤頁當成服務台：先交代目前找不到內容，再提供與原本需求相關的去處。若網站沒有足夠資訊判斷訪客要找什麼，提供可用的搜尋、分類或求助入口即可。
錯誤頁的導覽成效，可以觀察訪客是否找到其他內容或完成原本任務。分析時將真人與機器人請求分開，並留意進入來源；停留時間與跳出率不能直接換算成 Google 的網站品質評分。
處理順序是先修復本來應該有效的網址與錯誤內鏈，再改善正常 404 的說明和導覽。已下架且沒有替代內容的網址，不需要為了讓報表歸零而全部轉址。
404 的實際影響要看網站紀錄，不能先假設固定比例。可先從伺服器紀錄或分析工具確認有多少真人碰到 404、從哪個頁面進入，以及是否原本帶著明確任務。若高流量入口或重要轉換路徑持續出現 404，修復與導覽設計就應列入 SEO 健檢；若是無人造訪的隨機錯誤網址，優先度自然較低。
先盤點，再動手：你的網站到底藏了多少 404
改網址、移除文章、調整分類或外部連結拼錯，都可能留下 404。盤點時保留網址、發現來源、原本用途及處理結果，之後才容易分辨新增問題與預期下架。
找 404 有三條主要路線，建議你交叉使用而不是只靠一種。
第一條是 Google Search Console（簡稱 GSC）。在 GSC 的「網頁索引」報表裡，你會看到「未找到 (404)」的區塊，列出 Googlebot 已發現並嘗試檢索的部分網址。這不代表 Google 認為它們值得索引，也不是全站 404 清冊；來源可能是舊 Sitemap、站內連結、外部連結或歷史網址。想知道怎麼操作這套工具，可以看 Google Search Console 完整教學。
第二條是伺服器或 CDN 的存取紀錄。實際能看到哪些請求，取決於紀錄位置、設定與保存範圍；其中可能同時有真人與機器人，來源頁資訊也可能缺漏。應結合狀態碼、時間與其他訊號判讀，不能把每筆紀錄都算成真人訪客。
第三條是爬蟲工具。Screaming Frog 或 Ahrefs Site Audit 可協助找出本次檢索範圍內的失效連結。登入、JavaScript、檢索限制及未被發現的頁面會影響涵蓋範圍，因此結果不等於全站所有失效網址。
左右捲動檢視完整表格
| 來源 | 可看到的範圍 | 判讀限制 |
|---|---|---|
| GSC 網頁索引 | Google 已知網址中的狀態與範例 | 不是全站清冊，也不代表每個網址重要 |
| 伺服器或 CDN 紀錄 | 有被紀錄的請求與回應 | 有機器人、來源缺漏及保存範圍限制 |
| 爬蟲工具 | 本次可發現及可檢索的連結 | 受登入、設定與渲染能力影響 |
依原本應存在的內容、使用者影響、站內連結及可用替代頁排優先順序。重要流程因設定錯誤而失效，通常應先處理；無關的隨機網址可保留正確 404。不要只憑外部工具的權重分數決定是否轉址。
這裡頭藏著一個常被看漏的 SEO 機會：處理指向失效頁面的反向連結。可交叉使用爬蟲、反向連結工具與伺服器紀錄，找出仍帶來造訪或具有相關性的失效網址；若有明確替代內容，就用 301 指向最相關的新頁面，搜尋引擎可能據此整併部分訊號，但不是保證完整轉移。相關策略可參考 反向連結建立指南。
盤點完之後，你會得到一份 404 清單。這時候千萬不要一股腦全部轉址到首頁。哪些該轉、哪些該重建、哪些其實留著就好，要看 404 的「來歷」。這就牽涉到下一節要談的分類。
四種 404，四種完全不同的處方
可依以下四類整理處理方式。相同狀態碼可能有不同原因，先確認原本應提供什麼內容，再選擇對應的修正。
第一種：網址改過了（URL 結構變更）
若網址永久移到新位置，可設定 301 或 308，並更新站內連結與 Sitemap。舊網址是否已由系統處理，需實際測試；永久轉址是 canonical 訊號，不保證固定比例的權重或流量轉移。 延伸可參考301 與 302 轉址完整教學。
第二種：頁面真的刪掉了（內容下架）
內容下架後，先判斷是否有能滿足原本需求的替代頁；有合適替代內容時可永久轉址，沒有時保留 404，或在確知永久移除時用 410。錯誤頁可提供導覽，但不應假裝資源仍存在。 延伸可參考SEO 網址優化指南。
移除商品或活動頁之前，先核對流量、內外部連結及售後需求。若原頁仍提供有用的停產資訊或支援，可以保留內容；若已永久搬移，就轉到相應頁面。分類頁只有在能實際承接原需求時才可能適合，不能因有反向連結就硬轉。沒有替代內容時，404 或 410 可以是正確結果；同時修正自己能管理的選單與內鏈。 延伸可參考網站結構與 SEO。
第三種：外部連結打錯或舊連結失效
外部網站或 AI 服務提供的連結可能拼錯或過時。若能確認其原本目的、且有正確內容可接續，可修正來源或安排轉址；不需要替每個隨機錯誤網址建立規則。應以本站紀錄判斷實際影響，不把 AI 來源當作已量測的流量趨勢。
第四種：程式或設定錯誤
rewrite、固定網址或路由設定錯誤，可能讓本來存在的文章、分類或資源回傳 404。先重現受影響範圍，修正設定並驗證內容恢復；若正式網址未改變，通常無須另加轉址。
左右捲動檢視完整表格
| 404 類型 | 成因 | 正確處方 |
|---|---|---|
| 網址改了 | URL 結構變更、改 slug | 301 永久轉址到新網址 |
| 內容刪除 | 活動過期、商品停產 | 有真正替代內容才永久轉址；否則回 404，確知永久移除可用 410 |
| 外部錯連結 | 別人拼錯網址 | 能確認原本目的且有正確內容時安排對應；隨機錯誤可保留 404 |
| 設定錯誤 | rewrite、permalink、主機設定 | 依使用者影響優先修設定，恢復本來應存在的內容 |
永久轉址的目標應能承接原本需求。已刪商品若沒有合適替代頁，可保留 404 並提供分類或搜尋連結，讓訪客自行選擇下一步；這和自動轉到不相關首頁是不同做法。
Soft 404：畫面與回應狀態不一致時怎麼查
Soft 404 是 Google 對回應的判定，常見情況是頁面顯示找不到內容，卻回傳成功狀態；導向不相關頁面也可能被如此處理。它不是實際的 HTTP 狀態碼，也不等於所有內容較少的頁面都有問題。
依Search Console 網頁索引說明，遇到 soft 404 應核對狀態碼與 Google 實際取得的畫面。確實不存在的資源需回傳適當狀態；原本應有效的頁面則要檢查內容、資源載入或渲染錯誤。
例如不存在的文章網址顯示「找不到頁面」，伺服器卻回傳 200，便可能被 Google 判為 soft 404。另一種情況是原本有效的頁面因資源載入失敗，讓 Google 取得錯誤或不完整內容；應先修復載入問題。
Soft 404 通常比正確的 404 更難診斷。真正的 404 清楚告訴 Google「這個網址不存在」，soft 404 卻讓狀態碼與畫面內容不一致。當網站大量產生這類網址時，也可能造成不必要的重複檢索；大型或更新頻繁的網站可搭配閱讀 爬取預算優化策略。
GSC 報表若標示 soft 404，先用網址檢查及網路回應確認實際內容、狀態碼與轉址。不能只根據標籤判定它一定回傳 200，或直接把應存在的頁面改成 404；修法取決於該網址應該提供什麼。
先用瀏覽器網路面板檢查實際 GET 回應，再與 GSC 網址檢查的內容比對。對於允許檢索的篩選組合網址，Google 的 faceted navigation 指引建議：沒有結果、不合理或重複的篩選組合，以及不存在的分頁，應在該 URL 回傳 404，而不是轉到共用的「找不到」頁；錯誤畫面仍可提供清除條件或其他導覽。
有實際用途的頁面，應確認內容完整且可正常渲染；不存在、無替代內容的資源則回傳 404，確知永久移除可回 410。Google 重新檢索與處理需要時間，不保證改碼後立即從索引消失。
404 頁面可評估的五種元件
清楚說明與可用的下一步，是設計時的重點。以下五種元件可依網站內容量與任務選用，不必全部塞入；它們也不是保證挽回訪客的公式。
元件一：一句清楚的說明，承認發生了什麼
用一般人能理解的語句交代頁面找不到，例如「這個頁面目前無法找到」。原因未確定時，不要斷言是訪客輸入錯誤或頁面已刪除；必要時提供聯絡或回報方式。
元件二：一條回家的路
可依網站規模提供首頁、主要分類或站內搜尋入口。搜尋框適合有內容可搜尋、且搜尋功能已測試的網站，不是所有 404 的必要元件。是否幫助訪客繼續操作需觀察實際路徑，不能把跳出率直接當作排名分數。 延伸可參考跳出率與 SEO 的關係。
元件三：少量相關的下一步
依原網址、網站內容及常見任務挑選幾個相關連結，避免把所有熱門頁面塞進錯誤頁。三到五個可作初稿範例，不是技術標準；實際數量與順序應以手機閱讀、鍵盤操作及內容相關性調整。
元件四：一個不破壞氣氛的行動呼籲
如果你的網站有聯絡表單、訂閱功能或客服管道，404 頁面是一個低壓力放上行動呼籲（CTA）的好地方。重點是「低壓力」，不是要你在錯誤頁上塞一個「立即購買」。一句「找不到你要的東西嗎？告訴我們，我們幫你找」配上聯絡按鈕，既解決了訪客當下的困境，也為你創造了一次互動的機會。CTA 的設計邏輯，可以延伸參考 Landing Page 轉換優化。
元件五：品牌一致性，不要讓訪客覺得走錯了站
保留能辨識網站的名稱、視覺與語氣，並提供必要導覽即可。頁首與選單可依錯誤頁任務簡化，不必複製所有正常頁元件；仍需測試讀者是否知道自己在哪裡及下一步怎麼做。 延伸可參考品牌網站設計指南。
左右捲動檢視完整表格
| 元件 | 用途 | 驗證方向 |
|---|---|---|
| 清楚說明 | 交代目前找不到內容 | 原因未確定時不亂下結論 |
| 主要導覽或搜尋 | 提供可繼續的路徑 | 連結與搜尋是否真的可用 |
| 相關下一步 | 協助找到替代資訊 | 是否與原本需求相關 |
| 聯絡或回報 | 需要協助時可求助 | 是否符合本站服務能力 |
| 品牌識別 | 辨識目前所在網站 | 名稱與視覺是否清楚一致 |
完成設計後，同時驗收狀態碼、連結與實際操作。記錄訪客碰到 404 後的下一步，才能判斷搜尋、分類或求助入口是否有用。
行動版 404 頁面空間有限，應優先放清楚說明與最可能的下一步；搜尋框、熱門頁面或聯絡按鈕的順序可依網站內容量與使用者需求決定。上線前要檢查響應式、鍵盤操作與可讀性，整體原則可搭配響應式網頁設計檢視。
狀態碼要符合資源的實際情況
自訂錯誤畫面不會自動確保狀態碼正確。請用一個不存在的網址實際測試，核對最初回應、轉址過程與最終內容。
不存在且沒有替代內容的網址，可回傳 404；若已知永久移除，可用 410。友善錯誤畫面不應改成成功的 200 回應。HTTP 狀態描述資源情況，頁面內容則協助讀者找下一步，兩者應相互一致。
常見的設定錯誤有幾種。有些主機預設把所有「找不到檔案」的請求導向自訂錯誤頁，卻沒有同時回傳 404 狀態碼，而是回了 200。有些架站平台或佈景主題把 404 頁面包裝成一般頁面，狀態碼也被改成 200。確認的方法很直接，用瀏覽器的開發者工具或線上的 HTTP 檢查工具，隨便打一個你站上不存在的網址，看看回應的狀態碼是不是 404。如果不是，這是技術 SEO 層面必須優先處理的問題，相關的全面排查可以參考 技術性 SEO 完整指南。
這裡有一個相關但不同的狀態碼：410（Gone），表示資源已永久移除。Google 通常會以相近方式處理 404 與 410，因此不必為了追求更快移除而全面改成 410；當你能明確判定內容永久下架時，410 可讓伺服器語意更精準。
談轉址就不得不提兩個技術陷阱：轉址鏈和轉址迴圈。轉址鏈指 A 轉到 B、B 又轉到 C，多次跳轉會增加延遲、浪費檢索資源，也提高日後維護出錯的機率；不要把它簡化成每一跳固定損失 PageRank。能直接指向最終網址就直接指向。轉址迴圈則是 A 轉到 B、B 又轉回 A，搜尋引擎和使用者都無法抵達內容，應定期用爬蟲工具檢查。
驗收時同時確認回應狀態與畫面。狀態正常不代表導覽一定好用，畫面友善也不能代替正確回應；對重要流程與改版後網址，應安排相應檢查。
轉址、重建還是放生？一張決策表幫你果斷抉擇
以下決策表將原因對應到處理方式。先判斷原網址是否應存在，再確認是否有能承接需求的替代內容，最後依實際影響安排優先順序。
左右捲動檢視完整表格
| 情境 | 有沒有替代頁 | 建議做法 |
|---|---|---|
| 改過網址，舊網址還有內外部連結 | 有（新網址） | 301 轉址到新網址 |
| 刪掉頁面，有相關內容可替代 | 有（同主題頁面） | 301 轉址到最相關的頁面 |
| 刪掉頁面，沒有任何替代內容 | 沒有 | 回傳 410 或維持 404，搭配設計過的錯誤頁 |
| 拼錯或失效的外部連結，帶來有意義流量 | 有（正確網址） | 301 把錯網址指到正確頁 |
| 無關的隨機錯誤網址 | 沒有 | 可保留 404；自己能管理的錯誤內鏈仍應修正 |
| 大量設定錯誤產生的 404 | 看情況 | 優先修設定，再決定是否轉址 |
不要把所有 404 都轉到首頁。若訪客原本要找的內容在首頁沒有對應，這個轉址無法解決需求，也可能被 Google 視為 soft 404。沒有合適替代內容時，保留 404 或適當的 410，並提供可選的相關導覽。
一般已移除網址可透過正確的 404 或 410，讓 Google 在重新檢索後逐步處理；沒有固定完成時間。索引報表與即時測試是不同資料，前者可能延遲，後者也不能保證當下索引狀態。 延伸可參考Google 索引查詢方法。
WordPress 與常見架站平台的 404 實作清單
WordPress 的錯誤頁依主題類型而異。傳統主題可使用 404.php，沒有專用檔案時依階層回退；區塊主題則使用 templates/404.html，也可能有網站編輯器儲存的自訂範本。先確認目前主題與範本來源，再修改。可參考官方範本階層。
第一，確認 404 狀態碼正確。WordPress 本身在找不到文章時會正確回傳 404，但有些外掛或自訂的 rewrite 規則會把它改成 200。裝一個能檢查狀態碼的外掛，或者乾脆用 curl 指令測試，確保你的 404 真的是 404。在 WordPress 生態裡做好整體的 SEO 設定，WordPress SEO 完整指南是很好的起點。
區塊主題可透過網站編輯器處理支援的範本；Elementor 的自訂 404 使用其 Theme Builder，需核對 Pro 方案與目前功能。依網站需求選用說明、導覽或搜尋元件，再到前臺測試不存在的網址。SEO 外掛是另一類用途，不能當作自訂錯誤頁的必要工具。 延伸可參考WordPress SEO 外掛推薦。
轉址可在伺服器、主機／CDN 工具或 WordPress 外掛管理。選擇取決於環境權限、規則數量、維護流程與實際量測，不能只按網站大小決定。使用外掛日誌時，也要核對設定、資料保存與效能，而不是預設所有請求都會完整記錄。
改固定網址前，列出實際會變動的網址，先備份與測試轉址對應。不是每次調整都會令全站舊網址失效，也不能假定系統已處理所有舊路徑。更新站內連結與 Sitemap；自動產生的 Sitemap 應確認內容正確，不必因例行內容更新而反覆手動提交。 延伸可參考WordPress 固定網址 SEO 設定、Sitemap 提交實作教學。
第五，檢查 WordPress 自動產生的彙整頁。標籤、作者、日期彙整與站內搜尋結果頁可能被索引，但它們不會因為是彙整頁就自動成為 soft 404。先判斷頁面是否有獨立導覽價值、是否重複，以及 Google 實際怎麼處理；沒有搜尋價值的頁面可考慮設定 noindex，細節可參考 noindex 入門介紹。若多個網址呈現高度相近的可索引內容，再依 Canonical URL 指南選擇合適做法，而不是把 canonical 當成 soft 404 的通用解法。
其他架站平台也需核對回應狀態、錯誤頁導覽及轉址，但可編輯範圍與操作入口依平台而異。先查目前文件，再在實際網站驗證，不假定都能直接修改範本或狀態碼。
五步行動方案，本週就能上手的 404 搶救計畫
先處理本來應有效的重要內容，再測試轉址與錯誤頁，最後安排後續複查：
- 匯出 GSC 已知 404 範例，補上可用的存取紀錄與爬蟲結果，依實際影響排序。
- 分清搬移、下架、外部錯連與設定錯誤；優先恢復本來應可使用的重要內容。
- 有真正替代內容時設定永久轉址，驗證最終頁面與狀態，避免迴圈及無關轉址。
- 按任務設計清楚說明與相關導覽，測試手機、鍵盤及錯誤回應。
- 依改版與內容變動頻率安排複查，觀察新增問題和後續互動；正常下架的 404 不必全部清零。 延伸可參考網站流量恢復方法。
驗收清單可包含：狀態符合資源情況、說明易懂、下一步可用、品牌可辨識、手機與鍵盤操作正常。搜尋框或熱門連結依需要選用，沒有固定數量或必須全放在首屏的規則。改版、換主題或調整路由後再測一次，確認沒有回歸。
404 請求可能來自真人、爬蟲或隨機掃描；應先分清來源與任務，再評估導覽需求，不預設每月造訪人數或每筆請求都有購買意圖。
把 404 做好，不一定會帶來明顯的流量成長。比較實際的驗收方式，是確認重要失效網址已有正確去處、站內不再持續產生錯誤連結、404 頁能協助訪客繼續導覽，並觀察碰到 404 後的離站率與後續互動是否改善。
把修正日期、原因與驗收結果記入同一份清單。後續若流量或互動改變，便能對照當時的內容、路由及其他網站變更。
可先從 GSC 已知範例著手，再與本站紀錄交叉比對，整理出第一批需要處理的網址。
