robots.txt 里的 AI 训练偏好信号：站点如何声明、如何自检生效范围

如果你在找一条能写进 robots.txt、用来声明“我的内容不许用于 AI 训练”的指令，先说结论：robots.txt 可以承载这类偏好声明，但它表达的是意愿，不是访问控制。它无法阻止任何不打算遵守的抓取方，也无法追溯约束已经被拿走的内容。真正需要做的工作分两半：一半是把声明写在对的位置、覆盖对的主机名和爬虫；另一半是自检这条声明到底落在什么范围里——很多站点以为生效了，实际只是文件返回了一个 200 的 HTML 首页。

下面关于 robots.txt 通用行为的说明属于协议层面的背景常识；关于 AI 训练偏好信号的具体字段、语法与参与方名单，本次可用素材只有一句概述，文中会逐处标注“待核实”，请不要把任何未确认的写法直接推上生产。

先分清两层控制：能不能抓，和抓走之后能不能用#

robots.txt 长期承担的职责很窄：告诉爬虫哪些路径可以访问、哪些不要访问。它的标准化文本是 RFC 9309，核心指令就是 User-agent、Disallow、Allow 这几类。这套语义全部落在“访问”这一层。

访问层的控制有一个结构性缺口：它只在抓取发生的那一刻起作用。内容一旦被取走，Disallow 对后续发生的一切都没有约束力。而“拿这些内容去训练模型”恰恰发生在抓取之后，属于用途层的问题。用访问层的工具去表达用途层的意愿，语义上就是错位的。

AI 训练偏好信号要填的就是表格后两行。它和 Disallow 是并列关系而不是替代关系：前者管用途，后者管路径，两者都写不冲突，但都不能当访问控制用。

关于这个共享信号，目前能确认与不能确认的#

根据 OpenAI 的公告摘要，可确认的事实只有一条：OpenAI 表示将遵守一个共享的 robots.txt 信号，用来帮助站点运营者向参与方传达其 AI 训练偏好（来源：OpenAI, Making it easier for websites to express AI training preferences）。

从这句表述可以做出两点谨慎推断，注意是推断不是事实：其一，“共享信号”意味着它被设计成多个服务商共同识别的约定，而不是某一家厂商的私有指令；其二，“参与方（participating providers）”这个措辞本身说明覆盖范围是有边界的，未参与的抓取方不受它约束。

不能确认的部分同样重要：具体的指令名称、取值、是写在 robots.txt 的哪个位置、是否已正式生效、参与方完整名单——这些都待核实。摘要不等于全文，本文没有读到该公告的完整技术细节。因此在下面的示例中，凡是涉及具体写法的位置，一律用占位内容并明确标注，不作为可上线的配置。

站点侧怎么声明：现在能做的四步#

第一步，确认 robots.txt 由你自己控制

这听起来是废话，但出问题最多的就是这一步。使用托管建站平台、SaaS 商城或 CDN 默认配置时，根路径的 robots.txt 可能由平台生成，你的改动会被覆盖或在下一层被重写。先确认这个文件的实际来源。

第二步，把用途偏好和访问规则分开放

建议在文件里用注释分区块，让后续维护者一眼看出哪几行是路径规则、哪几行是用途声明。注释不会影响解析：

# 访问层：路径规则
User-agent: *
Disallow: /admin/
Disallow: /search

# 用途层：AI 训练偏好
# 具体指令语法请以官方文档为准，此处为占位示意，未执行、不可直接上线
# <training-preference-directive>: <value>

上面第二块只是结构示意，不是有效语法。等官方文档给出确切字段后再替换，替换时不要整块复制粘贴，逐行核对。

第三步，覆盖所有对外主机名

robots.txt 的作用域是单主机。主域、www 子域、内容 CDN 域、历史遗留的旧域名，各有一份独立文件。只改主域、放任 www 指向同一份内容却使用另一份 robots.txt，是最常见的覆盖漏洞。

第四步，把声明和内容策略对齐

声明只有和实际可访问性一致才有意义。如果某类内容本就不打算公开，正确做法是鉴权或删除，而不是靠 robots.txt 或用途声明拦住。声明是给守规矩的一方看的，不是安全边界。

怎么自检生效范围#

“生效范围”可以拆成五个可独立验证的维度：可达性、内容类型、UA 分组、主机名覆盖、实际抓取行为。逐个查，比笼统地说“我加了一条”可靠得多。

可达性与内容类型

# 未执行的示例；example.com 为占位域名，请替换成你的站点
curl -sS -D - -o /tmp/robots.txt https://www.example.com/robots.txt
head -n 20 /tmp/robots.txt

看三件事：状态码是不是 200；Content-Type 是不是纯文本；文件开头是不是你以为的内容。很多 SPA 站点因为前端回退规则，/robots.txt 会返回 HTML 首页——状态码 200，看起来一切正常，但解析器读到的是标签而不是指令。只看到 200 就认为生效，是自检里最容易犯的错。

UA 分组是否真的匹配

robots.txt 按 User-agent 分组生效。分组名拼错、大小写处理不当、或者把声明写在了 User-agent: * 通配组里而某个爬虫只认自己那一组，都会导致意愿落空。检查方法是：把文件里每个 User-agent 行单独列出来，确认目标爬虫能匹配到哪一组，以及那一组里是否包含你的用途声明。

主机名覆盖清单

把站点所有对外解析的域名和子域列成表，逐个请求 /robots.txt，记录是否包含用途声明。这一步没有捷径，靠清单逐项打勾。

从真实网络位置验证

CDN 和 WAF 可能按地区、按 UA 返回不同内容，甚至对非浏览器 UA 返回挑战页。至少从两个位置验证：本地网络和一台生产环境同区域的机器。如果返回的是挑战页 HTML，说明你的 robots.txt 在部分网络路径上根本读不到。

用服务端日志交叉验证

这是唯一能证明“有人在按你的声明行事”的证据。观察目标爬虫对 /robots.txt 的请求频率与时间点，再对照它对受控路径的抓取是否随之变化。没有日志证据时，不要对外声称声明已生效——你只能证明文件写对了，不能证明它被遵守了。

三个常见误判#

• 把声明当防火墙。robots.txt 和用途信号都依赖自愿遵守。真正的访问控制是鉴权、签名 URL、限流，这些工具在 API 层，不在文本文件里。
• 以为一条指令覆盖所有服务商。“参与方”三个字已经说明覆盖面是有限的。对未参与的抓取方，这条声明没有任何效力。
• 忽略了已抓取内容。声明通常面向未来的抓取行为，对已经进入他人数据集的内容没有追溯力。这一点在公告文本中如何表述，需查阅全文核实。

对同时提供 API 的站点多说一句#

如果你的站点既对外提供网页内容，又对外提供 API，两者要用完全不同的手段对待。robots.txt 只对爬虫有意义，对直接调用 API 的客户端没有约束力。API 的访问边界靠密钥、配额、鉴权和审计——把它混进 robots.txt 的讨论里，只会让两边都做不扎实。

回到最初的问题：声明这件事，写下来只完成了一半，另一半是自检它落在什么范围里。在具体字段语法与参与方名单得到官方文档确认之前，稳妥的做法是先把可达性、内容类型、UA 分组和主机名覆盖这四项查干净，把日志留好，等语法确定了再补齐用途层的那几行。