站内页面被删除、商品下架、栏目合并之后，很多站点只处理了“页面看不到”这一层，却没有处理“服务器告诉蜘蛛什么”这一层。结果就是页面对用户显示找不到内容，HTTP 状态码却依然是 200。这种页面在搜索引擎眼里是正常可抓取的页面，只是内容空洞——也就是常说的软 404。
状态码是给机器看的说明书
用户看到的是页面，爬虫先看到的是响应头。状态码不统一，后面的抓取、去重、索引判断都会跟着偏。
- 200：内容正常，用户和蜘蛛看到的是同一份有效内容。
- 301：内容永久搬家，新地址明确且唯一。
- 302 / 307：临时跳转，适合活动页或短期调整。
- 404：内容不存在，且没有合适的替代地址。
- 410：内容已永久删除，明确告知不必再来。
- 403 / 401：访问受限，常用于登录后或付费可见的内容。
- 500 / 503：服务端异常或暂时不可用，503 建议配合 Retry-After 使用。
软 404 常见的几种来源
内容下架了，模板还在
商品删除、文章下线后只从列表里移除，详情页模板仍会渲染出一个空壳，状态码依旧是 200。这类地址数量往往很多，且会随着时间不断累积。
空列表页与空详情页
某个标签、某个分类下暂时没有内容时，页面上只剩标题和“暂无数据”，但状态码正常。对用户来说是空状态，对爬虫来说是一个内容极薄的有效页面。
搜索无结果页与筛选空页
站内搜索、多条件筛选在无匹配结果时，如果统一返回 200，很容易被大量参数组合放大成成千上万个薄页面。
服务器把错误页重写成 200
部分配置为了“友好错误提示”，把 404 页面通过内部重写返回成 200，浏览器看起来一切正常，响应头已经在说谎。
单页应用的前端路由
前端路由接管后，服务端对所有路径都返回 200 和同一个入口文件，实际的内容是否存在只有脚本执行后才知道。
怎么自查
- 命令行看响应头：对目标地址执行 curl -I，第一行的状态码才是重点，不要只看页面里写了什么。
- 浏览器开发者工具的 Network 面板，勾选保留日志，确认看到的是服务端返回码，而不是前端渲染后的结果。
- 日志分析：筛选状态码分布，看 404、410 是否集中在某些目录或参数下，是否存在大量 200 的空页面请求。
- 清单比对：把已下线的 URL 清单和真实返回码做一次对照，逐一确认是 301、404 还是仍然 200。
- 抽查历史地址：随机取几十个半年前存在、现在可能已失效的地址，看它们今天返回什么。
治理时的顺序建议
- 先把页面分类：有明确替代内容的做 301，一次跳转到位，不要串成长链条。
- 彻底删除且没有替代的返回 404；确认不会再有同类内容的，可以考虑 410。
- 空数据页要么改为 404，要么给出有效的推荐内容并保留 200，但不要两套逻辑互相打架。
- 清理站内入口：相关栏目、导航、正文内链里的失效链接一并去掉，别让蜘蛛顺着旧入口反复撞墙。
- 维护期使用 503 并附带 Retry-After，不要用返回 200 的“维护中”页面。
- 改完之后再跑一遍抽查，确认状态码与页面内容已经一致。
几个容易踩的坑
- 把 404 页面 302 到首页，会让所有失效地址都指向同一个入口，容易形成大量重复路径。
- 404 页面返回 200，等于把死链当成正常页长期保留在站内。
- 同一个地址今天 404、明天 200，反复横跳会消耗爬虫对站点的耐心。
- 测试域名或调试参数混进正式环境，状态码正常，但内容本不该对外出现。
- 用 200 处理所有异常，监控报表看上去很健康，问题却全部藏在内容层。
状态码不是给用户看的装饰，而是站点与爬虫之间的约定。约定越清晰，后续的结构调整和内容下线才越容易收尾。
建议先在团队内部固定一套规则：什么情况用 301，什么情况用 404，什么情况用 410，维护期统一用什么状态码。规则写下来之后，模板改动、内容下架、服务器配置调整才有统一的判断依据，而不是每个开发各按习惯处理。