What You See Is Not What You Deliver: How to Audit Whether Your Content Exists for Google and AI Agents

There’s an intuition that anyone who has been doing this for years has already internalized: the page you see in your browser and the page a bot receives are not the same thing. We learned it with Flash, we learned it again with JavaScript frameworks, and now we have to learn it a third time, with an added complication: there is no longer a single mechanical reader to satisfy. Now there are three, and each one reads differently.

This article is an invitation to do something every SEO knows in theory and almost nobody actually checks in practice: open one of your own pages and ask, layer by layer, which parts of that content truly exist for each of the readers arriving without fingers, without eyes, and increasingly, without patience.

Three readers, three ways of reading

Googlebot is the most generous reader. It downloads the HTML and then renders it in a headless Chrome environment, executes the JavaScript that runs on load, and works with the resulting DOM. But rendering is not the same as interacting: it does not click, open accordions, switch tabs, or scroll to trigger the next batch of content. It executes what runs automatically; anything that depends on a user event never happened as far as Googlebot is concerned.

LLM crawlers are more basic. A joint study by Vercel and MERJ across their network of sites, published in late 2024, found no evidence of JavaScript execution among the major AI bots: GPTBot, ClaudeBot, PerplexityBot, and others download the HTML exactly as the server returns it. Sometimes they even fetch the JavaScript files, but they do not run them. For them, if something is not in the raw HTML, it is not there.

That data is almost two years old and these bots evolve quickly, so it is worth checking again periodically. But the underlying principle remains the same: do not bet your content on a bot behaving like a person.

AI agents are the new reader, and the strangest of the three. They are not here to index; they are here to complete a task for someone. Some navigate with a real browser, which means they can see rendered content and sometimes even click. Others simply fetch the HTML, like a crawler. But they all share one constraint the other two readers do not have: a token budget. They do not read your page from top to bottom; they trim it. And whatever gets trimmed is something that, for them, effectively never existed.

I’ll come back to this later, because this is where visibility stops being purely a technical problem and becomes a writing problem.

The three layers where your content can live

Before auditing anything, it helps to understand that “the content is on the page” can mean three different things, and that each reader reaches a different layer.

Layer 1: the HTML sent by the server. What you see with Ctrl+U, before a single line of JavaScript runs. This is the only layer that every reader can reliably access. If your important content is here, you can sleep well.

Layer 2: the DOM after the page loads. What you see in the Elements tab in DevTools once the page has finished loading. This includes anything JavaScript injected automatically, without anyone touching anything. Googlebot reaches this layer. LLM crawlers, based on the available evidence, do not.

Layer 3: what appears after an interaction. The FAQ answer that only gets written into the DOM after you open it. The content in the second tab. Reviews loaded after clicking “show more.” Products that appear when you scroll. A technical specification hidden behind a modal. At this point, you can no longer assume anyone will reach it. Googlebot should not depend on that interaction; LLM crawlers should not either; and the fact that an agent can click does not mean it will.

And then there is a fourth layer that barely even counts as a layer: content that exists, but in a format no mechanical reader is likely to process well. Text inside images. Pricing tables saved as PNGs. Comparisons inside an embedded PDF. For the user, it is content; for the crawler, it is a rectangle.

The two-minute check, generalized

This is the method we use at the agency to check whether content is readable by everyone:

1. Open a page in Chrome that contains content you care about. Ideally, use a template such as a product page or service landing page: whatever you find will apply to every page that uses it.
2. Choose a piece of content that sits behind an interaction: a closed FAQ, an inactive tab, a collapsed block. Open it and copy five or six consecutive words that are unlikely to appear anywhere else on the page.
3. Right-click and select Inspect. In Elements, press Ctrl+F (Cmd+F on Mac) and paste the fragment. If Chrome highlights it in the DOM, the text is there now.
4. Reload the page. And this is the key part: after reloading, do not touch anything.
5. Search for the same fragment again in Elements.

If it appears, your component is honest: the content was already available before the interaction and the click only revealed it. It is either layer 1 or layer 2. If it does not appear, you have just confirmed that the content is injected on click. That is layer 3. For any crawler, that block has a heading and no body.

Two more steps will tell you exactly which layer you are dealing with:

• Press Ctrl+U and search for the same fragment in the source code. If it is in Elements but not in the source, it is layer 2: Google will probably read it, while LLM crawlers probably will not. If it appears in both places, it is layer 1, which is what you want.
• Disable JavaScript and reload. In DevTools, press Ctrl+Shift+P, type Disable JavaScript, hit Enter, and reload the page. What remains on screen is, approximately, what a non-rendering bot receives. It is the visual version of the previous test, and the one that works best when you need to show the problem to someone who is not technical. If you would rather do it with one click, the Web Developer extension, which we covered in the 13 Chrome extensions every SEO team should use, has exactly that switch.

