退避现象往往不是蜘蛛变懒
很多站点运营者发现搜索蜘蛛抓取量突然下降，第一反应是蜘蛛不来了。但抓取日志里若密集出现 429、503 或连接超时，更可能的情况是：调度端收到了服务端的负反馈，主动降低了对这个主机的请求频率。抓取预算并没有被砍掉，只是被暂时压低了节奏。
这类问题的难点在于表现一致、成因却很多。下面按先分清信号、再核对配置的顺序梳理。
先把服务端信号分成三类
- 429 Too Many Requests：多为速率限制触发，来源可能是 CDN 或 WAF 的限流规则，也可能是源站应用层的限流中间件。
- 503 Service Unavailable：源站过载、进程池打满、数据库连接耗尽，或正在维护。带 Retry-After 时应重点记录该值。
- 连接层错误：超时、连接重置、握手中断。日志里可能只显示无法连接，连状态码都拿不到。
三类信号的排查方向不同：429 看限流规则，503 看容量与负载，连接层错误看网络与服务器稳定性。混在一起看，很容易把 429 当成服务器故障去扩容。
按小时聚合，而不是只看总量
把抓取日志按小时或按十分钟聚合，观察错误集中出现的时段。如果错误只出现在整点或凌晨，优先看定时任务、备份、日志切割；如果全天均匀出现，则更像限流阈值设置偏低或并发上限过紧。
核对顺序
- 确认日志时间戳的时区与服务器、CDN 控制台一致，避免把两段错开的时间当成同一事件。
- 统计 429 与 503 的占比、集中时段和涉及的 URL 范围，判断是入口页还是全站。
- 用同一时段的其他请求做对照，看看普通用户是否也遇到同样的限流或超时。
- 检查 CDN、WAF、反向代理的限流配置，包括单 IP 速率阈值、并发连接数、突发流量拦截规则。
- 检查源站的定时任务、批量导入、图片处理、全量缓存刷新等是否与抓取高峰重叠。
- 检查 Sitemap 的分片数量与提交频率，是否在短时间内集中推送了大量新 URL。
- 检查内链结构在近期是否发生过改版，导致蜘蛛需要重新发现大量路径。
几个容易踩的坑
只看抓取总量
抓取量下降但错误率正常，可能是站点内容更新变少或入口结构稳定，抓取自然收敛，不一定是故障。反之，抓取量没变但 429 占比升高，说明限流已经在生效，只是还没到影响总量的程度。
用 UA 黑名单处理限流
把搜索蜘蛛整体封禁来解决限流，短期看似服务器轻松了，长期会让正常的 URL 发现和内容更新同步变慢。更稳妥的做法是调整阈值和并发，而不是一刀切拒绝。
忽视 Sitemap 提交节奏
Sitemap 是入口，也是触发器。一次提交过多新 URL，容易在短时间内形成抓取请求高峰，叠加站内其他流量后触发限流。分片提交、控制新增 URL 的批次大小，比事后调阈值更省事。
退避是服务端与调度端之间的协商结果。恢复通常需要一段时间，具体节奏不由单方面控制。
调整时优先保住的几件事
- 保持首页到内容页的点击路径稳定，避免入口在短时间内反复变动。
- Sitemap 分片清晰、地址可访问，更新时间与内容实际更新保持一致。
- 服务器留出余量，尤其是数据库连接、进程数和带宽在高峰期的上限。
- 监控 429、503 与连接超时的占比，把它们当作和 TTFB 同级的常规指标。
抓取节奏的恢复是渐进的。与其频繁改动配置反复试探，不如先把限流规则、源站负载和入口提交节奏这三件事确认清楚，再观察几天日志变化。