AI 爬虫不再只有一种：搜索、训练与代理访问分化后，品牌网站该怎样治理？

一、行业变化到底是什么：同一家平台开始使用多种访问身份

过去，站长谈爬虫时通常只问一个问题：要不要让它抓。传统搜索场景里，这个问题已经不够精确；到了生成式搜索与智能代理阶段，它更容易导致错误决策。模型训练需要批量获得材料，搜索产品需要发现并更新可引用页面，用户提问又可能触发一次即时读取，代理还可能进一步打开表单、比较库存或执行操作。这些访问虽然都可能来自“AI 产品”，目的、频率、价值和风险并不相同。

OpenAI 的公开说明把这种分化表现得很直接。其出版商与开发者 FAQ 要求希望内容进入 ChatGPT 摘要和片段的网站不要阻止 OAI-SearchBot；若网站希望把页面排除在潜在训练之外，则应针对 GPTBot 设置规则。Cloudflare 的官方机器人目录还将 ChatGPT-User列为 AI Assistant，把它与 AI Search 类的 OAI-SearchBot、AI Crawler 类的 GPTBot分开。

Anthropic 也公开列出三类身份。ClaudeBot用于模型开发相关抓取，Claude-SearchBot用于提升用户搜索结果的相关性和准确性，Claude-User则在个人向 Claude 发出问题时代表用户访问网站。Anthropic 明确提示，阻止搜索或用户访问身份，可能降低内容在相应用户搜索结果中的可见度或准确性。这不是收录保证，但说明不同规则会影响不同能力。

Google 的做法不完全相同。Googlebot继续服务 Google Search 的抓取和索引，而 Google-Extended是独立的产品令牌，用于管理已抓取内容是否可被用于未来 Gemini 模型训练，以及 Gemini Apps 与 Vertex AI Grounding with Google Search 的 grounding。Google 同时明确：Google-Extended 不影响网站进入 Google Search，也不是 Google Search 排名信号。这一条尤其重要，因为它证明“搜索可见”和“生成式产品使用”不能简单合并。

如果需要验证这些独立标识在具体规则中的实际判读，可继续查看6 组 robots.txt 中性规则实验。该实验只验证规则文本，不把允许访问写成抓取、索引或引用结果。

基础设施也在适应这种变化。Cloudflare 的 AI Crawl Control 目录按 AI Crawler、AI Search、AI Assistant 等类别识别多个运营方的访问，并允许站点按具体爬虫选择允许或阻止。它还公开表示，免费方案主要依据 user-agent 字符串识别自我声明的爬虫，更完整的识别需要额外的机器人检测信息。因此，分类越来越细，并不意味着身份判断已经百分之百可靠。

二、先把三类访问的价值和边界分开

第一类是搜索发现与答案引用。它的目标是让系统知道页面存在、读取最新内容，并在相关问题中把页面作为候选来源。允许这类爬虫，只能说明技术上没有主动拒绝访问；页面是否被抓取、索引、选择、引用或点击，仍由平台系统、内容质量、问题相关性和其他信号共同决定。品牌不能把“已允许”写成“必然被推荐”。

第二类是训练或模型改进。它关注内容是否可能进入训练或改进流程，与某次用户问题的即时检索不是同一事件。出版商、会员内容站和拥有独家数据的企业，通常需要在版权、合同、数据价值和长期分发之间单独做决定。阻止训练身份，不必然等于退出传统搜索；反过来，允许搜索身份也不自动等于同意所有训练用途。具体效果要以各平台当期公开规则为准。

第三类是用户触发或代理访问。用户在聊天产品中要求“读取这篇文章”“比较这两个方案”或“帮我完成某项任务”时，系统可能以专门身份访问网站。它比批量抓取更接近真实用户需求，但也可能触碰登录、价格、库存、个人信息、表单与交易。对于纯内容页，主要问题是能否清楚读取；对于可执行页面，必须进一步考虑授权、确认、幂等、防误操作和失败恢复。

