Every page on your site exists in two versions. The first is the bytes your server sends in response to a GET request. The second is the document object model that exists in a browser after your JavaScript has run. You have only ever looked at the second. Most agents only ever receive the first.
The gap between those two versions is where the majority of serious agent readiness findings live, and it is invisible to anyone who tests in a browser, because a browser cannot show you the first version without being asked to. Check A7 in our rubric exists to measure it. This post explains what the two fetches are, why the gap swallows so much of the rest of the rubric, how A7 turns it into a number, and how to compute a rough version of that number yourself in about a minute.
Fetch one, the raw HTML
This is what a plain HTTP client gets. No JavaScript is executed, no further requests are made, nothing is hydrated. It is exactly what curl returns:
curl -sL https://example.com/ > raw.html
It is also what the browser shows under "view source", which is the one place a browser will show you the first fetch. Whatever is in that file is what a program without a JavaScript engine has to work with: the text, the links, the forms, the JSON-LD, the meta tags, all of it or none of it.
If your site is server-rendered, raw.html contains the page. If your site is a client-rendered application, raw.html contains a div with an id, a few script tags, and perhaps a loading spinner. Both look identical in a browser two seconds later.
Fetch two, the rendered DOM
This is what a browser builds. It downloads the raw HTML, runs the scripts, waits for the data they fetch, and assembles the result into a live document. The inspector in your developer tools shows you this version, and only this version. It is the page as you think of it, and it is the page your analytics, your QA process and your screenshots are all based on.
Our crawler captures both. Each page is fetched once with a plain client and once more in a headless browser, and the crawl records the visible text from each. Our own crawler policy describes the full procedure.
Why the gap swallows everything downstream
An agent that fetches raw HTML and finds nothing in it does not report a rendering problem. It reports nothing. From its point of view the page is empty, and every other property the page might have had is empty with it.
That is why A7 is upstream of most of the rubric. JSON-LD that a client-side script injects after load is absent from the raw fetch, so check B1 sees no schema and check B2 sees no types. A form that a framework renders during hydration is absent, so check C1 finds no inputs to label. Navigation that a component mounts is absent, so check C2 finds no link graph. Heading structure, landmarks, alt text, the price and availability the commerce check C5 compares against schema: every one of them is measured on what the agent receives.
The recommendation text the scanner attaches to a zero on A7 puts it directly: schema an agent never receives may as well not exist. It is the single highest-value fix on most reports where it appears, and the most involved.
How A7 measures it
The check is deliberately simple, so that its output can be reproduced by anyone.
The scanner takes the homepage's raw HTML, parses it, strips the contents of script, style, noscript, template and svg elements, and extracts the visible text with whitespace collapsed to single spaces. It takes the visible text from the headless render of the same page and collapses its whitespace the same way. It then divides the length of the first by the length of the second, capped at 1.0.
Scoring follows the thresholds published in the rubric. A ratio at or above 0.8 scores the full five points. A ratio at or above 0.5 but below 0.8 scores three. Below 0.5 scores zero, because an agent using a plain fetch sees essentially nothing. The check is rated High effort, because the fix is usually architectural.
Two details are worth knowing. First, noscript content is stripped along with scripts, so a fallback block inside noscript does not count towards the raw side. Second, the ratio is capped: if the raw HTML somehow carries more text than the render, the score is full marks, not more than full marks.
The evidence block on a scan report shows three fields for this check, rawTextLength, renderedTextLength and ratio. When the score is three, the recommendation states what proportion of the visible content only appears after JavaScript runs, which is simply one minus the ratio. Our own report at /site/agentfriendlyrank.com shows the block for this site, and reading your scan report walks through the format.
A related point about the rubric's design. Server-rendering frameworks commonly inline a serialised copy of the page data inside a script tag so the client can hydrate without refetching. That payload duplicates the page text and can be a large share of the document. Check B5, the clean text ratio, excludes script and style contents from its denominator precisely so that this pattern is not penalised; the changelog entry for rubric version 1.0.1 on /methodology explains the correction. A7 rewards server rendering and B5 was adjusted so that it does not punish the same architecture.
Measure it yourself
You do not need our scanner to see the gap. The crude version takes a minute.
Fetch the raw HTML and strip the tags. This is rougher than the scanner's parser, because it does not remove script contents before counting, but it is enough to show whether the page is there at all:
curl -sL https://example.com/ \
| sed -e 's/<script[^>]*>[^<]*<\/script>//g' \
| sed -e 's/<[^>]*>//g' \
| tr -s '[:space:]' ' ' \
| wc -c
Then open the same page in a browser, open the developer console, and ask for the rendered text length in the same units:
document.body.innerText.replace(/\s+/g, " ").trim().length
Divide the first number by the second. If the result is near 1.0, your content is in the raw HTML and the agent sees what you see. If it is near zero, your homepage is a shell, and everything you have built on it, structured data included, is on the wrong side of the gap.
The even quicker check needs no terminal at all. Open the page, use "view source", and search for a sentence you know appears on the page. If it is not in the source, it is not in the first fetch.
What fixes it
The fix is server rendering or prerendering for the routes that matter commercially, not a script tag that promises to help at runtime, because a runtime patch runs on exactly the side of the gap the agent never reaches. Most frameworks now support rendering on the server or at build time; the work is in moving the routes that matter to that mode and keeping them there through the next deploy. It is the most expensive item on a typical report and the one with the largest score movement, which is why our implementation service scopes it against architecture rather than page count.
If a full move is not feasible, prerendering the homepage and the handful of pages an agent is most likely to fetch, pricing, product, docs and contact, moves the check that measures those pages. The scanner measures A7 on the homepage, so that is where to start.
Check your own site
The free scan runs both fetches against your homepage and reports the ratio with the raw and rendered text lengths beside it, so you can see the gap rather than take our word for it. A7 is defined in full under discovery and access on the methodology page.