Short answer: ChatGPT-User is OpenAI's user-triggered fetch agent. When a person asks ChatGPT a question and ChatGPT needs to open a web page to answer, it visits that page as ChatGPT-User. It is not the bot that builds ChatGPT search results, and it is not the bot that collects training data. Because the visit starts with a user request, OpenAI says robots.txt rules may not apply to it — so a robots.txt block that works fine against GPTBot can leave ChatGPT-User visits untouched.
If you run a site and you have ever checked your logs, seen ChatGPT-User, and wondered why it ignored your robots.txt file, this guide explains the gap. It also covers the mistake to avoid: blocking every OpenAI agent in one broad rule, which can quietly remove your site from ChatGPT search answers even though you only meant to opt out of training.
ChatGPT-User is a fetch, not a crawl
Most bots you deal with crawl on their own schedule. They discover links, work through a queue, and revisit pages on a cycle. ChatGPT-User works differently. Nothing happens until a person takes an action: they paste a link into ChatGPT, ask about a specific article, or use a custom GPT that needs to read a page. Only then does OpenAI fetch that one page, for that one request.
OpenAI's own crawler documentation puts it plainly: ChatGPT-User is not used for crawling the web in an automatic fashion, and it is not used to decide whether content may appear in search. That distinction matters for everything that follows. A crawler follows a systematic plan; a fetch follows a person. Search engines and bot operators have long treated user-initiated fetches as closer to a human visit than to bulk crawling, which is why the normal robots.txt bargain does not cleanly apply.
Think of it this way. GPTBot is a librarian copying books for a future library. OAI-SearchBot is a librarian building an index so people can find books. ChatGPT-User is a friend who walks into the shop because you asked them to read one specific page aloud. The first two take instructions from the shop's posted rules. The third is acting on your request, and the shop's sign about bulk copying was never written for that case.
The three OpenAI agents, side by side
Confusion about ChatGPT-User almost always comes from lumping OpenAI's agents together. They share a company, but they do different jobs and they obey different rules. Here is the split, as documented by OpenAI:
- GPTBot crawls content that may be used to train OpenAI's foundation models. Disallowing GPTBot in robots.txt signals that your content should not be used for training. Blocking it has no effect on whether you appear in ChatGPT search.
- OAI-SearchBot builds the index behind ChatGPT search. Sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers, though they may still appear as plain navigational links. OpenAI says it takes about 24 hours for a robots.txt change to take effect for search.
- ChatGPT-User fetches a page when a user action in ChatGPT or a custom GPT requires it. It does not build the search index and it does not collect training data in the way GPTBot does. Robots.txt rules may not apply because the action was initiated by a user.
OpenAI also documents a fourth agent, OAI-AdsBot, which only visits landing pages submitted as ChatGPT ads to check them. It does not train models and it has nothing to do with organic search or citations, so most site owners can ignore it unless they advertise on ChatGPT.
The practical rule is simple: each setting is independent. You can allow OAI-SearchBot so you stay citable in ChatGPT search while disallowing GPTBot to opt out of training. That combination — allow search, block training — is exactly what many publishers choose, and it only works if you write separate rules for each agent instead of one blanket block.
Why robots.txt may not stop ChatGPT-User
Robots.txt is a voluntary protocol. It works because well-behaved crawlers agree to read it and follow it. It was designed for automated crawling, where a bot decides on its own what to visit next. A user-triggered fetch sits outside that design: the bot is not deciding to crawl your site, it is carrying out a specific person's request to read a specific page.
OpenAI is upfront about this. Its documentation says that because ChatGPT-User actions are initiated by a user, robots.txt rules may not apply. Note the careful wording: “may not apply” is not a promise that it always ignores robots.txt, and it is not a claim that it always obeys it either. In practice, you should treat a robots.txt rule for ChatGPT-User as unreliable. Sometimes it may be respected; you cannot count on it, and you should not build a content-protection plan on it alone.
This is also why testing can mislead you. You might block ChatGPT-User in robots.txt, ask ChatGPT to open your page, and find that it still summarises the page. That does not mean your robots.txt file is broken, and it does not mean OpenAI is ignoring all of your rules. It means you tested the one agent for which robots.txt is the wrong tool. Your GPTBot and OAI-SearchBot rules can be working perfectly at the same time.
What blocking ChatGPT-User actually changes
Suppose you do manage to block ChatGPT-User at a layer that enforces the block, such as a firewall rule or server-level block. What changes for your site?
First, a person who pastes your URL into ChatGPT will no longer get a fresh read of that page. ChatGPT may fall back to what it already knows, refuse to open the link, or summarise from search results instead. If your business depends on people sharing your pages in chat — a tool page, a pricing page, a help article — that friction lands directly on real users, not on a faceless crawler.
Second, blocking ChatGPT-User does not remove you from ChatGPT search answers. Search eligibility is controlled by OAI-SearchBot. If you want to stay visible in ChatGPT search, keep OAI-SearchBot allowed and keep your pages crawlable. If you want to leave ChatGPT search, block OAI-SearchBot and wait about a day for the change to register. Blocking ChatGPT-User alone achieves neither of those outcomes reliably.
Third, blocking ChatGPT-User does not opt you out of training. That is GPTBot's job. A site that blocks only ChatGPT-User while leaving GPTBot allowed has done the opposite of what most publishers intend: it has inconvenienced real readers while leaving training collection open.
If you really need to stop the fetch, use an enforcing layer
Some sites do have a genuine reason to stop live fetches: paywalled reporting, embargoed pages, client work that must not be summarised, or licensed content that cannot be redistributed through a chat answer. For those cases, you need a layer the fetch cannot simply walk past.
The strongest option is authentication. If a page requires a login, a fetch without credentials gets a login screen, not your content. This is the approach Framer itself recommends for pages that need stronger protection than a noindex tag: access control beats a polite request every time. Use it for genuinely private material, not for public marketing pages you also want indexed, because the same login wall that stops ChatGPT-User also stops Googlebot and human visitors without accounts.
The next option is a firewall or CDN rule that blocks the ChatGPT-User user-agent string or its published IP ranges. OpenAI publishes IP ranges for ChatGPT-User, which lets you verify and block at the network edge. A CDN rule is easier to maintain than a server change, and it can be scoped to sensitive paths — your draft folder, your members area, your unreleased reports — instead of your whole site. Keep the scope narrow. A site-wide user-agent block is easy to write and easy to regret when a partner, a customer, or a journalist pastes your link into ChatGPT and gets nothing.
A third option, useful for pages that are public but should not be quoted at length, is to control what the fetch can see rather than whether it can connect. Put the sensitive detail behind a click, a form, or a second step that a simple fetch does not complete. This is not a security boundary — anyone determined can still read the page in a browser — but it raises the effort for casual summarising without breaking the page for search engines or ordinary readers. Be honest with yourself about which category your content falls into: if it truly must not leak, use authentication; if you just prefer it not be summarised, a friction step may be enough.
Whatever layer you choose, test it the way a user would: paste the URL into ChatGPT and ask about it, and also check that Googlebot and ordinary visitors still reach the page. A block that also breaks search traffic is a much more expensive mistake than the fetch you were trying to stop.
How to verify a real ChatGPT-User visit
Not every request claiming to be ChatGPT-User actually is. User-agent strings are trivial to fake, and scrapers routinely borrow the names of famous bots to slip past naive blocks. Before you change any rule because of a log entry, verify the visitor.
OpenAI publishes the IP ranges its agents use, including a separate list for ChatGPT-User. A genuine visit comes from one of those ranges. Check the requesting IP against the published list, and treat anything outside it as unverified, no matter what user-agent string it carries. The same discipline applies to GPTBot and OAI-SearchBot: published ranges exist for them too, and matching on the token (ChatGPT-User, GPTBot, OAI-SearchBot) rather than a full versioned string keeps your rules working when OpenAI ships a new version number.
In your logs, look for the pattern, not just one hit. A real ChatGPT-User visit is usually a single request for a single page, close in time to a user sharing that link. A burst of requests across hundreds of pages in minutes, all claiming to be ChatGPT-User, is not a person asking questions — it is a scraper wearing a costume. Block the pattern at your firewall, and do not blame OpenAI's documented agent for traffic it never sent.
A decision guide for different sites
Blogs, docs, and marketing sites that want citations: allow OAI-SearchBot, disallow GPTBot if you do not want training use, and leave ChatGPT-User alone. Your readers sharing links in ChatGPT is distribution, not theft, and blocking the fetch only makes your content harder to discuss.
News and paywalled publishers: keep the paywall as the boundary. Let search agents see enough to cite you (headlines, summaries, and the pages you choose to leave open) and let authentication protect the full text. Blocking ChatGPT-User while leaving the full article public in a browser achieves very little.
Sites with embargoed or client-confidential pages: do not publish those pages on a public URL and rely on robots.txt. Keep them behind login, on a staging host that search engines never see, or offline entirely until release. A robots.txt rule is a request, and a user-triggered fetch is the exact case where requests get weakest.
E-commerce and SaaS sites: the usual worry is a competitor asking ChatGPT to summarise your pricing or comparison pages. That is public information, already visible to anyone with a browser. Blocking the fetch does not hide it; it only makes your own customers' research slightly harder. Spend the effort on clearer pricing pages instead.
FAQ
Does blocking GPTBot stop ChatGPT from reading my site?
No. Blocking GPTBot opts your content out of training collection. It does not stop OAI-SearchBot from indexing you for search answers, and it does not reliably stop ChatGPT-User from fetching a page a user asked about. Each agent needs its own rule, and ChatGPT-User needs an enforcing layer if you truly want it stopped.
Will blocking ChatGPT-User remove me from ChatGPT search?
No. Search visibility is decided by OAI-SearchBot. If you block ChatGPT-User but allow OAI-SearchBot, your pages can still appear in ChatGPT search answers. If you want out of ChatGPT search, block OAI-SearchBot and allow about 24 hours for the change to take effect.
Why did ChatGPT summarise my page even though I blocked it in robots.txt?
Most likely because the fetch came through ChatGPT-User, for which OpenAI says robots.txt rules may not apply since a user initiated the visit. It can also happen if the summary came from search-indexed content rather than a fresh fetch. Check your logs for which agent actually visited, and verify its IP against OpenAI's published ranges before concluding that a rule was ignored.
Should I block all OpenAI agents to be safe?
Almost never. A blanket block removes you from ChatGPT search, inconveniences users who share your links, and still may not stop a determined fetch. Decide separately for each agent: training (GPTBot), search (OAI-SearchBot), and live fetch (ChatGPT-User). A split decision is more work to write, but it is the only version that matches what you actually want.
How do I check which OpenAI agent visited my site?
Search your server logs for the tokens GPTBot, OAI-SearchBot, and ChatGPT-User, then confirm the source IP against OpenAI's published IP lists for each agent. Match on the token, not the full versioned string, because version numbers change. A single-page visit close to a user sharing the link points to ChatGPT-User; steady crawling across many pages points to GPTBot or OAI-SearchBot.
Does allowing ChatGPT-User mean OpenAI trains on my content?
No. Training collection is GPTBot's role, controlled by its own robots.txt rule. Allowing a live fetch for a user who asked about your page does not, by itself, authorise training use. Keep the two decisions separate in your robots.txt file so a future reader of your file can see exactly what you intended.
For a ready-made robots.txt file with separate rules for GPTBot, OAI-SearchBot, and the other major AI crawlers, try the free robots.txt generator, and test the result before publishing with the robots.txt tester. If you want the broader picture, read how to get cited by ChatGPT and how to block AI crawlers with robots.txt.
