頁面下线、URL 改名、栏目合並之後，站点里往往留下一些已经打不開的地址。這些地址本身不致命，但如果一直以错誤的狀態碼返回，會消耗抓取配額、扰乱站内連結结构，也让用戶点進来看到一片空白。這篇整理一套可以定期执行的自查办法。
先把几種“打不開”分清楚
很多人把狀態碼不對的頁面统称為 404，其實它們的處理方式並不一样。
- 硬 404：服務器明确返回 404，頁面确實不存在。這是最干净的一種。
- 软 404：頁面其實已经没了，服務器却返回 200，正文寫着“内容不存在”或只剩一句提示。抓取程序會把它当成正常頁面带走。
- 410：明确告知頁面已永久刪除，比 404 更干脆，但不是所有场景都需要。
- 统一跳首頁：把大量失效地址一股脑跳到首頁，看起来“没报错”，實际是让所有舊地址都指向同一個頁面。
狀態碼是给机器看的信号。頁面還有没有價值是一回事，返回什么狀態碼是另一回事，两者要對得上。
自查清單：從哪几個地方找問题
- 抽样看狀態碼。用開發者工具或 curl 查看几個已知下线的舊地址，確認返回的是 404 還是 200。软 404 通常就是這样被發現的。
- 翻抓取日誌。把服務器日誌里狀態碼為 404、410 的记錄按 URL 路径聚合，看哪些目錄、哪些栏目集中出現。某個栏目整体 404，往往說明栏目改過名而連結没跟上。
- 跑一遍站内連結。抓取站内頁面上的所有連結，找出指向 404 的内鏈。内鏈指向死鏈比外鏈更值得優先處理，因為它是自己可控的。
- 检查跳轉鏈。看有没有 A 跳 B、B 又跳 C 的情况。鏈條越長，传递效率和用戶体驗越差。
- 看 404 頁面本身。它是否返回正确的 404，是否還能正常加载，有没有给用戶一條回到主干的路径。
按頁面價值决定處理方式
值得保留的，做 301
如果舊地址對應的内容還在，只是換了位置，就把它 301 到最接近的新地址。目标要相關，不要一律指向首頁或某個栏目頁。多個舊地址指向同一個新地址是正常的，但方向要准确。
确實没有替代内容的，返回 404
内容彻底刪除、也没有相近頁面可以承接时，老老實實返回 404。硬 404 不會拖累整站，長期挂着的软 404 才會让狀態碼統計變得混乱。想表達“永久刪除、不必再来”的，可以用 410。
批量下线的栏目，要一起收拾
栏目關閉时，除了栏目頁，還要處理它下面的内容頁、列表分頁，以及站内其他頁面指向它的入口連結。只處理顶层那一頁，剩下的地址會以 404 的形式散落在各處。
404 頁面该有的样子
- 保留站点的头部、底部和導航，別做成一個孤零零的纯文本頁。
- 给一句明确的說明，告诉用戶這個地址已经不可用。
- 提供几個入口：首頁、相關栏目、站内搜尋。
- 不要自動跳轉。用戶還没看清發生了什么就被彈走，体驗很差。
- 不要在這個頁面上堆砌大量推荐連結，它不是一個内容頁。
把這件事變成常規動作
404 不是清理一次就結束的問题。每次改版、下线专题、調整 URL 規則，都會产生新的失效地址。比較省力的做法是：日誌每周掃一次，新出現的 404 按来源归類，能修的当场修，需要观察的先记下来，一個月後再看是否還在被請求。持續被請求的舊地址，通常說明站外還有連結指着它，值得優先處理。
整件事的目标不是让 404 數量归零——那不現實，也没必要。真正要做的是让每一個失效地址都有一個合理的去向：能接上的接上，接不上的说清楚。