先做一个拆分
Cloudflare 这轮 AI crawler 设置最重要的变化，不是“能不能挡住 AI”，而是把同一个爬虫问题拆成三个问题：Search、Agent、Training。
对内容站、文档站和产品站来说，默认答案不应该是全部放行或全部封锁。更实用的顺序是：保留传统搜索发现，单独判断 AI 助手实时使用内容是否可接受，再明确限制或拒绝模型训练。
如果你只记一个结论，就是这句：不要把“被搜索找到”和“被拿去训练模型”混成同一个权限。
Cloudflare 改了什么
Cloudflare 在 2026 年 7 月的公告里说，新的 AI traffic options 会按三类用途管理 crawler：Search、Agent 和 Training。官方还说，这些选项面向 Cloudflare 网络上的所有站点，包括 Free tier。
它同时给了一个时间点：2026 年 9 月 15 日起，相关默认设置会在展示广告的页面上默认阻止 Training 和 Agent，Search 默认仍保持允许。Cloudflare 还特别提到，多用途 crawler 如果同时承担搜索和训练等行为，会按其全部行为接受更严格的规则。
这就是为什么这件事值得现在处理。以前很多站长只是在 robots.txt 里写几个 user-agent。现在问题变成了：你到底允许哪一种使用？
三类权限怎么理解
可以先用这张表把概念压清楚。
| 类型 | 更接近什么 | 站点常见态度 |
|---|---|---|
| Search | 建索引、返回链接、短摘要 | 通常允许，因为它能带回访问 |
| Agent | AI 助手为了回答或完成任务实时读取页面 | 视页面而定，尤其要看是否替代访问 |
| Training | 用内容训练或微调模型 | 很多内容站会限制或拒绝 |
Cloudflare 的 Content Signals Policy 也用类似方式拆分：search 指搜索索引和搜索结果；ai-input 指把内容输入 AI 模型用于检索增强、grounding 或实时生成答案；ai-train 指训练或微调模型。
这个拆分对站点负责人很有用，因为它让你可以说：我欢迎搜索索引，但不默认同意训练；我可能允许部分页面进入 AI 回答，但不允许会员内容、付费内容或敏感产品页被同样使用。
建议的设置顺序
第一步，先按页面类型分组。公开博客、帮助中心、产品文档、价格页、登录后页面、付费内容页和广告变现页，不应该用同一个策略。
第二步，先保留 Search。除非你有非常明确的封闭站点需求，否则传统搜索仍然是内容被发现的基础。Cloudflare 这次也把 Search 和 Training 分开，就是为了避免站点因为反训练而误伤正常发现。
第三步，明确 Training 态度。如果你的内容是原创文章、教程、产品文档或付费资料，至少应该在 robots.txt 或 Content Signals 里表达 ai-train=no 这类偏好。Cloudflare 的 managed robots.txt 文档示例也展示了用 content signal 表达搜索允许、训练拒绝的思路。
第四步，单独评估 Agent。AI 助手读取网页来回答问题，有时会带来品牌发现和引用，有时会替代访问。适合开放的页面通常是 FAQ、文档、公开教程和需要被准确引用的知识页；更要谨慎的是价格、库存、付费内容、医疗法律金融等高风险内容。
第五步，监控实际 crawler。Cloudflare AI Crawl Control 文档说，它可以查看 AI 服务访问、设置 allow/block 策略、跟踪 robots.txt 合规，并提供 pay-per-crawl 相关选项。也就是说，robots.txt 是声明，日志和边缘规则才是复查。
robots.txt 不是防火墙
这里最容易误解的一点是：robots.txt 不是技术阻断。
Cloudflare 文档明确说，robots.txt 合规是自愿的。它能表达你的偏好，但不能保证所有 crawler 都会遵守。要真正执行阻断，就需要 Cloudflare AI Crawl Control 这样的边缘控制，或其他访问规则。
所以更合理的组合是：
| 工具 | 用途 | 局限 |
|---|---|---|
robots.txt | 告诉 crawler 你的偏好 | 自愿遵守 |
| Content Signals | 说明 search、ai-input、ai-train 的许可边界 | 标准仍要靠 crawler 理解和尊重 |
| AI Crawl Control | 监控、允许、阻止、跟踪合规 | 需要持续查看日志和误伤 |
| 页面策略 | 区分公开页、付费页、广告页、产品页 | 需要站点自己维护 |
不要以为打开一个开关就完成了 AI 内容治理。更现实的做法是先声明，再监控，再按误伤和流量变化调整。
混合用途 crawler 是最大风险点
Cloudflare 公告里有一个很实际的提醒：多用途 crawler 如果同时承担 Search 和 Training，会按全部行为进入规则判断。TechCrunch 也把这解读为 Cloudflare 在推动 AI 公司拆分搜索、代理和训练 crawler。
对普通站点来说，风险在这里：你以为自己只是拒绝训练，但某个 crawler 同时负责搜索发现，那么限制训练可能也影响它的访问。反过来，如果你为了搜索放行它，也可能放宽了你不想开放的用途。
这不是说一定会丢搜索流量，而是说不要盲设。设置之后要看三类数据：
- Search crawler 是否还能正常抓取重要页面。
- AI crawler 请求是否从训练页、付费页或广告页减少。
- 来自搜索、AI answer、直接访问和引用来源的访问是否有异常变化。
没有这些数据，就不要把任何设置说成“必然涨流量”或“必然保护内容”。
适合大多数内容站的基线
如果你只是一个公开博客、文档站或小型内容站，可以先用这个保守基线：
| 页面 | Search | Agent / ai-input | Training / ai-train |
|---|---|---|---|
| 公开文章和教程 | 允许 | 先观察，必要时允许高质量引用 | 默认拒绝或明确限制 |
| 帮助中心 / FAQ | 允许 | 可考虑允许 | 默认拒绝或限制 |
| 价格页 / 产品页 | 允许 | 谨慎，防止过期信息被复述 | 拒绝 |
| 付费内容 / 登录后页面 | 不公开索引 | 拒绝 | 拒绝 |
| 高风险建议内容 | 允许摘要需谨慎 | 谨慎或拒绝 | 拒绝 |
这个基线的核心不是反 AI，而是让不同用途走不同门。
不确定性和边界
第一，这些设置不是 SEO 魔法。它们不能保证更高排名、更高点击率或更多收入。搜索表现仍取决于内容质量、索引健康、页面结构、速度、标题、内部链接和真实需求。
第二，Cloudflare 的分类和执行能力不等于所有 crawler 都会透明配合。Content Signals 是一个很清晰的表达方式，但整个生态还在磨合。
第三，pay-per-crawl 对大型出版商可能更有意义，小站现在更应该先把页面分组、权限边界和监控做好。
第四，如果你的站点依赖广告、订阅、联盟销售或高价值产品线，9 月 15 日默认变化值得提前检查，不要等 crawler 访问或搜索表现异常后才回头排查。
FAQ
Search、Agent、Training 有什么区别？
Search 更接近传统搜索索引和链接返回；Agent 是 AI 助手为了完成任务或生成回答而实时使用内容；Training 是训练或微调模型。Cloudflare 和 Content Signals 都在把这些用途拆开。
应该直接 Block AI bots 吗？
不建议一刀切。大多数站点仍需要搜索发现；更稳的做法是允许 Search，审查 Agent，限制或拒绝 Training，再看真实 crawler 数据。
robots.txt 能真正挡住 AI crawler 吗？
不能保证。Cloudflare 文档明确说明 robots.txt 合规是自愿的；它表达偏好，但不等于技术阻断。需要执行时要用 AI Crawl Control 或其他边缘规则。
Content Signals 里的 ai-input 是什么？
它指内容被输入到 AI 模型中用于实时答案、检索增强或 grounding。它和传统搜索索引不同，也和长期训练不同。
这些设置会提高搜索流量吗？
不能承诺。它们主要是访问治理工具，不是排名工具。搜索流量仍取决于内容质量、索引、站点结构、页面速度、链接和用户需求。
图片和信源说明
封面图为 Wesbase 原创清单图，没有使用 Cloudflare logo、后台截图、媒体图或出版商 logo。本文依据 Cloudflare 2026 年 7 月 AI traffic options 公告、Cloudflare managed robots.txt 文档、AI Crawl Control 文档、Content Signals Policy 公告，以及 TechCrunch 对 9 月 15 日默认变化的公开报道。文中把官方事实、媒体解读和本文推断分开表述。