AI 爬虫不都是一种流量：网站该怎样决定开放范围

网站希望被用户发现，又不希望内容被无限制搬走。这两个目标并不矛盾，问题在于把所有自动访问都叫作“AI 爬虫”后，很容易只剩下全部开放和全部阻止两种选择。

更有用的区分是：这次访问是为了建立搜索索引、训练模型，还是正在替某个用户完成任务？目的不同，网站得到的回报、承担的负担和需要的控制也不同。本文从 Cloudflare 的公开变化出发，讨论内容站和产品官网怎样做这个判断。资料核对截至 2026 年 9 月 5 日，不涉及修改任何网站的实际配置。

从一个 AI 开关，转向访问目的

Cloudflare 在 2026 年 7 月的公告中，把 AI 相关访问进一步区分为 Search、Agent 和 Training。Search 用于收集或索引内容，供后续查询；Agent 侧重代表用户执行即时任务；Training 用于模型训练或微调。这是 Cloudflare 的产品分类，不是整个互联网已经统一执行的通用标准。

这种区分值得关注，因为同一份公开文档可能承担不同角色：搜索系统读取它，是为了以后帮助别人找到答案；一个助手现在读取它，可能是因为用户正在调试接口；训练采集则可能与当下任何访问者的问题无关。

对产品官网，第二种访问未必天然没有价值。假设开发者在助手里询问一个参数的含义，助手能否读到版本准确的文档，会影响用户能否继续接入。这个价值不一定立刻表现为一次浏览器点击。

但这也不能推导出“所有 Agent 都应该放行”。访问是否符合网站允许的用途、是否需要身份验证、是否造成异常负担，仍然要分别判断。把名称里带 AI 的访问全部视为获客机会，和把它们全部视为无价值流量，同样粗糙。

9 月 15 日的安排，不能写成所有网站已经生效

Cloudflare 的配置文档写明，计划于 2026 年 9 月 15 日调整部分默认行为：对新接入域名的广告页面，默认阻止 Training 和 Agent 类访问，保留 Search；同时调整同时用于搜索和训练的混合用途爬虫与训练阻止策略的关系。

这段话有几个不能省略的限定：计划日期、新接入域名、广告页面，以及混合用途访问的规则。文章核对时还是 9 月 5 日，不能把它改写成“Cloudflare 已封锁所有网站的 AI 访问”。网站最终行为还取决于实际设置及后续产品更新。

如果你使用相关服务，值得检查的不是某篇转述文章用了多强烈的标题，而是当前账号里的策略、页面分类和真实访问记录。一个全站开关可能同时影响多个页面目的；一个被归为混合用途的访问者，也不能仅靠名字推断最终会被允许。

我们的判断是：这类变化最应该触发一次范围核对，而不是一次情绪化的全站切换。先列出希望被发现的内容，再检查策略是否和这个目标冲突。本文不建议照抄任何配置，也不代表我们已经检查过你的账户。

robots.txt、用途偏好和实际阻止，是不同层次

RFC 9309明确说明，robots 排除规则不是访问授权机制。它告诉遵守协议的爬虫应当怎样访问，却不能代替登录、权限检查或服务端访问控制。

这意味着，一份文档如果不能公开，就不应仅依靠 robots.txt 隐藏。反过来，一份希望公开传播的说明，即使 robots.txt 允许抓取，也可能被其他网络或应用规则拦住。判断是否可访问，需要看真实响应，不是只看一个文件。

Cloudflare 的同一份公告还介绍了正在测试的内容使用偏好信号，并说明偏好表达本身不会直接发出封锁。对于网站经营者，应把“我表达了什么偏好”“服务执行了什么规则”和“访问者实际做了什么”分开记录。不能因为写入一条信号，就宣布内容已经不会被训练或转载。

本文讨论的是技术与产品范围，不把访问设置当成对内容权利或使用许可的完整判断。需要限制的私有信息，应由真正的身份和权限机制保护；需要公开的资料，应明确版本、出处及可用范围。

能被读取，不等于已经被引用

Google 的 AI 搜索功能说明仍然强调基础 SEO：可抓取、通过站内链接发现、重要内容以文本呈现，以及结构化数据与页面正文一致。成为相关 AI 搜索功能的支持链接，页面需要满足收录与摘要展示资格；满足要求也不保证被抓取、收录或展示。

因此，日志里出现一次爬虫请求，只说明发生了访问。它不能证明页面进入搜索索引，更不能证明某次 AI 回答采用了这篇内容。回答提到了品牌，也未必在来源列表中引用了该页面。

对内容团队，这种区分会改变日常判断。一篇文章刚上线，首先可以检查公开访问、链接和内容是否正确；之后再看搜索系统的收录与展示。如果一开始就拿“有没有被 AI 引用”作为唯一验收，既可能过早判定失败，也可能把一次偶然提及当成长期增长。

调用方也有相同问题：搜索命中、正文读取和结论核验是不同步骤。站内的 Agent 搜索工具选择从使用者一侧解释了这个区别；本文则从内容拥有者一侧看访问和分发，不把两者合并成一种指标。

按页面的用途决定，不按对 AI 的态度决定

我们建议先把页面分成几类，再讨论访问目的。公开产品文档的重点通常是帮助用户理解和完成接入；原创研究文章可能更关注归属、引用与持续维护；登录后的客户数据则应该由用户权限控制，不能因为希望增加可见度而公开。

对于每一类页面，可以问四个具体问题：

1. 希望谁在什么任务中读到它？是潜在用户发现产品，还是现有用户排错？
2. 自动访问能否帮助完成这个任务？有什么可以观察的证据？
3. 哪些访问或使用方式不在预期范围？需要偏好声明、流量控制，还是严格鉴权？
4. 如果调整策略，怎样确认没有误伤目标用户，并能够恢复原设置？

这不是要求为每个爬虫单独写一份复杂政策，而是让一次规则修改能够说清楚理由。例如，希望 API 文档帮助用户排错，就应检查用户发起的正常读取能否拿到正文；希望某些数据仅供登录用户使用，就应测试未授权请求能否被拒绝。两者的成功标准完全不同。

规则变化还可能改变数据样本。假设某个公开来源暂时无法访问，一个观察系统得到的内容会变少，但这不等于外部讨论真的减少。做跨来源分析时，应保留覆盖缺口，不能把缺失当作零。站内的多平台口碑监控蓝图讨论了这种采集状态与业务结论的分离；它是方法说明，不是本文观察到的客户故障。

最后看回报，也看是否伤害了正常使用

策略调整后，可以按同一观察窗口分别记录：自动访问量与错误、重要页面可读取情况、搜索展示与点击、能够核对的引用链接，以及用户进入文档或完成接入的有效行为。不要把这些数字加成一个模糊的“AI 流量”。

其中一些回报可能暂时无法可靠归因。例如，用户先在助手里了解产品，后来直接访问官网，常规来源记录未必能还原完整过程。正确的处理是保留这部分未知，而不是补一个估计数字证明策略有效。

AI 访问管理正在变细，网站自己的决策也应该变细。先明确哪些内容要服务谁，再核对访问目的、实际规则和使用结果。对于需要被发现的官网，目标不是让日志里的机器人越多越好；对于需要保护的内容，也不是让所有机器请求一律失败。目标是让合适的人和工具，在允许的范围内，获得足以完成任务的可靠信息。