Does AI render JavaScript

#What the test actually proved

This is not a new idea for search engineers, but it had been argument rather than evidence. Now it has been tested directly, and the evidence is uncomfortable for the large class of sites built as JavaScript applications that assemble their content in the browser.

#The experiment, in one paragraph

The test, run by Andre Alpar and published through CitationOne, was simple and hard to fool. The page served a decoy reference number in its raw HTML. The real number was substituted only by external JavaScript, fetched from a second endpoint. Each assistant was given a unique, unguessable URL, and the server logged three separate events: the page fetch, the JavaScript file fetch, and the call to the number endpoint. The logic is airtight. Return the real number and you executed the script. Return the decoy and you read only the HTML.

#Who read only the HTML

These assistants returned the decoy, meaning they grounded on raw HTML and never ran the script:

• ChatGPT
• Claude
• Gemini
• Perplexity
• Meta AI
• Microsoft Copilot

Grok executed the JavaScript on one node but still returned the decoy, so even where the script ran, the rendered value did not make it into the answer.

#Who did render JavaScript

Five assistants returned the real number, proving they executed the script:

• DeepSeek, ERNIE, Qwen and Kimi, all from China
• Mistral, from Europe

So JavaScript rendering by AI is genuinely happening. It is just that, for the major Western assistants most European businesses actually care about, it is the exception. The split is striking enough to plan around: build for the assistants your customers use, and today those read HTML.

#”But Google renders JavaScript”

This is the objection that derails the conversation, so deal with it head on. Yes, Googlebot renders JavaScript for the classic search index. That is a separate pipeline from AI-answer grounding, and the test is about the second one. A page can rank perfectly well in classic Google search on content that only exists after JavaScript runs, and still be invisible when ChatGPT or Perplexity fetches it to compose an answer. Treating “Google renders JS” as proof that “AI renders JS” is the mistake. The two systems behave differently, and the gap is exactly where AI visibility quietly leaks away.

#What this breaks in practice

The risk is concentrated in a recognisable set of patterns:

• Single-page applications that ship an almost-empty HTML shell and assemble the page in the browser.
• Prices, stock status, or specifications injected by JavaScript from an API after load.
• Content hidden behind client-side tabs, accordions, or “load more” that only fetches on interaction.
• Product or service descriptions rendered by a client framework with no server-side fallback.
• Reviews, ratings, and FAQ widgets embedded as third-party JavaScript.

If any of those carry the facts you want an AI to repeat, you are betting your AI visibility on rendering behaviour that six of seven Western assistants just failed.

#The boring fix, now confirmed for AI

The remedy is the rule classic SEO has repeated for a decade: put the load-bearing facts in server-rendered HTML. Static site generation and server-side rendering both satisfy it. The framework does not matter; where the HTML is assembled does. Render the content on the server, ship it in the initial response, and let JavaScript enhance rather than supply it.

You can verify your own site in a minute. Fetch a page without a browser and read what comes back:

curl -s https://your-site.example/your-page/ | less

If the headings, body copy, prices, specs, and the Schema.org JSON-LD are all in that raw response, AI assistants can read them. If the page is a thin shell that fills in after the script runs, that is your problem, and now you can see it.

#How our own stack handles this

We are not neutral here, because we made this bet on purpose. wppoland.com runs on Astro, which renders pages to static HTML at build time and serves them from the edge. Everything that matters is in the raw response: the body text, every heading, the FAQ, and the Schema.org JSON-LD. We checked it the same way the test did, by reading the raw HTML rather than the rendered page, and the content is all there before a single line of our JavaScript runs. JavaScript on our pages is enhancement, never the source of the content.

That is the same conclusion we reached the long way around in serving content to AI agents: clean, server-rendered, semantic HTML plus Schema is the one signal both classic crawlers and AI systems actually consume. This test is the cleanest evidence yet for that position. It is also why a GEO and LLMO programme has to start with how the page is rendered, not with clever metadata, because metadata an assistant never executes is metadata it never reads.

#Glossary

For readers who run a business rather than a build pipeline:

• Server-side rendering / static generation - the page’s HTML is assembled on the server (or at build time) and arrives complete in the first response.
• Client-side rendering - the server sends a near-empty shell and the browser’s JavaScript builds the page afterwards.
• Grounding - when an AI assistant fetches real pages to base an answer on facts rather than memory.
• Hydration - JavaScript attaching interactivity to already-rendered HTML; safe, because the content was there first.

#The honest takeaway

JavaScript rendering by AI assistants will probably improve over time, and the Chinese assistants plus Mistral show it is technically routine. But you do not get to publish for the assistants you wish existed. You publish for the ones your customers use, and in June 2026 the biggest Western assistants read raw HTML and stop there. The safe, boring, decade-old answer turns out to be the correct one for AI too: serve your facts in HTML the server already rendered, and treat anything that only appears after JavaScript as content the AI will not see.