为什么 5xx 比 404 更值得警惕
404 只是告诉蜘蛛“这个地址没有内容”，而 5xx 说的是“服务器这次没能完成任务”。前者是内容层面的答案，后者是服务层面的故障。蜘蛛遇到 5xx 通常不会立刻放弃，而是降低抓取频率、稍后再来。问题在于：如果故障持续存在，抓取预算会被反复消耗在失败的请求上，正常页面的抓取节奏也跟着变慢；时间拉长，收录与更新都可能受影响。
先分清几种常见状态码
- 500：应用内部报错，常见于未捕获异常、数据库连接失败。
- 502 / 504：反向代理联系不上上游或上游超时，多见于服务重启、进程假死、接口阻塞。
- 503：服务暂时不可用，通常配合 Retry-After 使用，适合计划内维护。
- 507 / 509：磁盘写满或带宽、配额超限，属于资源类故障，容易被忽略。
自查清单：从日志开始
- 统计访问日志里 5xx 的占比与集中路径，判断是整站故障还是个别页面出错。
- 翻看 Nginx、PHP 与应用错误日志，按时间对齐，找出第一次出现的时刻。
- 用 curl -I 带上蜘蛛 UA 请求首页、栏目页、详情页，确认返回码是否稳定。
- 检查磁盘空间、内存、进程数、数据库连接数，排除资源耗尽。
- 排查是否有同步调用第三方接口且未设超时时间，把整个请求拖死。
- 确认健康检查地址不是返回 200 的静态文件——它并不反映真实业务状态。
处理时的几个原则
计划内维护尽量用 503 加 Retry-After，而不是直接砍掉服务、返回 502；永久移除的页面应该给 404 或 410，不要用 5xx 代替，那会让蜘蛛反复回来重试。发布环节上，滚动重启、灰度发布比一次性重启更能压缩 502 的时间窗口。对重要栏目可以做静态兜底，即使动态服务挂了，核心页面仍能返回正常内容。
别用返回 200 的“出错啦”页面糊弄蜘蛛。它读到的是正常内容，用户看到的是故障，两边都被误导。
监控与恢复后的回归
把 5xx 比例做成监控指标并设置阈值告警，比事后翻日志高效得多。故障恢复后，留意抓取频率是否回升，必要时通过 Sitemap 和内部链接把重点页面重新推给蜘蛛。定期回看故障记录，把每次 5xx 的成因沉淀成检查项，比单次修复更有价值。