Cloudflare Bot Preference Sync 发布后：robots.txt 与 AI 爬虫策略怎么对齐

网站团队常把 AI 爬虫策略分成两处维护：控制台里有一套 bot 偏好，站点根目录又放着手写的 robots.txt。Cloudflare 在 2026 年 8 月 21 日公布 Bot Preference Sync，试图把这两处设置对齐，让 Search、Agent、Training 三类 AI bot 的访问意图通过同一套偏好生成公开规则。

它解决的首先是策略重复维护和容易漂移的问题，不等于替站点自动做出内容开放决策；上线后仍应检查公开的 robots.txt、例外路径和实际请求。

Bot Preference Sync 改变的是哪一层配置

Cloudflare 官方公告把这个功能描述为：不再分别维护静态文件，而是让网站所有者管理 bot 偏好，再自动对齐 robots.txt。这里的“同步”更像配置发布链路的收口，不是给网页增加新的抓取协议。

对开发团队来说，最容易感知的变化是责任边界变清楚了：控制台偏好决定希望表达的方向，站点公开的 robots.txt 是外部能直接读取的结果，访问日志则负责验证真实流量是否符合预期。

Search、Agent、Training 三类 bot 为什么要分开判断

三类 bot 的使用意图并不一样。Search 更接近搜索发现，Agent 可能需要读取页面来完成用户委托的任务，Training 则涉及内容是否被用于训练。站点可以对它们做不同取舍，例如允许公开产品文档被 Search 和 Agent 读取，同时对 Training 采取更严格的限制。

这张表不是 Cloudflare 的套餐说明，而是发布前的决策顺序。先按内容类型做判断，再把结果映射到 bot 偏好；不要因为某个开关名字听起来相近，就把三类访问当成同一件事。

同步后的公开结果怎么检查

第一次启用或修改策略后，先从站点根域名读取 /robots.txt。检查文件是否已经反映新的允许或限制关系，重点看通配规则、具体 bot 规则和敏感目录是否出现互相覆盖。随后再用站点日志或边缘请求记录观察变化，不要只看控制台显示“已保存”。

建议保留一次变更前后的文本快照，并把下列三件事写进发布验收：公开文件能读到、关键路径符合预期、真实请求没有越过不该访问的区域。若站点还有 CDN 缓存，检查缓存刷新后的结果，否则可能把旧文件误判为同步失败。

默认策略之外，哪些例外不能交给同步功能替你决定

同步工具可以减少重复编辑，却不能替业务判断内容边界。登录后页面、用户资料、内部接口、下载文件和含个人信息的路径，仍需要独立的认证、访问控制或服务端拒绝逻辑。robots.txt 是公开约定，不是安全闸门。

还要注意一条常见误区：允许某类 bot 访问，只能说明站点没有在 robots 层表达拒绝，不代表 Cloudflare 会保证收录，也不代表第三方一定遵守规则。对 Agent 场景尤其如此，页面中的价格、库存、政策和操作说明仍要通过正式接口或业务权限核对。

发布前的四项判断清单

1. 按内容分区：把公开文档、营销页面、用户内容和内部路径分别列出，不用一个全站结论覆盖所有页面。
2. 按 bot 意图：分别决定 Search、Agent、Training 的允许范围，保留做出决定的理由。
3. 看公开结果：重新读取根路径 /robots.txt，核对规则顺序、路径范围和缓存状态。
4. 看实际请求：在日志里确认访问者、请求路径和响应状态；敏感数据保护依靠鉴权和服务端控制。

相关问题

robots.txt 能阻止未授权访问吗？

不能。它是面向爬虫的公开规则，真正的敏感数据保护仍要依靠认证、授权和服务端访问控制。

允许 Agent 读取就等于页面会被推荐吗？

不等于。是否读取、如何理解和是否推荐由具体代理及其检索策略决定，站点只能先明确可访问范围和内容质量。

启用同步后还需要保留 robots.txt 检查吗？

需要。公开文件是外部实际能看到的结果，缓存、例外路径和规则覆盖都可能让结果与控制台意图不同。

把同步当成发布流程的一环

Bot Preference Sync 的价值在于减少“控制台改了、文件忘了改”的漂移，让站点对 Search、Agent、Training 的偏好有一个更清晰的发布出口。稳妥的做法是把它放进内容分区、公开文件检查和日志复核组成的小流程里；涉及登录、个人信息和业务动作的边界，仍然要由应用自身负责。