只要站点上线一段时间，404 就几乎无法避免。改版、删栏目、调整 URL、外部链接失效，都会留下打不开的地址。问题不在于 404 本身，而在于它出现时返回了什么状态码、展示了什么页面，以及有没有被及时发现。
先分清：真 404 和软 404
从服务器角度看，404 是一种明确的 HTTP 状态码，表示请求的资源不存在。它本身不是错误配置，反而有助于蜘蛛判断这个地址不用再抓。麻烦的是“软 404”：页面内容已经不存在，服务器却返回 200，或者把用户自动跳到首页。这样蜘蛛会以为这是一个正常页面，继续浪费抓取预算。
- 真 404：地址不存在，服务器返回 404 状态码，页面给出友好提示。
- 软 404：地址不存在，服务器返回 200，页面显示“内容已删除”或空白列表。
- 错误跳转：任何无效地址都 301 到首页，蜘蛛无法判断哪些地址真正失效。
- 服务器错误：返回 5xx，说明是临时故障，不要和 404 混在一起处理。
为什么值得专门做一次 404 自查
404 页面不只是技术细节。访客点进来时，如果只看到一行冰冷的“Not Found”，多数人会直接离开；如果能看到返回入口和搜索框，还有机会继续浏览。对搜索引擎来说，大量真 404 会消耗抓取资源，软 404 则会干扰索引判断。内链和外链里长期存在的失效地址，也会让页面的可信度打折扣。
可执行的 404 自查步骤
- 查看服务器访问日志。筛选状态码为 404 的请求，按路径和来源分类，看是旧文章、旧图片、测试地址，还是被外部站点引用的地址。
- 抽查 404 页面的响应头。用浏览器开发者工具或命令行确认状态码确实是 404，而不是 200。注意有些 CMS 会默认返回 200。
- 检查站内链接。从首页、栏目页、文章正文、导航和页脚逐层点击，重点看改版后没有更新的入口。
- 检查站点地图和提交记录。地图中不应包含已经删除的地址；如果地图里还留着死链，蜘蛛会反复访问无效页面。
- 检查外部来源。在访问日志中看 Referer，找出外部站点引用的失效地址。能联系对方更新的就更新，不能更新的可以考虑做 301 指向最相关的新页面。
- 关注移动端和不同 UA。有些站点对手机蜘蛛返回的页面不同，404 处理也可能不一致，自查时别只测桌面浏览器。
- 设置监控。404 数量突然上升往往意味着改版、误删或程序异常。可以用日志分析工具或简单的定时脚本观察趋势。
一个有用的 404 页面应该包含什么
404 页面不需要复杂，但要让访客和蜘蛛都能快速理解现状。以下内容比写一大段道歉更有用：
- 一句清楚的说明：页面不存在，可能是地址输入有误或内容已调整。
- 返回首页、主要栏目或上一级分类的入口。
- 站内搜索框，方便访客直接找目标内容。
- 几个热门文章或最新更新，给访客一个继续浏览的理由。
- 联系方式或反馈入口，方便访客报告失效地址。
需要提醒的是，不要用 JavaScript 自动跳转到首页。自动跳转会让访客来不及看清提示，也可能让蜘蛛无法正确识别 404。手动入口比强制跳转更稳妥。
常见误区
- 把所有 404 都 301 到首页。这会把大量不相关地址合并到一个页面，蜘蛛难以判断哪些地址真正失效。
- 让 404 页面返回 200。这是典型的软 404，会让索引里堆积无效内容。
- 404 页面只放一句英文。访客看不懂，也不会留下来继续找内容。
- 在错误页暴露服务器版本、堆栈信息。既影响安全，也没有实际帮助。
- 只看数量，不看来源。404 数量下降不代表问题解决，可能只是蜘蛛不再抓了。
404 不是敌人，无法被识别的 404 才是。让服务器说清楚“这个地址不存在”，让访客看到下一步能去哪里，比强行把错误页伪装成正常页面更有价值。
做完一次 404 自查后，建议把检查频率固定下来：改版上线后必查，内容批量删除后必查，日志里 404 明显上升时必查。它不会直接带来排名，但能减少无效抓取、改善访客体验，属于站点运营里投入不大、回报稳定的基础工作。