服务器返回的状态码，是抓取工具和浏览器判断一个地址“是什么情况”的第一手依据。页面内容再正常，只要状态码给错了，后续的抓取、缓存、展示都会按错误的假设走。这项自查不需要改模板，只要在几个关键位置确认响应头是否符合实际语义。
状态码为什么会直接影响抓取判断
抓取工具拿到 200，会认为这是一个可索引的正常页面；拿到 404 或 410，会逐渐把地址从队列里清掉；拿到 301 或 302，会把后续请求转到新地址；连续拿到 5xx，则可能降低对整站的抓取频率。状态码是机器读到的第一句话，内容只是第二句话。
问题在于，很多站点是在页面层面处理错误，而不是在响应头层面。模板渲染出一个“找不到内容”的页面，状态码却仍然是 200，机器读到的就是“这里有一篇正常内容”。
三个最常见的错配
软 404：返回 200 的空内容页
这是最普遍的一种。文章被删除、商品下架、参数拼错，程序没有走到 404 分支，只是列表为空、正文为空，页面照样以 200 输出。对访客来说体验尚可，对抓取来说却多了一个内容重复或近乎空白的地址，长期积累会稀释有效页面分到的抓取份额。
排查方式很简单：随机抽几十个已删除或参数错误的地址，用命令行查看响应头，而不是只看页面长什么样。
该 404 的页面被重定向到首页
把失效地址一律 302 到首页，看起来“没有死链”，实际上是把所有错误信号揉成一团。大量不同的失效地址最终指向同一个首页，抓取工具会把它当成软 404 的一种形式，首页也会因此收到一堆无意义的请求。
5xx 当成常态
接口超时、数据库连接失败、模板报错时返回 500，本身没错。但如果某个栏目长期有较高比例的请求返回 5xx，抓取频率会被主动调低，恢复之后想再提上来需要时间。所以 5xx 是要被监控的异常，而不是可以长期存在的状态。
一轮可执行的自查清单
- 准备一份地址样本：正常内容页、已删除页、参数错误页、权限受限页、搜索无结果页，各取几个。
- 用 curl -I 或浏览器开发者工具的网络面板，只看状态码和 Location，不看渲染结果。
- 确认已删除内容返回 404 或 410；有语义相同替代内容的，用 301 指向新地址，而不是 302。
- 确认登录页、后台、接口类地址不会返回 200 的完整内容页。
- 检查 301 链是否只有一跳，避免 A 到 B 再到 C 的连续跳转。
- 确认不存在整站范围的 5xx 或大量超时，并把阈值写进监控告警。
- 把修改过的状态码记录下来，改版后重新跑一遍同样的样本。
顺手要看的几处细节
- 搜索页无结果：返回 404 还是 200 空页，需要按实际设计统一，不要让每个关键词组合都产生一个 200 页面。
- 大小写与结尾斜杠：统一规范后，另一种写法应 301 到规范地址，而不是各自返回 200。
- 分页越界：访问超出范围的分页参数，应返回 404，而不是直接显示最后一页。
- 维护页：短期维护用 503 并带上 Retry-After，比返回 200 的“正在维护”页面更准确。
从日志里确认，而不是凭感觉
服务器日志记录了每个请求的状态码，按路径分组统计一下，比例异常的目录通常就是问题所在。重点看三类：某个栏目 404 占比突然升高、某个前缀大量出现 302、以及 5xx 集中在某个时间段。抓取日志同样值得对照，看蜘蛛拿到的状态码分布是否和你的预期一致。
状态码是站点对外的第一句回答。回答得准确，后面的内容与结构优化才有意义；回答错了，再好的内容也会被当成异常地址来处理。