这三类不是一条线上的先后步骤。训练爬虫访问了内容，并不表示搜索会引用；搜索爬虫建立了索引，也不表示用户一定点击；用户触发读取可能直接访问一个刚收到的 URL，而不依赖完整索引。治理时应该把它们当作并列的访问目的，再与页面类型交叉判断。

三、为什么“全部允许”不是天然开放，“全部阻止”也不是天然安全

全部允许的最大问题，是把公开传播、训练授权和事务访问混成一个许可。企业官网的品牌介绍、帮助文档和公开政策，本来就希望被发现；但内部文件、客户资料、未发布价格、测试接口和带个人参数的页面，不应因为“想做 GEO”而对任何自动访问开放。真正的边界来自信息分级与权限系统，不来自对 AI 的态度。

全部阻止的代价，则是搜索与用户访问可能一起被切断。OpenAI 和 Anthropic 的公开说明都把搜索身份与训练身份分开；如果网站只写一条宽泛规则，把某个平台的所有身份全部拒绝，可能同时放弃希望保留的答案发现、来源链接或用户主动读取。品牌应该先回答“我们希望公开内容在哪些用户场景被使用”，再决定具体身份，而不是先按公司名称封锁。

安全方面还有一个常见误区：robots.txt 不是访问控制。Google 的官方文档把 robots.txt 定义为管理抓取流量的指令，并明确指出它不能强制所有爬虫遵守，也不适合保护敏感信息。被拒绝抓取的 URL 仍可能因为外部链接而被发现；真正需要保密的页面应使用身份认证、授权、网络隔离或直接不公开。

同样，允许 user-agent 也不等于信任请求。user-agent 是客户端可以填写的字符串，恶意程序可以伪装成已知爬虫。Cloudflare 文档明确区分了仅依据 user-agent 的基础识别与更完整的机器人检测。网站日志看到一个熟悉名称时，应把它当作待验证信号，而不是平台已经为访问背书的证明。

因此，治理的核心不是写一份更长的 robots.txt，而是建立多层控制：公开内容用 robots 表达抓取偏好，边缘层用经过验证的机器人分类和速率策略管理自动流量，应用层用认证授权保护数据与操作，内容层用 canonical、更新时间和清晰事实减少旧版本冲突。每一层解决不同问题。

四、品牌网站应先做内容分级，再写爬虫规则

第一层是希望广泛传播的公共事实，包括品牌名称、主体、公开产品说明、服务范围、门店信息、公开政策、帮助文档和文章。这些页面通常适合搜索发现与用户触发读取。是否允许训练，需要依据企业的授权策略另外决定。即使允许抓取，也要保证页面只有一个稳定主版本，重要事实有明确日期和来源。

第二层是有商业价值但仍公开的深度内容，例如研究、数据库摘要、白皮书和专业教程。它们可能希望获得搜索引用和引荐，却不希望被无限批量复制。此时可以允许搜索与用户访问，限制训练身份或异常高频抓取，并通过许可说明、下载规则和访问日志保留边界。不要用把正文做成图片或故意破坏结构的方式保护内容，因为那也会伤害真实用户和无障碍访问。

第三层是需要登录或按合同提供的内容，包括付费课程、客户报告、内部知识库和账户数据。它们不应该仅靠 robots.txt 隐藏。搜索、训练和用户代理都必须服从现有身份与授权；即使用户让代理访问，也不能越过用户本人的权限。页面还应避免在 URL、HTML 源码或公开错误信息中泄露敏感字段。

第四层是事务与高风险接口，例如提交订单、修改资料、付款、预约、上传文件和发送消息。这里讨论的已不只是“能不能读”，而是“能不能做”。网站必须要求清楚的用户确认，校验权限和参数，对重复请求保持安全，记录操作结果，并为失败和撤销提供路径。若这些条件不成熟，可以先允许读取说明页，而不是开放自动操作入口。

