Cloudflare 在 2025 年 7 月上线了一个新选项，允许网站在 robots.txt 之外，单独声明拒绝 AI 训练用途的抓取。它把过去绑在一起的两种用途拆开了：搜索收录和 AI 训练，现在可以分别对待。但 robots.txt 标准层面的支持还没跟上，Bing 仍在跟进。对 SEO 来说，收录和排名基本不受影响；对 GEO 来说，真正的问题从"堵爬虫"变成了"被允许的抓取能不能拿到可引用、可核查的内容"。
这个开关拆开了什么
过去网站主面对的是一个二选一的局面。要么在 robots.txt 里放行所有爬虫，让 AI 训练和搜索收录一起进来；要么一刀切封禁，连 Googlebot 也挡在门外。Cloudflare 的 Disallow AI Training 把这两件事拆成了两个独立开关：训练用途可以单独拒绝，混合用途爬虫仍然保留给搜索使用。
这个区别值得说清楚，因为不少解读把它当成"一键屏蔽所有 AI"。它针对的是训练用途，不是 AI 搜索本身。Googlebot 这类爬虫同时承担搜索索引和部分 AI 功能，Cloudflare 的处理方式是让这类混合用途爬虫继续可用，而不是把它们一并拒掉。
机制上，Cloudflare 是在自己的网络层做判断，而不是修改 robots.txt 标准。这意味着它的生效范围取决于请求是否经过 Cloudflare，以及对方爬虫是否愿意识别这个信号。它更接近一个"声明加执行"的组合，而不是技术上的强制拦截。
Google 和 Apple 已表态遵守，Bing 的 robots.txt 支持还在路上
据 Search Engine Journal 的报道，Google 和 Apple 已经表示会遵守训练退出信号，Bing 对 robots.txt 层面的支持尚待跟进。这个执行状态的差异，直接决定了开关的实际效果。
换句话说，这个开关能不能起作用，取决于对方是否自愿遵守。它不是防火墙，不能强制任何爬虫停下。Google 和 Apple 表态遵守，意味着对这两家的训练抓取，信号大概率会被尊重；Bing 还没对齐，意味着对 Bing 系 AI 产品的训练用途，这个开关目前未必有效。
robots.txt 本身也是同样的逻辑。按照 RFC 9309 和 Google 搜索中心的说明，robots.txt 是爬虫抓取控制的公开标准，遵守与否由爬虫方自愿决定。训练退出信号建立在同一套自愿框架上，所以网站主需要接受一个现实：你能做的是清晰表达意图，不能保证所有对方都照做。
对 SEO 的实际影响：收录、排名与抓取预算基本不受影响
最需要先消除的恐慌是"开了就掉排名"。从机制上看，Disallow AI Training 针对的是训练用途，Googlebot 的搜索抓取不在拒绝范围内，所以收录、排名和抓取预算不会因为这个开关本身发生变化。
真正需要自查的是配置有没有互相打架。比如 robots.txt 里是否已经存在针对 Googlebot 的封禁规则，CDN 缓存是否会把不同用途的请求混在一起处理，页面级是否有 noindex 标签。这些既有配置才是影响搜索表现的因素，新开关只是多了一层用途区分。
一个常见的误操作是：为了拒绝训练，顺手在 robots.txt 里写了 User-agent: * 加 Disallow: /。这会连搜索爬虫一起挡住，和 Cloudflare 开关的初衷正好相反。开关和 robots.txt 应该是配合关系，不是叠加封禁。
对 GEO 的实际影响：被允许的抓取更需要可引用内容
开关解决的是"谁可以抓"，但 GEO 要解决的是"抓到了之后，AI 搜索会不会引用你"。这两件事不在一个层面上。你把训练抓取拒掉，AI 搜索该抓的还是会抓；但如果页面本身没有可引用的结构，被允许的抓取也拿不到有价值的东西。
具体到内容层面，有几个方向是可以直接动手的。结论前置，让 AI 在摘要时能直接取到判断句，而不是从第三段才开始说重点。实体清晰，品牌名、产品名、关键概念在页面里有明确定义和一致表述，避免同一件事换三种说法。来源可核查，涉及数据、政策、排名的表述给出出处，让引用时有据可依。FAQ 可复用，把高频问题写成独立问答块，方便被直接摘取。
天行 GEO 在方法上强调的正是这一层：结论前置、问题优先、实体清晰、来源可核查、FAQ 可复用、内链可追踪。这些不是为训练爬虫准备的，而是为被 AI 搜索引用准备的。开关让你决定谁能抓，内容质量决定抓了之后有没有用。
开启前必须确认的三件事
上线前建议按顺序过一遍这三项，避免开关和既有配置互相抵消。
第一，检查 robots.txt。确认里面没有针对 Googlebot 或其他搜索爬虫的封禁规则，也没有 User-agent: * 的全站 Disallow。如果历史上有过临时封禁，确认已经清理干净。
第二，检查 CDN 缓存规则。如果缓存策略按 User-Agent 做了区分，确认新增的用途区分不会导致搜索爬虫拿到错误的缓存版本。缓存和抓取控制是两套逻辑，混在一起容易出问题。
第三，检查页面级策略。确认没有页面在 meta 标签里写了 noindex，或者 canonical 指向了不该指向的地址。这些页面级设置和 Cloudflare 开关无关，但会独立影响搜索表现，容易被忽略。
不同站点该怎么选
开与不开，取决于你的内容对训练用途的依赖程度，以及你对内容被用于训练的容忍度。
内容站和媒体站通常更敏感。原创内容被用于训练，可能稀释内容的稀缺性，开启 Disallow AI Training 是合理选择，前提是确认搜索抓取不受影响。电商站的情况不同，商品页和分类页的主要价值在于被搜索和比价场景触达，训练用途的收益有限，开启的动机相对弱一些，但也没有明显损失。品牌官网介于两者之间，官网主源承担着被 AI 搜索引用的职责，训练用途可以拒绝，搜索和引用用途必须保留。
判断框架可以简化成三个问题：你的核心内容是否依赖稀缺性？训练用途是否给你带来可衡量的回报？你是否有能力在被允许的抓取上提供可引用内容？三个问题里有两个以上指向"是"，就值得开启；如果核心诉求是被引用而不是被训练，重点应该放在内容资产建设上，而不是开关本身。
需要把"允许抓取"转化为"被 AI 搜索稳定引用"的站点，可以进入 GEO 专题栏目 查看内容资产与 FAQ 体系的建设方法，或通过 服务页 了解官网主源与结构化数据的落地支持。
Q&A
开启 Disallow AI Training 后，Googlebot 还会正常抓取和收录我的页面吗？
会。这个开关针对的是训练用途，Googlebot 的搜索抓取不在拒绝范围内。收录、排名和抓取预算不会因为这个开关本身发生变化。前提是 robots.txt 和页面级配置没有额外的封禁规则。
如果 Bing 还没支持 robots.txt 层面的训练退出，这个开关对 Bing 系 AI 产品有效吗？
目前不能保证。据 Search Engine Journal 报道，Bing 对 robots.txt 的支持尚待跟进。在它对齐之前，这个开关对 Bing 系 AI 产品的训练用途未必生效。网站主能做的是清晰表达意图，执行与否取决于对方是否遵守。