ChatGPT-User
速览要点
- 它是什么
- OpenAI 的用户触发取回器:只有当用户在实时对话中问到某个页面时,它才会取回该页面,不会按计划自动抓取
- 用户代理字符串
- Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot。编写规则时只匹配
ChatGPT-User,不要把版本号固定在规则中 - robots.txt
- OpenAI 写明「这些动作由用户发起,robots.txt 规则未必适用」。OpenAI 列出的可由 robots.txt 管控的令牌也不包括它
- 对 ChatGPT 搜索的影响
- 没有影响。OpenAI 写明它「不参与决定内容能否出现在搜索中」;ChatGPT 的搜索收录由 OAI-SearchBot 负责
- 影响最大的错误配置
- 启用一键「屏蔽 AI 爬虫」开关。多数预设会同时拦截这个用户触发取回器和训练爬虫,使真实读者无法取得答案,却不能阻止训练抓取,因为它原本就不用于训练
1. ChatGPT-User 是什么
ChatGPT-User 是 OpenAI 在实时 ChatGPT 对话中需要访问某个页面时发送的用户代理。当用户提问、粘贴链接或使用某个 Custom GPT,而回答又需要模型尚未取得的网页内容时,OpenAI 就会发送这一用户代理。
OpenAI 在爬虫文档中明确说明,ChatGPT-User「不会以自动方式抓取网页」(见 Overview of OpenAI Crawlers)。它仅在用户提出请求后代表该用户取页,不会自行按照预定计划抓取。因此,它可能不受 robots.txt 约束,使用独立的 IP 基础设施;安全厂商也将它与另外两种程序分开归类。
在 OpenAI 的这组程序中,ChatGPT-User 负责用户触发的取页;另外两个分别是用于训练的 GPTBot 和用于搜索索引的 OAI-SearchBot。三者用途不同,屏蔽任何一个都会产生不同后果,具体差异见 AI 爬虫。
日志中每出现一次 ChatGPT-User 请求,就说明有一位真实用户当时提出的问题需要访问该页面。如果请求失败,这位用户便无法取得相应内容,系统也不会通过重试队列再次取回内容。
2. 什么会触发一次取页
OpenAI 列出了三个场景:
| 场景 | 用户操作 | 是否有文档说明 |
|---|---|---|
| ChatGPT 对话 | 问了一个需要取页才能回答的问题,或直接粘贴了网址 | 是 |
| Custom GPTs | 向某个 Custom GPT 提问,而回答需要实时取页 | 是 |
| GPT Actions | 通过 Action 与外部应用发生交互 | 是 |
OpenAI 的文档没有说明 ChatGPT 定时任务会发送哪一种用户代理。robots.txt 可能不适用的理由是「动作由用户发起」,但定时任务在凌晨六点运行时,用户未必正在主动操作,这与上述理由并不完全相符;公开资料也没有说明这类任务实际携带什么令牌。
触发方式决定了这类流量的特征:请求会随着对话出现,不会成批抓取整个网站;某个话题受到较多关注时,请求会集中增加,无人询问时则不会出现。请求量取决于外界对相关话题的关注度,与站点地图的大小无关。
因此,多数团队使用的常规报表无法记录这类请求:取回器不运行 JavaScript(见 §8),依赖客户端脚本的统计工具不会记录访问。ChatGPT-User 请求只能在服务器日志中查到。
3. ChatGPT-User 令牌的适用范围
ChatGPT-User 并不代表 OpenAI 为用户取页的全部流量。仅针对它编写访问规则,所能管理的流量会比预想少得多。
| 场景 | 发送的令牌 | 如何辨认 |
|---|---|---|
| ChatGPT、Custom GPTs、GPT Actions | ChatGPT-User | 用户代理加公布的 IP 段 |
| ChatGPT 智能体模式 | 无,普通 Chrome UA | HTTP 消息签名(RFC 9421) |
| Atlas 浏览器 | 无,普通 Chrome UA | 无法仅凭 HTML 请求辨认 |
| 广告落地页校验 | OAI-AdsBot | 用户代理 |
这两类由浏览器驱动的请求无法通过用户代理规则管理。它们使用 Chromium 实例,与用户浏览器一样渲染页面;即使表明身份,使用的也是密码学签名,而非产品令牌。OpenAI 没有为智能体流量公布 IP 段文件:chatgpt-agent.json 返回 404,而 chatgpt-user.json 返回一份完整列表。
带签名的智能体请求很可能代表身份验证方式的发展方向。IETF 为自动化流量制定的 HTTP 消息签名规范已得到多家大型基础设施厂商支持,Cloudflare 也记录了会出示签名的程序。但 ChatGPT-User 目前没有签名,仍然只能通过 IP 核验,见 §5。
OAI-AdsBot 是 OpenAI 文档列出的第四个令牌。它只访问被提交为广告的页面;OpenAI 说明,它收集的内容不用于训练基础模型。
4. 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 在 2025 年 12 月 9 日修改了这段表述。此前的版本用一句概述涵盖所列的全部程序;修订后,robots.txt 管控明确限于 OAI-SearchBot 和 GPTBot,并新增了「未必适用」这句话(见 Search Engine Roundtable)。这次修改缩小了概述所涵盖的范围,并非撤回原有承诺:较早的文本从未单独确认 ChatGPT-User 可以由 robots.txt 管控。
这种做法并非 OpenAI 独有。Google 对自家用户触发取回器的说明也很相似,而且措辞更加明确:
由于该次取页由用户请求发起,这些取回器一般会忽略 robots.txt 规则。
Cloudflare 的程序目录也给出了相同结论:ChatGPT-User 被标记为不遵守 robots.txt,GPTBot 和 OAI-SearchBot 则被标记为遵守。Cloudflare 对整个 AI 助手类别都采用了这一判断,涉及多家运营方的数十个用户触发取回器。OpenAI 的政策、Google 对同类程序的说明,以及 CDN 对该类别的划分,三项相互独立的证据都支持同一结论。
有些第三方程序目录和 SEO 文章仍称 ChatGPT-User 会遵守 robots.txt。这与 OpenAI 自己的文档相抵触;凡是依据这一说法提供建议的工具,都应重新复核。
目前没有任何标准可以裁定这件事。RFC 9309 完全没有涉及取页的动机,协议也没有提供区分计划抓取与用户触发取页的词汇。IETF 关于表达使用偏好的工作至今仍是草案,尚未成为正式 RFC;更早一份为协议增加用途令牌的提案也已过期,未获采纳。由于规范没有规定这种情况,各运营方分别制定了自己的政策,因此现阶段应以厂商文档为准。robots.txt详细说明了协议机制和具体指令的写法。
5. 在日志里辨认 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 的字符串标注为「示例用户代理字符串(版本号可能变化)」。第三方程序目录对于是否存在更高版本说法不一;如果规则固定匹配 1.0,版本一旦变化,规则就会失效。因此,主流爬虫管理厂商都只匹配令牌本身。
ChatGPT-User 有独立的 IP 段文件,因此可以直接核实它与其他程序使用的网段是否重叠。下表数据于 2026 年 7 月 18 日从 OpenAI 公布的端点直接取得:
| 令牌 | 公布的 IP 文件 | 网段数 | 与 GPTBot、OAI-SearchBot 的网段重叠情况 |
|---|---|---|---|
| ChatGPT-User | chatgpt-user.json | 286 | 与两者的网段均无重叠 |
| OAI-SearchBot | searchbot.json | 35 | 与 GPTBot 共用 6 段 |
| GPTBot | gptbot.json | 21 | 与 OAI-SearchBot 共用 6 段 |
| ChatGPT 智能体 | 无(404) | 无 | 无 |
ChatGPT-User 的网段数量比另外两个程序多一个数量级,而且与它们没有任何网段重叠。这与它的工作方式相符:用户会等待取页结果,因此这类请求对延迟敏感,需要使用比后台抓取更多的出站 IP。相比之下,GPTBot 与 OAI-SearchBot 共用 6 个网段,这与 OpenAI 说明的做法一致:站点同时允许两者访问时,一次抓取可以用于两种用途。
ChatGPT-User 不出示任何请求签名,因此只能通过 IP 核验。可用的方法有两种:AI 爬虫所述的前向确认反向解析,以及与 OpenAI 公布的 IP 段进行比对。AI 爬虫访问审计提供了具体的 grep 命令,并说明如何确认请求的真实来源,而不是仅凭用户代理所声称的身份判断。
Cloudflare 将 ChatGPT-User 列为已核验程序,但实际配置时还有一项限制:只有较高档位的套餐才能按厂商的检测 ID 编写规则,其余套餐只能匹配用户代理字符串。因此,只匹配令牌本身并非单纯的写法偏好,而是多数站点唯一可行的方式。
6. 它的访问量有多大
以下每项数据都只适用于相应厂商的样本,不同样本之间不能直接比较。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头,Cloudflare 在说明自身数据时也提到了这一点。目前没有只针对 ChatGPT-User 的可信抓取引流比,以此名义出现的数据均由其他数据推算而来。
7. 屏蔽它的代价
屏蔽 ChatGPT-User 能否让网站退出 ChatGPT 搜索,OpenAI 已明确说明:
ChatGPT-User 不参与决定内容能否出现在搜索中。管理搜索的退出与自动抓取,请在 robots.txt 里使用 OAI-SearchBot。
屏蔽 ChatGPT-User 不会使网站退出 ChatGPT 搜索,搜索收录由 OAI-SearchBot负责;屏蔽它也不影响训练,训练用途由 GPTBot负责。屏蔽后,正在询问该页面的用户将无法即时取得页面内容。
因此,屏蔽的实际代价与预期效果并不相称:用户无法取得答案,但自动收集内容的行为几乎不受影响,因为这个取回器原本就不会自行收集内容。
| 做法 | 背后的想法 | 实际结果 |
|---|---|---|
| 屏蔽 ChatGPT-User,以使网站退出 ChatGPT | 「只要屏蔽 OpenAI 的程序,网站就会退出 ChatGPT」 | 屏蔽它对搜索收录毫无影响;OAI-SearchBot 才负责搜索收录 |
| 屏蔽 GPTBot,以阻止实时取页 | 「GPTBot 是负责取页的爬虫」 | GPTBot 只用于训练,屏蔽它不会阻止实时取页请求 |
| 在 robots.txt 中写入 Disallow,并认为规则已经生效 | 「robots.txt 可以阻止所有 AI 访问」 | OpenAI 明确说明,robots.txt 对 ChatGPT-User 未必适用 |
| 启用一键「屏蔽 AI 爬虫」开关 | 「这个开关只会拦截训练爬虫」 | 多数预设会同时拦截用户触发取回器 |
| 将一次 ChatGPT-User 请求记作一次访问 | 「服务器收到请求,统计工具就会记录访问」 | ChatGPT-User 不执行 JavaScript,依赖客户端脚本的统计工具不会记录这次请求 |
即使团队审慎配置,一键开关仍可能造成误拦截。Netlify 的文档明确建议不要屏蔽这一类别:
这一类别的流量通常量不大,且直接由真人用户的请求发起。一般不建议屏蔽或限速这些请求,因为它们说明你的内容正被 AI 系统判定为相关而呈现出来。
然而,行业中的同类一键开关往往会同时拦截这个令牌和批量爬虫。产品标签所描述的类别经常与实际拦截范围不一致,因此判断一项预设时,应核查它实际匹配的程序,而不能只看标签说明。
Cloudflare 旧版「屏蔽 AI 爬虫」设置仅适用于训练用途,它「屏蔽的是被归类为以 AI 训练为目的进行抓取的已核验程序」,因此不会拦截 ChatGPT-User。这并非专门为 ChatGPT-User 设置的例外。这一点将在 2026 年 9 月 15 日改变:Cloudflare 文档写明,届时新接入的域名将在展示广告的页面上默认屏蔽智能体类别的程序,但仍允许搜索类别访问;ChatGPT-User 属于智能体类别。如果站点目前依赖这项默认放行,应在该日期前明确决定是否允许 ChatGPT-User 访问。
更稳妥的做法是分别决定是否允许训练和检索程序访问,AI 爬虫列出了相应的判断依据。按照 robots.txt中的方法编写指令时,也应考虑到该文件对 ChatGPT-User 未必有效。最后还需在网络层核验请求的真实来源,不能只依据请求中的令牌或产品预设作出判断。
8. 确保取页成功
允许 ChatGPT-User 访问并不足以保证取得有效结果,还要确保它能取回适合引用的内容。
它不执行 JavaScript。Vercel 与 MERJ 在 2024 年对大量 AI 爬虫请求进行实测后发现,OpenAI 的取回器会请求 JavaScript 文件,却从不执行其中的脚本,因此纯客户端渲染的页面只会返回不含正文内容的 HTML。这项结论发布后,OpenAI 尚未公布任何变化,但仍不能将其视为永久不变的保证。§3 所述的两种浏览器驱动场景属于例外:智能体模式和 Atlas 使用 Chromium,可以正常渲染页面。
同一项研究还发现,OpenAI 的取页请求中有相当大的比例遇到 404 和重定向。许多 AI 取页失败源于普通的链接失效和重定向链,并不涉及特殊机制。修复过期的站内链接,是降低此类失败率且成本很低的一项改进。
关于超时时长,目前没有可信的公开数据,流传的具体秒数也都没有可靠出处。因此,应按照常规性能要求缩短响应时间,而不要针对未经证实的超时阈值进行优化。
站点内部的统计工具还无法发现另一类失败。限速和质询规则很可能将面向单个用户的取页判定为异常:它是来自陌生网段的单次请求,也没有连续抓取活动可以帮助系统确认其性质。为防范自动采集程序而配置的防护措施经常会拦截这类请求;如 §2 所述,拦截记录又不会进入依赖客户端脚本的统计工具。AI 爬虫访问审计提供了相应的诊断方法。
成功取页并不意味着页面一定会被引用。是否引用还取决于页面结构是否清晰、段落能否独立表达完整含义,以及论断脱离上下文后是否仍然成立,详见 可引用性。ChatGPT 搜索说明了 ChatGPT 何时会进行检索,以及检索后通常会引用哪些内容。
关于经常与此话题一同出现的 llms.txt,OpenAI 没有任何文档表明 ChatGPT-User 会读取该文件,因此发布 llms.txt 不能改变这个取回器的行为。
9. 相关条目
- AI 爬虫:介绍三种程序类别,以及如何按类别决定允许或屏蔽访问
- GPTBot:OpenAI 的训练爬虫;若要退出训练,应屏蔽这一程序
- OAI-SearchBot:OpenAI 的搜索索引程序,负责管理搜索收录
- robots.txt:介绍协议机制和指令写法
- llms.txt:介绍该文件,并说明文档尚未确认其控制能力
- OpenAI:介绍这四个令牌的运营方
- 可引用性:说明成功取页后,页面内容是否适合被引用
- AI 爬虫访问审计:核验抵达服务器的请求来自何方
- ChatGPT 搜索:介绍 ChatGPT 如何检索和引用页面内容
参考资料
Primary
- OpenAI — Overview of OpenAI Crawlers
- OpenAI — Publishers and Developers FAQ
- OpenAI — ChatGPT-User published IP ranges
- Google Search Central — List of Google user-triggered fetchers
- IETF — RFC 9309: Robots Exclusion Protocol
- IETF — RFC 9421: HTTP Message Signatures
- IETF — A Vocabulary For Expressing AI Usage Preferences (draft)
- Cloudflare — Block AI bots
- Cloudflare — AI Crawl Control bot reference
- Netlify — User agent categories
Secondary
- Cloudflare — The crawl-to-click gap(2025 年 8 月 29 日)
- Cloudflare — Your site, your rules: new AI traffic options(2026 年 7 月 1 日)
- Vercel / MERJ — The rise of the AI crawler(2024 年 12 月 17 日)
- Search Engine Roundtable — OpenAI Updates Its ChatGPT Crawler OAI-SearchBot(2025 年 12 月 9 日)
- TollBit — State of the Bots, Q3/Q4 2025:出版商样本数据,样本量未披露,且该厂商销售爬虫变现产品
常见问题
ChatGPT-User 是什么?
ChatGPT-User 遵守 robots.txt 吗?
屏蔽 ChatGPT-User 后,网站会从 ChatGPT 中消失吗?
为什么统计后台看不到 ChatGPT-User 的访问?
OpenAI 代表用户取页时,只使用 ChatGPT-User 吗?
延伸阅读
参考来源
一手来源
- Overview of OpenAI Crawlers · OpenAI
- Publishers and Developers FAQ — OpenAI Help Center · OpenAI
- ChatGPT-User published IP ranges (chatgpt-user.json) · OpenAI
- List of Google user-triggered fetchers · Google Search Central
- RFC 9309: Robots Exclusion Protocol · IETF · 2022-09-01
- RFC 9421: HTTP Message Signatures · IETF · 2024-02-01
- A Vocabulary For Expressing AI Usage Preferences (draft-ietf-aipref-vocab-06) · IETF (Internet-Draft)
- Block AI bots — Cloudflare Bots docs · Cloudflare
- Bot reference — Cloudflare AI Crawl Control docs · Cloudflare
- User agent categories — Netlify docs · Netlify
二手来源
- The crawl-to-click gap: Cloudflare data on AI bots, training, and referrals · Cloudflare
- Your site, your rules: new AI traffic options for all customers · Cloudflare
- The rise of the AI crawler · Vercel / MERJ
- OpenAI Updates Its ChatGPT Crawler OAI-SearchBot · Search Engine Roundtable