There is a moment most businesses never think about: a person is sitting in ChatGPT, asking about a company, a service, or a specific question, and ChatGPT reaches out and reads a live web page to answer them. That page might be your client's. The agent doing the reading is called ChatGPT-User, and it is different in kind from the crawlers everyone argues about. It is not indexing the web in the background. It is fetching one page, right now, because a real person asked. For an agency, that changes the job from being found to being ready.
The plain-English version
OpenAI runs an agent called ChatGPT-User that fetches a live page when a ChatGPT user's request needs one, to help answer the question and to provide a source link back (OpenAI's crawler docs). It is explicitly not an automated bulk crawler, unlike OAI-SearchBot, which surfaces you in search, or GPTBot, which trains on content. ChatGPT-User acts on behalf of a specific person in a specific moment. When it hits a client's page, it means someone is actively researching that client, or the topic the client serves, inside ChatGPT, and the model went to read the page to give that person a real answer with a link.
That framing is the whole reason this matters commercially. A live fetch is not background noise, it is a buyer with their hand halfway up. The agency's job is not to decide whether to allow it, because these are your client's potential customers, and blocking them would be self-defeating. The job is to make sure that when the fetch happens, the page is fast enough to be read, readable enough to be understood, and complete enough to answer on its own. Being fetch-ready is a real deliverable, and most client sites are not.
Why you cannot, and should not, block it
There is an important technical wrinkle an agency needs to understand before advising a client. Per OpenAI's December 2025 documentation update, ChatGPT-User no longer complies with robots.txt rules for user-initiated actions. Because the fetch happens on behalf of a real person who asked, it is treated more like a browser loading a page than like a crawler indexing one, so a robots.txt disallow is not a reliable way to stop it. That surprises people who assume robots.txt is a universal off switch. It is not, for this agent.
But the more important point is that you would not want to block it even if you could. A ChatGPT-User fetch is a potential customer being handed your client's page as an answer, with a link back. Blocking that is like refusing to let a walk-in customer read your sign. The entire posture here is the opposite of the training conversation, where blocking is sometimes right. With live fetches, the goal is to welcome them and serve them well, because each one is a person your client wants to reach, arriving at the exact moment of interest.
The technical version: making a client fetch-ready
Fetch-readiness is a specific, auditable property, and it overlaps with performance and accessibility work you may already do, but the framing is sharper: can a machine, in the moment, fetch this page, render its content, and read a clear answer. Run this checklist on a client's key pages.
- Serve content as real, server-rendered text. A live fetch may not execute heavy client-side JavaScript, so content that only appears after scripts run can be invisible to it. The core answer of every key page should be in the initial HTML, not painted in later.
- Be fast. A live fetch is happening while a person waits for an answer. Slow responses risk being abandoned or truncated. Core Web Vitals and server response time matter here for a reason beyond Google.
- Keep key pages free of hard gates. Login walls, aggressive interstitials, and cookie modals that block content can stop a fetch from reaching the substance. Gate what you must, but keep the pages you want cited open and readable.
- Make each page answer on its own. A live fetch usually pulls one deep page, not your whole site, so the specific service or answer page has to stand alone. It cannot rely on context the user never loaded.
- Keep information current. Because the fetch is live, it reads what is on the page today. Stale hours, prices, or availability get served as current. Freshness is now a correctness issue, not just a nicety.
None of this requires blocking anything or editing robots.txt. It is content and performance hygiene aimed at a new consumer: a real-time agent reading on behalf of a live buyer. It also compounds with the search work in the OAI-SearchBot agency playbook, because the same fast, readable, standalone pages that get fetched well also get surfaced well.
Turning live fetches into a client signal
The reporting opportunity here is genuinely new and most agencies are not using it. Because ChatGPT-User fetches are tied to live user interest, they are a leading indicator of demand forming inside ChatGPT, before any click, form, or call. Verify the fetches against OpenAI's published ranges at openai.com/chatgpt-user.json so you are counting the real agent, then log them per client and per page. A client whose service pages are getting a rising number of live fetches is being actively researched inside ChatGPT, and that is a story worth telling in a monthly report, alongside the search-visibility and access numbers.
It also sharpens where to invest. If the fetches cluster on a handful of pages, those are the pages buyers are being handed as answers, so those are the pages to make fastest, clearest, and most complete. The signal tells you which content is actually doing the work in front of live buyers, which is more useful than guessing. Over time, the mix of which pages get fetched is a map of what ChatGPT thinks your client is good for, which is a strategic input, not just a metric.
A worked example: reading the fetch signal
Make the signal concrete. Suppose you run this for a mid-sized law firm client with practice-area pages for estate planning, business formation, and personal injury. You verify and log ChatGPT-User fetches per page for a quarter. The estate-planning page shows a steady, rising line of live fetches; the business-formation page shows a trickle; the personal-injury page shows almost none. That pattern is a map of where ChatGPT-mediated demand is forming for this client, and it is available nowhere else in their analytics, because it sits upstream of every click and call.
What do you do with it? Three things. You tell the client, because a rising line of live fetches on estate planning is a real story about demand they cannot see any other way. You prioritize fetch-readiness work on that page first, making it the fastest, clearest, most standalone page on the site, because it is the one being handed to live buyers most often. And you ask why personal injury gets no fetches: is the firm not positioned for it in a way ChatGPT recognizes, or is the page not fetch-ready enough to be chosen. The signal turns vague optimization into a prioritized, evidence-backed plan, which is exactly what a client wants to see in a report.
Over several quarters, the shifting mix of which pages get fetched becomes a longitudinal read on what ChatGPT associates the client with, and how that is changing. That is strategic intelligence, not a vanity metric, and being the agency that surfaces it positions you well above the one reporting rankings and bounce rate. It is a new column in the report that only exists because you understood that a live fetch is a buyer, and you instrumented for it.
Packaging fetch-readiness as a deliverable
Fetch-readiness fits cleanly into the productized model you already use for AI access and search. The audit is concrete: for a client's top pages, confirm server-rendered content, measure performance, check for hard gates, and verify freshness, then hand back a scored list of what to fix. The ongoing work is the fetch-signal reporting plus rechecks after any site change, since a replatform or a new performance regression can silently make a previously fetch-ready page slow or script-dependent. Priced as an add-on to an existing retainer or folded into a care plan, it carries its own margin because the audit is repeatable and the reporting is largely automated once the logging is in place.
The pitch to the client writes itself once you frame it right. When a buyer asks ChatGPT about them, the client is either handed a fast, clear, current page or a slow, broken, stale one, and right now nobody is checking which. You check it, you fix it, and you report the live demand it reveals. That is a real service tied to a channel the client's competitors are almost certainly ignoring, which is exactly the kind of offer that both retains a client and differentiates your agency.
The thread tying the audit and the reporting together is a single reframe worth stating plainly to every client: a live fetch is a buyer, not a bot. Once a client internalizes that, the fast page, the readable text, the current information, and the open access all stop feeling like technical chores and start feeling like customer service, which is exactly what they are. Your job as the agency is to make that reframe stick and then deliver on it.
The mistakes that cost a client here
- Assuming robots.txt controls it. For user-initiated fetches it does not, per OpenAI's current docs. Do not promise a client you blocked ChatGPT-User via robots.txt.
- Rendering the answer only in JavaScript. If the substance appears after heavy scripts, a live fetch may read an empty shell. Put the core content in the server-rendered HTML.
- Ignoring the signal. Live fetches are a leading demand indicator. Not verifying and logging them means leaving a real client story on the table.
- Letting key pages go slow or stale. A live fetch serves whatever is on the page, at whatever speed. Slow or outdated pages get read as the client's current, best answer.
- Hard-gating pages you want cited. A cookie wall or login in front of a service page can stop the fetch from reaching the substance a buyer needed.
One more reason to move on this now rather than later: the field is wide open. Most businesses have not thought about fetch-readiness at all, because most agencies have not either. Their deep pages are slow, their answers are painted by scripts, and their edge posture was never checked against a live agent. That means the bar to being the fastest, clearest, most reliably-served option in a category is currently low, and an agency that gets a client there early is banking an advantage while competitors are still unaware the channel exists. As with the search work, the window is open and uncontested today, and it will not stay that way once fetch-readiness becomes table stakes.
What changes by client size inside your book
- Micro and solo clients (1 to 9): usually one site, a handful of pages. Fetch-readiness is mostly speed and real text. The owner-facing version is the micro-business live-fetch guide.
- Small and mid clients (10 to 249): many pages, so standalone completeness and consistent performance across the site matter more, covered in the growing-business live-fetch guide.
- Mid-market clients (250+): the wrinkle is the edge. A WAF that challenges ChatGPT-User can break real users' answers, which is a governance problem covered in the mid-market live-fetch governance guide.
Search gets a client into consideration. Training shapes what the model generally knows. The live fetch is the moment a specific buyer is handed the client as the answer, so it is where readiness pays off most directly. Being fetch-ready and being the firm the model chooses to hand over are two halves of the same job, and the second half is the authority work in the answer engine optimization cornerstone. See also how the training decision fits in the GPTBot agency guide.
Want us to audit your client book for fetch-readiness and stand up the live-fetch reporting with you? Run discovery or see what we ship.
