Anthropic 爬取回流比约 38000:1——AI 爬虫"只取不予"

爬取回流比（crawl-to-visit ratio）刻画的是 AI 爬虫“只取不予”的结构：据 Cloudflare Radar 口径（2025-06，厂商自报），Anthropic 每回访 1 次要爬约 3.8 万页（约 38000:1），OpenAI 约 1700:1，作为对照的 Bing 约 40:1。换句话说，一个放行 Anthropic 爬虫的站点，要用数万页的抓取成本，才换得回一次来自 Claude 产品的访问引荐。对站长而言，放行爬虫换可见度从此不是可以凭感觉表态的问题，而是一笔有量级数据支撑的交换决策。

38000:1 是怎么算出来的

分子是爬取请求，分母是回访引荐。Cloudflare Radar 在其固定客户群上统计各家爬虫的页面抓取量，再对照用户从对应 AI 产品点击进入站点的访问量，两者相除得到回流比；样本为厂商自报口径，研究档案见Cloudflare：AI 爬虫流量年度研究。这个口径有两个先天限制：客户群结构决定读数——技术内容密集的站点本来就被爬得更狠；回访的归因依赖跳转识别，AI 产品链路里的归因缺口会低估真实回流。

读数还要注意时间窗的错配：分子是当月爬取量，分母是当月引荐量，而今天的抓取换来的引用可能发生在数月之后的答案里——训练与索引都有滞后。这个错配意味着观测到的比值还高估了交换的即时性，也再次说明该指标只适合量级判断，不适合精细核算。

因此三个比值都应作量级读。38000:1 与 1700:1 之间的差距，远大于测量误差的可能范围，这个量级差本身就是结论；但纠结 38000 与 40000 之间的差别没有意义。本站引用时锁定“据 Cloudflare Radar”的口径与 2025-06 的时间戳，不做二次加工的换算。

三个量级，三种交换契约

Bing 的 40:1 是理解这组数字的锚。传统搜索引擎的隐含契约是“我抓你，用户搜到你，你我各取所需”，抓取与回访之间存在一条粗但成立的回流通道；Anthropic 的数万页抓取换一次回访，说明其抓取当前主要服务于训练语料建设而非即时检索。按训练·检索·用户触发爬虫（三型）的框架，这是训练型爬虫的典型画像；OpenAI 居中，既有训练抓取，也有服务于搜索产品的检索抓取。

这与抓取量级侧的证据互相咬合：四大 AI 爬虫月请求合计已约为 Googlebot 的 28%，但其中真正决定 AI 搜索可见度的检索型爬虫仅占全部请求的约 1.1%，口径见四大 AI 爬虫月请求合计约为 Googlebot 的 28%。两个数字合读的结论很直接：“抓得凶”与“帮你可见”是两件事——放行决策应当按爬虫类型分开做，而不是对“AI 爬虫”这个整体一刀切，各条爬虫的身份与用途辨析见AI 爬虫（AI Crawlers / Bots）。

把成本科目摊开，这笔交换才看得清。抓取请求的直接代价是带宽与源站算力；间接代价至少还有三项：日志体量上涨带来的存储与解析成本、缓存与回源策略被打乱的性能成本、以及伪装成知名爬虫的扫描流量混入后安全侧的甄别成本。对中小站点，这些科目加起来仍小到可以忽略——月请求量级摆在那里；对高流量站点，每一项都足以进运维的月度账单。回流比的决策权重因此与站点体量正相关：站越大，38000:1 越是一笔需要认真算的账。

放行决策怎么落地

我们建议把 robots 配置写成按类型分开的三份答卷。检索型爬虫默认放行，它们是 AI 可见度的入场券；训练型爬虫按品牌姿态取舍——接受的是一笔回报周期极长、几乎无法归因的交换：反对者用 38000:1 说明“白给”，支持者认为进入训练语料是长期能被模型内化提及的资产，两边判断都成立，分歧在业务的时间视野而不在对事实的认定。配置项与各厂商标记的对应关系，展开见robots.txt（AI 语境）。

工程上，比 robots 更可控的是网关层治理。对高流量站点，数万比一的回流比意味着带宽与算力是实打实的支出：按爬虫标识做速率限制、给训练型爬虫设每日配额、避免被无条件回源，这些手段把“放行”从二值开关变成可调的旋钮。全站封禁又解封的反复横跳则要避免——它既破坏任何一类抓取的可预期节奏，也让自家日志失去连续性。

还要防一个记账错误：把放行的账全部记在可见度头上。放行训练型爬虫的收益（进入模型知识）不体现在引荐流量里；反过来，AI 引荐起量时也不该归功于训练抓取。两本账分开记，放行决策才不会变成自我说服的循环论证。

配置生效后要留观察期：每次调整 robots 或网关规则后，跟踪一段时间的抓取与引荐两条线，确认行为符合预期再走下一步——一次只改一个变量，归因才有意义。

这笔账会变，要定期重算

回流比不是常数。AI 产品的用户规模扩大、答案挂出来源链接的形态成熟之后，分母（回访）会自然增长，比值会朝 Bing 的方向回落——方向可以预判，速度不能；Cloudflare 的客户群结构也会随时间漂移。这张表是 2025-06 的快照，不是长期合约。

最可靠的做法是算自家版本：日志侧按爬虫标识统计各家月请求量，分析侧把 AI 引荐单独建渠道分组，两数相除就是你站点的回流比。技术站、资讯站、电商站的读数会差得很远，外部比值只能回答“该不该认真算这笔账”，算出来的取舍永远应该以自家数字为准。

复核纪律：先确认真的是那条爬虫

回流比与放行决策都建立在日志可信的前提上，而顶着知名爬虫名义的请求并不都是真的。复核动作应是标配：用各家官方公布的网段反查请求来源，把伪装流量从统计里剔掉，再谈放行与否。这一步在中文语境里尤其必要——扫描器与采集器冒用主流爬虫标识的情况不少见，把它们的请求计入“AI 爬虫成本”，会同时高估抓取压力、误判对方行为。

复核的产出建议固化成三个观察量：各爬虫请求量的月度序列（谁在涨、谁消失）、各引擎引荐访问的月度序列（分母有没有起量的迹象）、两者相除的自家回流比序列。第三个量是决策的核心仪表——它从“数万比一”向“数百比一”移动的速度，就是这笔交换变划算的速度，也是重启配置复核与商务对话的时间信号。

两个极端场景，两种答案

同样的数字，落在不同体量的站点上，答案方向相反。新站与中小站点：抓取量本身有限，成本科目近乎为零，放行的下行风险很小，而进入引擎视野的期权价值真实存在——默认放行、把精力放在内容与结构上，是合理默认。高流量站点：成本科目逐项实打实，需要按爬虫类型分级治理、按网关限额，甚至把抓取政策写进与厂商的商务对话——内容授权与许可谈判里，抓取量与引荐量的悬殊正是议价的背景事实。

介于两者之间的站点，判断标准只有一条：把自家回流比算出来。外部比值给的是“这件事值得算”的判断，自家比值给的才是“该怎么取舍”的答案。这也是本卡想留下的方法论：量级数据用来建立问题意识，决策数据必须自己生产。