收录报告里的数字通常滞后。当服务器端开始出现间歇性 5xx 或超时，最先变化的往往不是收录量，而是抓取日志里的失败记录和爬虫的访问频次。等到收录量出现波动时，问题其实已经发生了一段时间。
先分清：是抓不到，还是不想收
抓取和收录是两个阶段。抓取失败意味着爬虫没拿到内容；收录判断发生在拿到内容之后，决定这个 URL 要不要放进索引。服务器问题属于前者，它一般不会直接把页面判定为“质量差”，但会推迟后面所有环节：没抓到，就谈不上渲染、比对和收录。
所以看到收录不动时，先别急着改内容，第一步是确认爬虫到底有没有成功拿到页面。
常见响应状态码对爬虫意味着什么
- 200 / 304：正常返回或内容未变，是最理想的状态。
- 301 / 302：跳转本身没问题，但跳转链过长会消耗抓取额度，长期使用 302 也容易被当作临时跳转处理。
- 403 / 401：常见于 WAF 或权限规则误拦。爬虫看到的页面和你浏览器里看到的可能完全不同。
- 404 / 410：内容明确消失，索引会逐步清理，属于正常回收。
- 429：请求过多，通常是限速触发。短时间密集访问同一目录容易踩到。
- 500 / 502 / 503 / 504：服务端问题。其中 503 如果带上 Retry-After，相当于告诉爬虫“过一会儿再来”，比裸奔的 500 更友好。
- 连接超时：日志里可能只留下一条没有状态码的记录，容易被统计漏掉。
持续 5xx 会带来什么连锁反应
偶尔一次失败，爬虫会把 URL 放回队列重试，影响有限。真正麻烦的是持续失败：重试会占用抓取额度，挤压其他正常页面的抓取机会；如果某个目录甚至整站大面积 5xx，爬虫可能主动降低访问频率，等站点恢复后，还需要一段时间才能回到原来的抓取节奏。
已经收录的页面长期返回 5xx，也可能从索引中消失。这通常不是惩罚，而是系统判断该 URL 无法稳定提供内容，先把它挪出结果。
容易被忽略的几处
- CDN 回源超时，源站日志看起来正常，边缘节点却在报错。
- 缓存失效瞬间的并发，导致部分请求集中失败。
- JS、CSS 等静态资源被拦或超时，页面虽然返回 200，渲染出来的内容却是残缺的。
- 安全策略把搜索引擎的 IP 段限速过狠，正常访问被当成异常流量。
- 日志里把 5xx 当偶发噪声，没有按 URL 做聚合统计。
自查顺序
- 导出服务器日志，按爬虫 UA 与状态码分组，算出 5xx 占比，并看清集中在哪些目录或接口。
- 区分偶发与持续：单次失败可以先放过，同一 URL 连续多日失败就需要查。
- 检查 WAF、CDN 和安全插件规则，确认没有整段屏蔽或过度限速。
- 把静态资源单独看一遍，渲染所需的文件拿不到，页面等于只交付了一半内容。
- 修复后继续观察抓取日志，确认状态码回到 200，再等收录层面的变化。
服务器修好不等于马上收录。抓取频次回升、页面被重新抓取、内容被重新评估，这几步都需要排队，中间隔着的时间往往比想象中长。
故障期间不建议做的几件事
不要在服务不稳的时候批量提交新 URL，抓取额度本来就紧张；不要反复修改 robots.txt，规则一变会让排查线索更难对上；也不要因为几天没收录就换模板或大改 URL 结构。故障期的频繁动作，容易把真正的原因埋在噪声里。
把服务器稳定性当成日常监控项，比每天刷新收录数字更有意义。抓取通畅了，收录才有讨论的前提。