实测 6 组 robots.txt：AI 搜索、训练与用户访问能否分开控制？

先给结论：可以分开写规则，但“写得开”不等于“平台一定按你的业务目标执行”

这次实验得到一个清楚但需要限定的结论：只要平台为不同用途提供独立的 robots.txt 标识，网站就能在文本规则层面分别表达“允许搜索发现、拒绝潜在训练”“允许训练、拒绝搜索抓取”或“只开放某些目录”等选择。6 组样本共形成 168 个“标识—路径—规则”判定，其中 117 个结果为允许、51 个结果为阻止；没有出现判读器无法决定的规则。

然而，这些数字只是规则决策数量，不是访问量、引用率或模型采用率。每个判定的权重相同，不能用“117 次允许”推导某种策略更优。实验也没有等待真实爬虫访问中性样本，更没有测试搜索收录、回答引用或训练数据采用。它回答的是一个更窄的问题：在公开标识与明确匹配规则下，三类用途能不能被写成彼此不同的访问偏好。

答案是能，但前提有三项。第一，必须使用平台当前公开的准确标识，不能凭日志里看见的近似名称猜测。第二，要理解通配组与专用组的优先关系，不能以为全局规则会自动与专用规则叠加。第三，robots.txt 是面向守规抓取器的公开指令，不是身份认证、访问控制或保密工具。敏感内容仍要依靠登录、授权和服务器端控制。

为什么要做这次实验

很多网站的 AI 抓取策略仍停留在一个总开关：要么对所有机器人开放，要么在看到“AI”之后全部阻止。但公开平台已经把用途拆开。搜索机器人负责发现或构建可用于回答的索引，训练机器人表达未来模型训练偏好，用户触发访问则是在某个用户问题或操作发生后读取页面。三者都可能请求公开内容，却不代表同一件事。

如果把不同用途混在一个 User-agent 组里，团队可能得到与目标相反的结果。例如，品牌只想拒绝训练，却误阻止了搜索标识；或者希望禁止用户代理读取受限目录，却只写了训练机器人规则。更常见的是全局先写 Disallow，再单独写一个 Allow，却没有验证解析器是否会选择专用组。规则看上去完整，真实含义却可能与编辑者想象不同。

这次实验采用中性样本，是为了把规则判断与任何真实网站隔离。路径只使用根目录、当前指南、历史指南和私有草稿四种抽象名称，不包含客户、品牌、产品、账号或内部目录。测试结果可以复现规则逻辑，却无法反推出任何站点结构，也不把某个真实网站的抓取记录当作公开案例。

测试对象：7 个公开标识，但它们并不都是同一种“爬虫”

截至 2026 年 9 月 10 日，我们核对了三家平台的一手公开说明。OpenAI 的发布者与开发者 FAQ说明，OAI-SearchBot 与 ChatGPT 搜索中的发现、摘要和来源展示有关；希望排除潜在训练用途时，应针对 GPTBot 表达偏好。允许 OAI-SearchBot 不等于一定出现于答案，阻止 GPTBot也不等于阻止所有搜索发现。

Anthropic 在 2026 年 4 月 7 日更新的说明列出 ClaudeBot、Claude-SearchBot 与 Claude-User。其公开用途分别对应可能用于模型训练的数据收集、改善搜索结果质量的网络导航，以及用户发起问题后对网页的访问。三者使用不同标识，正是本次独立控制实验的主要依据。

Google 的常见抓取器文档说明，Googlebot 的规则会影响 Google 搜索及其相关功能。Google-Extended 则是一个独立的产品控制标识，用于管理内容是否可用于未来 Gemini 模型训练，以及 Gemini Apps 与 Vertex AI 中的相关 grounding 用途；Google 同时明确，它不会影响网站进入 Google 搜索，也不是搜索排名信号。

因此，文章把它们统称为“公开标识”，而不是声称存在七个完全相同的网络机器人。尤其是 Google-Extended，官方明确它没有单独的 HTTP 请求 User-Agent 字符串，抓取仍可能由既有 Google 用户代理完成。日志里找不到名为 Google-Extended 的请求，不能反推规则无效；它本来就主要承担产品控制作用。

测试条件：6 组规则、4 类路径、168 个确定性判定

测试时间为 2026 年 9 月 10 日。我们建立 6 份彼此独立的中性 robots.txt：全局允许、只阻止训练、只阻止搜索、只阻止用户触发访问、全局阻止但为搜索设置专用放行，以及按目录分层。每份规则都对 7 个标识检查 4 个路径，共计 6 × 7 × 4 = 168 个判定。

