AI 爬虫（AI Crawlers / Bots） AI Crawlers

AI 爬虫（AI Crawlers / Bots，也叫 AI 抓取器、AI Bots）指 AI 厂商部署的抓取程序。判断一条爬虫对你的含义，唯一可靠的出发点是它的用途：同一家厂商的不同爬虫，可能一条在喂模型、一条在建搜索索引、一条在替用户实时取页。放行或屏蔽哪一类，直接决定你的内容进入 AI 生态的哪一环——长期语料、AI 搜索引用池，还是用户当场提问的结果。三类用途必须分清，这是所有 robots 决策的前置知识，也是这张卡要交付的核心框架。

训练、检索、用户触发：三类爬虫各自决定什么

训练爬虫（GPTBot、ClaudeBot、Bytespider 等）把抓到的内容喂给模型训练，影响的是长期语料层：你的内容会不会成为模型“认识世界”时的一部分。它不决定你此刻在不在 AI 搜索的引用池里——屏蔽它，损失的是长周期里模型对你的先验认知与话语权沉淀，收益是内容不进入别家的训练语料。这一层的取舍节奏慢，改一次心智成本高，值得想清楚再动。

检索/索引爬虫（OAI-SearchBot、PerplexityBot、Googlebot 等）为 AI 搜索产品建索引，是 AI 可见度的入场券——决定你进不进 AI 搜索引用池的就是这一类，屏蔽即出局。想做 GEO 却挡住检索爬虫，等于拿着门票不进场的镜像操作：所有内容优化都作用于一个索引器永远看不到的站点。对以 AI 引用为目标的站点，这一类默认应当放行，例外情况极少。

用户触发爬虫（ChatGPT-User、Perplexity-User 等）在用户提问时实时抓取指定页面，官方声明通常无视 robots.txt。它们不建索引、不喂模型，只为“用户此刻要这个页面”服务。协议层基本控制不了它们，能做的是保证页面服务端可达、内容可摘录，让“被现场读取”这件事至少发生在一个准备好的页面上。

三型的行为边界与逐型决策框架，本库另有专卡展开：训练·检索·用户触发爬虫（三型）。单条爬虫的档案（官方声明、验证端点、索引还是训练）见各自词条，例如OAI-SearchBot；检索型一端同样以自建索引著称的 PerplexityBot，也有独立档案卡。

放行是一次交换：先看量级，再谈态度

AI 爬虫的抓取已经不是零星现象。据 Vercel 对其托管网络的统计（媒体转述，本站未复验），四大 AI 爬虫的月请求合计已约为 Googlebot 的 28%——AI 抓取成为基础设施级流量。同一份报告还有一个对内容方更要紧的定性发现：主流 AI 爬虫普遍不执行 JavaScript，客户端渲染的页面在它们面前大概率是空壳。量级与口径见数据卡四大 AI 爬虫月请求合计约为 Googlebot 的 28%。

放行的另一面是“换回什么”。Cloudflare Radar 口径下，Anthropic 每回访站点一次要抓取约数万页，OpenAI 也是数百页起步的悬殊比例——“只取不予”是 AI 爬虫的结构性特征，抓取量与回流访客之间存在巨大落差。对站长而言，放行检索爬虫是“以语料换可见度”的投资决策，放行训练爬虫则是更长期的、几乎无法归因的话语权投资；两者都不是理所当然的义务，量级数据让这些决策有据可依。完整口径见Anthropic 爬取回流比约 38000:1——AI 爬虫“只取不予”。

屏蔽训练爬虫挡不住 AI 搜索，全屏蔽等于退场

最常见的误判是对象搞错：站长屏蔽了 GPTBot，就以为“我们不出现在 AI 里了”。决定 AI 搜索可见度的是检索爬虫——想退出 ChatGPT 搜索的引用池，要动的是 OAI-SearchBot；想退出 Perplexity，要动 PerplexityBot；Google 系的 AI 摘要干脆共用常规搜索索引，连单独的开关都不存在。训练爬虫的去留只影响语料层，把它当成 AI 搜索的开关，方向就是错的。

