站点运行时间一长，总会积累一批失效地址：产品下架、文章合并、栏目调整，都会留下打不开的 URL。404 本身不是故障，但怎么处理，会影响到蜘蛛的抓取效率和用户的落地体验。这篇从自查角度，说说 404 与软 404 该怎么排查和安排去处。
先分清硬 404 和软 404
硬 404指服务器明确返回 404 状态码，告诉客户端这个地址不存在。这是正常的表达方式，蜘蛛收到 404 后会逐步把该 URL 从索引中移除，不会反复来抓。
软 404则是页面内容已经不存在，但服务器仍然返回 200 状态码。常见表现是页面显示“内容不存在”“暂无数据”，或者只剩导航和页脚的空壳。蜘蛛会把它当成正常页面，继续抓取、继续占用抓取预算，用户从搜索结果点进来也只会看到空白。
判断标准很简单：如果一个地址实际没有内容可看，就不要用 200 状态码把它包装成“正常页面”。
常见的软 404 场景
- 内容被删除或下架后，详情页直接返回 200 的空模板。
- 站内搜索结果页没有匹配结果，仍返回 200 的可抓取页面。
- 列表分页超出实际范围，例如只有 5 页却存在 page=99 并正常返回。
- 筛选、排序参数生成了大量无内容的组合页面。
- 用户中心、订单页等登录后才有内容的页面，在未登录状态下返回 200。
有替代内容就 301，没有就老实 404
处理失效页面之前，先问一句：站内有没有内容相近、可以承接的页面？
- 有明确替代：用 301 永久重定向到最相关的新地址，比如旧产品页跳转到同系列新品页，合并文章跳转到保留的那一篇。
- 没有替代：直接返回 404，不要用 302 临时跳转到首页，也不要用 JS 跳转。这两类做法容易让蜘蛛误解，用户也会觉得被强行丢到不相关的地方。
重定向要一跳到位。如果 A 跳 B、B 又跳 C，既有跳转链的损耗，也不利于后续维护。
把 404 页面做成有用的落地页
404 不等于死路。返回正确状态码的前提下，页面本身可以承担引导作用：
- 用一句人话说明当前地址已失效，不要只丢一个冷冰冰的错误码。
- 给出首页、主要栏目、站内搜索的入口，让用户能继续找。
- 可以列出几篇近期更新的内容或常用入口，但不要做自动跳转。
- 移动端同样要保证按钮可点、文字可读。
定期从日志里翻 404
自查不能靠猜，服务器访问日志和蜘蛛抓取日志里就有答案。可以按下面几步看：
- 统计一段时间内返回 404 的 URL，按访问次数从高到低排。
- 区分来源：是站内链接指错，还是外部老链接，还是蜘蛛仍在访问的历史地址。
- 站内链接导致的 404，直接改链接；有替代页面的，补上 301。
- 持续被抓的高频 404，检查是否有配置或模板问题在批量生成错误地址。
一份可以照做的自查清单
- 抽查删除内容后的旧 URL，确认状态码是 404 还是 200。
- 检查搜索无结果页、空列表页的响应状态。
- 检查分页参数超出范围时的返回内容。
- 确认 404 页面自身返回 404，而不是 200。
- 确认站内没有指向已删除页面的死链。
- 确认重定向为一跳，且目标页面内容相关。
- 把高频 404 整理成清单，定期复看。
404 处理不复杂，关键是把“失效”这件事如实告诉蜘蛛和用户。状态码说真话，页面给出路，剩下的交给时间。