有些站点在日誌里看不到大量 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 價值梳理清楚，比單纯放開限制更有效。