先判斷要求的網址發生了甚麼事
網址打不開，不一定是同一種編輯或技術事件。顧客可能打錯一個從未存在的路徑；已發表的指南可能搬到明確的新地址；限時活動可能已結束且沒有合適替代頁；亦可能是正常商品頁因程式故障而無法顯示。先把這些情況列成由負責人維護的判斷表，再設計畫面。MDN 將 404 定義為找不到資源，並不代表這個缺失一定是暫時或永久。若已確定內容永久移除，410 可以更明確表達。Google Search Central 建議，頁面若已搬到清楚的替代地址，使用永久轉址；若沒有替代內容，回傳 404 或 410。暫時伺服器故障要用相應的故障處理，不應假裝成 404。顧客看到的文字應與回應狀態說同一回事。企業可以把 404 頁做得友善，但不能靠漂亮文案把未知網址變成「成功取得資源」。狀態碼與畫面一致，瀏覽器、搜尋引擎、監控工具及客服同事才能對同一個請求作出一致理解。
有用的頁面也要配正確狀態碼
常見錯誤是畫面寫着「找不到頁面」，伺服器卻回傳 HTTP 200。Google 稱這類情況為 soft 404：回應說成功，內容卻說失敗，搜尋系統可能因此把它排除。自訂錯誤頁仍可有正常導覽、搜尋框及清楚下一步；只是原來那個缺失網址的回應必須維持 404。檢查時要看顧客要求的網址，而非只測試獨立的錯誤頁模板。應用程式路由、靜態網站後備頁和單頁應用程式都可能在此出錯：若所有未知路徑一律送回首頁及 200，網站看來正常，實際卻說錯了狀態。另一種錯誤是把每個失效網址都轉往首頁，既掩蓋原頁不存在的事實，也常把顧客帶到毫不相關的內容。只有找到用途相近、明確的後繼頁，才應設定相應轉址。若內容永久消失又沒有合適替代，就誠實回傳 404 或 410，再從錯誤頁提供有用選擇。視覺頁面與協定回應屬於同一段顧客體驗，即使由不同團隊負責設定也一樣。
幫顧客返回原來的任務
好的 404 頁先清楚說明找不到指定頁面，再提供根據網站真實結構設計的去路。保留熟悉的導覽，讓顧客知道自己仍在同一個網站。首頁連結有用，但如果企業有不同服務、商品分類或支援渠道，也應提供少量穩定而相關的目的地。若網址顯示原本是某個舊分類或指南主題，可連到相近分類，前提是那裏真的有相關內容。不要過度肯定地猜一個替代頁，令顧客誤以為它是同一款商品、同一價錢或同一優惠。若企業能接收並處理失效連結報告，可設回報途徑及附上嘗試開啟的網址；沒有跟進能力就不要製造一個無人理會的按鈕。Google 對自訂 404 頁的建議包括清楚解釋、與全站一致的外觀、有用連結及回報失效連結的方法。頁面不應重述已失效推廣的日期、暗示舊優惠仍適用，或顯示對顧客沒有幫助的內部路徑細節。香港雙語網站若支援顧客正在使用的語言，錯誤訊息與連結亦應跟隨該語言，同時保留切換語言的途徑。
用三個網址演練不同做法
假設維修店有一篇指南搬到永久新網址、一個季節活動已過期，另有顧客輸入從不存在的地址。對舊指南，先核實新指南確實回答同一個問題，再把舊地址永久轉往新地址；若只是圖方便轉到寬泛的服務目錄，讀者仍可能找不到答案。對已過期活動，先查有沒有用途相同而內容真實的現行頁。若沒有，且舊優惠已結束，便可用 404 或 410 說明頁面不可用，並連到現行服務，但不能暗示舊條款繼續有效。對打錯地址，回傳 404、提供網站導覽及可能有用的搜尋框；不要把隨機錯字永久轉到猜測的頁面。再加入第四個情況：有效的預約頁因程式故障暫時出錯。這應查明並按伺服器故障處理，不能重新標籤成「頁面不存在」。這幾個例子可以成為員工清單：原頁是否有已核實的後繼頁、是否刻意移除、還是營運故障？回應方式由證據決定，不應只為了讓錯誤報表看起來較少數字。
從失效網址修補真正的路徑
404 頁只是安全網，不能代替日常維護連結。檢查失效網址紀錄時，要看來源及顧客原本的任務。若連結來自自家選單、結帳電郵或商品說明，企業能控制源頭，就應盡快修正。若外部網站指向舊而仍有價值的內容，而且有已核實的替代頁，針對該地址的轉址可能有幫助。隨機機械探測和偶然打錯字要另作處理；單純 404 請求總數不是網站品質分數。紀錄可包括嘗試開啟的路徑、可取得時的來源頁、出現次數及顧客影響，同時避免不必要地保存可能含個人資料的查詢參數。建立轉址前先對照現有路由清單。過分寬鬆的統一轉址會掩蓋真正的程式回歸；若商品目錄更新後突然有一群商品頁失效，也許是內部網址產生程式出錯。修補流程很直接：重現網址、找出誰連到它、決定是修正源頭連結、轉往真正的後繼頁，還是保留正確 404，最後再測試。未知流量不能直接當成舊優惠仍有需求的證據，也可能只是自動掃描或過時書籤。
同時測狀態、內容及目的地
推出前，在每種受支援語言各要求一個刻意不存在的網址，查看真正 HTTP 狀態、呈現的頁面及連結。再測一個已搬遷頁、一個刻意刪除頁，以及在安全測試環境中模擬暫時不能使用的有效頁。核對轉址沒有循環、會到達預期語言，而且目的地仍能滿足原來的閱讀或購買目的。失效頁要在鍵盤和手機版下檢查導覽；文字須清楚說明問題而非責怪顧客，搜尋框亦不能把主要訊息蓋住。若網站使用 CDN 或主機後備規則，要看最終回應，因為邊緣層可能改掉應用程式原本送出的狀態。單頁應用程式則同時測站內點擊及在全新瀏覽器分頁直接輸入未知網址。保留一份小型代表性網址清單，在路由或主機設定修改後重跑。單張畫面截圖不足以驗收，因為它看不出網址回傳的是 200、404、410 還是轉址。完成的方案應在協定層說真話，並讓真正到訪的人有路可走。
為下架內容指定決定人
最難處理的失效頁，往往在技術工單出現前就已決定。營銷團隊可能停止活動，商品團隊可能下架貨品，但客服仍在傳送舊連結。每類內容應有負責人，能回答是否有真正後繼頁，以及原來承諾何時結束。簡單記下舊網址、處理決定、適用的目的地及修改日期，可避免日後維護者把已失效優惠轉往條款不同、只是表面相似的新推廣，也方便客服解釋書籤為何失效。可行時，404 模板不要完全依賴即時存貨或活動資料，否則商品服務一故障，連挽回頁也變空白。若錯誤頁提供搜尋，也要留下靜態導覽作搜尋不能使用時的後備。顧客從舊電郵連結進來，仍能看懂發生甚麼；企業也能追溯當初由誰決定該網址的去向。
進行前先確認
- 分清已搬遷、已刪除、未知及故障中的有效網址。
- 沒有替代頁時，配合有用頁面回傳 404 或 410。
- 檢查主機或 CDN 規則後的最終 HTTP 狀態與目的地。
