JavaScript is probably not your problem
Six per cent of the sites we scanned fail on client-side rendering. Nine per cent are refused at the door before rendering is even a question. The advice everyone gives is aimed at the smaller number.
·3 min read
Figures as of 9 September 2026, taken over 350 scanned sites. They move as scans arrive — the live version is here.
Every piece of writing about making a site legible to AI opens with the same advice: your content is behind JavaScript, crawlers do not run JavaScript, server-render it. It is real advice and it is not wrong. It is just aimed at a problem that, in our corpus, is a third the size of the one nobody mentions.
What we actually measure
We fetch the page twice: once as raw HTML with no execution, once through a headless browser that runs everything. Then we compare how much readable text exists in each. A site where the raw HTML carries almost none of the words is one where a client that does not execute scripts gets an empty document.
That check fails on 6% of sites, and warns on rather more. The framework era did most of this work already: Next, Nuxt, Astro, SvelteKit and Remix all server-render by default, and a large share of the web that people assume is a client-side app ships its text in the first response.
What the ranking actually is
Ordered by how often sites fail it, the list looks nothing like the advice:
- No agent manifest — 90%. Mostly fine, and we changed our scoring because of it. Why is a post of its own.
- No markdown or plain-text alternative — 77%.
- No reachable API or developer documentation — 61%.
- No llms.txt — 42%. Worth less than the people selling it say.
- Cache headers that make conditional requests impossible — 38%.
- A sitemap whose lastmod is the build date — 37%.
- Missing semantic landmarks — 25%.
- Duplicate titles or descriptions across pages — 24%.
- No structured data at all — 20%.
- An edge that refuses at least one AI client — 9%.
- Content that only exists after JavaScript runs — 6%.
Why the advice is shaped the way it is
Rendering is the problem that transferred cleanly from SEO. It was the crawler problem for a decade, everyone who writes about crawlers already knew the argument, and it needed no new evidence to repeat. The edge-refusal problem is newer, it is invisible from inside your own browser, and finding it requires deliberately asking your own site a question with a different name on the request.
Which is most of why we built this. Not because rendering does not matter, but because the check nobody runs is the one that finds the worst thing.
The order to work in
- Confirm nothing is refused. Five status codes, one minute, no tooling required.
- Confirm the words are in the first response. If they are, rendering is done and you can stop reading advice about it.
- Then the legibility work: structured data, a stable description, a plain-text alternative, honest cache headers.
One and two are usually an afternoon between them. Three is ongoing. Nearly everything published on this subject starts at three. The full check list and every weight is published, so you can disagree with the order.