第五层是明确不应公开的内容，例如密钥、个人敏感信息、未披露财务资料、内部草稿和安全配置。它们不属于任何 GEO 优化对象，也不应出现在公网可猜测 URL 中。正确做法是从发布流程、存储权限和网络边界上阻断，而不是期待所有机器人尊重文本指令。

五、按平台名称封禁，为什么容易产生连带损失

团队常见的规则是“我们不接受某平台训练，所以把它所有 bot 都禁掉”。这在身份未分化时似乎合理，但当前公开文档已经显示，同一家运营方可以有多个用途。例如阻止 GPTBot 是训练选择，OAI-SearchBot 则关系到 ChatGPT 搜索发现；ClaudeBot、Claude-SearchBot 和 Claude-User也承担不同角色。用运营方名称写一个模糊总规则，可能让真实意图无法落地。

另一种错误是照抄网上的“AI 爬虫大全”。名单可能过期，大小写、匹配范围和产品含义也会变化；某些身份仅适用于特定服务，另一些平台可能通过合作搜索源获得链接。站点应把官方文档作为主记录，保存观察日期和变更原因，并在测试环境验证规则。第三方列表适合发现线索，不适合直接成为生产策略。

Google-Extended 是理解连带影响的好例子。Google 明确说它不影响 Google Search 收录，也不是 Search 排名信号。如果团队因为不希望某些 Gemini 用途而错误阻止 Googlebot，损失会扩展到传统搜索；若只配置 Google-Extended，则应理解它管理的是官方列出的 Gemini 训练与 grounding 用途，而不是一个能够控制所有 Google 产品的总开关。

OpenAI 的说明还提示另一个边界：即使某页面不允许 OAI-SearchBot 抓取，如果平台从第三方搜索提供商或其他页面获得 URL，并判断与问题相关，仍可能只展示链接和标题；若不希望页面出现在这类结果中，应考虑 noindex，同时必须允许爬虫访问页面才能读取该指令。这说明抓取许可、索引控制和链接发现是不同层次，不能互相替代。

最稳妥的记录不是“允许 OpenAI/拒绝 Anthropic”，而是一张政策表：身份名称、官方角色、允许路径、拒绝路径、业务理由、负责人、验证日期和复查日期。未来平台新增身份或修改用途时，团队能找到需要重审的决策，而不是在 robots.txt 中猜当年的含义。

六、技术实施：robots、边缘规则、应用权限怎样配合

robots.txt 适合表达对守规矩爬虫的路径偏好。规则应尽量简单，使用明确的 user-agent 和目录，避免互相覆盖。发布后要检查公网最终响应，而不是只看仓库文件，因为 CDN、托管平台或安全产品可能改写 robots。本站此前的robots、sitemap 与结构化数据实测就说明，仓库配置与边缘实际返回需要分开核对。

边缘层负责执行型控制，包括验证机器人身份、速率限制、阻止异常请求、按路径设置规则和观察状态码。Cloudflare AI Crawl Control 的公开文档允许按具体爬虫查看请求、失败请求和 robots 违规，并选择允许或阻止；其付费与测试能力会随方案变化，使用前应核对当前可用范围。不要把控制台分类当成法律授权结论，它只是技术信号和执行工具。

应用层负责真正的安全。登录页、账户接口和交易动作应验证会话、权限、来源与参数，不因为请求自称“用户代理”就放宽。对会造成外部影响的动作，增加预览、明确确认、限额、幂等键、审计日志和撤销机制。只读内容与写操作最好使用不同端点和权限。

内容层负责减少机器理解冲突。公开页面应有稳定 URL、正确 canonical、清楚标题、可见更新时间、与正文一致的结构化数据，以及能够说明事实条件和边界的连续正文。搜索身份能访问并不意味着页面容易理解；如果同一产品在多个页面给出不同价格或状态，增加爬取只会更快暴露矛盾。建设方式可以继续参考品牌官网成为可引用信源的完整框架。