四个路径分别是站点根路径、当前指南路径、历史指南路径和私有草稿路径。它们只代表不同内容职责，不对应真实网址。每个判定只问“按照当前规则，这个标识是否允许访问这一路径”，不发送网络请求，也不记录 IP、响应时间、缓存、访问频率或抓取结果。

静态判读器遵循Google 于 2026 年 8 月 31 日更新的 robots.txt 解释：优先选择与标识最具体匹配的 User-agent 组；存在专用组时，不再把全局星号组的规则叠加进去；同一组内优先采用匹配路径更长的规则；长度相同且 Allow 与 Disallow 冲突时，采用限制较少的 Allow。

这套解释用于让实验可重复，不代表 OpenAI 与 Anthropic 已公开承诺每个边缘语法都与 Google 完全相同。为了降低外推风险，核心场景只使用准确标识、根路径与清楚的专用组，不依赖大小写陷阱、复杂百分号编码或多层通配符。边缘语法越少，跨平台配置越容易复核。

结果总表：独立控制成立，但全局规则最容易被误读

总计 117 个允许和 51 个阻止，说明规则文本确实能够产生不同用途、不同路径的差异化结果。更重要的是，各场景的变化符合预设目标：切换训练组没有连带改变搜索组，切换搜索组也没有自动改变 Claude-User。独立标识带来的控制能力，在静态解析层面成立。

但表格不能被解读成平台之间的能力排名。OpenAI 在本次纳入两个标识，Anthropic 有三个，Google 有两个；各自判定数量不同，不代表谁更开放或更严格。产品定义也不完全对称，例如 Google-Extended 同时涉及训练和特定 grounding 控制，而 Claude-User是用户发起访问。正确比较对象是“规则是否符合自己的内容政策”，不是数哪个平台的允许格子更多。

场景一：只阻止训练，不会自动阻止搜索发现

第二组规则先对星号组全局允许，再分别对 GPTBot、ClaudeBot 与 Google-Extended 写根路径 Disallow。结果是三个相关标识在四类路径上全部被阻止，产生 12 个阻止判定；OAI-SearchBot、Claude-SearchBot、Claude-User 与 Googlebot 仍获得 16 个允许判定。

这组结果说明，“拒绝潜在训练”和“退出 AI 搜索”不应被写成同一句话。至少从三家当前公开的标识设计看，训练或产品控制可以与搜索发现分开表达。网站如果只想限制训练，应该准确写训练相关标识，而不是笼统阻止所有名称中带 AI 的机器人，更不应误伤普通搜索抓取。

边界在于允许搜索标识只是保留可访问条件。页面还要能被发现、返回有效响应、提供清楚内容，并满足平台自己的来源选择机制。robots.txt 没有“请引用我”的指令，也不能让内容自动进入任何答案。

场景二：只阻止搜索，训练相关访问仍可能保持允许

第三组对 OAI-SearchBot、Claude-SearchBot 与 Googlebot 分别设置根路径 Disallow，同时保持星号组允许。结果同样是 12 个阻止与 16 个允许，但含义完全不同：搜索相关标识被阻止，GPTBot、ClaudeBot、Google-Extended 与 Claude-User 没有因为搜索规则而自动被关闭。

这正是总开关思维容易遗漏的地方。某团队可能以为“我已经禁止 AI 搜索，所以也不会用于训练”，但如果训练标识仍处于允许状态，文本规则并没有表达这个意图。相反，若团队想保留传统 Google 搜索，只应谨慎处理 OAI-SearchBot 与 Claude-SearchBot，不能把 Googlebot 一并关闭后再期待 Google 搜索正常抓取。

对外描述也要准确。阻止搜索抓取可能减少被发现或准确呈现的机会，但不能承诺某个 URL 会立即从所有界面消失。平台可能已经持有旧索引，或通过第三方获得标题和链接；OpenAI 当前 FAQ 也提醒，即使页面被禁止抓取，某些情况下仍可能展示链接与标题，并建议在需要时配合可读取的 noindex。

场景三：用户触发访问需要单独决策

第四组只为 Claude-User 设置根路径 Disallow，其余标识依赖全局允许。4 个路径全部对 Claude-User 阻止，另外 24 个判定保持允许。这证明在 Anthropic 当前提供的三个标识中，用户发起的网页读取可以与搜索导航及潜在训练收集分别表达。

但“用户触发”不等于用户拥有越权访问权限。robots.txt 只适用于公开路径的抓取偏好，不能把本应登录的订单、合同、后台或个人资料放到公网，再指望 Claude-User 的一行规则承担安全责任。真正非公开的内容必须由身份验证和授权系统阻止，任何未知客户端都不应仅凭自报 User-Agent 获得访问。

