Crawl-delay 常被当成控制抓取压力的開關：在 robots.txt 里寫上一行，就觉得蜘蛛會按秒數排队。實际使用中，它更像一條建议——愿不愿意讀、讀到後折不执行，取决于具体引擎。把它当成唯一手段，往往會在流量波動时措手不及。
Crawl-delay 實际约束了谁
它是 robots.txt 的非标准扩展指令，並非所有主流引擎都支持。有的引擎歷史上支持過並逐步弱化，有的從一開始就明确不讀取该字段，而是依據站点响應速度、错誤率、内容更新频率自行决定抓取节奏。因此先要明确：寫下數值只是表達意愿，真正决定請求量的仍是對方調度和你服務器的反馈信号。
声明之後抓取量没降，常见于這几種情况
- 引擎不讀取该指令：日誌里請求數毫無變化，通常就是這一條。
- 並發與连接數被誤讀：延迟约束的是同一来源的請求間隔，多個抓取节点並行时，總量仍可能翻倍。
- 响應變快反而被上調：服務端優化後，引擎會主動提高抓取频次，节流声明被抵消。
- 入口數量增加：Sitemap、Feed、外鏈、站内聚合頁同时提供入口，抓取任務随之變多。
- lastmod 频繁抖動：Sitemap 中時間戳反复變化，會让引擎判定内容一直在更新。
用日誌核對节流是否真的生效
把蜘蛛 UA 的請求按分钟聚合，看峰值、均值與請求路径分布，再把 robots.txt 修改前後各取一周做對比。注意区分同一 IP 段與分散 IP：若請求量没變但分布更散，說明對方只是換了节点，並未降速。同时观察狀態碼结构，如果 5xx 占比上升，抓取频次下降可能是错誤触發的，而不是 Crawl-delay 起作用。
UA 字符串可以伪造，节流评估要结合 IP 段、請求時間間隔和訪問路径一起看，單看 UA 容易得出错誤结论。
比 Crawl-delay 更可控的做法
- 先降响應耗时：慢响應會让請求在连接上堆积，這是抓取压力的主要来源之一。
- 短时使用 503 與 Retry-After：在确實扛不住时返回明确的重试時間，比長期压制更干净，但不宜常態化。
- 补上缓存相關响應头：减少未變更内容的重复传輸。
- 收敛 Sitemap 條目：只保留稳定、重要、可返回正常内容的 URL。
- 整理内鏈入口：减少同一頁面被大量重复路径指向的情况。
什么时候不建议用它
新站或内容量較小的站点，抓取總量本身有限，压制間隔只會拉長新 URL 的發現等待時間。對這類站点，優先優化服務端稳定性和入口结构，比限制對方节奏更划算。抓取频次的最终調节權在引擎手里，站点的可控項是响應质量、入口清晰度和内容更新信号的一致性。
核對清單
- 確認目标引擎是否讀取该指令，別預設全部生效。
- 按分钟統計蜘蛛請求，区分峰值與均值。
- 對比修改前後至少一周的資料窗口。
- 观察 5xx 與超时占比，判断频次變化的原因。
- 检查 Sitemap 時間戳是否被批量刷新。
- 梳理重复入口，减少同一内容的多路径抓取。