站点跑久了，总有一些页面会悄悄失效：下架的商品、改名的栏目、活动结束后没清理的专题、被拼错的旧链接。用户看到的是“内容不存在”，但服务器返回的可能是 200，蜘蛛拿到的也是一份内容稀薄的“正常页面”。这类问题不会报错，也不会触发告警，却会一点点消耗抓取预算，让日志里的判断失真。
先分清三种状态
真 404 与 410
页面确实不存在，服务器直接返回 404 或 410。这是最诚实的回答，蜘蛛访问一次之后就会降低再来试探的频率，日志里也能一眼看出。
软 404
URL 可以访问，状态码是 200，但正文只有一句“抱歉，内容已删除”或者干脆一片空白，页头、页脚、导航却照常渲染。对抓取程序来说，这和正常页面没有区别。
5xx 服务端错误
服务器临时故障、后端超时、数据库连接不上。短时间内蜘蛛会稍后重试，但如果长时间大面积 5xx，抓取频率会被压低，恢复之后也需要一段时间才能回到原来的节奏。
软 404 的常见来源
- 商品或文章下架后只删了正文，模板仍然输出完整页面框架；
- 栏目被清空，列表页返回 200 但没有任何条目；
- 站内搜索无结果页被当成普通页面，甚至被内链指向；
- CMS 的草稿预览、未到发布时间的定时稿页面可被直接访问；
- 分页参数越界（如 page=99）返回空白列表而不是 404；
- 改版后旧模板残留，落在一个通用的兜底页上。
自查步骤
- 抽样比对：从访问日志里挑出一批状态码为 200 的 URL，随机取几十个实际打开，看正文字数、是否有实质内容，重点看那些平时没人点、只被蜘蛛访问的地址。
- 批量验证状态码：用命令行工具或脚本对核心栏目、旧版路径批量请求，统计 200、301、404、410、5xx 的分布，异常集中在哪个目录一眼就能看出来。
- 看 404 高频路径：日志里反复出现的 404，往往是站内还有死链没清理，或者外部旧链接没做跳转，需要区分对待。
- 核对错误页模板：手动访问一个确定不存在的地址，确认返回的是 404 而不是 200，同时页面里要有返回入口，别让用户卡在死胡同。
- 检查空结果场景：列表页、搜索结果页、标签页在无内容时，应返回 404 或至少不输出可索引的空白模板。
- 排查 5xx 分布：如果 5xx 集中在某个时间段或某台后端，先解决服务器问题，再谈抓取层面的优化。
处理时的取舍
内容永久删除的，给 404 或 410；只是暂时下线、很快会恢复的，用 503 加上 Retry-After 头，而不是返回一个 200 的空白页；页面整体迁移的，用 301 指向最接近的新地址，并且只跳一层。需要特别注意的是，把大批失效 URL 全部 301 到首页，本质上只是换了一种形式的软 404，对用户和抓取都没有帮助。
清理完成之后，还要做两件收尾的事：一是把站内链和导航里指向失效地址的链接改掉或去掉，避免蜘蛛顺着链接反复撞墙；二是同步更新站点地图，别再让地图把已经下线的地址继续列出去。
状态码是给机器看的结论，页面内容是给人看的说明。两者说的是同一件事，日志才值得信任。
这类检查不需要天天做，但建议在每次大改版、批量下架或栏目调整之后跑一遍，把它当成站点运营的例行体检项目之一。