是否允许用户代理，要结合页面用途判断。公开帮助文档可能适合被用户在对话中读取；需要执行操作的表单则还涉及权限、确认和失败处理。允许读取也不等于允许代表用户提交表单、购买或修改数据，这些行为需要另外的应用层控制。

场景四：全局阻止再专门放行，结果依赖“专用组优先”

第五组先对星号组设置根路径 Disallow，再为 OAI-SearchBot、Claude-SearchBot 与 Googlebot 分别设置根路径 Allow。按照本次解析规则，三个专用搜索组不会与星号组叠加，因而得到 12 个允许；另外四个标识没有专用放行，得到 16 个阻止。

这是最值得人工复核的配置。很多人直觉上会把所有组理解为从上到下累计：先全局拒绝，再遇到专用允许就覆盖。Google 的公开解释更准确地说，是先选择最具体的 User-agent 组，专用组与全局组不合并；组在文件中的先后顺序也不是决定因素。虽然本组结果与“覆盖”的直觉相同，但原因不同，遇到多个专用组或路径规则时，错误理解会产生意外。

跨平台使用时，应避免把关键策略建立在复杂冲突上。与其写多层相互抵消的规则，不如为每个官方标识建立清楚组，并让同一用途的 Allow 与 Disallow 尽量少。发布前用至少一个独立解析器逐路径检查，不能只凭肉眼看格式正确。

场景五：按目录分层，比整站全开或全关更接近内容治理

第六组把当前指南保持开放，把历史目录对 GPTBot、ClaudeBot 与 Google-Extended 关闭，同时把私有草稿目录对 OAI-SearchBot、Claude-SearchBot、Googlebot 与 Claude-User 关闭。最终得到 21 个允许与 7 个阻止：历史目录贡献 3 个训练相关阻止，私有草稿目录贡献 3 个搜索阻止和 1 个用户访问阻止。

这个结果展示了路径级策略的价值。网站不一定只有一个内容政策：公开事实页、新闻档案、授权资料、用户页面和测试环境承担不同责任。只要 URL 结构能反映职责，就可以把规则限制在必要范围，避免为了一个目录关闭整个域名。

不过，“private”只是中性路径名称，不代表安全属性。即使所有已知标识都被 robots.txt 阻止，任何不守规则的客户端仍可能直接访问公开 URL。路径分层适合管理守规抓取，不适合隐藏秘密。真正的草稿环境必须不可公开访问，并避免通过站点地图、内链、日志页面或错误提示泄露地址。

从实验到实际配置：先写政策表，再写 robots.txt

动手之前，先把内容与用途做成一张政策表。每一行是一类内容，例如公开产品事实、帮助文档、历史政策、新闻资料、用户数据和测试页面；每一列是搜索发现、潜在训练、用户触发访问和普通浏览。格子里只写允许、拒绝或需授权。团队先确认业务含义，再把需要由 robots.txt 表达的公开访问偏好翻译成规则。

如果目标是“允许搜索、拒绝潜在训练”，至少要分别审查 OAI-SearchBot 与 GPTBot、Claude-SearchBot 与 ClaudeBot，以及 Googlebot 与 Google-Extended。不要复制一份多年未更新的机器人名单长期不管，因为平台名称、用途说明和产品边界会变化。每次重大调整前都应回到官方文档核对观察日期。

如果目标是“某些公开目录可搜索，但用户代理不能即时读取”，要确认平台是否提供独立用户标识。当前纳入的三家中，Anthropic 公开列出了 Claude-User；不能因为一个平台有对应标识，就自行推导其他平台一定存在同名或同用途标识。没有官方依据时应写“无法单独表达”或采用更高层的访问策略。

规则上线后，要同时检查原始文本、HTTP 状态、字符编码与每个子域名。robots.txt 通常按协议、主机和端口生效，一处主域配置不会自动覆盖所有子域。还应记录变更原因与责任人，但公开文章只需说明当前政策，不应暴露安全规则、内部目录或运维细节。

怎样复现这 168 次判读，而不把测试工具当成平台结论

复现时先把输入固定下来。建立一张标识表、一张路径表和六份独立规则文本，给每份文件编号，避免在同一文件上反复改动后忘记当前版本。标识必须保持官方大小写写法，路径同时保留根路径与有代表性的子路径。判读结果至少记录规则编号、标识、路径、命中的 User-agent 组、命中的最长路径规则和最终允许状态。

第一轮只检查组选择。对每个标识查找最具体的匹配组；若没有专用组，再使用星号组。不要在这一步处理 Allow 与 Disallow，否则很容易把“选择哪一组”和“组内哪条路径更具体”混成一个判断。第五组实验之所以重要，就是因为专用搜索组被选择后，不再叠加星号组的根路径阻止。

