逐个核查 robots.txt 是否挡住 AI 爬虫

同一份 robots.txt，可能把 GPTBot 全站拒之门外，却让 Googlebot 连 /private/ 都能访问。问题不在规则写得够不够多，而在每个机器人究竟会选中哪一组规则。

作者给出的检查方法很直接：先按机器人的 User-agent 找到适用分组，再针对具体 URL 判断，最后用服务器日志核对实际请求。对维护技术博客、文档站的程序员来说，这能帮你分清三个容易混在一起的问题：是否允许训练、是否允许搜索，以及服务器是否真正拦住了访问。

为什么写了通用禁令，机器人仍然能访问

按原文引用的 RFC 9309，机器人会先查找与自身标识匹配的 User-agent 分组，匹配不区分大小写。有对应分组，就使用对应规则；没有，才回退到 *。

下面这份配置，能说明通用规则为什么没有覆盖所有机器人：

User-agent: *
Disallow: /private/

User-agent: GPTBot
Disallow: /

User-agent: Googlebot
Allow: /

要看的是 User-agent: Googlebot 后面的 Allow: /。Googlebot 有自己的分组，因此不会继承 * 下的 /private/ 禁令，可以抓取全部路径。

GPTBot 同样使用自己的分组，但得到的是全站禁止。ClaudeBot 没有专属分组，才会使用 *，只能抓取 /private/ 之外的内容。

专属分组不会自动继承通用分组里的限制。

选中分组后，还得继续判断路径：匹配路径最长的规则优先；如果 Allow 和 Disallow 的匹配长度相同，则 Allow 优先。不能只看文件里哪一行排在前面，也不能检查首页后就认定整站结果相同。

禁止训练和允许被搜索，需要分开配置

厂商可能用不同标识承担训练采集、搜索发现、用户主动请求取页等任务。拦错对象，可能达不到目的，也可能影响你希望保留的搜索入口。

原文重点区分了三个情况：

• GPTBot 对应的限制不能代替 ChatGPT 搜索控制，后者需要看 OAI-SearchBot。
• Google-Extended 不是独立爬虫，没有单独的 User-agent 字符串。实际抓取由 Googlebot 完成，Google-Extended 是用途控制标识，日志里不会出现一个同名爬虫；限制它也不会让页面退出 Google Search。
• ChatGPT-User 属于用户触发的取页场景。原文转述 OpenAI 的说明称，robots.txt 规则可能不适用于它，不能把它当作普通自动爬虫处理。

如果希望页面被搜索和引用，同时拒绝相关训练用途，作者给出了这份配置：

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Disallow: /private/

User-agent: *
Disallow: /private/

要注意搜索分组中的 Disallow: /private/。这里必须重复声明，因为这些机器人有了自己的分组，就不会再采用 * 的规则。

这份配置表达的是站点的访问与用途偏好。它不能保证页面一定被引用，也不能证明内容一定不会被用于训练。

一次有效审计，要查线上文件和访问日志

作者建议从每个主机名实际返回的 /robots.txt 开始检查，各子域名都需要自己的文件。只读仓库里的版本不够，因为 CDN 可能改变最终响应。例如 Cloudflare 的 AI bot 设置可以添加规则，也可能直接在边缘拦截请求。

HTTP 状态码同样影响结果。原文按 RFC 9309 概括：返回 4xx 时，爬虫可以抓取全部内容；返回 5xx 或文件不可达时，爬虫应假定不能抓取内容。这是协议层面的处理预期，不能当成所有机器人的实测行为。

随后列出所有具名分组，逐一检查 GPTBot、OAI-SearchBot、ClaudeBot、Claude-SearchBot、PerplexityBot、Google-Extended、Googlebot 的适用规则。测试对象应包含真实内容路径，例如 /blog/post，每次修改后重新检查。

日志则用来验证实际行为：

• 请求过 /robots.txt，之后没有访问禁止路径，与遵守规则的表现一致。
• 出现 403 或验证挑战页面，说明服务器、防火墙或 CDN 在实施拦截，需要单独排查。
• 被禁止路径仍返回 200，可能是分组理解有误，也可能是机器人没有遵守规则。

最后别只信 User-agent。它很容易伪造。原文建议结合 OpenAI 公布的机器人 IP 范围，以及 Google 为 Googlebot 提供的反向 DNS 验证方法核实身份。

我的判断

我认同作者把规则解析和实际访问分开检查的思路。robots.txt 适合声明抓取偏好；需要保护的内容，仍应通过鉴权或服务器访问控制落实。目录叫 /private/，再加一条 Disallow，并不能让它成为私密区域。

不过，这篇提供的是协议解释与审计方法，没有给出各家机器人遵守规则的对照实验。日志里暂时没出现违规请求，也不足以证明对方始终遵守。作者还介绍了自己开发的免费检查器，但没有展示其解析实现和测试结果，适合作为辅助，不能替代日志核验。

维护成本也要算进去。原文称，社区项目 ai.robots.txt 截至 2026 年 11 月收录了 208 个标识，并可生成 robots.txt 和服务器配置。这个数量说明名单需要持续更新，但不代表把所有标识抄进文件就完成了治理。

能拿来做什么

• 给技术博客或文档站列出明确目标：哪些用途允许，哪些用途拒绝，再配置对应标识，避免用一条全站禁令代替用途选择。
• 在修改 robots.txt 时，同时核对首页、文章页和受限路径；新增专属分组后，检查是否遗漏原先依赖 * 的限制。
• 排查机器人访问异常时，把线上 robots.txt、HTTP 状态码、CDN 设置和访问日志放在一起看，定位规则声明与实际拦截分别发生在哪里。
• 按作者建议，每隔几个月对照更新后的机器人名单检查一次，并在每次规则变更后重新审计。