ChatGPT Search

ChatGPT 搜索的引用供给是「自建索引+Bing 信号」双轨：OpenAI 用自家的 OAI-SearchBot 建搜索索引，排序侧大量倚重 Bing 的信号，用户把链接递进对话时再由实时抓取兜底。对站长而言，Bing 收录与 OAI-SearchBot 放行构成一组入场券，缺哪条腿都会静默出局；而它的引用窗口窄（平均约 7.9 个来源），「进前几名来源」的竞争远比传统 SERP 激烈——这两件事合起来决定了 ChatGPT 优化的全部重心：先把资格问题解决干净，再谈窗口内的位次。

三只爬虫，三扇不同的门

ChatGPT 的内容链路上有三只名字相近、职责完全不同的爬虫，混淆它们是这类工作里最常见的配置事故。OAI-SearchBot 是检索型：为搜索建索引，官方声明遵守 robots.txt 且不用于模型训练，它是引用池的守门人，屏蔽它等于放弃 ChatGPT 搜索可见度，档案与真伪验证方法见OAI-SearchBot。ChatGPT-User 是用户触发型：用户在对话里点名某个页面时实时抓取，通常无视 robots，配置拦不住它，只能把页面自身的可抓取性做好。GPTBot 是训练型：抓语料喂模型，只影响模型对品牌的长期认知，与某次搜索引不引用你没有直接关系。

三扇门要分别决策、分别记账：想进搜索引用，放行 OAI-SearchBot 并做好 Bing 收录；在意长期认知，另行评估 GPTBot 的取舍；ChatGPT-User 管不住，也不必硬管。实践中大量「屏蔽了训练爬虫、顺带失去搜索可见度」的事故，都源于把几个名字当成一个开关。robots 还有一条硬规则：具名爬虫组不继承通配组的规则，全站存在禁令时必须为 OAI-SearchBot 单独建组放行；改完配置要在服务器日志里验证它真的开始来访，按 UA 加官方 IP 段双重过滤，别把伪装流量当成抓取回暖。

训练通道的取舍值得多说一句，因为它的时间尺度和搜索完全不同。GPTBot 抓走的内容进入训练语料，影响的是模型未来版本「认不认识你、用什么口径描述你」，这笔投资没有月度报表可看，收益出现在下一代模型发布的时候。搜索通道则是即期的：放行与收录当周就能在抓取日志里看到变化。把两笔账写进同一份周报去要效果，团队必然动作变形——正确的做法是给训练通道单独立项，按品牌资产的节奏考核，与搜索可见度的 KPI 分开。

放行之后还要防回退。站点改版、迁移或批量重写 robots 时，逐组的放行规则最容易在重写中丢失，这类事故一出就是整条通道静默消失，而且没人说得清是从哪天开始的。把当前配置纳入备份与变更评审，等于给 ChatGPT 通道上了保险；配置表旁边留两列「决策依据、复核时间」，成本几乎为零，半年后复盘时它是最值钱的字段。

87% 重合度怎么读、怎么用

据 Seer Interactive 的对比实测（本站未复验），ChatGPT 的引用与 Bing 首页结果约有 87% 重合，Copilot 同源——口径与留档见ChatGPT 引用与 Bing 首页约 87% 重合。这条数据把「从哪入手」变得非常具体：Bing 站长工具验证、IndexNow 即时推送、不屏蔽 OAI-SearchBot，三件事成本都不高，缺一件链路就断在那一环，而且断链是静默的。IndexNow 的机制边界见IndexNow：它推的是 Bing 系引擎，解决的是收录时效而非收录质量，采不采信仍由内容与权限决定。

87% 也要放对预期。它说的是「引用池像谁」，不保证你在池里的位次——资格靠收录与放行，位次靠内容的相关度与可摘录性，两码事不能互相折算。还有一个容易被漏掉的对称推论：Bing 收录的波动会直接传导为 ChatGPT 引用的波动。站点改版导致 Bing 收录掉量、robots 误伤导致抓取停止，症状往往先出现在「AI 引用变少」而不是「Bing 流量变少」，因为引用池的采样比流量报表更敏感。看到引用异常，第一反应应是查上游索引健康度，而不是先改内容。