第二个极端是“全屏蔽 AI 爬虫”。这等于一次性退出所有环节：训练语料、检索引用池、用户触发的现场抓取全部放弃，是主动退出 AI 生态的决策。对内容生意而言，它通常只在版权诉求明确、且清楚知道代价（等于把引用池让给所有竞品与所有第三方内容）的时候才值得选。选了就要接受结果，不能既全屏蔽又抱怨 AI 不引用自己。

第三个误操作是忘记用户触发型不受 robots 控制。ChatGPT-User、Perplexity-User 在用户明确要求读取某页时行动，官方口径一般忽略 robots.txt——指望用协议挡住它们必然落空。robots 语义的三条铁律（具名组间不继承、大小写不敏感、遵守出于自愿）展开见robots.txt（AI 语境）；Google 系的细粒度控制另有一类“控制型 token”，例如屏蔽 Google-Extended 只影响 Gemini 训练语料、不影响搜索收录与 AI 摘要出现，是“分层取舍”的典型样本，见Google-Extended。

从盘点到定案：一次像样的决策流程

对多数站点，我们建议把爬虫决策拆成五步走完，而不是凭一两条新闻就改 robots。第一步盘点：拉一段有代表性的访问日志，统计各条 AI 爬虫 UA 的请求量、命中路径分布与抓取深度，先知道自己实际在被谁抓、抓的是什么。第二步归类：把出现的爬虫按三型框架归位，训练的归训练、检索的归检索、用户触发的单独列出——很多站长在这一步会发现，自己纠结半天的某条爬虫根本不是决定可见度的那条。第三步定目标：明确你要进入哪些引擎的引用池、是否在意长期语料层，目标不同，矩阵完全不同。第四步写配置：逐组写 robots 声明，宁可啰嗦也不要依赖通配组的隐式继承；有法务或授权诉求的，再并行写用途声明。第五步复核：过一段时间回到日志，验证各爬虫的实际行为是否与配置一致，同时观察目标引擎的引用表现有没有变化，把“配置—行为—结果”的链条闭上。

成本也是矩阵里的一列。放行不等于无条件接受全部压力：对高流量站点，AI 爬虫的抓取会带来实打实的带宽与算力开销，用网关层的速率限制管理压力，比在 robots 里反复横跳更可控——robots 表达的是偏好，限流执行的才是纪律。中文站点还要多想一层生态差异：各家中文 AI 产品的引用池结构差别很大，有的深度依赖自家生态内容，第三方站点进入的通道与权重各不相同，照搬海外攻略往往失灵，先分清“这条爬虫服务于哪个产品、进的是什么池子”再决定投入。

动手之前先核实：日志、UA 与反查

执行层面还有一条纪律：日志里出现某条知名 UA，不等于它就是那家厂商的真爬虫。伪装扫描器常顶着 GPTBot、Bytespider 之类的名字探测漏洞路径，把攻击流量当成厂商抓取来决策，会得出完全错误的取舍。核实的方法是 UA 加官方 IP 段反查（各家公布各自的验证端点），再对命中请求抽查行为特征：真爬虫按声明用途行动，抓取节奏平稳、路径集中在内容页；伪装流量则常伴随可疑路径的探测与异常的请求模式。对无法验证的流量，按风险处理而不是按传言处理——把它们从“厂商关系”的账本里划出去，交给安全团队按扫描器对待。

决策建议落在一张配置矩阵上：列出你关心的全部爬虫，逐条标注用途类型、放行与否、验证方式，再核对“想进哪一环”的目标是否与矩阵一致。本站的 robots 配置矩阵与各爬虫档案整理在技术规范栏（P2 上线），届时可逐条对照使用；在那之前，按三型框架先把自己的日志归类，是最务实的第一步。