AI crawlers don’t run JavaScript.

The measurement

Vercel published a crawler study that instrumented real requests from the major AI agents, and the 2026 measurements that followed agree with it. GPTBot downloads JavaScript on roughly 11.5% of its requests and executes none of it. ClaudeBot downloads it on roughly 23.8% and executes none. Downloading a file is not the same as running it, and the distinction is the whole argument: these crawlers fetch the assets a page references and then do nothing with them.

Onely’s February 2026 analysis put a number on the cost. Across the sites they measured, 42% of JavaScript-rendered content never reached AI systems at all. For a fully client-side application the figure is not 42%, it is close to everything: the crawler receives a shell, a title, and a script tag.

Two exceptions matter. Google’s Gemini rides Googlebot’s rendering infrastructure, so it sees rendered content. Applebot renders too. Everything else in the list above does not.

Why this is a product problem and not a trivia question

A category of tools has grown up around a genuinely good idea: most people cannot get a developer to change their page templates, so apply the fix in the browser instead. Add a script tag, and titles, meta descriptions, schema and internal links get rewritten after the page loads. It is a real solution to a real bottleneck and it works for Google.

The same products now sell AI visibility monitoring, because that is where the category went. And the two halves cannot help each other. The schema block injected at runtime is not in the HTML that ClaudeBot received. The rewritten title is not in the HTML that PerplexityBot received. The dashboard will report your citation rate accurately, and the fix sitting next to it on the screen cannot change that number.

Nobody in that category says this out loud. It is not a conspiracy, it is an awkward fact about two features that were built at different times for different reasons and ended up on the same page.

The second fact: a fix you do not own is a fix you are renting

Search Atlas’s own documentation confirms that schema, meta changes and redirects applied through their pixel revert when the pixel is removed. Content changes and Business Profile updates persist, because those were written into systems the customer owns.

That is the tell, and it generalises. Whatever is written into your CMS survives cancellation, a billing failure, or a decision to bring the work in house. Whatever is injected at runtime disappears with the subscription. A year of SEO work that evaporates on churn was never an asset, and it should be priced as a service rather than sold as a fix.

How to check your own site in thirty seconds

Fetch the page the way a crawler does and read what comes back. If your content is not in that response, it does not exist for any of the engines listed above.

curl -sS -A "GPTBot" https://example.com/your-page | wc -c
curl -sS -A "GPTBot" https://example.com/your-page | grep -o "<title>[^<]*"

Or use the extractability checker, which does the same fetch and counts the words, the title, the description and the structured data that survive. It is free and needs no account.

What to do about it

• Render the pages you want cited on the server. Static generation or server-side rendering. This is the whole fix and everything else is a workaround.
• Write SEO changes into the CMS, not into a runtime script. The change then exists in the served HTML, is visible to every crawler, and is yours.
• Check that the crawlers are allowed in at all. Extractability is the second question. The first is whether robots.txt lets them fetch the page, and the answer is no more often than people expect.
• Stop treating an AI visibility dashboard as a fix. Measurement is a diagnosis. The treatment is crawler access, extractable content, entity clarity and mentions on sources the models already trust.

Questions