有些站点担心抓取压力，会主动限制蜘蛛的请求速率。这本身是合理做法，但限制的方式和返回值不一样，蜘蛛后续安排抓取的方式也会跟着变。
限速不等于拒绝
限速的核心意思是「现在太密了，慢一点」，而不是「这个 URL 不要了」。蜘蛛对这两种信号的解读完全不同：前者会让它推迟抓取，后者可能让它把页面从待抓列表里划掉。所以限速时返回什么状态码，值得先确认清楚。
429 与 503 的差别
- 429 Too Many Requests：服务器还在正常工作，只是当前请求超过了允许的速率。这是限速最贴切的表达。
- 503 Service Unavailable：服务暂时不可用，通常指后端过载、维护或依赖故障，语义比 429 更重。
- 403 Forbidden：表示拒绝访问。用它来限速，容易让蜘蛛把请求理解成「禁止抓取」。
如果是限速，优先用 429，并尽量带上 Retry-After 头，告诉蜘蛛多久之后可以再来。有这个头，蜘蛛不必自己猜；没有，它只能按经验往后退，节奏会更保守。
Crawl-delay 能做什么，不能做什么
Crawl-delay 写在 robots.txt 里，形式上是请求间隔的秒数。它的局限主要有两点：一是并非所有蜘蛛都完全遵守；二是主流搜索引擎在自家站长平台里另有抓取速率设置，那个设置的实际权重往往更高。
所以 Crawl-delay 更适合当作辅助手段。如果服务器确实吃紧，与其只写一行 Crawl-delay，不如同时观察日志和抓取统计，看真实请求量落在什么区间。
限速之后，蜘蛛可能的行为
- 降低对该主机的请求频率，一段时间内的抓取总量可能下降。
- 如果 429 或 5xx 长期大量出现，抓取节奏会更保守，恢复需要时间。
- 已经发现的 URL 一般仍会排队等待，只是抓取被推迟，而不是立刻消失。
- 抓取日志里会积累失败记录，失败率上升也会反过来影响蜘蛛对站点可用性的判断。
限到什么程度比较合适
- 先看服务器实际能扛住多少并发，再回推允许的请求速率，而不是凭感觉设一个数字。
- 用日志或站长平台的抓取统计，找出请求集中的时段，重点在这些时段做限制。
- 优先限制对动态、重查询类 URL 的抓取，静态资源可以放得宽一些。
- 限速规则尽量按目录或参数区分，避免全局一刀切，把正常页面的抓取也一起压下去。
几个容易踩的坑
- 用 WAF 或 CDN 直接给蜘蛛返回 403，蜘蛛没法区分这是策略还是故障。
- 按 IP 段整段屏蔽，可能连正常的抓取请求一起挡掉。
- 限速响应不带 Retry-After，蜘蛛只能自己估算退避时间。
- 把限速错误当成 404 返回，会让蜘蛛以为页面已经不存在。
一份简单的检查清单
- 服务器在压力升高时，是返回 429，还是直接超时或 5xx？
- 限速响应里是否带了 Retry-After？
- 429、503、403 三种情况是否区分清楚，没有混用？
- 是否有一条针对爬虫的独立限速策略，而不是和普通用户共用？
- 连续观察一段时间，抓取量和失败率的变化是否在预期之内？
限速的目标是让抓取更平稳，而不是把蜘蛛推得更远。把状态码写对、把退避时间说清，比单纯压请求量更有效。