crawl delay：343 个分组里只有四条，没有一条点的是 AI 爬虫

实测 · 2026-08-19 · 30 个站 · 单次快照

样本与口径：与我们此前 robots.txt、sitemap、首页结构、请求链四轮实测同一批 30 个站。每个站请求一次 robots.txt，浏览器 UA，2026-08-19，出口在日本大阪。一个站拒绝了我们，实际解析的是 29 个文件。

29 个 robots.txt 里一共 343 个 user-agent 分组，crawl delay 这条指令只出现了四次。四次。其中三次点的是某一个具体爬虫，一次对所有人生效，而四条里没有一条点的是 AI 爬虫——尽管这 29 个文件里有 13 个在别处点了至少一个 AI 爬虫的名字。

怎么测的

口径在跑之前定死，跑完没改。

1. 用桌面浏览器 UA 请求一次 https://<域名>/robots.txt。
2. 按标准的分组规则解析：连续的 User-agent 行开一个组，第一条非 user-agent 的行把组头关掉。
3. 记下每一个带 Crawl-delay 值的分组，以及这个组管着哪些 UA。

stackoverflow.com 的 robots.txt 返回 418，所以它不进本篇任何计数。上一轮它也是这么回的，至少稳定。

343 个分组里的四条

全在下面。这不是抽样，是我们找到的全部。

规律读得出来。Hacker News 是一台小服务器扛着一个很大的读者群，所以它对所有人限速 30 秒。另外三个各自限了一个具名的商业爬虫，别的都不管。这批站里没有一个把这条指令当成通用策略在用。

顺带一条中文读者会注意到的

github.com 那条限的是 baidu，值是 1 秒。它没有限任何一个 AI 爬虫，也没有限 Googlebot——被单独点名的是一个中文搜索引擎的爬虫。这只是一个数据点，不代表什么普遍趋势，但它说明这类限速通常是「某个具体爬虫来得太凶」之后的补丁，不是事先设计的策略。

Google 根本不支持这个字段

这句话就写在 Google robots.txt 文档里，在「它读哪些字段」那一段里：Google supports the following fields (other fields such as crawl-delay aren't supported)（Google 支持以下字段，其他字段比如 crawl-delay 并不支持）。它支持的四个是 user-agent、allow、disallow、sitemap。这一句和下面引的抓取频率那几句，都是 2026-08-19 在 developers.google.com 的 robots.txt 与「降低抓取频率」两份文档里读的。

所以 Hacker News 那条 30 秒，对 Googlebot 不起任何作用。对别的实现了这条指令的爬虫可能有用——我们没有测哪些爬虫真的遵守，而单看 robots.txt 也测不出来。这是这一带里少数几件只能从自己服务器日志上学到的事之一。

一条最大的那个爬虫不读的指令，不是限速。它是一句请求，说给碰巧读到的人听。

Google 说该怎么做

官方给了替代做法，比多数人预期的更猛：If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.（如果你需要在短时间内——比如几个小时或一两天——紧急降低抓取频率，那就对抓取请求返回 500、503 或 429，而不是 200。）

它带着一个硬时限和一个写明的后果：We don't recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products. For example, in case of Search, if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google's index.（我们不建议长期这么做，也就是超过一两天，因为这会对你的网站在 Google 各产品里的表现产生负面影响。以搜索为例，如果 Googlebot 连续多天在同一个 URL 上看到这些状态码，这个 URL 可能会被从索引里剔除。）

恢复是自动的——Once the number of these errors is reduced, the crawl rate will automatically start increasing again.（这些错误变少之后，抓取频率会自动开始回升。）另外还有一条给「实在没法返回错误码」的站用的慢通道：一张表单，但官方注明 it may take several days for the request to be evaluated and fulfilled（这个请求要几天才会被评估和处理），而且不能拿它申请提高抓取频率。

点名和限速是两种习惯

点名最多的文件，恰恰不是限速的那些。The Verge 的 robots.txt 有 106 个 user-agent 分组、零条限速。纽约时报 57 个，BBC 40 个，维基百科 34 个，Figma 21 个。

这几家正是我们之前测出来大面积屏蔽 AI 爬虫的出版类站点。两个结论并起来读，做法就很清楚了：这些站想让一个爬虫慢下来的时候，它们不让它慢下来，它们直接把它挡掉。29 个文件里 13 个点了至少一个 AI 爬虫的名字，而这些名字全部出现在放行或禁止规则里，没有一个出现在限速上。

你自己该拿 crawl delay 怎么办

两个该做的，两个别做的。

• 已经有的那条留着，如果确实有某个非 Google 的爬虫在拖垮你。它不花什么钱，而且有些爬虫确实读它。
• 真的负载有问题就在服务器上解决：缓存，或者一个会返回状态码的限流，别指望一个文本文件。
• 别指望加一行就能让 Googlebot 慢下来。文档就是那么写的：不支持。
• 别把 429 或 503 挂过一两天。Google 说连续多天看到这些码，URL 可能被剔出索引。

如果你真正担心的是 AI 爬虫吃带宽，那杠杆不在「慢」，在「进不进得来」——哪个爬虫允许进、进来之后拿到什么。它实际从你页面上拿到了什么，可以用 AI 爬虫可达性检查器先过一遍。

访问规则本身怎么一条条写，在 robots.txt 怎么写才管得住 AI 爬虫那篇。同一批文件里还有多少个指了 sitemap，在 sitemap 提交的两条路那篇。

常见问题

你们是怎么测的

2026-08-19，每个站请求一次 robots.txt，浏览器 UA，出口在日本。把每个文件解析成 user-agent 分组，记下每个带 Crawl-delay 值的分组。30 个里解析了 29 个，stackoverflow.com 返回 418。

Google 遵守 crawl delay 吗

不遵守。Google 的 robots.txt 文档列出了它支持的字段，并写明其他字段（其中就包括 crawl-delay）不被支持。

AI 爬虫遵守吗

我们不知道，这次抓取也答不了。要知道答案，得在自己服务器日志里盯着某个具体爬虫，加这一行之前和之后各看一段。

那到底怎么让 Googlebot 慢下来

按官方说法，短时间内对抓取请求返回 500、503 或 429，并且在一两天内停手。另外还有一张申请表单，要几天才处理，而且不能用来申请抓得更多。

30 秒这个值算高吗

对遵守它的爬虫来说，30 秒大约是每天 2,880 个页面，小站够用，大站根本不够。Hacker News 敢这么写，是因为它的内容基本就在一页上。