有些站点担心抓取压力，會主動限制蜘蛛的請求速率。這本身是合理做法，但限制的方式和返回值不一样，蜘蛛後續安排抓取的方式也會跟着變。
限速不等于拒绝
限速的核心意思是「現在太密了，慢一点」，而不是「這個 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 三種情况是否区分清楚，没有混用？
- 是否有一條针對爬虫的獨立限速策略，而不是和普通用戶共用？
- 连續观察一段時間，抓取量和失敗率的變化是否在预期之内？
限速的目标是让抓取更平稳，而不是把蜘蛛推得更遠。把狀態碼寫對、把退避時間说清，比單纯压請求量更有效。