GPTBot 档案：训练爬虫的官方口径与放行决策

在 OpenAI 官方文档在册的四条爬虫里，GPTBot 是唯一的训练采集线：抓取的内容可能进入生成式基础模型的训练语料。它与检索线的 OAI-SearchBot、用户触发的 ChatGPT-User、广告校验的 OAI-AdsBot 并行存在，在 robots.txt 上各自独立表态。名单一直在扩员——第四条 OAI-AdsBot 就是大厂商业化闭环补上的一环——对单一厂商做决策前先看清全族分工。全景名单与验证端点见AI 爬虫全景档案表，本页只做 GPTBot 的单爬虫深档：官方口径、验证方法与放行封锁的取舍逻辑。

家族分工：GPTBot 站的是训练岗

官方文档把四条爬虫的用途与屏蔽后果写得直白，逐条对照如下。

这套分工对站长最重要的一点是：GPTBot 的屏蔽决策与 ChatGPT 搜索可见度脱钩。屏蔽 GPTBot 不会让你退出 ChatGPT Search——那是 OAI-SearchBot 的事；反过来只放行 GPTBot 也换不来任何搜索引用。两条线必须分开决策，把“要不要挡 OpenAI”当成一个问题来谈，是配置事故的起点。训练与检索两条线的取舍差异，站内另有专卡展开（见GPTBot 与 OAI-SearchBot 的区别）。

还有一点值得放进背景认知：四条线覆盖了训练、检索、用户动作、广告校验四种用途，意味着 OpenAI 对内容的取用面是全链路的。站长在 robots.txt 里做的其实是四次表态，而不是一次站队——这也是为什么具名组纪律对 OpenAI 家族格外重要。

官方口径：UA、robots 语义与生效节奏

官方 UA 以 Mozilla/5.0 兼容串开头，核心标识是 GPTBot/1.4，尾部带指向 openai.com 的官方标识页；文档同时提示版本号可能变动，写匹配规则时不要把版本钉死，用前缀匹配加 IP 核对才是稳的。一个对日志分析有用的细节：GPTBot 抓取 robots.txt 时会在 UA 串里附加 robots.txt 标记，靠这个标记可以在缺少路径信息的日志里把“取规则”与“取页面”分开——做抓取审计时这是个便宜的分诊字段。

robots 语义上有四条官方口径值得记。第一，GPTBot 遵守 robots.txt，但具名组要自己写——语法里“具名组不继承通配组”的规则对它同样适用，写在通配组里的放行或禁令对它都不生效。第二，robots.txt 变更后约需 24 小时生效，这是官方原文口径；生效节奏与 robots 文件自身的缓存机制叠加，改完配置别指望即时开关，验证效果要等满一个缓存周期再下结论。第三，双开关独立但抓取可以合并：官方原话是“如果你的站点同时放行了两个爬虫，我们可能只用一次抓取的结果服务两种用途”——同时放行 GPTBot 与 OAI-SearchBot 的站点，训练与检索共享同一次抓取，两个开关的设置仍然互不影响。第四，文档域名经历过一次迁移，现托管在 developers.openai.com 域下，引用官方口径的脚本与书签应核对新址。具名组的完整写法与通配组陷阱见robots.txt AI 配置矩阵。

验证：分爬虫的 IP 核对与两条行为注脚

OpenAI 的验证粒度是大厂里最细的：四条爬虫各有一份官方 IP 清单，GPTBot 对应 openai.com/gptbot.json。判定流量时必须对到具体爬虫的清单，不要用“OpenAI 的 IP”这种笼统概念——把 ChatGPT-User 的请求记进 GPTBot 的账，训练策略的评估就被污染了；把 OAI-SearchBot 的请求当成 GPTBot 限速，可见度反而被自己误伤。UA 命中、IP 核对、反解闭环的完整三关流程见爬虫日志验证方法档案。

两条行为注脚帮你看懂日志。其一，第三方实测中 GPTBot 会下载 JS 文件但并不执行，把 JS 当静态文本处理——日志里看到它请求 JS 资源，不等于它渲染了你的页面；据此得出“我的前端渲染站点没问题”的结论，是这条注脚要拦住的误读（量化细节见GPTBot 下载 JS 数据卡）。其二，量级参考：Vercel 口径 GPTBot 月请求约 5.69 亿次，四大 AI 爬虫合计约为 Googlebot 的 28%（见四大 AI 爬虫月请求数据卡）——它是 AI 爬虫里流量最大的一条，任何限速与预算方案都绕不开它，放行决策要连带算带宽账。

另外要单独拎出一类容易混淆的访客：带 Web Bot Auth 签名的 OpenAI agent 流量（ChatGPT Agent、Operator）不是 GPTBot，行为是真浏览器式的任务访问，会点击、会等待渲染，验证与处置路径都不同——在日志里把它们与 GPTBot 混为一类，会同时污染训练账与体验账。

放行还是封锁：训练线的取舍逻辑

GPTBot 的决策本质是“要不要进 OpenAI 的未来语料”，我们的取舍框架分三问。第一问，内容时效：训练语料影响的是模型的长期认知，沉淀周期以年计；对时效敏感、靠“被检索”吃饭的站点，屏蔽训练线的即时损失很小。第二问，引用结构：官方没有把训练放行与 ChatGPT 引用挂钩，“喂训练数据换引用”没有官方依据——这与屏蔽 OAI-SearchBot 的明确后果（退出搜索答案）完全不对称，谈交换之前先看清这个不对称。第三问，姿态成本：训练线放行的成本主要是抓取带宽与内容被长期沉淀；若选择放行，至少把站内搜索、参数页、后台路径这类零价值路径在 GPTBot 组里排除，把抓取赶到高价值页。

两个常见误判顺手记下。一是“屏蔽 GPTBot 会影响 ChatGPT 引用”——把训练线与检索线的后果记串了，官方后果表里没有这层联动。二是“放行了 GPTBot 就等于内容会被整段背下来进答案”——训练进的是长期语料，与检索式引用是两条机制，后者取决于 OAI-SearchBot 的索引与答案合成，不是训练线的直接产物。

决策落成配置之后还有一步常被省略：回读日志验证姿态与实际行为是否一致。robots 写了 Disallow 之后，日志里 GPTBot 的请求应在一个缓存周期内归零；仍在出现的“具名 GPTBot”流量要按伪装嫌疑走验证三关，而不是默认它是官方来的。姿态、配置、日志三层对上，这条训练线的台账才算闭合。

我们的口径：默认姿态是“检索放行、训练单独决策”，而不是对 OpenAI 全族一刀切。检索线是可见度入场券，训练线是长期资产配置，两类资产的生命周期不同，决策节奏也应分开。user-triggered 类的 ChatGPT-User 在协议层管不到，闸门在边缘层，这条边界与各家的完整对照见 robots 配置矩阵。