站点里出現失效地址是常態。内容下线、栏目調整、URL 改寫，都會留下断開的路。真正麻烦的往往不是 404 本身，而是它被错誤地表達出来：该返回 404 的頁面返回了 200，或者所有失效地址统统跳去首頁。前者让搜尋引擎把空頁面当成正文，後者用一次跳轉掩盖了一大片失效連結。
先把三種情况分開
- 正常 404：服務器确實返回 404 狀態碼，頁面给出清晰提示和可走的出口。這是健康狀態，不需要修。
- 软 404：狀態碼是 200，頁面内容却是“内容不存在”“该内容已刪除”。搜尋引擎會把它当作正常頁面抓取，甚至尝试索引。
- 错誤跳轉：失效地址被 301 或 302 到首頁，用戶和蜘蛛都落到一個與预期無關的頁面。問题被藏起来，但連結依舊失效。
三種情况的處理方式完全不同，所以第一步不是急着删連結，而是先確認你面對的是哪一種。
自查可以從三個方向入手
1. 抓取日誌里筛“狀態碼 200、内容很薄”的地址
把日誌按狀態碼分组，挑出返回 200 但响應体很小的 URL，再抽样打開看看。如果這些頁面统一在说“没有找到内容”，那就是典型的软 404。這類地址數量往往不小，因為它們不會报错，只會在後台安静地累积。
2. 用命令行確認狀態碼
不要只看浏览器里的頁面長相，直接請求一次更可靠。在终端执行 curl -I 加上完整地址，看响應第一行的狀態碼。只返回 200 却在正文里寫“頁面不存在”的，就是软 404；返回 302 並指向首頁的，就是错誤跳轉。如果站点地图或後台里存着歷史地址清單，可以寫個小脚本批量請求，輸出狀態碼與最终跳轉地址，比人工点開快得多。
3. 检查内鏈里的死鏈
外鏈失效你控制不了，站内自己鏈出去的地址失效則完全可以避免。重点看栏目頁的推荐位、舊文章正文里的引用、頁脚和侧邊栏的固定連結。這些位置改版时最容易漏，而它們往往出現在全站的每一頁上，一次失效就是成倍的無效請求。
404 頁面本身怎么寫
一個合格的 404 頁面並不需要花哨，但要做對几件事：
- 服務器返回正确的 404 狀態碼，頁面再好看也不能用 200 兜底。
- 用一句人话說明地址可能已失效，不要只顯示一個错誤编号。
- 给出出口：返回首頁、進入主要栏目、使用站内搜尋，三者至少留两個。
- 可以顺带推荐几篇热门内容，但不要塞成广告位，让人以為進错了站。
- 不要設定几秒後自動跳轉，自動跳轉會打断用戶，也让狀態碼變得没有意义。
判断标准很简單：如果這個頁面返回 200，用戶和搜尋引擎都會期待里面有内容。你寫的是“没有内容”，那就不该用 200。
舊地址怎么處理，看它還有没有價值
- 内容迁移了：用 301 指向最相關的新地址，只跳一层，不要串成鏈條。
- 内容彻底没了，但仍有外鏈和搜尋流量：考虑做個简短說明頁，指向同類内容，而不是直接消失。
- 内容没了也没人訪問：让它正常返回 404，必要时用 410 表明已永久移除。
- 整站栏目合並：按栏目批量做映射，別用一個總跳轉把所有舊地址都導向首頁。
把失效地址集中導到首頁，短期看着“没有 404 了”，實际上是把問题轉嫁给首頁，让搜尋引擎反复抓取一個不相關的頁面。這種做法既不解决用戶需求，也不节省资源。
一份可以照着走的检查清單
- 從日誌中導出近一個月的 404、410 狀態地址，按路径前缀归類。
- 抽取其中返回 200 的可疑地址，確認是否為软 404。
- 检查内鏈、頁脚、推荐位里是否還挂着已失效地址。
- 核對跳轉規則，確認没有把大批舊地址统一導向首頁。
- 確認 404 頁面返回正确狀態碼，並且提供了可用出口。
- 把本轮處理過的映射關系记錄下来，方便下次改版时复用。
做完這轮自查，你未必會看到立刻的變化，但站点里那些被反复請求却什么也给不出的地址會明顯减少。抓取资源有限，把它留给真正有内容的頁面，本身就是运营的一部分。