为什么 5xx 比 404 更值得优先处理
404 说明某个地址没了，搜索蜘蛛记一笔就走；5xx 说明服务器当时根本没接住请求。对蜘蛛来说这是两种完全不同的信号。遇到 5xx，通常会被判定为一次抓取失败，过一会儿再来，同一个地址可能在短时间内被反复重试。如果整站或某个栏目持续返回 5xx，抓取频次会被压缩，恢复之后也需要一段时间才能回到原来的水平。
更麻烦的是，5xx 往往是间歇性的：人工打开时一切正常，只有并发稍高或者某个后端接口超时才暴露出来。所以这类问题不能靠“我打开看了一眼没问题”来判断。
自查清单：先确认哪些地址在报错
- 随机抽 20～30 个已收录的 URL，用脚本批量请求，记录状态码和耗时。
- 单独测一遍 Sitemap 里最近新增的地址，新页面最容易命中没有预热的后端接口。
- 检查分页、筛选、站内搜索这类动态地址，它们更容易触发超时。
- 分别用移动端和桌面端的 UA 请求同一批页面，有的站点移动模板会走另一套接口。
- 把响应时间明显偏长的请求单独列出来，即使返回 200 也要关注。
常见成因，按排查顺序看
应用层
- 数据库慢查询：缺索引，或者统计类查询直接跑在主库上。
- 缓存击穿：缓存过期的瞬间，大量请求同时回源。
- 第三方依赖超时：支付、地图、统计之类的外部接口卡住了主流程。
服务器与网关层
- 应用进程数不足，请求排队时间超过了网关的等待上限。
- 网关或负载均衡的超时阈值比应用短，应用还在处理就被判为失败。
- 磁盘写满、日志文件过大导致写入阻塞。
- 定时任务与抓取高峰撞在一起，抢同一批资源。
修复与验证的顺序
- 先把持续报错的地址修掉，哪怕是临时屏蔽，也别让它一直返回 5xx。
- 对确实已经废弃、不再提供内容的地址，改成 404 或 410，让信号变清晰。
- 对偶发超时，先加缓存和限流，再考虑扩容。
- 核对网关与应用的超时设置，保持各层一致，避免一层已经放弃、另一层还在等。
- 改完之后连续观察几天日志，确认错误率回落再收工。
日志里该看什么
不要只盯着总抓取次数。按状态码分组统计，再把 5xx 的 URL 按目录聚合，通常很快就能看出是某一个栏目、某一类模板还是某一个接口的问题。
顺带提醒一句：错误页面如果本身返回 200，也可能被抓取并建索引，这比返回 5xx 更糟。至少要让它返回正确的状态码，并附上一句简短的说明文字。
计划内维护时怎么处理
如果确实要停机，尽量避免让蜘蛛长时间拿到 5xx。维护期间可以返回 503，并在响应头里写上 Retry-After，告诉对方多久之后再来。这样比直接断开连接要清晰得多，恢复后也更容易回到正常的抓取节奏。
- 维护窗口尽量避开抓取高峰时段。
- 维护页不要跳转到首页，否则容易被当成软跳转。
- 维护结束后手动请求几个关键地址，确认状态码恢复正常。
把它变成日常习惯
- 把状态码监控加进例行巡检，而不是等流量掉了才回头查。
- 上线新功能时，同步检查它对抓取路径有没有影响。
- 记录每次故障的时间和原因，方便对照日志里抓取量的波动。
5xx 自查不是一次性任务，它更像一条底线：只有服务器在稳定地回应请求，后面的栏目规划和内容更新才有讨论的意义。