蜘蛛抓取页面时，服务器返回的第一个信息不是内容，而是状态码。很多站点在优化内链、Sitemap 和 URL 结构，却忽略了状态码对抓取节奏的影响——一个持续返回 5xx 的路径，可能让整站的新 URL 发现速度慢下来。
状态码是蜘蛛收到的第一句反馈
状态码决定了蜘蛛接下来做什么：200 会解析内容并沿着链接继续发现 URL；301、302 会跟随到新地址；404 和 410 表示地址不可用，蜘蛛会逐步降低对该 URL 的访问；而 5xx 系列则被理解为“服务器暂时出问题”，蜘蛛会保留这个 URL 并稍后重试。
关键在于“稍后重试”的代价。单次 5xx 影响不大，但如果一个目录、一类模板页或某个接口路径持续返回 5xx，抓取系统会整体调低对站点的抓取频次，而且调低容易，恢复慢。
5xx：最容易被低估的抓取减速器
5xx 不一定是整站宕机。常见的诱因有：
- 数据库连接池耗尽，动态页面在高并发下间歇性报错；
- 缓存层失效，请求直接穿透到后端，超时后返回 500 或 502；
- 图片、字体等静态资源路径配置错误，返回 500；
- 限流策略把蜘蛛的并发请求也一并拦下，返回 502 或 503。
这些问题在人工访问时往往只表现为“偶尔刷新慢一点”，但在蜘蛛批量抓取时会被放大成成片的错误，进而影响同一条抓取路径上的其他正常页面。
429 和 503：主动限速时要说清楚
如果确实需要限制蜘蛛的请求量，用 429（Too Many Requests）或 503（Service Unavailable）比用 403、404 更合适，因为前者明确告诉蜘蛛“稍后再来”，后者可能被理解为地址失效。
更重要的是带上 Retry-After 响应头，给出一个具体的等待秒数或时间点。蜘蛛拿到这个值后，通常会按提示延后重试，而不是在错误里反复试探。
与其让蜘蛛在 5xx 里自己猜恢复时间，不如用 Retry-After 给一个明确的等待窗口。含糊的报错换来的往往是更长时间的抓取空窗。
超时和空响应同样算失败
还有一种情况不体现在状态码上：服务器处理时间过长，蜘蛛在等待中主动断开连接。这时蜘蛛既没拿到内容，也没拿到链接，URL 发现自然停在这一步。常见诱因包括慢查询、同步调用外部接口，以及首字节时间本来就很长的页面。
建议把响应时间的目标定在“稳定”而不是“偶尔很快”：平均值好看、长尾很差的服务端，对蜘蛛来说依然是不稳定的抓取源。
排查与恢复的基本顺序
- 按蜘蛛 UA 聚合服务器日志，统计各状态码的数量和占比，先看清 5xx 集中在哪些路径。
- 区分错误来自源站、CDN 还是 WAF，不少 5xx 实际上是中间层拦截或回源超时。
- 核对限流规则、防火墙策略和 robots.txt，确认抓取请求不是被误伤。
- 修复后持续观察一段时间，抓取频次通常不会立刻回到原来的水平，需要逐步恢复。
- 对已经修复的地址，可以通过 Sitemap 重新提交，帮助蜘蛛再次发现。
稳定的抓取通道，比一次性的提交更重要
URL 发现、内链传递和 Sitemap 提交，都建立在蜘蛛能稳定取回页面这个前提上。服务器频繁抖动时，即使内链结构再清晰，蜘蛛也可能走不到深层页面。把状态码、响应时间和重试提示处理好，抓取路径才会真正顺畅。