429 不是“封禁”，而是一次减速信号
当服务器返回 429 Too Many Requests，意思是“请求太多了，先停一停”。它和 403 不同，403 更像拒绝访问，429 则是限流。对搜索蜘蛛来说，429 通常不会直接导致页面被永久放弃，但会打乱原本的抓取节奏。蜘蛛会根据响应头、历史抓取表现和站点整体稳定性，决定是降低频率、延后重试，还是暂时减少对该目录的抓取。
很多站点在压力大时会用防火墙或 CDN 规则统一返回 429，这能保护源站，但也可能让蜘蛛把“暂时繁忙”理解成“这个站点不太稳定”。如果 429 持续出现，抓取队列里的 URL 可能被排到更后面，新页面和更新内容的发现速度也会变慢。
Retry-After 是给蜘蛛的等待提示
429 响应里可以带一个 Retry-After 头，告诉客户端多久之后可以再试。它可以是秒数，也可以是一个 HTTP 日期。蜘蛛通常会参考这个值来调整重试时间，而不是立刻反复请求。
如果 Retry-After 设得太短，蜘蛛可能很快回来，服务器压力没有真正缓解；设得太长，又可能让正常抓取被拖延。
比较稳妥的做法是结合当前负载设置一个合理的等待窗口，比如几分钟到几小时，而不是几秒。对于短期高峰，可以短一些；如果是计划内维护或持续限流，宁可长一点，也不要让蜘蛛在门口反复撞。
429、503 和 Crawl-delay 各管什么
- 429：针对“请求频率过高”的限流，适合短时保护。
- 503：表示服务暂时不可用，更适合维护、过载或后端故障；带 Retry-After 同样有用。
- Crawl-delay：写在 robots.txt 里，是站点对抓取间隔的长期建议，但支持程度不一。
三者不要混用。比如源站已经恢复，却因为 CDN 缓存或规则继续返回 429，蜘蛛会一直收到错误的减速信号。反过来，如果只是某个接口被刷，却把整站都设成 429，也会误伤正常的页面抓取。
站点侧可以做的几件事
- 先看日志里 429 的比例和来源。如果集中在少数路径，优先修这些路径的限流规则，而不是全站加码。
- 检查 Retry-After 是否合理，避免过短或过长；没有这个头时，蜘蛛只能按自己的策略退让。
- 区分蜘蛛与普通用户的限流策略。可以用 User-Agent 或反向 DNS 验证，但不要完全依赖 UA 做唯一判断。
- 如果站点长期资源紧张，先优化动态查询、缓存和数据库，再考虑调整抓取频率。
- 观察抓取覆盖和服务器错误率的变化。429 下降后，抓取节奏通常会逐步恢复，但不会瞬间回到原水平。
别让限流变成长期状态
429 适合应急，不适合当常态。长期返回 429，等于不断告诉蜘蛛“这里很挤”。蜘蛛可能会减少对站点的抓取投入，把预算分给更稳定的站点。对于内容更新频繁的栏目，这种减速会直接影响新 URL 的发现和旧页面的重访。
如果确实需要控制抓取，优先用 robots.txt 的 Crawl-delay 或更精细的路径规则，并确保规则不会挡住关键页面。限流的目标是保护服务器，而不是把蜘蛛挡在门外。
最后，定期从服务器日志里看 429 的时间分布和路径分布，比只看单日总数更有用。抓取节奏的变化往往先出现在日志里，再反映到抓取覆盖数据上。