5xx 和超时，蜘蛛看到的是两种信号
500、502、503、504 这类状态码，是服务器明确告诉蜘蛛“我这边出了问题”；而超时是指服务器在蜘蛛设定的等待时间内没有给出任何响应，蜘蛛拿到的是“没有回应”，不是一个明确的错误码。两者共同点是：这次抓取没有取到内容，一次抓取机会被消耗掉了。
区别在于后续判断。503 通常被理解为“暂时不可用”，如果带上 Retry-After，蜘蛛可能按提示稍后再来；但如果一个地址长期返回 503，又看不到任何恢复迹象，它也可能被当成持续不可用处理。超时则更容易被归到网络或服务器响应能力的问题上，排查方向偏向源站性能和链路稳定性。
出错之后，蜘蛛通常不会立刻放弃
单次失败往往先进入重试流程，间隔逐步拉长。如果同一目录、同一 IP 下大量 URL 连续失败，蜘蛛更可能降低整站的抓取频率，而不是逐个反复重试。这也是为什么一次持续数小时的故障，影响面通常大于“几条 URL 抓失败”。
短期影响
- 待抓队列里的 URL 被推迟，新页面被发现的时间变晚；
- 已有页面的回访间隔被拉长，内容更新不能被及时看到；
- 抓取额度花在失败请求上，有效抓取量下降。
需要留意的滞后效应
持续的 5xx 或超时，会让蜘蛛对站点稳定性形成判断。故障结束后，抓取频率的回升往往滞后于服务器恢复正常的时间。换句话说，服务器一好，抓取并不一定立刻回到原来的样子。
故障恢复期可以做的事
- 先看日志确认错误类型分布：错误集中在某个目录、某个 IP，还是全站？集中型问题通常更好定位。
- 区分故障来源：源站超时、数据库慢查询、缓存击穿、上游回源失败，处理方式完全不同。
- 恢复后对比数据：观察故障前后同一时段的蜘蛛请求数、状态码比例、被抓取 URL 数量是否回到正常水位。
- 更新 Sitemap 中的 lastmod：这能给蜘蛛一个“这批页面有变化”的提示，但能否立即抓取仍取决于蜘蛛自己的安排。
- 不要急着用大量 404 或跳转清理坏链，先确认这些 URL 是否还有访问价值。
把稳定性做成可预期的事
抓取中断大多不是突然发生的，而是容量、超时设置和监控缺失一点点累积的结果。
- 给蜘蛛请求和用户请求设置合理超时，避免慢请求占满工作进程；
- 对需要查库、动态生成的页面加缓存，减少后端压力；
- 限制单 IP 并发，避免一次抓取高峰把源站打满；
- 为可降级的模块准备静态兜底，宁可返回不完整但可用的页面；
- 把 5xx 比例、响应时间分位数纳入日常监控，而不是等抓取量下滑才发现。
抓取中断不会直接决定页面是否被收录，但它会推迟蜘蛛看到内容的时间。对更新频繁的站点来说，这段时间差往往就是流量差。
怎么判断“已经恢复”
可以从三件事上看：日志里 200 状态码的比例是否回到正常，新发布的 URL 是否重新进入抓取队列，以及抓取深度、抓取 URL 总数是否回到故障前水平。如果一两周后抓取量仍然偏低，再从内链结构、Sitemap 覆盖范围、robots 规则等方向逐项排查，而不是反复提交同一批地址。