And to finish with the official confirmation: open URL Inspection in Search Console, click Test Live URL, then View Tested Page → HTML. Search for the fragment in the rendered HTML that Google actually processed. That is what you show the developer when they tell you that “Google executes JavaScript,” because yes, it does, and the text still is not there.

Where things usually break

FAQs are the classic example, but the list of suspects is much longer, and it is worth running the check on all of them:

• Accordions and FAQs that load the answer when opened.
• Tabs (description / specifications / reviews) where only the first tab is included in the HTML.
• “Show more” or “load more” buttons that fetch content through AJAX.
• Infinite scroll on product or article listings.
• Modals and drawers containing technical specifications, sizing charts, or terms and conditions.
• Reviews and ratings injected by a third-party widget.
• Content that depends on accepting cookies, selecting a location, or logging in.
• Text inside images, infographics, and embedded PDFs.

One detail that is easy to overlook: if your SEO plugin generates FAQPage or Product schema from that content, the JSON-LD may contain the text even when the visible HTML does not. That does not save you. Google requires structured data to correspond to the actual content on the page. If a piece of information exists only in the JSON-LD, but not in the content available to users and crawlers, you have at least an inconsistent signal.

The solution is almost never to fight the component itself. The accordion is fine. The tab is fine. What you need to ask development to do is render the content in the initial HTML — on the server or at build time — and let JavaScript handle only the showing and hiding. In most stacks, this is a small change. In WordPress, it often means replacing a block or plugin with one that prints the content into the markup. Many do it correctly, some do not, and the only way to know is to run the check above.

The other kind of visibility: the one DevTools cannot audit

So far, visibility has meant “the text is where the reader is going to look for it.” AI agents introduce a second question that DevTools cannot answer: assuming the text is available, is it written in a way that allows it to be retrieved and understood out of context?

The team at Pare & Co published an idea this year that I think is one of the most useful right now: most systems that consult the web in order to answer a question do not read your entire page. They retrieve passages. They break the content into chunks — often by paragraph — select the fragments that are semantically closest to the query, and put only those into the model’s context window. Your content competes passage by passage, not page by page.

In their experience auditing clients, the passages that end up being cited are the ones that contain a complete unit of information — claim, evidence, and implication — within a relatively short block. Passages that require the context above them in order to make sense are retrieved less often and are almost never cited. These are observations from their own work, not a controlled study, and they should be treated accordingly. But they line up with what you see when you ask an assistant a question and inspect the exact paragraph it retrieved.

If that is true, then the visibility audit has a second pass, and this one is about writing:

• Does the first sentence of each section answer something, or does it merely set the scene?
• Do your headings say what the section claims, or only what topic it covers?
• Are your paragraphs self-contained units that still make sense when read in isolation, or do they depend on a “as we saw above”?
• Is your best piece of information buried in the fourth paragraph of the third section, after all the preamble?

It is the same logic we discussed when looking at Anchor Context and the surrounding environment of a link: the value was never contained in the word alone, but in what surrounded it. The difference now is that this surrounding context has to travel inside the same block, because that may be the only thing the agent takes with it.

None of this requires bad writing or abandoning the narrative thread that keeps human readers engaged. It requires moving the substance forward. The writer who saves the conclusion for the end is writing for suspense; the writer who wants to be cited puts it first.

There is another layer, even more uncomfortable, that academia has started to examine: the agent as a reader is a reader with limits on interpretation. At this year’s ACM Hypertext conference, Gupta and Joshi presented a paper whose title goes straight to the point: The Assumed Reader. For thirty years, we designed pages for a human reader who navigates, infers, and fills in what is missing.

An agent can infer, but you should not design content on the assumption that it will correctly fill in what is missing. It takes fragments, interprets them within a limited context, and builds an answer from them. That literalness is also a vulnerability — the same paper engages with the literature on indirect prompt injection through web pages — but for those of us who write, the message is simpler: you can no longer assume how your reader reads.

Same old problem, one more time

I kept thinking about why this mistake is so common, and I think the answer is uncomfortable: pages are designed for the person who uses them, and that person clicks, scrolls, opens things, reads selectively, and still understands. The component works for the user, the product team approves it, and nobody in the chain develops the reflex to ask what happens when the visitor has no fingers, no eyes, and no intention of reading everything.

The page is not what you see. The page is what you deliver. Everything you place on the interaction side, no matter how valuable it is, is a bet that someone will go looking for it. And everything you place on the suspense side is a bet that someone will wait for it. The readers that now decide whether or not to cite you do neither: they take what is there.

So the next time someone shows you a flawless landing page, do what any suspicious old man would do: reload it, touch nothing, turn off JavaScript, and see what remains. Then read the first paragraph of every section as if it were the only thing anyone was ever going to see. Because it probably is.