退避現象往往不是蜘蛛變懒
很多站点运营者發現搜尋蜘蛛抓取量突然下降，第一反應是蜘蛛不来了。但抓取日誌里若密集出現 429、503 或连接超时，更可能的情况是：調度端收到了服務端的负反馈，主動降低了對這個主机的請求频率。抓取预算並没有被砍掉，只是被暂时压低了节奏。
這類問题的难点在于表現一致、成因却很多。下面按先分清信号、再核對配置的顺序梳理。
先把服務端信号分成三類
- 429 Too Many Requests：多為速率限制触發，来源可能是 CDN 或 WAF 的限流規則，也可能是源站應用层的限流中間件。
- 503 Service Unavailable：源站過载、進程池打满、資料库连接耗尽，或正在维護。带 Retry-After 时應重点记錄该值。
- 连接层错誤：超时、连接重置、握手中断。日誌里可能只顯示無法连接，连狀態碼都拿不到。
三類信号的排查方向不同：429 看限流規則，503 看容量與负载，连接层错誤看網絡與服務器稳定性。混在一起看，很容易把 429 当成服務器故障去扩容。
按小时聚合，而不是只看總量
把抓取日誌按小时或按十分钟聚合，观察错誤集中出現的时段。如果错誤只出現在整点或凌晨，優先看定时任務、备份、日誌切割；如果全天均匀出現，則更像限流阈值設定偏低或並發上限過紧。
核對顺序
- 確認日誌時間戳的时区與服務器、CDN 控制台一致，避免把两段错開的時間当成同一事件。
- 統計 429 與 503 的占比、集中时段和涉及的 URL 范围，判断是入口頁還是全站。
- 用同一时段的其他請求做對照，看看普通用戶是否也遇到同样的限流或超时。
- 检查 CDN、WAF、反向代理的限流配置，包括單 IP 速率阈值、並發连接數、突發流量拦截規則。
- 检查源站的定时任務、批量導入、图片處理、全量缓存刷新等是否與抓取高峰重叠。
- 检查 Sitemap 的分片數量與提交频率，是否在短時間内集中推送了大量新 URL。
- 检查内鏈结构在近期是否發生過改版，導致蜘蛛需要重新發現大量路径。
几個容易踩的坑
只看抓取總量
抓取量下降但错誤率正常，可能是站点内容更新變少或入口结构稳定，抓取自然收敛，不一定是故障。反之，抓取量没變但 429 占比升高，說明限流已经在生效，只是還没到影响總量的程度。
用 UA 黑名單處理限流
把搜尋蜘蛛整体封禁来解决限流，短期看似服務器轻松了，長期會让正常的 URL 發現和内容更新同步變慢。更稳妥的做法是調整阈值和並發，而不是一刀切拒绝。
忽视 Sitemap 提交节奏
Sitemap 是入口，也是触發器。一次提交過多新 URL，容易在短時間内形成抓取請求高峰，叠加站内其他流量後触發限流。分片提交、控制新增 URL 的批次大小，比事後調阈值更省事。
退避是服務端與調度端之間的协商结果。恢复通常需要一段時間，具体节奏不由單方面控制。
調整时優先保住的几件事
- 保持首頁到内容頁的点击路径稳定，避免入口在短時間内反复變動。
- Sitemap 分片清晰、地址可訪問，更新時間與内容實际更新保持一致。
- 服務器留出余量，尤其是資料库连接、進程數和带宽在高峰期的上限。
- 监控 429、503 與连接超时的占比，把它們当作和 TTFB 同級的常規指标。
抓取节奏的恢复是渐進的。與其频繁改動配置反复试探，不如先把限流規則、源站负载和入口提交节奏這三件事確認清楚，再观察几天日誌變化。