OAI-SearchBot OAI-SearchBot

OAI-SearchBot 是 OpenAI 的搜索索引爬虫，专职为 ChatGPT 搜索建立索引，是 ChatGPT 搜索引用池的守门人。OpenAI 官方声明它不用于模型训练，且遵守 robots.txt。对站长而言，它的直接含义只有一句：屏蔽它，等于放弃 ChatGPT 搜索可见度。

检索型爬虫：它在 OpenAI 爬虫家族里的位置

OpenAI 的爬虫按用途分三型：GPTBot 抓取用于模型训练，OAI-SearchBot 抓取用于建搜索索引，ChatGPT-User 在用户提问时实时抓取指定页面。三型的 robots 行为与 GEO 含义完全不同（详见 训练·检索·用户触发爬虫（三型））。OAI-SearchBot 属于其中的检索型：这类爬虫是 AI 可见度的入场券，屏蔽即出局；各家检索型爬虫的横向画像见 AI 爬虫（AI Crawlers / Bots）。

还有一个身份问题先澄清：OAI-SearchBot 与 GPTBot 不是一回事，前者为搜索建索引、后者为训练抓语料，两者的 robots 组各自独立，放行或屏蔽必须分别配置。实践中大量“屏蔽了训练爬虫、顺带失去搜索可见度”的事故，都源于把两个名字当成一个开关。

“遵守 robots.txt”的官方声明也值得单独强调：它意味着站长对这个爬虫有真实控制权，“放行”才是一个有意义的动作。相比之下，用户触发型爬虫通常无视 robots，配置再多规则也管不住——把预算和注意力放在能被控制的环节，是爬虫策略的第一原则。

把三个爬虫连起来看，ChatGPT 的内容链路是接力式的。OAI-SearchBot 建的索引决定“候选池”，Bing 信号参与排序；GPTBot 抓的训练语料影响模型对品牌的长期认知底子——答不答得上你、用什么口径描述你，与训练期见过什么有关；ChatGPT-User 则在用户把链接递给模型时实时抓取，决定“这一次能不能读全”。三段互相独立又互相影响，只守 OAI-SearchBot 一道门，是必要而不充分的。

对配置策略的含义是分通道决策：想进搜索引用，放行 OAI-SearchBot 并做好 Bing 收录；在意长期认知，另行评估 GPTBot 的取舍；ChatGPT-User 无法用 robots 控制，只能把页面本身的可抓取性做好。一份配置表按三个通道分别写结论，比一句“允许 AI”或“禁止 AI”严谨得多。

记录决策理由与时间也属于配置的一部分。AI 爬虫名单在持续扩容，今天的三型决策到下个季度可能要加新条目；没有留档的配置，半年后没人说得清每组规则为什么这么写，复盘与调整都无从下手。配置表加两列“决策依据、复核时间”，成本几乎为零。

引用供给：自建索引加 Bing 信号

ChatGPT 搜索的引用供给是“自建索引+Bing 信号+实时抓取”的组合（引擎档案见 ChatGPT Search）。实测口径显示，ChatGPT 引用与 Bing 首页高度重合，约 87%（Seer 口径，未复验；数据卡 有留档与注意事项）。因此“进 ChatGPT”=OAI-SearchBot 放行+Bing 收录（Bing WMT+IndexNow）双管齐下，两条腿缺一不可：只放行爬虫而 Bing 侧无收录，等于让索引层失去信号来源；只做 Bing 收录而爬虫被屏蔽，自建索引里根本没有你。

窗口窄进一步加剧竞争：ChatGPT 的引用窗口平均约 7.9 个来源（引擎档案口径），“进前几名来源”的争夺比传统 SERP 激烈得多。放行爬虫解决的是资格问题，能否进窗口取决于内容的相关度与可摘录性——这也是为什么爬虫配置只是入场动作，从不承诺出场顺序。

诊断的第三环是内容本身。前两环都通而引用仍少，就要回到“引擎为什么选别人”：同一问法下被引的页面长什么样、结构与表述有什么可借鉴之处。供给链诊断负责“能不能参赛”，内容诊断负责“能不能上场”，两份结论不要混在一份报告里。

