失效頁面不只是“用戶点不到”

很多站点的 404 是被動發現的：某個用戶点了舊連結，或者在日誌里看到一片 404 记錄，才知道又坏了一批地址。失效頁面的影响其實有三层：用戶走到這里會中断，内鏈和導航结构出現断点，而搜尋引擎的抓取预算會持續消耗在這些没有内容的地址上。定期處理失效連結，本质上是在维護站点的通行性。

先分清是哪一種失效

處理之前先分類，不同情况對應的返回碼完全不同：

• 临时下线：比如活動頁結束、栏目临时维護。如果确定几周内會恢复，用 503 配合 Retry-After 更合适，不必急着 301。
• 永久刪除：内容确定不再提供，直接返回 410 或 404，让蜘蛛尽早放手。
• 地址迁移：頁面還在，只是換了 URL。這種情况應该 301 到新地址，並且尽量一一對應。
• 誤删或配置错誤：本该存在的頁面被删掉，優先恢复内容，而不是用重定向遮掩。

最容易被忽略的是“软 404”

有一類情况更麻烦：HTTP 狀態碼返回 200，頁面上却寫着“内容不存在”，或者只剩一個空壳模板。這種软 404 會让蜘蛛以為抓到了一篇正常頁面，反而更可能反复来訪。自查方法很简單，挑几個已刪除的地址手動訪問，看返回碼和頁面内容是否一致。

狀態碼是给机器看的，頁面是给人看的，两者表達的信息不一致时，吃亏的通常是站点自己。

失效地址通常從哪几個地方冒出来

• 導航、面包屑、頁脚里的老連結，改版後没有同步更新；
• 正文内鏈指向已经下架的内容；
• Sitemap 或 RSS 里還留着已经刪除的地址；
• 带參數的舊地址，比如早期的跟踪參數、分頁參數；
• 图片、JS、CSS 等资源路径變更，頁面本身正常但资源 404。

從服務器日誌里按狀態碼筛一遍，把 404、410 的訪問量排個序，通常能很快看出高频失效地址集中在哪個目錄，進而定位到是哪次改版或哪批内容下架留下的痕迹。

按優先級處理，比一次性清空更現實

失效地址往往成百上千，全量處理並不現實，可以先挑三類：被外部連結引用過的、日誌里被抓取频次較高的、原本有轉化或訪問量的。這三類值得花時間找最接近的替代頁面做 301，或者直接恢复内容。剩下的長尾地址，做好 404 頁面的引導說明、從内鏈和 sitemap 里移除，就已经足够了。

需要提醒的是，不要把全部 404 统统一 301 到首頁。這種做法對用戶没有帮助，也容易让搜尋引擎把首頁当成一堆無關地址的落点。

留一張台帳，避免重复劳動

處理结果最好记下来：原地址、失效原因、處理方式（301 到哪、410、還是恢复内容）、處理日期、复查日期。改版频繁的站点，三個月後同样的問题很可能再出現一次，有台帳就不用從头查起。巡检节奏也不用太密，每月盘一次高频失效地址，配合改版後的即时抽查，基本能覆盖大部分問题。