Client-Side Rendered Shells
The HTML ships an empty container and the words arrive later via JavaScript. A crawler that does not execute scripts reads nothing and moves on.
Find out whether AI assistants and search crawlers can reach, understand and quote your pages — with the raw evidence behind every result and no black-box score.
Built on Open Web Standards & Protocols
Four causes account for almost every failed check. All four are invisible in a browser, which is why they survive quarterly reviews.
The HTML ships an empty container and the words arrive later via JavaScript. A crawler that does not execute scripts reads nothing and moves on.
A WAF rule or a robots.txt line written for scrapers also stops GPTBot and ClaudeBot. The site looks fine in a browser and is invisible to everything else.
Without JSON-LD there is no machine-readable statement of who you are, what the page is about, or which question it answers — so an assistant has to guess.
The answer sits in paragraph nine. Extractable content states the conclusion first, structures it in lists or tables, and shows when it was last updated.
Pick a capability on the left, or scroll: the panel keeps the sample output for whichever one is in view.
$ aeolith check --domain example.com --agent GPTBot
// report excerpt — one row, trimmed
{
"check": "A2",
"status": "pass",
"evidence": "text_nodes_without_js=412/418",
"checked_at": "2026-09-28"
}
Three groups, five checks each. Every item is machine-verifiable, which is what lets a result be reproduced instead of argued about.
The full definition of each check — including what counts as evidence for a pass — is in the standard, and the methodology explains how a measurement is taken.
No account, and no JavaScript needed to read the result.
We fetch your public pages the way an AI crawler does — no JavaScript execution, no assumptions.
Fifteen checks, pass or fail, each with the response we received and the markup we parsed.
One concrete change per failure, per platform, written to be handed to whoever ships your site.
Run the same check again. The history shows the before and after on identical items.
Every figure below comes from the report rows in our own database — nothing is rounded up, and no customer logo appears anywhere on this site until a customer says it may.
8
Each one keeps its per-check rows: the response we received, the markup we parsed, the timestamp.
7.8/15
The distribution matters more than the mean, which is why a report shows all fifteen items.
6/8
Six of the eight sites we have checked were unreachable in practice. None looked broken in a browser.
12/15
We run the same fifteen checks on ourselves and leave the result public — including the three we still fail.
Three artefacts, all readable without an account — and all of them point at the evidence rather than at a score.
Every check with its raw evidence and the date we saw it. Plain server-rendered HTML that needs no JavaScript to read.
The specific change that turns each failure into a pass, grouped by platform, with the recheck that proves it.
Run the same check after you deploy. Same fifteen items side by side, so improvement is a recorded fact instead of a claim.
A score you cannot inspect is an opinion. Each check stores the same five fields, so a report can be re-examined instead of trusted.
We store the directive block that applied to the AI user agents we used, plus the status code the file returned.
The text-node count from the raw response and from the rendered page, so "renders empty" is a measurement rather than a guess.
The JSON-LD types we actually parsed, not whether the string application/ld+json appeared somewhere in the markup.
The visible date on the page and its machine-readable counterpart, recorded separately because they often disagree.
Status code, byte size, the moment of the fetch, the standard version and the engine version that judged it.
Not yet claimed: we do not store a cryptographic fingerprint of each fetched response today, so this ledger shows the responses themselves. When the SHA-256 digest is written per check, this section can honestly be called what the design calls it — a cryptographic trust ledger.
Longer explanations of the failures we see most often.
Short answers. Where a claim needs detail, it links to the page that carries it.
It means the assistants people ask for recommendations — ChatGPT, Claude, Gemini, Perplexity — can fetch your pages without running JavaScript, work out what you are and what the page answers, and quote a specific sentence from it. This check covers the fifteen things that decide whether that can happen, and records the evidence for each one.
An SEO audit optimises for a ranked list of links. This checks whether a machine can read and reuse your content: crawler access for AI user agents, text present in the raw HTML, valid structured data, an llms.txt, a heading tree, and a conclusion that comes first. Plenty of sites pass an SEO audit and still fail the reading checks.
No. You enter a domain and read the report. There is no account, no tracker on the report page, and no JavaScript needed to read a result — reports are plain server-rendered pages.
That is the failure this check is built to catch. If the text only exists after JavaScript runs, a crawler that does not execute scripts sees an empty shell. The report names the pages that rendered empty, and the repair guide gives the server-side rendering or prerender fix for your stack.
Yes. The same fifteen checks run the same way for every domain, and the leaderboard only lists sites whose owners opted in. Each report keeps its evidence, so two reports can be compared item by item instead of by an opaque number.
Occasionally. A firewall, a rate limit or a bot rule can block us the same way it blocks an AI crawler, and then the failure is real but the cause is infrastructure. The report says which response we received, so you can tell a blocked crawl from an unreadable page.
We publish the full definition, including what counts as evidence for a pass, in the standard. Every report links back to it, so the rule you failed is the rule you can read — and the methodology page explains how a check is measured.
These are our own numbers, taken from the same engine that scores your site. Nothing here is estimated or rounded up.
Fifteen items, the evidence behind each one, and the exact fix for the ones that fail. If a check cannot be measured, the report says so rather than guessing.