训练·检索·用户触发爬虫（三型） Training / Search / User-Triggered Crawlers

把 AI 爬虫按“抓下去的数据拿去干什么”来分，只有三类：训练型抓语料喂模型，检索型建 AI 搜索索引，用户触发型在用户提问时实时抓取指定页面。这个三分法来自 OpenAI 的 bots 官方文档——它把自家 GPTBot、OAI-SearchBot、ChatGPT-User 分别归入三种用途，其余厂商的产品线也基本能落进这三个格子。对站长而言，三分法的价值在于把“AI 爬虫要不要放行”这个混沌问题，拆成三个可以分别回答、分别承担后果的问题。搜索“训练爬虫和检索爬虫的区别”的人，要的其实也是这张决策地图：同一份 robots.txt，对三类爬虫意味着三件完全不同的事。

训练型：屏蔽的代价在长期语料

GPTBot（OpenAI）、ClaudeBot（Anthropic）、Bytespider（字节跳动）、Meta-ExternalAgent（Meta），以及 Google 侧由 Google-Extended token 控制的那部分用途，都属于训练型：抓内容的用途是喂模型，而不是回答任何一次具体搜索。主流训练爬虫均声明遵守 robots.txt，屏蔽它们的直接后果只有一个——退出未来的训练语料。页面不会从搜索结果里消失，AI 搜索的引用也不受影响，损失发生在“模型对你的认识”这个缓慢的维度上：下一代模型发布时，它对你的产品、术语与观点的熟悉程度，取决于你的内容在不在这份语料里。

这个后果的迟滞期容易被低估。今天屏蔽，伤害要等模型版本更新才会显现，而且几乎无法归因——你观察到的是模型“不提你”，却很难把这件事与当年那次 robots 改动对应起来。反过来，放行训练爬虫也不是无代价的善意：据 Cloudflare Radar 口径，Anthropic 的爬取回流比约为 38000:1，即每换来一次回访要先抓约 3.8 万页（爬取回流比），“只取不予”的结构性不对称真实存在。我们的口径是把它当一笔回报周期极长、又无法写进任何合同的交换来决策，而不是默认放行。

还有一条工程事实要并进决策：据 Vercel 托管网络的观察，四大 AI 爬虫的月请求合计约为 Googlebot 的 28%，且主流 AI 爬虫不执行 JavaScript（AI 爬虫与 Googlebot 请求量对比）。依赖客户端渲染的内容，训练型爬虫放行了也读不到——想进训练语料，前提是内容在 HTML 源码里就完整可读，这与服务端渲染的技术选型直接相关（SSR / SSG）。

检索型：AI 可见度的入场券

OAI-SearchBot（ChatGPT Search 的索引爬虫，见 OAI-SearchBot）、PerplexityBot、Googlebot、Claude-SearchBot 属于检索型：抓取是为了建 AI 搜索的检索索引，你的内容在不在这个索引里，直接决定 AI 回答能不能引用你。屏蔽即出局——没有申诉入口，恢复要等索引刷新，期间你在对应引擎的 AI 可见度是零。“入场券”就是这个意思：内容质量、引用率、赢得媒体，全部建立在“先被索引”这块地基上，地基抽掉，上层动作全部空转。

检索型也是最常被误伤的一类。robots.txt 的语义是具名组只看自己的规则、不继承通配组，于是常见的自伤有两种：在 User-agent: * 组里写了禁令，以为会自动作用于所有爬虫，结果具名组照抓不误；或者反过来，通配组全站禁止、漏给检索爬虫单独开组，AI 可见度归零却毫无感知。逐组写规则、逐组核对日志，是管理这一类的纪律（详见 robots.txt（AI 语境））。

用户触发型：robots 管不到的那一环

ChatGPT-User、Perplexity-User、Claude-User 是第三类：用户在对话里点名“读一下这个网页”时，产品实时抓取该 URL 供本次会话使用。官方口径是这类爬虫一般忽略 robots.txt，站长无法用 robots 事前管控——这不是协议漏洞，而是产品逻辑：robots 表达的是站点对自动抓取的意愿，用户明确指定的抓取被视为用户自己的授权，意愿声明管不到用户指令。

它对 GEO 的含义有两层。其一，这一环的可达性只能靠页面本身：不依赖 JavaScript 渲染、标题层级清晰、开头就有自含式的即答段，机器来了能读、读了能用。其二，出现在这一环意味着用户已经带着你的 URL 进入对话——这是强意图信号。监测时值得把用户触发型抓取从爬虫日志里单独归类：它是“品牌被用户主动带入 AI 对话”的最原始证据，也是三型里唯一由用户点名、而非引擎决定的那一环。

这一环还有一个常被忽略的时效优势：检索索引以天到周为单位刷新，用户触发型以秒计。价格、政策、版本号这类时效敏感信息，改完页面不用等重收录，用户下一句“帮我读一下这个链接”拿到的就是新版。对经常发勘误和更新的站点，这意味着页面维护的回报有一部分是即时的，不完全受索引周期摆布。

按环节逐类决策，不要一键全开或全禁

配置原则一句话：按“想进哪一环”逐类决策。注意决策单位是用途而不是公司——OpenAI 同时运营训练型的 GPTBot 与检索型的 OAI-SearchBot，放行一个、屏蔽另一个是完全正常的组合，不必因为对某家厂商的态度把两类捆绑处理。我们建议的默认顺序是：检索型默认全放，这是可见度的入场券，屏蔽等于主动退赛；训练型按品牌姿态二选一，愿意成为公共语料就放行，介意内容被无偿取用就屏蔽，代价是接受“模型长期不认识你”；用户触发型无法用 robots 控制，预算花在渲染可达性与内容结构上，而不是纠结规则。

还要接受一个现实：爬虫名单不是静态的。厂商会新增产品线、调整某个 bot 的用途归类，各家官方文档才是当前事实的唯一来源。每次复核 robots 配置时顺手对一遍名单，别拿一份多年前的“AI 爬虫清单”做今天的决策——清单会过期，三型框架不会。

用日志核对三型爬虫的真实行为

规则写了不等于行为如预期，核对要靠服务器日志。做法上，把日志按 User-Agent 分桶，归入三型，再分别看三件事：抓取量级的变化（哪类爬虫最近变多或消失）、路径分布（抓的是核心页还是被无意义参数页消耗）、抓取后的状态码构成（多少 200、多少 404 与跳转）。训练型看趋势，检索型看覆盖是否完整，用户触发型看单次访问的上下文——它通常跟着特定的页面类型走。

两个核对细节值得写进流程。其一，具名爬虫可以反向核验归属：自称 GPTBot 的请求，可以通过反向解析确认是否真的来自对应厂商的基础设施，伪装 UA 的抓取不该计入任何一型的决策依据。其二，核对应有节奏：每月例行一次，robots 改动后加做一次，站点大改版或重要活动后专门看检索型回访是否正常。三型爬虫的决策依据、风险形态、复核方式都不同，唯一共通的是：每次 robots 改动后，都要在日志里确认改动只影响了你想影响的那一环。把三型混为一谈、一键全开或全禁，几乎必然在某一环上付出看不见的代价——而那一环的损失，往往要等很久才被察觉。