第二轮在已选组内比较路径。根路径斜杠能匹配所有测试路径，较长的目录规则只匹配对应前缀。若同时存在允许与阻止，应把真正匹配的字符长度列出来，再决定哪条更具体。仅凭规则在文件里出现得更晚，不能可靠判断优先级。对于必须跨多个平台工作的配置，最好避免使用等长冲突，把意图写成没有歧义的路径组。

第三轮做逆向用例。每条“应该阻止”的规则至少配一个相邻的“应该允许”路径，每条专用放行也要配一个没有专用组的标识。例如，验证训练机器人无法访问历史目录时，还要确认搜索机器人仍能访问同一目录；验证搜索标识可访问当前指南时，也要确认没有放行本应受全局规则限制的其他标识。只有阻止用例而没有允许用例，无法发现范围写得过宽。

第四轮才进入网络层验证：把规则放到不含敏感信息的测试环境，确认 robots.txt 能正常返回、内容没有被网关改写，并用平台提供的验证方式或可信解析器复查。即使网络层结果一致，也只能说明公开规则可读取，不能证明某个平台已经安排爬取。真实访问还需要经过日志身份验证，不能仅凭请求头中的名称认定来源。

最后保留一份预期与实际差异表。若两个解析器给出不同结果，先缩短规则，找出是组匹配、通配符、编码还是 Allow 优先造成分歧；在原因没有确认前，不要发布高风险配置。生产规则应优先选择多个解析器都能得出相同结论的简单写法，而不是追求用最少行数表达最多例外。

常见错误：规则格式正确，业务含义仍可能完全错误

把星号组当成永远叠加的底层规则。在 Google 的解释中，找到更具体的专用组后，星号组不会继续合并。若专用组只写一条局部规则，未被写出的路径可能变成允许，而不是继续继承全局禁止。

按名称猜用途。GPTBot、OAI-SearchBot、ClaudeBot、Claude-SearchBot、Claude-User、Googlebot 与 Google-Extended的命名风格不同。最可靠的方法是维护“标识—官方用途—核对日期”表，而不是看到 Bot、Search 或 User 就自行解释。

把 Google-Extended 当作日志里应出现的独立机器人。官方明确它没有单独 HTTP User-Agent 字符串。它在 robots.txt 中承担控制作用，不能用服务器日志里没有同名请求证明它未被使用。

把 Disallow 当成 noindex。robots.txt 管的是抓取访问，不是通用删除指令。页面 URL 仍可能通过外部链接被发现；而 noindex 需要抓取器能够读取页面或响应头。需要从搜索结果移除时，应按具体平台说明组合正确方法。

把 User-Agent 当成可信身份。请求头可以被伪造。若要验证真实 Google 抓取器，官方建议结合来源 IP 与反向 DNS；其他平台也应参考其公开验证方法。安全边界必须建立在服务器端认证授权上。

一次通过就永久不复查。平台文档会更新，产品用途也会变化。规则文件没有语法报错，不代表半年后仍符合业务目标。应在平台更新、产品发布、目录调整和内容政策变化时重新核对。

这次实验能证明什么，不能证明什么

它能证明：在 6 组给定文本和本次明确解析规则下，7 个公开标识对 4 类中性路径可以产生独立、可重复的允许或阻止结果；训练、搜索和用户访问不是必须绑定在同一个开关上；全局规则与专用规则的关系会显著改变结果。

它不能证明：OpenAI、Anthropic 或 Google 已经抓取某个页面，某次请求一定来自真实官方机器人，某个规则已被平台采纳，允许之后会被收录、引用或用于训练，也不能证明阻止之后所有历史数据都会被删除。静态解析与平台实际处理是两个证据层级。

它也不能给所有 AI 服务建立永久名单。本次只纳入三家有明确一手说明且能对应本实验问题的标识。其他模型、搜索引擎、数据合作方与代理工具可能有不同名称、不同语法支持或没有公开选择。团队应按真实风险和目标逐个平台核对，不能把本文矩阵直接当作全球通用配置。

最后，robots.txt 是公开文件。任何人都可以读取其中的路径线索，因此不要为了阻止抓取而把敏感目录名称逐条公开。安全内容应从网络访问层面保护；抓取政策只表达对公开资源的自动访问偏好。

下一步阅读

如果还没有建立三类访问的治理框架，可先阅读AI 爬虫搜索、训练与代理访问治理方法，确定哪些内容应该开放、限制或授权。若规则调整涉及旧页面退出，还应结合GEO 内容下线判断方法，避免把抓取禁止误当成页面已经删除。

本文给出的矩阵适合做配置讨论的起点，不应原样复制到生产环境。真正上线前，应使用自己的公开内容政策重新生成规则，用当前官方文档核对标识，并由技术、内容、安全与合规责任人共同确认。