不少站点在抓取異常时的第一反應是“蜘蛛来得太少”。但另一個同样常见的問题是反過来的：蜘蛛来得太频繁，服務器扛不住，于是開始返回 429 或 503，抓取量反而掉下去。抓取速率本质上是站点與搜尋引擎之間的一次协商，站点並不是只能被動接受。
抓取速率由哪几方共同决定
- 搜尋引擎的全局調度：不同引擎、不同站点權重，預設並發和频次並不相同。
- 站点声明：robots.txt 里的 crawl-delay，以及 HTTP 响應中的限速狀態碼。
- 平台侧設定：部分站長平台提供抓取频次或爬虫压力反馈入口。
- 服務器實际能力：带宽、CPU、資料库查询耗时、動態渲染開销。
任何一方單獨變化，效果都會被另外几方抵消。所以調整之前，先確認自己面對的瓶颈究竟在哪一层。
三類常见的限速信号及适用范围
robots 中的 crawl-delay
在 robots.txt 中寫 User-agent: * 與 Crawl-delay: 5，表示希望同一爬虫两次請求之間間隔约 5 秒。需要注意的是，各引擎對這個指令的支持程度並不一致，有的完全忽略，有的只對特定 UA 生效。把它当作建议而非開關，寫完要用日誌驗證請求間隔有没有變化。
429 與 503 狀態碼
当服務器压力過大时，返回 429（請求過多）通常比返回 500 更合适，因為它语义明确，属于可恢复的限速信号。503 配合 Retry-After 响應头，可以告诉爬虫多久之後再试。两点要注意：一是不要長期返回 429/503，否則容易被理解為站点持續不稳定；二是不要用 200 狀態碼承载“稍後再来”的提示頁，那只會让爬虫繼續消耗抓取预算。
平台侧的抓取频次設定
部分站長平台允许手動指定抓取频次，或提供爬虫压力反馈。這類數值更像上限性质的建议值：調高不會立刻带来更多抓取，調低却會實际压低請求量。改動的观察周期通常需要几天到一两周，不宜频繁来回切換。
從訪問日誌讀出真實压力
調整之前，先用日誌確認現状，重点看以下几组資料：
- 單位時間内的蜘蛛請求數，按分钟聚合，观察峰值而非只看均值。
- 並發连接數，以及這些连接是否集中在少數耗时接口上。
- 响應時間分布，平均耗时容易被少量极慢請求拉偏，看 P95 更有參考價值。
- 狀態碼构成，以及 429、503、5xx 的占比和出現时段。
- 字节速率，大頁面和大图片占用的带宽往往比頁面數量更致命。
如果請求峰值恰好與业務高峰重叠，問题可能不是“抓取太多”，而是“抓取时段不合适”。
調整顺序：先保稳定，再谈提速
- 先解决導致超时的根因，例如慢查询、同步渲染、未加缓存的热点接口。
- 再為蜘蛛配置相對獨立的资源配額或缓存策略，避免與真實用戶争抢。
- 然後在 robots 或平台侧設定一個偏保守的频次，观察一到两周。
- 確認错誤率、响應時間稳定後，再以較小幅度逐步上調。
- 每次調整後保留對照資料，避免多因素同时變化導致無法归因。
抓取速率調整的目标不是让蜘蛛来得更多，而是让每一次抓取都能拿到有效内容。稳定性下降时，抓取量的增長通常也维持不住。
几個容易踩的坑
- 用 IP 封禁代替限速：短时封禁可能触發更長的退避，恢复周期比预期更久。
- 對整站统一限速：栏目頁、列表頁與詳情頁的開销差別很大，分級處理更合理。
- 只在 robots 里寫了 crawl-delay 就認為萬事大吉，忽略日誌驗證。
- 把 429 当成長期补丁挂着，掩盖了真實的性能問题。
最後提醒一点：抓取速率與 URL 發現、内鏈结构是相互影响的。如果站点存在大量低價值入口，即使把速率調高，抓取预算也會被消耗在意义不大的頁面上。先理清入口，再谈速率，往往更省力。