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 时间戳是否被批量刷新。
- 梳理重复入口，减少同一内容的多路径抓取。