监测层连接前三层。每次规则调整都要记录基线：公网 robots 内容、目标 URL 状态码、特定身份的允许结果、边缘命中规则、服务器请求量、引用与引荐变化。规则生效不等于业务有效，只有把配置、访问与结果分开观察，才能判断是技术问题、平台变化还是内容问题。

七、日志应该记录什么，又不能从日志推断什么

一条有用的自动访问记录至少包括时间、URL、方法、状态码、响应字节、user-agent、来源 IP 或已验证机器人标识、边缘分类、命中规则和缓存状态。对高频请求还应观察路径分布与时间间隔。日志保留应符合隐私和安全政策，敏感查询参数要脱敏，不为了研究爬虫额外收集用户内容。

日志可以确认某个请求到达了哪里、服务器如何响应、边缘是否阻止，以及访问模式是否异常。它不能确认页面随后是否进入训练、被索引、出现在答案中或影响了用户。即使官方身份访问过页面，也不能把请求量当作引用量；这与把普通搜索抓取次数当成排名相同。

只靠 user-agent 的日志还存在伪装风险。若平台提供 IP 验证、反向 DNS 或可信检测标识，应按官方方式验证；没有验证条件时，报告中写“自称某身份的请求”，而不是“某平台已抓取”。Cloudflare 也明确说明，其免费方案主要依据 user-agent识别，升级后的机器人管理可使用更完整的检测字段。

监测变化时要保留规则版本。假设某类请求突然下降，可能是 robots 改动、WAF 拦截、平台换了身份、内容需求降低或日志采样变化。没有版本记录，就会把基础设施变化误判成 GEO 下降。每次修改应关联提交、发布时间、负责人和回滚条件。

结果层则需要另外的数据：平台站长报告中的引用或索引状态、带来源参数的引荐、人工固定问题复测，以及站内任务完成。上一轮关于引用、引荐与业务结果的分层测量可以作为连接日志与经营指标的参考。不同事件不要合并成一个“AI 曝光”。

八、四种常见反例：看起来积极，实际制造了风险

第一种是为了“让 AI 都能看见”而开放原本需要登录的文档。结果可能不是更多引用，而是客户资料和合同内容被公开访问。解决办法不是再追加 Disallow，而是恢复认证、检查缓存和搜索索引，并评估是否已经泄露。

第二种是为了阻止训练，把搜索身份和用户触发身份一并封禁。团队随后发现相关平台无法读取最新帮助文档，却仍可能从旧来源或第三方页面描述品牌。此时减少了权威来源供给，却没有消除外部叙述。正确做法是重新区分身份，并修好希望公开的事实入口。

第三种是把 robots 当成保密协议。规则本身公开可读，而且不强制恶意爬虫遵守。将敏感目录写入 robots 还可能暴露路径线索。真正敏感内容必须从服务器端拒绝未授权访问，必要时清理公开链接与缓存。

第四种是按请求量汇报“AI 关注度”。某训练爬虫一次批量重抓就能造成巨大波动，与用户提问和品牌引用没有直接关系。应按角色拆分，识别重复抓取和异常流量，再与引用、引荐、人工回答记录分别分析。

第五种是永久冻结规则。平台会更新身份、用途和文档，基础设施也会调整分类。今天正确的策略可能在新产品上线后产生空白。至少按季度、重要平台更新和业务内容等级变化复核；高风险站点应更频繁。

第六种是用“允许抓取”代替内容治理。页面互相矛盾、缺少日期、事实没有负责人，即使爬虫完全可访问，也可能选择旧版本或无法判断哪一页权威。先解决页面责任与证据，再讨论访问扩展。

九、适合不同网站的三种治理方案

普通品牌官网可以采用“公开事实优先”方案：允许搜索与用户触发身份访问官网、产品、帮助和文章；对训练身份按企业政策决定；登录区、后台和临时文件统一由认证保护；用日志观察异常。目标是让最新权威信息容易被用户和搜索产品读取，不追求最大抓取量。

