Three paths, not one
Search Engine Land's August 2026 account of ChatGPT's retrieval stack describes three ways a page can reach the model. It can be in OpenAI's own index, where a short snippet of each page is stored at index time. It can be in a cache of pages the model previously opened in full. Or it can be fetched live during the answer by the ChatGPT-User agent. Which path your page takes decides how much of it the model ever sees.
| Path | What the model sees | Consequence for your page |
|---|---|---|
| Index snippet (the fast, free Instant path) | Title plus roughly 200 characters of visible body text after the H1, captured when the page was indexed | If the answer is not in that span, the fast path does not have it |
| Opened and cached | The full page, as previously fetched | Pages the model has opened are cited about 74% of the time in the analysis; retrieved-only pages about 7% |
| Live fetch by ChatGPT-User | The raw HTML at answer time, without executing JavaScript | Client-rendered content is invisible; pages over 4 MB are rejected with HTTP 400 |
What "the first 200 characters" means in practice
Count from the end of the H1. Skip the byline, the date, the breadcrumbs, the share buttons; the extraction is of body text, and everything before the first real paragraph is either dropped or wastes the budget. The first sentence should state the mechanism. The second should state what to do. If the page opens with "In today's fast-changing landscape", the fast path has already stopped reading.
The meta description does not rescue it. On the index path the analysis found it is ignored entirely; the snippet is cut from the visible text, not the head. Write the meta description for humans on Google, and write the first paragraph for the model.
The checks, in order
- Fetch the page without JavaScript. Use curl, or view source. Find the first sentence of your answer in the raw HTML. If it is not there, the page is client-rendered where it matters, and no amount of copy editing helps until that changes.
- Copy the text after the H1 and count 200 characters. Read only that. Does it say what the page is for and how the thing works? If not, rewrite the first paragraph until it does.
- Check the response size. Anything approaching 4 MB, including inlined scripts and base64 images, is at risk of an outright 400 on the live-fetch path.
- Check the status and canonical. A 200 with a self-referencing canonical. Redirect chains and soft 404s put the page on no path at all.
- Give the model a reason to open the page. The jump from 7% to 74% happens when a page is opened rather than merely retrieved. A snippet that promises a concrete answer (a number, a table, a step list) is what earns the open.
What this means for how you write
- The H1 is the job. The first paragraph is the answer. Everything else is support.
- One first-party number in the first paragraph, if you have one, with its date. Numbers are what a snippet can carry and a model can quote.
- No hero image between the H1 and the first paragraph that pushes the text down the DOM. Visual order does not matter; source order does.
- No accordion or tab hiding the answer. If the content is in the HTML it is fine to style it; if it is loaded on click, it does not exist.
- A table or numbered list within the first screen. It is the block most likely to be lifted when the page is opened.
How to know it worked
Re-index happens on OpenAI's schedule, not yours, so the fix is not visible the next day. Run the prompt weekly and watch the cited URL column. The change shows up as your URL appearing where it did not, on repeated runs. Record the date. If three weekly runs pass with no change, re-check the raw HTML before rewriting again; the most common failure is that the edit never reached the served page.