网站希望被搜索引擎发现，并不意味着它愿意把内容交给 AI 模型训练。Cloudflare 提出的新控制措施，正是要把这两种用途拆开：站点可以继续保持搜索可发现性，同时表达不允许 AI 训练的选择。
来源摘要还提到，新的 Accountable designation（标识） 与 Apple、Google、Microsoft 共同建立一种共享模式。不过，摘要没有提供具体配置入口、参与者义务或执行细节，因此不能把这个标识直接理解为“已经阻止所有训练抓取”的保证。
搜索收录和模型训练，不应是一张通行证
对网站经营者来说，这两类用途的回报并不相同：
- 搜索发现：用户通过搜索结果找到文章、产品或文档，再进入网站。
- 模型训练：内容进入模型训练流程，不一定带来访问量，也不一定保留可追踪的引用。
过去，站点往往只能在“允许抓取”和“拒绝抓取”之间做粗粒度选择。新的方向是按用途表达许可，而不是把所有自动访问都当成同一件事。
这里需要分清三个层次：
| 层次 | 要回答的问题 |
|---|---|
| 授权声明 | 网站允许哪些用途？ |
| 请求控制 | 哪些请求会被允许或拦截？ |
| 参与者责任 | 接收内容的一方如何遵守用途限制？ |
这些层次相互补充，但不能互相替代。一个 HTTP 请求被放行，并不意味着它获得了所有后续使用权。
可以这样实践：先检查网站已经声明了什么
下面的命令可以直接运行。运行前，把 SITE 改成你管理的网站域名。它只读取公开的 robots.txt，不会修改 Cloudflare 配置，也不能验证内容是否被用于训练。
#!/usr/bin/env bash
set -euo pipefail
SITE="https://example.com"
SITE="${SITE%/}"
curl --fail --silent --show-error \
--location --max-time 20 \
"$SITE/robots.txt" \
-o robots.txt
printf '\n=== robots.txt 全文 ===\n'
cat robots.txt
printf '\n=== 抓取规则摘要 ===\n'
grep -niE '^[[:space:]]*(user-agent|allow|disallow|sitemap):' \
robots.txt || true
检查时，重点看两件事：是否误伤正常搜索爬虫，以及是否已经存在针对特定自动化客户端的规则。
如果要演练按客户端区分访问，可以这样实践：
# 演示配置：ExampleTrainingBot 是占位名称，不是真实爬虫。
User-agent: ExampleTrainingBot
Disallow: /
User-agent: *
Allow: /
不要把这个演示文件直接覆盖到生产站点。先保留现有的私有路径限制，再用经过核实的爬虫标识替换占位名称。
更重要的是，robots.txt 是给遵守规则的爬虫看的。它本身不阻止网络请求，也不能识别某次抓取究竟用于搜索还是训练。上面的示例只是客户端级规则，不是 Cloudflare 新控制措施的实现方法。
Accountable 标识值得关注，但边界必须读清楚
共享模式的意义，在于让内容提供方与内容使用方不必各说各话。网站表达限制后，参与方如何理解、遵守和验证这些限制，才是机制能否发挥作用的关键。
在启用相关能力之前，建议确认：
- 适用范围：覆盖哪些参与者、客户端和内容用途？
- 执行方式：是用途声明、请求拦截，还是两者结合？
- 搜索影响：是否影响搜索抓取、索引更新或结果展示？
- 可观察性：是否能查看相关请求、拦截记录和例外情况？
- 历史内容：限制是否仅作用于未来访问？不要默认它能撤回已经获取的内容。
这些是部署时需要核实的问题，不是摘要已经给出的功能承诺。
落地时，把授权策略和访问策略分开管理
值得采用的不是“一键拒绝 AI”这个口号，而是更细的内容治理方式：允许搜索发现，不等于允许训练；声明不允许训练，也不等于已经技术性阻断所有使用。
可以先盘点现有抓取规则，再核实 Cloudflare 控制措施与 Accountable 标识的具体条款，最后分阶段调整策略。每次修改后，都观察搜索抓取和正常访问是否受影响。
目标不是让网站从互联网消失，而是让内容的可见性与使用授权不再被捆绑出售。