中文场景还要补一条边界：国内主流引擎不吃这套入场券，「做好 Bing 收录」服务的是 ChatGPT 与 Copilot，其他引擎按各自的供给结构另找钥匙。引擎之间的引用格局分裂程度，可以参照站内三引擎对比卡的口径去理解——不存在一个全局的「AI 排名」，入口策略必须分引擎写。

入场券与位次的时间尺度也不同，给管理层汇报时建议拆开说。入场券是工程动作，配置正确当天生效，第一份周报看链路通了没有；位次是内容资产，按月按季度积累，第二份季报才看引用位次动了没有。把两种节奏压进同一个考核周期，是 ChatGPT 入口工作里最常见的预期错位——链路刚通就追问位次，或者位次不动就推翻入口配置，都是节奏错配制造的假问题。

窄窗口里的内容竞争

引用窗口是这台引擎最该被严肃对待的参数：平均约 7.9 个来源，头部域名又占掉其中相当大的份额，口径见引用窗口：ChatGPT 平均引 7.9 源。窗口窄意味着近似零和——多一个来源进列表，就有一个被挤出去，所以位次竞争要按「可摘录性」来打。内容被切块、被检索、被塞进上下文、再被转述引用的完整流水线见RAG（检索增强生成），每一格都是漏斗，任何一格掉队内容就彻底不出现在用户面前。

写法上有实证口径可依：约 44.2% 的引用来自页面前 30% 的内容（服务商单源口径），配套发现是被引文本含问句的概率约高一倍，见44.2% 的引用来自页面前 30%。翻译成动作就是即答段前置——页面开头直接给出自含的答案块，小标题用问句对齐真实提问，参数与结论尽量放在页面中部之前。位置效应的机制背景是模型对长上下文的首尾利用更好、中部易被忽略，这也是「把关键事实埋在中部」在这类引擎上格外吃亏的原因。

另一条常被忽视的证据指向同一个方向：ChatGPT 最常引用的页面中 28.3% 在 Google 自然结果前 100 之外（Semrush 口径，未复验）——它的「排名货币」本来就不是 Google 排名，在 Google 侧零可见而在 ChatGPT 高频被引，两个事实放在一起毫无矛盾。不要用 Google 排名报表去解释 ChatGPT 的引用表现，那是拿错刻度。

内容改造的优先级也照这个逻辑排。先改那些「已经在池里但排不进窗口」的页面：把埋在中部的答案提到小节开头、给参数表配上自含的结论句、给每个小节加问句式小标题——这些动作直接作用于可摘录性，反馈周期短。再补「对位高频提问但完全没有对位内容」的空白——没有对位内容的页面连参赛资格都没有。最不需要着急的是排名稳固的头部页面，它们更多需要的是守住口径一致性，而不是推倒重写。

没有站长平台，监测怎么做

OpenAI 不提供站长平台，没有「ChatGPT 收录量」「引用位次」这类官方报表，监测只能走两条替代路线：第三方工具，或用 API 自建采样。两条路线各有口径坑——API 的回答与网页端用户看到的答案不同构，检索范围、界面呈现、会话上下文都是变量，两套数字不能互换；第三方工具各有各的分母与加权，跨工具并表必然失真。我们的纪律是固定一套采集面，只比自家趋势，不做跨工具的绝对值比较。

落到日常，一套务实的组合是：固定问句集（品类、对比、评价各一组），分时段多次提问，把「回答正文是否提及」与「参考列表是否引用」分开记账，指标定义见引用率（Citation Rate）；日志侧定期核对 OAI-SearchBot 的真身到访，把「没来抓」与「抓了没引」分开归因。引用异常时按「robots 配置—抓取日志—Bing 收录—内容相关度」四层顺序排查，绝大多数「ChatGPT 看不见我」的案例断在前三层；四层都通而引用仍少，才轮到研究同题下被引页面长什么样的问题。