屏蔽训练爬虫时，别误封 AI 搜索入口

拒绝 AI 训练，和拒绝被 AI 搜索引用，是两件事。作者检查了 528 个站点的 robots.txt，发现禁止 GPTBot 的站点里，66.5% 也拦住了可能带来引用和访问的爬虫。问题可能出在一份看似简单、实际很容易误配的文件里。

这篇最有用的地方，是把训练、搜索索引和用户即时访问拆开讨论。对维护内容站、技术博客或产品文档的开发者来说，值得检查的不是「有没有封 AI」，而是每条规则究竟封住了谁。

拦住训练，为什么会连引用入口一起关掉

原文区分了 OpenAI 的三个 token，也就是 robots.txt 用来匹配访问者身份的名称：

• GPTBot 获取用于未来模型训练的内容。
• OAI-SearchBot 为 ChatGPT 浏览功能背后的搜索索引抓取内容，让页面具备被引用的资格。
• ChatGPT-User 在用户等待回答时发起访问，相关引用可以成为用户点击的链接。

因此，允许后两者访问，并不等于允许 GPTBot 训练。

训练授权与搜索发现，应该分别配置。

作者从 2026-11-07 下载的 Tranco top-1M 排名中，按 .com、.de、.fr、.es、.it、.jp、.nl 七类后缀，各选排名最高的 100 个域名，共 700 个。抓取通过 HTTPS 进行，先尝试 www，再尝试裸域名，跟随重定向，超时设为 12s。

最终成功读取 528 个站点；137 个无法访问，35 个返回了 HTML，而非预期的 robots.txt。

在成功读取的样本中，161 个禁止 GPTBot，其中 107 个也禁止了至少一种可能带来访问的爬虫，占 66.5%。全部有效样本里，只有 10.2% 做到了禁止训练、同时保留发现入口。另有 17.2% 拦住可能引用自己的 AI 爬虫，却允许 Googlebot。

市场之间也有差异。德国 .de 与 .com 禁止 GPTBot 的比例接近，分别是 30.9% 和 34.4%；但禁止流量相关爬虫的比例分别为 12.3% 和 29.7%。荷兰在两类封禁上都最高，日本则很少封禁。

这些数字说明配置存在差异，却不能直接证明站长配错了。作者把其中一部分解释为无意封禁，这是结合个别站点检查得出的判断，不是对所有站长意图的测量。

为什么看起来正确的规则，会产生相反效果

作者按照 RFC 9309 判断路径 / 的访问权限：存在匹配身份的专用分组，就使用该分组；没有才回退到 *，两者不叠加。匹配规则按最长匹配优先，同等长度时 Allow 胜出。

容易踩坑的是，开发者常把它理解成 CSS 那样的覆盖关系：先设一个全局限制，再补一点例外。这里不能这样读。

例如，通配组禁止 /，再给 Googlebot 单独允许 /，确实可以只放行 Google。但没有专用分组的 AI 爬虫也会落入通配组，一并被封。文件语法完全正确，自然不会因为违背站长意图而报错；作者指出，Search Console 也不会给出这种提醒。

更反直觉的是，下面这段用来展示「空分组为什么会放行」：

User-agent: *
Disallow: /

User-agent: GPTBot

要盯住最后一行：GPTBot 有自己的分组，但组内没有禁止规则，因此不会继承通配组的限制。作者发现，有人写下它时以为自己在封禁。

同理，Google-Extended 与 Googlebot 是不同 token。给前者设置 Disallow: /，不会限制后者。

如果目标是拒绝训练、保留引用入口，作者给出的完整示例如下：

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

关键是给需要单独表达态度的 token 建立明确分组，尤其是最后两个 Allow；不要指望一个 * 同时表达多种用途的取舍。

作者还把匹配器开源为 MIT 项目。命令 npx github:orenhacham-lab/ai-crawler-access nytimes.com 可以检查站点，原文称其零依赖、无需构建、一次网络请求。它会输出每个爬虫的判定，以及产生结果的具体行。Node 中也可通过 import { checkRobots, summarize } from 'ai-crawler-access' 调用，再执行 await checkRobots('example.com') 和 console.log(summarize(result))。

这类解释比一个红色「已封禁」标签更实用：你能知道结果来自哪个分组、哪条规则，才有办法修改。

我的判断

我认同把训练和发现拆开管理，也认同检查器应该解释命中的规则。相比直接复制「禁止所有 AI」的模板，这种方式更符合内容站的实际需求。

但标题里的「带来流量」，需要打个问号。作者测量的是 robots.txt 的允许与禁止，没有提供引用次数、点击量或修改配置前后的流量对照。允许抓取只是开放入口，并不保证收录、引用，更不保证用户点击。

样本也有限。它集中于高排名域名，不能代表中小网站；作者明确承认，还需要另一组低排名样本。172 个未成功读取的站点没有进入有效结果，结论应限定在成功读取的 528 个站点内。此外，判定只针对 /，不能据此断言文章页、文档目录和其他路径的权限完全一致。

还有两类边界不能混淆。Google-Extended 和 Apple 的对应 token 本身不执行抓取，而是控制已抓取内容的用途；原文称两家运营方都说明，这类限制不会使站点退出搜索结果。部分其他代理则明确表示可能忽略 robots.txt，所以文件表达的是请求，不能充当访问控制。

作者的数据集采用 CC BY 4.0，以 JSON、CSV 提供。每条记录附有运营方文档来源和读取日期，缺少官方依据的 token 单独列为 candidates。这个证据分层值得保留，但它也只说明文档如何描述行为，不能替代对实际请求的观察。

能拿来做什么

• 维护博客、产品文档或内容站时，先明确是否拒绝训练、是否希望被搜索引用，再逐项检查 GPTBot、OAI-SearchBot 和 ChatGPT-User 的有效规则，不要只搜索文件里有没有这些名字。
• 排查线上配置时，除了 /，也应检查真实文章路径和文档目录；重点留意只有 Googlebot 例外的通配封禁，以及没有任何规则的专用分组。
• 在 Node 发布检查中接入 checkRobots 与 summarize，保留命中行的输出，帮助团队审查 robots.txt 变更；上线后再结合访问日志与来源统计判断效果。
• 让 AI 编程助手修改 robots.txt 时，把「拒绝哪些用途、保留哪些入口」写进需求，并要求解释分组匹配结果，避免只得到一份语法正确、意图不符的文件。