内容出版与知识付费网站更适合“搜索开放、训练审慎”方案：公开摘要、目录和可引用事实保持可发现，全文访问遵守订阅授权；训练身份根据许可与商业模式配置；边缘层控制批量行为；为用户触发读取明确公开范围。若未来采用付费抓取或授权合作，应把技术规则、合同许可与收益核算连接，不能仅靠状态码表达全部条款。

平台型和交易型网站适合“读取与执行分离”方案：公开说明、库存摘要、规则和帮助页可被发现，用户账户与写操作严格走身份授权；代理访问只在可验证、可确认和可审计的范围内开放。对于价格、库存和资格等易变事实，页面要标记时间和条件，接口要防止重复提交。关于网站从回答走向行动的准备，可再看代理式搜索下的官网执行准备。

无论哪一种，都不应直接复制示例规则。企业需要确认法律责任、内容授权、所在地区要求、平台当期条款和技术架构。文章提供的是决策框架，不是法律意见，也不是任何平台的收录或训练结果保证。

十、边界与局限：公开控制比过去精细，但还不是完整授权系统

首先，平台公开角色和基础设施分类仍会变化。本文依据 2026 年 8 月 22 日可访问的一手页面整理，只描述当日公开含义。实施前应重新核对官方文档；如果平台说明与本文不一致，以最新官方说明和企业自身合规判断为准。

其次，robots 是自愿遵守的抓取协议，不是技术强制。守规矩的运营方通常会读取规则，恶意访问者可能忽略或伪装身份。需要保护的数据必须依赖认证、授权、加密、网络隔离和发布审查。边缘机器人识别也有误报与漏报，不能作为唯一安全边界。

第三，拒绝某个训练身份能表达针对该身份的选择，却不能让网站上的既有副本、第三方转载、历史数据或其他合法来源自动消失；具体范围取决于平台公开承诺与适用规则。品牌不应把一条 robots 记录解释成对整个互联网的删除命令。

第四，允许搜索或用户身份只保留访问机会，不保证抓取频率、索引、引用、答案准确性、引荐或推荐。生成式搜索还会受问题、地区、账号、产品版本、联网状态和其他来源影响。治理成果应通过技术检查、平台数据和固定问题复测分别验证。

最后，不同网站的价值冲突不同。希望广泛传播的企业帮助中心，与依赖独家内容收费的出版商，不应采用同一默认策略。正确答案不是“全部开放”或“全部封禁”，而是让每一类内容的公开目的、授权范围和风险控制一致。

十一、资料来源与下一步

本文仅采用平台和基础设施提供方的一手公开资料，并按 2026 年 8 月 22 日的可访问状态核对。下列页面的角色定义、产品范围和更新时间可能继续变化：

• OpenAI：Publishers and Developers FAQ，说明 OAI-SearchBot 与 ChatGPT 搜索内容发现、GPTBot 训练选择及来源链接的边界。
• Anthropic：网站抓取与站长控制说明，区分 ClaudeBot、Claude-SearchBot 与 Claude-User。
• Google：常见爬虫与 Google-Extended，说明该产品令牌管理的 Gemini 用途，并明确其不影响 Google Search 收录或排名。
• Cloudflare：AI Crawl Control Bot reference，列出主要 AI Crawler、AI Search 与 AI Assistant 身份及检测标识。
• Cloudflare：Manage AI crawlers，说明按爬虫观察与执行允许、阻止等控制，以及基础识别的限制。
• Google Search Central：robots.txt 介绍与限制，说明 robots 用于管理抓取流量，不能保护敏感信息，也不能强制所有爬虫遵守。

下一步可以从一张简单表格开始：列出最重要的二十个页面、公开等级、希望支持的访问角色、现有 robots 与边缘结果、真实负责人和复查日期。先把高风险的权限错误与高价值的搜索误伤找出来，再逐步扩展到全站。治理做得好，不是让更多机器人无差别进入，而是让正确的内容在正确的授权下被正确访问。