· 15 minute read
What LLMs Actually See When They Read Your Page
How AI systems process web content, what the research suggests, and where the evidence is still uncertain.
When someone asks ChatGPT a question and it searches the web, what happens to your page?
I'm interested in the mechanics. What does the system actually do with the HTML, the JavaScript, the structure you spent time building? How does it decide which parts matter and which parts to ignore?
There's a growing body of advice about optimizing content for large language models. Some of it is grounded in research. Some of it is extrapolated from research that says something slightly different from what's claimed. And some of it is speculation dressed as best practice, shared so confidently that it's hard to tell the difference.
This isn't a critique of the people doing that work. Figuring out how to be visible in AI-generated answers is a legitimate problem, and the people studying it are doing important early research in a field that's changing quickly. I'm one of those people. At Backlinko, our editorial team researches and writes about this regularly.
We need to separate what we know from what we're still guessing about. The difference matters for how you invest your time.
Some findings are more useful for making decisions than others.
Your page is not what they see
An AI system can use a page without seeing the layout a visitor sees. What it receives depends on the tools and retrieval process involved.
Retrieval-Augmented Generation (RAG) combines retrieved material with a model's response. The workflow below is a simplified example of retrieving text from a page. It is not a trace of ChatGPT or a description of every search product.
1. Fetch. In this example, a tool requests the URL and receives the HTML delivered by the server.
Simplified example HTML. It does not represent every crawler or retrieval system.
This example includes article text alongside navigation, scripts and other page elements. A text-extraction tool can remove material it does not need for the task.
2. Strip. CSS, JavaScript, navigation, footers and sidebars are removed in this example. What remains is closer to a text transcript than a web page.
Extraction happens outside the language model in this example. Other systems may use rendered pages, images or different representations. Training-data preparation and search-time retrieval should not be treated as the same process.
Illustrative extraction. Different tools preserve different parts of a page.
In February 2026, Cloudflare introduced Markdown for Agents. Its announcement took 16,180 tokens as HTML and 3,150 as Markdown, about an 80% reduction. Much of that saving came from representing the page more compactly.
That is a saving in tokens, not evidence that a model ignores 80% of an author's content.
3. Chunk. The extracted text can be split into overlapping passages. Chunk size and selection depend on the retrieval system. Some workflows instead supply a whole document or use other ways to select relevant material.
Invented example passages and token counts, used only to show overlapping chunks.
A content strategy starts with understanding what your audience actually needs. Not what you want to say, but what they're trying to accomplish. The gap between those two things is where most strategies fail. They begin with the company's goals rather than the reader's problems...
Overlap can help preserve text that spans a chunk boundary. It does not guarantee that all the context needed to interpret a passage will be retained.
4. Retrieve. In this example, the query guides which chunks enter the model's context. Some passages are left out.
Invented passages and similarity scores. This is not a recorded platform response.
The example uses invented similarity scores to show one way passages might be selected. Three of the six chunks are retained. That selection is illustrative, not a measured rate of content loss in a commercial search product.
5. Generate. The model synthesizes an answer from your selected chunks alongside chunks from other sources. Your content becomes one voice among several.
Fictional publishers and example text, used only to explain synthesis.
"...teams who interviewed their audience quarterly produced content that ranked better..."
"...some teams conduct audience research monthly..."
In this illustration, the page contributes three of six selected chunks. A real system may retrieve, combine and cite material differently. A passage can lose important context when it is separated from the surrounding argument.
In this example, the system uses selected passages rather than the full page.
It is worth checking whether your content makes sense as extracted text, as well as in its designed layout. This particular workflow does not preserve interactive elements or visual styling.
Design still matters for the people visiting the site. Text accessibility is an additional consideration, not a replacement for a good reading experience.
For the text-processing workflow described here, the words and structure need to make sense on their own.
What the research actually tells us
The studies below test different things: model performance, brand mentions and citation patterns. Each can inform a decision, provided we keep its scope in view.
Position can affect how models use context
The 2023 paper Lost in the Middle tested multi-document question answering and key-value retrieval. In those experiments, models often performed worse when relevant information sat in the middle of a long input.
That is a reason to be careful about how context is assembled. It is not proof that the middle of every webpage is ignored: a webpage's order may not match its position in the model's input.
I would not turn this finding into a rule about putting every important claim in the first third of a page. Clear openings are useful for people. Whether they improve AI citations needs separate evidence.
Brand mentions and AI visibility are associated
A December 2025 Ahrefs study of 75,000 brands found that branded web mentions correlated more strongly with brand mentions in ChatGPT than branded search volume did. This was an observational comparison of brand visibility, not a test of which ranking signals ChatGPT uses.
That differs from the emphasis SEO advice has traditionally placed on backlinks.
But the caveat matters: this is correlation, not causation. Well-known brands naturally have more mentions, more citations, and more backlinks. The causal chain might run through brand strength rather than mention count. A startup that artificially inflates its web mentions wouldn't necessarily see more AI citations.
For me, the useful question is whether people can find credible discussion of a brand beyond its own website. The study does not tell us that manufacturing more mentions will cause more citations.
Search rankings don't tell the whole story
A July 2025 Semrush study, covering more than 500 high-value digital-marketing and SEO topics and subtopics, found that almost 90% of ChatGPT Search citations came from pages in organic positions 21 or lower for related queries. That is a result from a particular topic sample, not all search.
In Profound's August 2024–June 2025 data, Wikipedia accounted for 47.9% of citations within ChatGPT's ten most-cited sources. That denominator matters: it was not 47.9% of all ChatGPT citations.
Rankings and citations are worth measuring separately. The Semrush report also notes that strong traditional rankings may help a page get cited. These findings do not make SEO irrelevant.
Where the evidence gets thinner
Other claims in the LLM optimization space have weaker or directly contradictory support. That doesn't mean they're wrong. It means we should hold them more lightly and watch for better data.
Schema markup and changes to the text
The GEO paper tested changes to text, including quotations, statistics and source citations. Several improved visibility in its experiments. It did not test schema markup, so it cannot settle that question.
Google's guidance says no special schema is required for its AI search features. Existing structured data should match the visible content. That is guidance for Google, not a finding about every AI platform.
llms.txt is not a visibility guarantee
The llms.txt proposal offers a way to provide an LLM-friendly overview and links to useful material. Providing a file and proving it improves discovery are different things.
Google says no new AI text files are needed for its AI search features. I would not prioritize this over making the content accessible and useful, unless there is a specific tool or workflow that needs it.
Early findings need careful interpretation
Research into AI visibility is useful. The problem comes when a finding about one model, metric or sample becomes a rule for everyone.
Before acting on a recommendation, I want to know what was tested, when it was tested, and whether the result applies to the platform I care about.
These are not the same system
The differences between platforms matter too.
When people say "optimize for LLMs," they're treating these systems as a single category. But the major AI search platforms work differently in ways that matter for your content strategy.
Public documentation helps separate known behavior from guesses about the architecture.
ChatGPT Search
OpenAI distinguishes automatic search crawling, potential training collection and user-requested visits. OAI-SearchBot concerns search access; GPTBot concerns content that may be used for training. ChatGPT-User is used for certain user-initiated visits, not automatic search crawling.
Those distinctions matter when reading crawler studies. Observing the training crawler does not tell us everything about what ChatGPT Search can retrieve or use.
Google AI features
Google says AI Overviews and AI Mode may use query fan-out: issuing related searches across subtopics and data sources while developing an answer. The features can use different models and techniques.
The example below shows what related searches might look like. It does not establish a fixed number of searches per question.
Example sub-queries, not a captured Google query trace.
This is a meaningful difference. A page optimized for one specific keyword might get pulled into an AI Overview through a completely different sub-query path. That gives a page possible routes into an answer beyond its target keyword.
Other platforms need their own checks
I would not use a finding about Google or ChatGPT as a description of Perplexity or Claude. Before giving platform-specific advice, check that platform's documentation and date any observations about its behavior.
The JavaScript blind spot
One practical check is whether your content is available before JavaScript runs.
A tool that fetches only the initial HTML cannot see text added later by client-side JavaScript. That is a limitation of that retrieval path, not proof that every AI product is unable to access rendered content.
If the initial response contains only an empty application shell, an HTML-only fetch has little to work with. The example below shows that particular problem.
The practical advice is straightforward. Ensure your important content is present in the initial HTML response, before any JavaScript execution. Server-side rendering or static generation solves this. If you're running a JavaScript-heavy site, view your page source, not the rendered DOM, but the actual HTML, and check whether your content is there.
If the important text is missing, investigate how the retrieval tools relevant to your audience access it. Serving useful HTML reduces reliance on client-side rendering.
What this means for your content
I'd be cautious about turning these findings into a fixed checklist. Several depend on the platform, model and conditions tested.
For now, I'd focus on a few questions.
Clear writing and accessible content are useful places to start. Clear writing, genuine expertise, logical structure, specific claims supported by evidence. These are good for readers, AND they're exactly what survives the extraction pipeline. When a model strips your page to text and selects relevant chunks, the quality of your writing and the clarity of your structure is what remains.
Those improvements also help the people visiting your site.
Check the text as well as the page. Are headings descriptive? Can a quoted passage be understood without losing a crucial condition or caveat? These are useful editorial checks, without assuming a particular chunk size or an attention rule.
Be specific about the platform. Decide which systems matter to your audience before investing in platform-specific work. I would start with accessible content and clear explanations, then test the narrower recommendations.
Watch the evidence, not the advice. This space is moving fast, and the advice is moving faster than the evidence supporting it. When you encounter a new LLM optimization recommendation, ask: what study is this based on? Has it been replicated? Does it apply across platforms or just one? The people doing the best work in this space, and there are many, are the ones citing specific research and acknowledging limitations.
Follow them.
What we're still figuring out
These systems are still changing. Future research may confirm some of today's findings and overturn others. I do not want to mistake a current observation for a permanent rule.
I want to keep learning without treating today's findings as permanent rules. Understand the mechanisms as best you can. Question claims that aren't sourced. Invest in the things that have always made content valuable, expertise, clarity, specificity, because those are the qualities that survive regardless of how the technology shifts.
This is a working document. As better research emerges, it will be updated.