页面下线、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 数量归零——那不现实，也没必要。真正要做的是让每一个失效地址都有一个合理的去向：能接上的接上，接不上的说清楚。