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 更像一張贴在门口的纸條，愿意看的人會看一眼。真正决定抓取节奏的，往往是服務器给出的响應速度、狀態碼，以及站点里有多少值得抓的地址。