robots.txt 里有一行 crawl-delay，写法简单，很多站点把它当成让蜘蛛慢点抓的开关。实际运行时，它的效果取决于对方是否愿意读、读了是否愿意照做。把它当成一份请求，而不是一道命令，理解会更准确。
crawl-delay 限制的是谁
crawl-delay 是 robots.txt 中的一个非标准指令，单位是秒，含义是两次请求之间请至少间隔这么久。它没有进入 robots.txt 的正式规范，属于各家抓取器自行决定是否支持的扩展。同一个数值，在不同的抓取器眼里可能是规则，也可能是一行被忽略的注释。
- Bing 的抓取器长期支持并读取 crawl-delay，会把它作为节奏参考。
- Google 的抓取器不使用 crawl-delay，抓取节奏由抓取预算与服务器响应情况决定，官方建议通过 Search Console 中的抓取速度设置来调整。
- 其他搜索引擎与第三方抓取工具态度不一，有的读，有的只当普通字段跳过。
- 各类采集脚本通常不解析 robots.txt，更不会理会这一行。
也就是说，crawl-delay 能覆盖的范围比很多人以为的要窄。它对正规搜索引擎可能有一点作用，对不请自来的抓取基本没有约束力。
写法上，它需要放在对应的 User-agent 分组里，例如在面向所有抓取器的分组后写一行 Crawl-delay: 5，表示希望两次请求之间间隔 5 秒。数值过小没有实际意义，过大又容易被忽略，比较稳妥的做法是先设一个偏保守的值，再根据日志逐步调整。
写了却不见效的几种情况
- 主流的那个蜘蛛恰好不读这个字段，写了等于没写。
- robots.txt 本身被 CDN 缓存或返回了错误状态，抓取器读到的是旧版本甚至是空内容。
- 数值设得过大，比如 60 秒以上，部分抓取器会直接忽略整条指令。
- 站点同时存在多个域名或协议版本，抓取器读的是另一个域名下的 robots.txt。
- 指令写在 User-agent 分组之外，或者拼写有误，被解析器跳过。
排查时先用抓取器的视角确认 robots.txt 能被正常取到，再看指令有没有落在对应分组里，最后才判断对方是否支持这条字段。
当它不生效时，更可控的做法
用状态码表达压力
服务器过载时，与其默默把请求拖到超时，不如尽快返回 429 或 503，并在 Retry-After 里给出建议等待时间。抓取器读到这类信号，通常会主动放慢甚至暂停。单纯延长响应时间也有类似效果，但容易连带影响真实用户，需要权衡。
从日志里读出真实节奏
把日志按分钟聚合，看单个抓取器每分钟的请求数、响应时间分布、最常见的 URL 类型。有了这组数据，才能判断是蜘蛛抓得太猛，还是站点自己的慢查询在放大压力。
把抓取额度引向重要页面
如果列表页、筛选页、参数页大量生成可抓取 URL，抓取器会花更多请求在这些低价值地址上。收紧这些入口，让内链和 Sitemap 指向真正需要被发现的内容，比调 crawl-delay 更接近问题的根。
分层限流而不是一刀切
在反向代理或 WAF 层面对已知抓取器做速率限制，把阈值设成可调节的，比在 robots.txt 里写一个固定秒数灵活。注意区分不同抓取器，避免把正常用户的访问也一起限掉。
怎么验证调整有没有用
- 调整前后各观察一段时间的日志，比对请求频率和响应时间的变化。
- 确认重要页面仍能被正常抓取，不要为了降速把关键入口一起挡住。
- 检查服务器错误率，限流规则过严会带来大量 429，反而浪费抓取机会。
另外，抓取节奏并不只由 robots.txt 决定。同一台服务器上，页面响应越快，抓取器在单位时间内能走的地址就越多；响应越慢，节奏自然会被压下来。所以调 crawl-delay 之前，先看看服务器的实际表现，往往更能解释为什么蜘蛛走得快或走得慢。
crawl-delay 更像一张贴在门口的纸条，愿意看的人会看一眼。真正决定抓取节奏的，往往是服务器给出的响应速度、状态码，以及站点里有多少值得抓的地址。