这也解释了为什么“ChatGPT 上搜不到我”的诊断要从两处同时下手。只查 robots 会漏掉 Bing 侧的收录欠账，只查 Bing 又可能漏掉爬虫被屏蔽的事实；两条线各自出结论再对表，才能定位断点在供给链的哪一环。

屏蔽的合理场景与代价

并不是所有站点都该放行。付费墙内容、依赖搜索流量变现且不愿被摘要替代的出版方、明确表态拒绝进入 AI 语料的创作者，屏蔽 OAI-SearchBot 是立场明确的商业决策——代价同样明确：ChatGPT 搜索的引用与展示从此与你无关。决策的关键是把代价写在纸面上，而不是事后再发现流量消失。

中间态也存在：允许被抓但限制特定路径、允许搜索索引但拒绝训练用途（训练归 GPTBot 与各家的训练开关分别管），这类组合在 robots 层都可以表达。先想清楚“要哪一环、不要哪一环”，再落配置，避免一键全禁或全开的粗颗粒决策。

边界情形还包括联合品牌与代理内容：站点上有不属于你的内容时，放行决策要对内容权属敏感；为他人托管的内容做不了主的，先厘清授权再动配置。这类情形不常见，出事时却最难收拾，值得在配置表里单列一栏备注。

放行与收录的实操清单

robots 配置的第一个坑是组间不继承：robots.txt 里具名爬虫组只看自己的规则，不继承通配组的设置（详见 robots.txt（AI 语境））。若站点对全部爬虫有全局 Disallow，必须为 OAI-SearchBot 单独建组放行，否则全局禁令会罩住它；反过来，想精准放行也必须逐组写，漏写一组就漏一个通道。改完配置用日志验证 OAI-SearchBot 是否真的开始来访，这一步不能省。

Bing 侧的动作同样具体：注册 Bing 站长工具提交站点与内容，配合 IndexNow 做新内容的即时推送，缩短从发布到进入候选池的延迟。中文站点还要注意 Bing 与国内引擎收录的独立性——Bing 收录不代表国内引擎收录，反之亦然，通道要分别经营。

配置改完还要防止回退：站点改版、迁移或重写 robots 时，逐组的放行规则最容易在批量重写中丢失。把当前配置纳入备份与变更评审，等于给 ChatGPT 通道上了保险——这类事故不出则已，一出就是整条通道静默消失，而且没人说得清是从哪天开始的。

确认放行生效后，日志能回答三个问题。来不来：按 UA 加 IP 段双重过滤出真身请求，观察是否出现与持续；来多勤：频率随站点权重与更新节奏浮动，新内容发布后请求是否跟进，能看出索引层的捡取速度；抓什么：被抓 URL 的分布对照站点结构，能发现重要区块是否被遗漏。三个答案合起来，就是 ChatGPT 通道的抓取健康度。

抓取健康度要与引用表现分开读。抓取活跃而引用不动，问题在内容的相关度或排位；抓取本身稀少，先回头查配置与收录。把两层混在一起归因，是通道诊断里最常见的错误。

怎么读日志、怎么验真身

UA 字段可以任意伪造，凭日志里的 User-agent 判断身份并不可靠——伪装采集、竞品抓取都可能顶着 OAI-SearchBot 的名字。验证其真身要用 UA 加官方 IP 段双重核对：OpenAI 发布的 searchbot JSON（openai.com/searchbot.json）列出了官方 IP 段，把日志来源 IP 与之比对，匹配才算真爬虫。

比对流程可以固化成三步：第一步按 UA 过滤出候选请求，第二步对候选做 IP 段匹配，第三步对未匹配的残量单独归档——残量里常有值得警惕的东西，比如伪装成官方爬虫的采集器、超常规频率的抓取。把残量也纳入例行观察，验证真身这件事就从防守变成了情报。

防伪造不是洁癖，而是为了把账算对。把“放行后的真实抓取量”与“伪装流量”分开，才能准确评估 ChatGPT 通道的健康度：抓取频率的变化、新页面被捡起的速度，都只有建立在真身流量上才有解读价值。日志核对建议做成例行环节，尤其是在流量突增突减时，先验真身再归因。