有些站点在日志里看不到大量 5xx，却会发现蜘蛛抓取量慢慢下降，状态码里夹着一批 429。429 的意思是请求过多，服务器明确告诉客户端“你发得太快了”。对搜索蜘蛛来说，这不是页面内容问题，而是抓取节奏和服务器承受能力之间的匹配问题。
蜘蛛遇到 429 时会怎么处理
不同蜘蛛的退避策略不完全一样，但大体逻辑相似：先降低对该站点的请求频率，过一段时间再试探性恢复。如果 429 持续出现，蜘蛛可能把更多抓取配额挪到其他站点，或者只保留少量关键 URL 的回访。表现出来就是日志里总抓取量还在，但新 URL 发现变慢，深层页面回访间隔拉长。
需要区分的是，429 和 5xx 的成因不同。5xx 通常意味着服务器出错或过载，429 更像是一道主动设置的闸门。排查时先确认状态码来源，再看限速规则，会少走很多弯路。
哪些服务器设置容易触发 429
- 并发连接数限制：同一 IP 或同一 UA 的并发超过阈值，服务器直接拒绝多余连接。
- 单位时间请求数限速：例如每秒只允许 N 个请求，超出部分返回 429。
- WAF 或安全插件：把蜘蛛 UA 误判为异常流量，触发限速或人机校验。
- 后端资源紧张：数据库慢查询、进程占满时，前置层可能主动限流来保护源站。
- CDN 回源限速：边缘节点回源频率过高，源站返回 429，缓存层再把它传给蜘蛛。
这些规则单独看都合理，叠在一起就容易让蜘蛛频繁撞墙。尤其是新站或刚恢复抓取的站点，蜘蛛可能会在短时间内集中回访，更容易触发限速。
Retry-After 是给蜘蛛的明确信号
返回 429 时，如果能带上 Retry-After 头，告诉客户端多久之后再试，蜘蛛的退避会更平滑。这个时间不宜拍脑袋写，最好参考后端实际恢复速度。写成几秒到几分钟，通常比写成几小时更合适；过长的 Retry-After 会让蜘蛛在很长时间内不再优先访问该站点。
如果站点同时有多个抓取来源，比如搜索蜘蛛、蜘蛛池、站内监控，Retry-After 应尽量统一，避免不同客户端拿到互相矛盾的节奏信号。
怎么判断是不是限速造成的抓取下降
- 按状态码统计蜘蛛日志，看 429 占比和出现时间段。
- 把 429 的 URL 归类：集中在某个目录、某种参数，还是全站均匀出现。
- 对照服务器访问日志和限速规则，确认触发的是并发、频率还是 WAF 规则。
- 观察 429 之后蜘蛛是否仍然回访，回访间隔有没有明显拉长。
- 检查 Sitemap 提交量与实际可抓取量是否差距过大，避免把蜘蛛引向大量低价值 URL。
调整抓取节奏的几个方向
- 对已知搜索蜘蛛适当放宽限速，同时保留对异常请求的防护，不必全站一刀切。
- 如果无法放宽，优先保证重要目录和 Sitemap 中核心 URL 的可访问性。
- 减少不必要的抓取入口：参数筛选、排序、会话 ID 等 URL 尽量用 robots 或 canonical 收口。
- 把抓取压力分散到不同时段，避免定时任务和蜘蛛高峰重叠。
- 检查 CDN 缓存策略，减少缓存频繁失效导致源站被反复请求。
和内链、Sitemap 的配合
限速不是单独的问题。如果内链把蜘蛛大量引向低价值页面，Sitemap 又提交了成千上万条 URL，服务器限速就会更早触发。相反，内链结构清晰、Sitemap 只保留值得抓取的地址，蜘蛛的请求会更集中，429 出现的概率也会下降。
如果使用蜘蛛池或其他方式做 URL 发现，也要注意不要把请求集中打到同一台源站。发现渠道越多，越需要控制总请求量，否则限速规则会先于内容问题暴露出来。
429 是服务器在说“慢一点”，不是“不要来”。把限速规则、抓取日志和 URL 价值梳理清楚，比单纯放开限制更有效。