robots.txt AI 配置矩阵

很多“robots.txt 对 AI 没用”的结论，其实来自配置错误而不是协议失灵。robots.txt 的标准本体是 RFC 9309，Google 的规范文档现势在 developers.google.com/crawling/ 下（2026-07 迁址后的新路径）；语法语义的完整背景见robots.txt（AI 语境），逐条爬虫档案（谁是谁、验证端点）见AI 爬虫全景档案表，三型用途的概念底座见训练·检索·用户触发爬虫（三型）。本页只解决三件事：语法上最容易踩的坑、状态码的边界行为、以及给一组可直接抄的配置矩阵。

为什么你的 robots.txt 管不住 AI 爬虫

按概率排序有三个原因。第一，具名组不继承 * 组——Google 规范原句是 “User agent specific groups and global groups (*) are not combined”：写在 User-agent: * 下的规则，对任何具名的 AI 爬虫都不生效，必须逐条写具名组。第二，把纯控制令牌当成爬虫去挡——Google-Extended 根本没有 UA、不抓取，屏蔽它挡不住 Googlebot。第三，一类 user-triggered 爬虫官方就不承诺遵守 robots.txt，协议层本来就管不到它们（本页最后一节展开）。前两个是写法问题，第三个是协议边界。

语法四则：官方规范里最常被踩的坑

各家官方指引在哪

写配置前先收藏一手来源——二手教程的滞后在爬虫这一栏尤其危险（2025-2026 间 Google 文档整个迁址、OpenAI 文档换域名）。六家的官方指引如下：

Meta 的一条官方表态值得记入配置依据：Meta 声明偏好行业标准 robots.txt，而非 NoAI 标签等非标准格式——对 Meta 系五条爬虫的控制，入口就是 robots.txt 具名组，不必找别的开关。

状态码语义：4xx、5xx、3xx 各意味着什么

robots.txt 本身的 HTTP 状态码决定它的效力，这一节是 2026 现势里最常被误读的部分。

两个实操注脚。其一，429 的单列意味着它是唯一保留“限制”语义的 4xx——但官方未给出细节，不要围绕它搭限速方案。其二，5xx 三阶段里“沿用最后好版本 30 天”说明 Google 会缓存 robots.txt 的最后有效版本：短暂的部署事故不会立刻全站失防，但超过 30 天不修复，规则就真的失效了。

纯令牌与真爬虫：二分法

AI 语境最大的单项配置错误，是以为屏蔽 Google-Extended 能阻止 Googlebot。Google-Extended 无 UA、不抓取，只是 robots.txt 里的控制令牌——管的是“你的内容是否用于训练未来的 Gemini，以及 Gemini Apps 与 Vertex AI 的 grounding”，官方原文明确“不影响 Google Search 收录，也不用作排名信号”（令牌背景见Google-Extended）。Applebot-Extended 同理：不自行抓取，只控制使用授权，屏蔽不影响搜索可见性。二分法记住一句：有 UA、会发请求的是爬虫，写不写决定它“能不能来”；无 UA、只读 robots.txt 的是令牌，写不写决定“来了能怎么用”。而“来了之后能怎么用”的下一代表达——按用途逐项声明偏好——就是 IETF 的 AIPREF 草案（见AIPREF（Content-Usage 声明）），它直接以 robots.txt 为附着点。

三种姿态的配置矩阵

姿态一，检索放行、训练屏蔽——多数内容站的默认推荐：

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: meta-externalagent
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: *
Disallow: /private/

注意写法本身就在演示组继承规则：检索爬虫各组必须显式 Allow: /，它们不会从 * 组“继承”任何放行。姿态二，全放行——不写任何 AI 具名组即可，但务必保证 JS/CSS 等渲染资源不被 Disallow（Google 渲染依赖 JS/CSS，官方示例 robots.txt 里甚至专门 Allow: /includes/；Applebot 同样会渲染）。姿态三，全屏蔽 AI——把训练与检索爬虫逐条 Disallow: /，并接受退出 AI 引用池的代价；即便如此也管不住下一节这一类。

Applebot 还有一条会悄悄改变配置效果的独有规则：robots.txt 里没有 Applebot 条目、但有 Googlebot 条目时，Applebot 跟随 Googlebot 组的规则。也就是说，只给 Googlebot 写了放行的站点，等于顺手放行了 Applebot；反过来想单独挡 Applebot，必须显式写 Applebot 条目，“只挡 Googlebot”挡不到它。

user-triggered 例外：协议的边界

ChatGPT-User、Perplexity-User（官方原文 generally ignores robots.txt rules）、meta-externalfetcher（可绕过 robots.txt）、facebookexternalhit（可因安全检查绕过）——这类由用户动作触发的抓取，不在 robots.txt 的约束设计之内。这是本栏对这一例外的唯一展开位置，其余档案页均内链至此。结论是方向性的：指望协议挡住它们必然落空，要控制这一层，闸门在 WAF 与边缘层，协议层只是偏好表达。这与 Google 2025-03 官方博客的定调一致——REP 是公共标准，任何单一方无法单方面修改，所以新的偏好开关（如 AIPREF 的 Content-Usage 规则）都选择以 robots.txt 为附着点，而执行层始终在协议之外。

对站长的操作清单

1. 逐条具名组写 AI 爬虫规则，绝不依赖 User-agent: * 覆盖具名 AI 爬虫。
2. 校验文件不超过 500 KiB、UTF-8 编码；改动上线后等满 24 小时缓存再验证效果。
3. 不要用 401/403 给 robots.txt 做软屏蔽——4xx（429 除外）等于无任何限制。
4. 保证 JS/CSS 渲染资源不被 Disallow，Googlebot 与 Applebot 的渲染都依赖它们。
5. 分清令牌与爬虫再写条目：Google-Extended、Applebot-Extended 是使用开关，不是来访闸门。
6. 不要为 user-triggered 类爬虫浪费时间调 robots——直接上边缘层方案。

限制与待核实

• 状态码与缓存语义为 Google 规范口径；其他厂商仅笼统声明“遵守 robots.txt”，是否逐条对齐无公开承诺。
• crawl-delay 的各家支持面无系统清单（Google 不支持、Anthropic 尊重，是已知两端）。
• meta-externalfetcher、facebookexternalhit “可绕过”的具体触发条件（安全检查的范围）官方文档未穷举。
• 429 的专门处理方式官方文档未给出细节，仅明确它不属于“无限制”。