在 OpenAI 的爬虫矩阵中,ChatGPT-User 是一个特殊且常被误解的存在。与 GPTBot 和 OAI-SearchBot 不同,ChatGPT-User 不是一个按计划自动抓取的程序,而是在用户发起特定操作时才会触发的取回器。这一根本区别,决定了它在 robots.txt 框架下的特殊地位,也决定了屏蔽它的实际后果。
ChatGPT-User 是 OpenAI 在实时 ChatGPT 对话中需要访问某个页面时发送的用户代理。当用户提问、粘贴链接或使用某个 Custom GPT,而回答又需要模型尚未取得的网页内容时,OpenAI 就会发送这一用户代理。
关键洞察:ChatGPT-User 不代表 OpenAI 为用户取页的全部流量。智能体模式和 Atlas 浏览器使用 Chromium,发送普通的 Chrome 用户代理,并通过 HTTP 消息签名而非令牌表明身份。仅针对 ChatGPT-User 字符串编写的规则,只能管理 OpenAI 代表用户发出的部分取页流量。
ChatGPT-User 的核心特征
理解 ChatGPT-User 的关键在于把握以下几个核心特征:
- 非自动抓取:OpenAI 在爬虫文档中明确说明,ChatGPT-User「不会以自动方式抓取网页」(见 Overview of OpenAI Crawlers)。它仅在用户提出请求后代表该用户取页,不会自行按照预定计划抓取。
- 不遵守 robots.txt:由于「动作由用户发起」,OpenAI 明确指出 robots.txt 规则对它未必适用。OpenAI 列出的可由 robots.txt 管控的令牌也不包括它。
- 独立 IP 基础设施:ChatGPT-User 使用与 GPTBot 和 OAI-SearchBot 完全不同的 IP 段,这反映了其对低延迟和高并发的需求。
- 不执行 JavaScript:与大多数实时抓取程序一样,ChatGPT-User 不执行 JavaScript,依赖客户端脚本的页面会对它返回空壳。
触发取页的三种场景
OpenAI 列出了三个会触发 ChatGPT-User 的场景:
| 场景 | 用户操作 | 是否有文档说明 |
|---|---|---|
| ChatGPT 对话 | 问了一个需要取页才能回答的问题,或直接粘贴了网址 | 是 |
| Custom GPTs | 向某个 Custom GPT 提问,而回答需要实时取页 | 是 |
| GPT Actions | 通过 Action 与外部应用发生交互 | 是 |
OpenAI 的文档没有说明 ChatGPT 定时任务会发送哪一种用户代理。robots.txt 可能不适用的理由是「动作由用户发起」,但定时任务在凌晨六点运行时,用户未必正在主动操作,这与上述理由并不完全相符;公开资料也没有说明这类任务实际携带什么令牌。
触发方式决定的流量特征
触发方式决定了 ChatGPT-User 流量的独特特征:
- 请求量与关注度正相关:请求会随着对话出现,不会成批抓取整个网站。某个话题受到较多关注时,请求会集中增加,无人询问时则不会出现。
- 请求量与站点大小无关:流量取决于外界对相关话题的关注度,与站点地图的大小或页面数量无关。
- 统计工具难以捕获:由于 ChatGPT-User 不执行 JavaScript,依赖客户端脚本的统计工具(如 GA4)不会记录这些访问。请求只能从服务器日志中识别。
关键洞察:日志中每出现一次 ChatGPT-User 请求,就说明有一位真实用户当时提出的问题需要访问该页面。如果请求失败,这位用户便无法取得相应内容,系统也不会通过重试队列再次取回内容。因此,确保取页成功不仅关乎技术实现,也直接影响用户体验。
ChatGPT-User 与其他 OpenAI 程序的关系
在 OpenAI 的这组程序中,ChatGPT-User 负责用户触发的取页;另外两个分别是用于训练的 GPTBot 和用于搜索索引的 OAI-SearchBot。三者用途不同,屏蔽任何一个都会产生不同后果。
| 令牌 | 用途 | 屏蔽后果 |
|---|---|---|
| GPTBot | 训练:采集内容用于未来模型训练 | 内容不进入训练数据;不影响搜索引用 |
| OAI-SearchBot | 检索:建立搜索索引,支持实时答案 | 内容不再出现在 ChatGPT 搜索中;影响立即可见 |
| ChatGPT-User | 用户触发:代表用户实时取页 | 当前提问用户无法取得答案;不影响自动引用 |
理解这三者的区别,是制定正确访问策略的基础。最常见的错误是将三者混为一谈,导致屏蔽后果远超预期。
ChatGPT-User 令牌的适用范围
ChatGPT-User 并不代表 OpenAI 为用户取页的全部流量。仅针对它编写访问规则,所能管理的流量会比预想少得多。
| 场景 | 发送的令牌 | 如何辨认 |
|---|---|---|
| ChatGPT、Custom GPTs、GPT Actions | ChatGPT-User | 用户代理加公布的 IP 段 |
| ChatGPT 智能体模式 | 无,普通 Chrome UA | HTTP 消息签名(RFC 9421) |
| Atlas 浏览器 | 无,普通 Chrome UA | HTTP 消息签名 |
| 广告落地页校验 | OAI-AdsBot | 用户代理 |
带签名的智能体请求很可能代表身份验证方式的发展方向。IETF 为自动化流量制定的 HTTP 消息签名规范已得到多家大型基础设施厂商支持,Cloudflare 也记录了会出示签名的程序。但 ChatGPT-User 目前没有签名,仍然只能通过 IP 核验,见下文。
OAI-AdsBot 是 OpenAI 文档列出的第四个令牌。它只访问被提交为广告的页面;OpenAI 说明,它收集的内容不用于训练基础模型。
robots.txt 与用户发起的例外
OpenAI 对 robots.txt 是否适用的表述是:
由于这些动作由用户发起,robots.txt 规则未必适用。
这里说的是未必适用,而非不适用。OpenAI 并未进一步说明 robots.txt 会在哪些情况下适用。
文档还写道:「OpenAI 使用 OAI-SearchBot 和 GPTBot 的 robots.txt 标签,让站长管理自己的站点和内容如何与 AI 交互。」OpenAI 列出的 robots.txt 控制令牌中没有 ChatGPT-User。OpenAI 也没有记录它的 robots.txt 用户代理标记,即爬虫抓取 robots 文件时附加的后缀;这项记录只适用于另外两个程序。如果程序不读取 robots.txt,也无需在这类请求中添加标记。
这种做法并非 OpenAI 独有。Google 对自家用户触发取回器的说明也很相似,而且措辞更加明确:
由于该次取页由用户请求发起,这些取回器一般会忽略 robots.txt 规则。
Cloudflare 的程序目录也给出了相同结论:ChatGPT-User 被标记为不遵守 robots.txt,GPTBot 和 OAI-SearchBot 则被标记为遵守。OpenAI 的政策、Google 对同类程序的说明,以及 CDN 对该类别的划分,三项相互独立的证据都支持同一结论。
有些第三方程序目录和 SEO 文章仍称 ChatGPT-User 会遵守 robots.txt。这与 OpenAI 自己的文档相抵触;凡是依据这一说法提供建议的工具,都应重新复核。
关键洞察:目前没有任何标准可以裁定这件事。RFC 9309 完全没有涉及取页的动机,协议也没有提供区分计划抓取与用户触发取页的词汇。由于规范没有规定这种情况,各运营方分别制定了自己的政策,因此现阶段应以厂商文档为准。
在日志里辨认 ChatGPT-User
OpenAI 公布的完整用户代理字符串:
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot
规则只匹配 ChatGPT-User,**不要匹配版本号**。OpenAI 将这条字符串标注为「完整用户代理字符串」,将 GPTBot 和 OAI-SearchBot 的字符串标注为「示例用户代理字符串(版本号可能变化)」。
ChatGPT-User 有独立的 IP 段文件,因此可以直接核实它与其他程序使用的网段是否重叠。下表数据于 2026 年 7 月 18 日从 OpenAI 公布的端点直接取得:
| 令牌 | 公布的 IP 文件 | 网段数 | 重叠情况 |
|---|---|---|---|
| ChatGPT-User | chatgpt-user.json | 286 | 与 GPTBot、OAI-SearchBot 的网段均无重叠 |
| OAI-SearchBot | searchbot.json | 35 | 与 GPTBot 共用 6 段 |
| GPTBot | gptbot.json | 21 | 与 OAI-SearchBot 共用 6 段 |
| ChatGPT 智能体 | 无(404) | 无 | 无 |
ChatGPT-User 的网段数量比另外两个程序多一个数量级,而且与它们没有任何网段重叠。这与它的工作方式相符:用户会等待取页结果,因此这类请求对延迟敏感,需要使用比后台抓取更多的出站 IP。
ChatGPT-User 不出示任何请求签名,因此只能通过 IP 核验。可用的方法有两种:AI 爬虫所述的前向确认反向解析,以及与 OpenAI 公布的 IP 段进行比对。AI 爬虫访问审计提供了具体的 grep 命令,并说明如何确认请求的真实来源。
它的访问量有多大
以下每项数据都只适用于相应厂商的样本,不同样本之间不能直接比较。CDN 统计的是自身网络中的流量,出版商统计的是各自站点的流量;两类样本即使对同一程序得出相差一个数量级的结果,也可能分别成立。
在 Cloudflare 网络中,2024 年 7 月至 2025 年 7 月,ChatGPT-User 占 AI 与搜索程序合计流量的比例从 0.1% 升到 0.9%,占纯 AI 程序流量的比例从 0.2% 升到 2.4%。同期在 Cloudflare 网络中,按用途拆分的结果是:训练类从 72% 升到 79%,搜索类从 26% 降到 17%,而用户动作类只从 2% 升到 3.2%。
用户动作类的数据与一个广为流传的说法相反。出版商样本涵盖经常被用户用于向 ChatGPT 提问的新闻与参考类站点;在这类样本中,检索型取页在 2025 年快速增长,训练类抓取则有所下降,ChatGPT-User 占 AI 流量的比例大致翻了一倍。两组数据在各自样本范围内都成立,但不能用于推断另一类样本;将出版商样本数据当作全网数据并不准确。
引用与这个程序有关的数据时,需要注意两点:
- 变化方向在 2026 年发生反转:多家追踪机构测得,ChatGPT-User 的访问量在 2026 年年中逐月下降,同期竞争对手程序的访问量则有所增加。引用 2025 年的增长数据时,必须注明相应时间范围;当前数据并不支持「ChatGPT-User 正在增长」这一说法。
- 抓取引流比按平台公布,而非按令牌公布:被反复引用的数据描述的是某家运营方的全部抓取活动,多数仍是 2025 年初的统计结果,而且受到一个无法量化的因素影响:原生应用带来的引荐不会发送
Referer头。
屏蔽它的代价
屏蔽 ChatGPT-User 能否让网站退出 ChatGPT 搜索,OpenAI 已明确说明:
ChatGPT-User 不参与决定内容能否出现在搜索中。管理搜索的退出与自动抓取,请在 robots.txt 里使用 OAI-SearchBot。
屏蔽 ChatGPT-User 不会使网站退出 ChatGPT 搜索,搜索收录由 OAI-SearchBot 负责;屏蔽它也不影响训练,训练用途由 GPTBot 负责。屏蔽后,正在询问该页面的用户将无法即时取得页面内容。
因此,屏蔽的实际代价与预期效果并不相称:用户无法取得答案,但自动收集内容的行为几乎不受影响,因为这个取回器原本就不会自行收集内容。
| 做法背后的想法 | 实际结果 |
|---|---|
| 屏蔽 ChatGPT-User,以使网站退出 ChatGPT | 屏蔽它对搜索收录毫无影响;OAI-SearchBot 才负责搜索收录 |
| 屏蔽 GPTBot,以阻止实时取页 | GPTBot 只用于训练,屏蔽它不会阻止实时取页请求 |
| 在 robots.txt 中写入 Disallow,并认为规则已经生效 | OpenAI 明确说明,robots.txt 对 ChatGPT-User 未必适用 |
| 启用一键「屏蔽 AI 爬虫」开关 | 多数预设会同时拦截用户触发取回器,将一次 ChatGPT-User 请求记作一次访问 |
关键洞察:Cloudflare 旧版「屏蔽 AI 爬虫」设置仅适用于训练用途,它「屏蔽的是被归类为以 AI 训练为目的进行抓取的已核验程序」,因此不会拦截 ChatGPT-User。这并非专门为 ChatGPT-User 设置的例外。这一点将在 2026 年 9 月 15 日改变:Cloudflare 文档写明,届时新接入的域名将在展示广告的页面上默认屏蔽智能体类别的程序,但仍允许搜索类别访问;ChatGPT-User 属于智能体类别。
确保取页成功
允许 ChatGPT-User 访问并不足以保证取得有效结果,还要确保它能取回适合引用的内容。
- 它不执行 JavaScript。Vercel 与 MERJ 在 2024 年对大量 AI 爬虫请求进行实测后发现,OpenAI 的取回器会请求 JavaScript 文件,却从不执行其中的脚本,因此纯客户端渲染的页面只会返回不含正文内容的 HTML。这一结论发布后,OpenAI 尚未公布任何变化,但仍不能将其视为永久不变的保证。
- 取页失败率较高。同一项研究还发现,OpenAI 的取页请求中有相当大的比例遇到 404 和重定向。许多 AI 取页失败源于普通的链接失效和重定向链,并不涉及特殊机制。修复过期的站内链接,是降低此类失败率且成本很低的一项改进。
- 关于超时时长,目前没有可信的公开数据,流传的具体秒数也都没有可靠出处。因此,应按照常规性能要求缩短响应时间,而不要针对未经证实的超时阈值进行优化。
站点内部的统计工具还无法发现另一类失败。限速和质询规则很可能将面向单个用户的取页判定为异常:它是来自陌生网段的单次请求,也没有连续抓取活动可以帮助系统确认其性质。为防范自动采集程序而配置的防护措施经常会拦截这类请求;如上文所述,拦截记录又不会进入依赖客户端脚本的统计工具。AI 爬虫访问审计提供了相应的诊断方法。
以下详细说明如何诊断和解决 ChatGPT-User 取页失败的问题:
常见取页失败原因及解决方案
根据 Vercel 与 MERJ 的实测研究,OpenAI 的取页请求失败主要有以下几类原因:
- 链接失效(404):这是最常见的原因。页面可能已被删除、重命名或迁移,但仍在 AI 回答中被引用。解决方案:建立定期的链接审计机制,及时修复或重定向失效链接。
- 重定向链过长:多个 301/302 重定向可能导致请求超时。解决方案:简化重定向链,确保主要页面直接返回 200 状态码。
- 服务器响应慢:虽然 ChatGPT-User 不执行 JavaScript,但如果服务器响应时间过长,仍可能导致取页失败。解决方案:优化服务器性能,确保 TTFB 在合理范围内。
- 安全防护误拦截:WAF 或速率限制规则可能将 ChatGPT-User 的请求判定为异常流量。解决方案:将 OpenAI 公布的 IP 段加入白名单。
- 页面结构复杂:虽然 ChatGPT-User 不执行 JavaScript,但过于复杂的 HTML 结构可能影响内容提取。解决方案:保持页面结构简洁,确保正文内容在首屏 HTML 中可见。
取页成功率监控建议
由于 ChatGPT-User 不执行 JavaScript,传统网站统计工具无法记录其访问。建议采取以下监控措施:
- 定期检查服务器日志,识别 ChatGPT-User 的请求模式
- 监控 404 和重定向错误的比例,及时发现链接失效问题
- 关注取页请求的响应时间分布,识别性能瓶颈
- 建立 IP 段白名单,防止防护措施误拦截合法请求
相关条目
- AI 爬虫:介绍三种程序类别,以及如何按类别决定允许或屏蔽访问
- GPTBot:OpenAI 的训练爬虫;若要退出训练,应屏蔽这一程序
- OAI-SearchBot:OpenAI 的搜索索引程序,负责管理搜索收录
- robots.txt:介绍协议机制和指令写法
- llms.txt:介绍该文件,并说明文档尚未确认其控制能力
- OpenAI:介绍这四个令牌的运营方
- 可引用性:说明成功取页后,页面内容是否适合被引用
- AI 爬虫访问审计:核验抵达服务器的请求来自何方
- ChatGPT 搜索:介绍 ChatGPT 如何检索和引用页面内容
常见问题解答
ChatGPT-User 是什么?
ChatGPT-User 是 OpenAI 在实时 ChatGPT 对话中需要访问某个网页时使用的用户代理。用户提问、粘贴网址,或者使用 Custom GPT 与 GPT Actions,都可能触发它。OpenAI 写明它「不会以自动方式抓取网页」,因此它不同于负责训练的 GPTBot 和负责搜索索引的 OAI-SearchBot。
ChatGPT-User 遵守 robots.txt 吗?
OpenAI 的文档写的是「这些动作由用户发起,robots.txt 规则未必适用」;「未必」并不等于「不」。同时,OpenAI 列出的、站长可以用 robots.txt 管控访问的令牌只有 OAI-SearchBot 和 GPTBot,其中没有 ChatGPT-User。这种做法并非 OpenAI 独有:Google 也说明,自家的用户触发取回器「一般会忽略 robots.txt 规则」。
屏蔽 ChatGPT-User 后,网站会从 ChatGPT 中消失吗?
不会。OpenAI 写明 ChatGPT-User「不参与决定内容能否出现在搜索中。管理搜索的退出与自动抓取,请在 robots.txt 里使用 OAI-SearchBot」。屏蔽它既不会使网站退出 ChatGPT 搜索,也不影响训练;GPTBot 才用于训练。真正受到影响的是用户:正在询问该页面的人将无法取得与之相关的实时结果。
为什么统计后台看不到 ChatGPT-User 的访问?
因为它不执行 JavaScript。Vercel 与 MERJ 在 2024 年的大规模实测中发现,OpenAI 的爬虫会请求 JavaScript 文件,却从不执行文件中的脚本,因此 GA4 这类依赖客户端脚本的统计工具无法记录这些访问。相关请求只会出现在服务器日志中。一个站点每天可能收到数百次 ChatGPT-User 取页请求,但依赖 JavaScript 的统计面板仍可能完全没有记录。
OpenAI 代表用户取页时,只使用 ChatGPT-User 吗?
不是。ChatGPT 的智能体(agent)模式和 Atlas 浏览器使用 Chromium,发送普通的 Chrome 用户代理,并通过 HTTP 消息签名而非令牌表明身份。仅针对 ChatGPT-User 字符串编写的规则,只能管理 OpenAI 代表用户发出的部分取页流量。
延伸阅读
ChatGPT-User 的实际影响分析
理解 ChatGPT-User 的实际影响,需要从一个具体场景出发。假设你的网站有一篇关于「如何配置 Kubernetes 集群」的技术文章:
- 场景一:用户 A 在 ChatGPT 中提问「Kubernetes 集群配置指南」,ChatGPT 引用了你的文章。这种情况下,ChatGPT-User 会访问你的页面,取回内容供答案生成使用。
- 场景二:用户 B 使用 Custom GPT「技术文档助手」查询相关内容,Custom GPT 需要访问你的页面获取最新信息。这种情况下,ChatGPT-User 也会触发取页请求。
- 场景三:用户 C 通过 GPT Actions 与你的 API 交互,需要访问你的落地页。这种情况下,ChatGPT-User 同样会触发请求。
在这三种场景中,如果屏蔽了 ChatGPT-User,用户将无法在相应的情境中获取你的内容。但需要注意的是,这不会阻止 GPTBot 抓取你的内容进行训练,也不会阻止 OAI-SearchBot 建立搜索索引。
ChatGPT-User 与搜索引擎优化的协同
虽然 ChatGPT-User 与传统的 SEO 工作关联不大,但两者的协同仍然有价值:
- 内容质量一致:确保 ChatGPT-User 能够读取的内容,也是 Google 搜索能够索引的内容
- 链接健康度:修复 ChatGPT-User 取页失败的问题,也有助于改善用户访问体验
- 结构化数据:正确的 JSON-LD 标记虽然不被 ChatGPT-User 解析,但有助于其他 AI 引擎理解内容
- 页面性能:优化 LCP、INP 等指标,虽然不影响 ChatGPT-User 的取页(因为它不执行 JS),但有助于改善整体用户体验
通过协同优化,可以确保网站在不同场景下都能获得最佳表现。
ChatGPT-User 的技术实现细节
深入了解 ChatGPT-User 的技术实现,有助于更好地管理其访问行为。
请求特征分析
ChatGPT-User 的请求具有以下特征:
- 请求频率:请求频率与用户关注度直接相关,热门话题时段请求量会显著增加
- 请求模式:请求通常是单次的,不会像训练爬虫那样批量抓取整个网站
- 用户代理:固定的用户代理字符串,不包含版本号以外的变化
- IP 来源:来自 OpenAI 公布的 IP 段,与 GPTBot 和 OAI-SearchBot 无重叠
- 请求时间:请求时间分布与用户活跃时间相关,而非固定的抓取时间表
与 GPTBot 和 OAI-SearchBot 的技术对比
| 特征 | GPTBot | OAI-SearchBot | ChatGPT-User |
|---|---|---|---|
| 用途 | 训练 | 检索索引 | 用户触发取页 |
| 抓取模式 | 批量自动抓取 | 批量自动抓取 | 按需单次取页 |
| 执行 JavaScript | 不执行 | 不执行 | 不执行 |
| 遵守 robots.txt | 是 | 是 | 未必适用 |
| IP 段重叠 | 与 OAI-SearchBot 共用 6 段 | 与 GPTBot 共用 6 段 | 无重叠 |
| 日志标识 | GPTBot | OAI-SearchBot | ChatGPT-User |
| 影响时效 | 滞后(数月) | 即时 | 即时(单次请求) |
取页失败的技术诊断
当 ChatGPT-User 取页失败时,可以通过以下方法进行诊断:
- 检查响应状态码:确认服务器返回的状态码,200 表示成功,404 表示页面不存在,403 表示被禁止
- 检查响应时间:如果响应时间过长,可能触发超时
- 检查页面结构:确认页面是 SSR 还是 CSR,纯 CSR 页面可能返回空壳
- 检查安全防护:确认 WAF 或速率限制规则没有误拦截
- 检查链接有效性:确认请求的 URL 有效,没有重定向链
通过系统化的技术诊断,可以快速定位和解决取页失败问题,提升用户获得答案的可能性。