Does AI render JavaScript

#Do AI assistants render JavaScript

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.

#How the AI JavaScript rendering test worked

The test, run by Andre Alpar and published on Search Engine World in June 2026, 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, and it appeared nowhere in the HTML or in the script source. Each of the twelve assistants was given its own unlinked, unguessable URL, so every server hit could be tied to one assistant, 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.

The fetch was user-triggered. Alpar pasted each URL into the chat by hand and asked the assistant to summarise the page and report the internal reference number, so the test measures what happens when a person hands an assistant a link, not what a background crawler does on its own schedule. He is explicit about the limits: it is “a single-pass, live-fetch test: one prompt per assistant, captured at one moment in time”, and background crawlers such as GPTBot and ClaudeBot “may well behave differently”. Read the result as a sharp snapshot of the live answer path in June 2026, not as a permanent property of each product.

#Which AI assistants read only raw HTML

In Alpar’s test, 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.

Three details from the server logs sharpen the picture. Among the US systems that did not render, Microsoft Copilot was the only one that downloaded the JavaScript file, through the third-party scraper Diffbot, but it never made the follow-up call for the number and reported the decoy. Gemini, which Alpar calls the surprise because it comes from Google, did not render either. Perplexity’s answer claimed it could not access the page, although its crawler had fetched it with HTTP 200, which is why Alpar’s advice is to trust the server log, never the chatbot’s account of what it did.

Glenn Gabe of GSQi repeated the question on five platforms and published the result on 19 October 2026. ChatGPT, Claude and Perplexity failed all three tests. Gemini and Copilot passed the first two: a page whose entire content loads through JavaScript, and a page with a static header and footer but JavaScript-loaded content. In the third test, a parallax site built on WebGL, Gemini read the content and Copilot did not. Gabe’s explanation is direct: “Gemini leverages Google’s search systems, so it can see content rendered via JavaScript.” He credits Copilot’s success to Bing’s search systems in the same way.

Both results can be true at once. Alpar gave each assistant a fresh, unlinked URL that no search engine had indexed, so Gemini and Copilot had to fetch the raw HTML like everyone else. Gabe tested existing sites that Google and Bing already knew, so Gemini and Copilot could draw on the version the search engine had rendered. For a new page, until a search engine renders it, the June result is the one that applies. ChatGPT, Claude and Perplexity read only the HTML in both tests.

#Which AI assistants execute JavaScript

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

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

DeepSeek on this list is the chat product. Suganthan Mohanadasan tested a different path from the same company, the DeepSeek search Fetch API, and wrote up the test on 19 October 2026. In the rendering test the fetcher loaded CSS but did not run JavaScript, load images or fire the XHR beacon, so content that needed the script did not appear in the result. It identified itself as Firefox/149.0 from AS136907 (Huawei Cloud, Hong Kong), with nothing naming DeepSeek, and fetched URLs blocked in robots.txt. The whole test, 110 API calls, cost about 0.08 USD. The DeepSeek chat and its page-fetching API are simply two different routes to your HTML, and in these tests only the first ran the script.

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 on a live fetch, and Gemini and Copilot see JavaScript content only through their search engine’s index. The split is striking enough to plan around: build for the assistants your customers use, and today those read HTML.

#What Vercel’s AI crawler study found about JavaScript

The June 2026 test is not the first measurement pointing this way. In December 2024 Vercel, working with MERJ, published an analysis of AI crawler traffic on its network and concluded that “none of the major AI crawlers currently render JavaScript”. ChatGPT and Claude did request JavaScript files, 11.50% and 23.84% of their fetches respectively, but did not execute them. In the month measured, GPTBot made 569 million fetches, Claude 370 million and PerplexityBot 24.4 million, against 4.5 billion for Googlebot across Gemini and Search. ChatGPT spent 34.82% of its fetches on 404 pages and Claude 34.16%.

Vercel named two crawlers that do render: AppleBot, through a browser-based crawler similar to Googlebot, and Gemini, because it uses Googlebot’s infrastructure. That second point conflicts with Alpar’s 2026 result, where Gemini returned the decoy. The two measurements look at different paths, background crawling across Vercel’s network versus a live fetch triggered by a user’s prompt, and the gap between them is the lesson: whether Google renders your page for its index tells you little about what Gemini reads while it answers a question. Vercel’s advice matches the rest of this article: render main content, meta information and navigation on the server, and keep client-side rendering for enhancement features.

#Does Google render JavaScript differently from AI

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 Google’s JavaScript SEO documentation says

Google describes its own pipeline in JavaScript SEO basics: JavaScript web apps go through three phases, crawling, rendering and indexing. Pages wait in a render queue before a headless Chromium runs their JavaScript, and Google says a page “may stay on this queue for a few seconds, but it can take longer than that”. The same page still recommends server-side rendering or pre-rendering, because it is faster for users and crawlers and because “not all bots can run JavaScript”.

That sentence is the bridge to AI assistants. Google says you can use JavaScript to generate JSON-LD and inject it into the page, and Googlebot reads it after the render step. Alpar tested a number in visible text, not structured data, but schema injected by a script reaches an assistant through the same mechanism, so an assistant that never runs the script never sees it. Google’s documentation is written for Googlebot. The AI answer layer is the “not all bots” case.

Google’s separate page on dynamic rendering, last updated on 10 December 2025, rules out the shortcut of detecting bots and serving them a server-rendered copy while users get the client-side version. Google calls that setup a workaround and does not recommend it, because it adds complexity and resource requirements, and points to server-side rendering, static rendering or hydration instead. Build-time prerendering, defined below, falls under static rendering, so every client, bot or browser, gets the same HTML.

#JavaScript patterns that hide content from AI

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.

#How to make JavaScript content visible to 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.

#Which user agents AI assistants use to fetch pages

The vendors document separate agents for training, search indexing and user-triggered fetches, and their robots.txt rules differ:

• OpenAI: GPTBot crawls content that may be used to train foundation models, OAI-SearchBot decides whether a site can appear in ChatGPT search answers, and ChatGPT-User fetches pages for user actions. ChatGPT-User is not used for automatic crawling, and because its actions are user-initiated, robots.txt rules may not apply. Each setting is independent, and OpenAI says a robots.txt change can take about 24 hours to reach search results.
• Anthropic: ClaudeBot collects training data, Claude-SearchBot indexes for search quality, and Claude-User fetches pages when a person asks Claude a question. Anthropic says its bots honour robots.txt and publishes its crawler IP list.
• Perplexity: PerplexityBot surfaces sites in Perplexity search and is not used for model training. Perplexity-User supports user actions and, because a user requested the fetch, generally ignores robots.txt.
• Google: Google-Extended is a robots.txt product token, not a separate crawler. It controls use for Gemini training and grounding, has no HTTP user agent of its own, and does not affect inclusion or ranking in Google Search.

None of these pages promises JavaScript rendering. In a second experiment, on robots.txt, Alpar found that only 3 of 12 assistants left a disallowed URL alone: ChatGPT as ChatGPT-User, Claude as Claude-User and Perplexity as Perplexity-User. Gemini arrived with a bare “Google” user agent, Copilot through Diffbot with a plain Chrome string, and Grok, DeepSeek, Qwen and Kimi with faked browser user agents. The practical consequence for rendering: you cannot reliably hand AI assistants a special pre-rendered version by sniffing user agents, so the HTML everyone receives has to carry the facts.

#How WordPress serves content to AI without JavaScript

A classic WordPress theme is on the safe side by default: PHP builds the page on the server, so posts, product descriptions and prices from the database are in the HTML before any script runs. The risk appears when content moves into client-side widgets, blocks that fetch data over the REST API after load, or a headless front end that renders only in the browser.

For interactivity, WordPress has an answer that keeps content on the server. The Interactivity API, introduced in WordPress 6.5, uses directives in a block’s markup, and its server directive processing lets WordPress generate the initial HTML with the correct state. The wp_interactivity_process_directives function finds the directives and uses the HTML API to rewrite the markup from the initial state and context. In the handbook’s example, a list built with data-wp-each and data-wp-text leaves the server as plain list items with the fruit names already filled in and no directives left. The page arrives complete, JavaScript adds behaviour afterwards, and an assistant reading raw HTML sees the same list a visitor does. The handbook gives the reason in its own words: the approach keeps “the SEO and performance benefits of traditional WordPress server-side rendering”.

#Static HTML with Astro for AI visibility

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.

#Server-side vs client-side rendering explained

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.
• Prerendering - running a client-side application at build time to capture its initial state as static HTML, as defined in web.dev’s Rendering on the Web. The same guide notes that crawlers can understand JavaScript, “but there are often limitations to how they render”.

#Should you wait for AI to render JavaScript

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.