AI Assistants and JavaScript Rendering: What SEOs Need to Fix
Andre Alpar tested whether AI assistants render JavaScript during grounding. The results show why raw HTML, server logs, and SSR matter for AI search visibility.
TL;DR: On June 16, 2026, Andre Alpar published a server-log test of 12 AI assistants. Six major US assistants (ChatGPT, Claude, Gemini, Perplexity, Meta AI, Microsoft Copilot) answered grounding prompts from the raw HTML decoy and never used the JavaScript-rendered value. Five non-US assistants (DeepSeek, ERNIE, Qwen, Kimi, Mistral) executed the script and reported the rendered value. Grok ran the JavaScript and then answered from the decoy anyway.
The headline you should take away is not "AI assistants cannot render JavaScript." It is "your server logs will tell you what each assistant actually saw, and your chatbot screenshot will not."
The phrase "Google can render JavaScript, so we are covered" is doing a lot of damage right now.
The old JavaScript SEO rule was simple enough: make sure Google can render the page. That rule is still true. It is just incomplete for AI search visibility.
It is true for Google Search. Googlebot queues pages, runs them through a headless Chromium pipeline, and indexes the rendered HTML. Martin Splitt has repeated that on record for years. Google's own JavaScript SEO basics documentation walks through the crawl, render, index loop in detail.
It is not true for every AI assistant that grabs your page when a user asks it a question. The retrieval path that ChatGPT, Claude, Perplexity, Copilot, or Gemini uses to ground a live answer can be much thinner than Googlebot, and the gap can quietly remove your content from the answer.
That gap is what Andre Alpar measured in a Search Engine World experiment dated June 16, 2026. His result is sobering, but the methodology is the part SEOs should copy.
Server Logs Beat Chatbot Self-Reports
Before the test mechanics, the core lesson.
In Alpar's run, Perplexity told the user in chat that it could not access the test URL. The server log showed PerplexityBot fetched that exact URL and received HTTP 200. The crawler did the work. The chat layer said the opposite.
That single mismatch should change how you debug AI visibility this quarter.
If you only test AI assistants by prompting them and reading the reply, you are letting the model self-describe its behavior. That is not evidence. It is a guess.
The trustworthy artifact is the request log on your origin: the URL, the user agent, the status code, the response size, the time, and whether the assistant later cited the page accurately. Everything else is weaker evidence.
That principle, "trust the log, not the chatbot," is the actual takeaway from this test. The rendering result is the news hook. The trust result is the operational fix.
How The Decoy Test Actually Worked
Alpar built a three-layer page for each of 12 assistants.
- A secret URL the assistant had never seen before.
- A decoy value written directly into the raw HTML.
- An external JavaScript file that, when executed, fetched a second endpoint and replaced the decoy with the real value.
The smart part of the design is the second endpoint. The real answer was not sitting in the HTML response. It was not visible by reading the JavaScript file as text either. To see the true value, a system had to actually run the script and make a follow-up request. That cleanly splits three behaviors that get conflated in most "does AI render JS" debates:
- Did the assistant fetch the HTML page?
- Did the assistant fetch the linked JavaScript file?
- Did the assistant execute the JavaScript and use the resulting value?
A bot can do step one and stop. It can do steps one and two and still ignore the result. Only the execution endpoint proves that the rendered DOM was actually consumed. The server log captured all three signals at once.
Result: Six Major US Assistants Stopped At Raw HTML
Here is how the 12 assistants behaved in the test.
| Behavior in the test | Assistants | What this means for your content |
|---|---|---|
| Executed JavaScript and reported the rendered value | DeepSeek, ERNIE, Qwen, Kimi, Mistral | These pipelines saw the value that only existed after script execution. |
| Executed JavaScript but still answered from the raw HTML | Grok | One subsystem reached the execution endpoint, yet the answer used the decoy. |
| Answered from raw HTML only | ChatGPT, Claude, Gemini, Perplexity, Meta AI, Microsoft Copilot | Content injected by JavaScript would not exist in this retrieval path. |
The geographic split is interesting on its own. Four Chinese assistants and one European assistant rendered. The major US assistants did not. But geography is not the lesson. The lesson is that the user-triggered grounding path on the assistants most North American teams already optimize for is, in this snapshot, a raw-HTML reader.
That makes this a technical SEO problem, not only an AI content problem. If the important content is not in the first HTML response, the assistant may never reach it.
A few important caveats before anyone calls it a universal rule:
- This was a single-pass, live-fetch test of user-triggered grounding. It is not proof that every background crawler, every training fetch, or every future product update will behave the same way.
- Vendors can change retrieval behavior at any time without announcement.
- "Did not render in this test" is not the same as "can never render anywhere."
Vercel's own analysis of AI crawler traffic reached a similar conclusion from a different angle: assistant crawlers may fetch JavaScript assets, but fetching is not executing, and assistant answers can quietly drift from cache or training memory. Glenn Gabe documented a matching field pattern in his AI search JavaScript rendering case study, where client-side rendered content was harder for ChatGPT, Perplexity, and Claude to surface.
Googlebot Is Not The Same As Grounding
The most common bad reading of Alpar's test is "Google cannot render JavaScript." That is wrong, and it will lead teams in the wrong direction.
Google Search is an indexing pipeline. It can defer rendering, retry it, batch it, render with the Web Rendering Service over time, and use the rendered HTML for indexing decisions. Google still recommends server-side rendering and pre-rendering for performance and reliability, but its own documentation is explicit that JavaScript-generated content can be indexed.
Live AI assistant grounding is not the same pipeline. It is a request that happens when a user submits a prompt. It has tight time budgets, different infrastructure, and different decisions about whether running a browser is worth the cost. The two paths can give you very different answers about the same URL.
Here is the cleanest way to phrase it to a developer or product manager:
Google Search rendering is a background indexing process. AI assistant grounding is a live read. They can disagree about your page even when both succeed.
Four Retrieval Layers You Need To Audit Separately
"AI crawler" is a useless category for diagnostic work. There are at least four distinct retrieval layers, and each behaves differently.
| Retrieval layer | What it represents | Common failure mode |
|---|---|---|
| 1. Human browser | Rendered DOM after JS, hydration, CSS, and interaction. | The page looks perfect while raw HTML is essentially empty. |
| 2. Google Search rendering | Googlebot plus the Web Rendering Service indexing pipeline. | Rendering is delayed, throttled, or skipped on resource-heavy pages. |
| 3. Background AI crawlers | Examples include GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot. | Each crawler has its own scope and rendering behavior; many do not execute JS. |
| 4. User-triggered assistant fetchers | Examples include ChatGPT-User, Perplexity-User, similar live fetchers. | Often raw-HTML reads, often ignore robots.txt, often misreport in chat. |
OpenAI's own crawler documentation makes this split explicit. GPTBot is the training/utility crawler. OAI-SearchBot powers search-style surfacing inside ChatGPT. ChatGPT-User is the user-triggered fetcher that visits a page when a user asks for it, and OpenAI states it is not used for automatic crawling or to decide whether content appears in Search.
Perplexity's crawler documentation draws the same line. PerplexityBot is for indexing and linking. Perplexity-User handles user-requested fetches, and because it is user-triggered, Perplexity says it generally ignores robots.txt.
If you debug all four layers with one ChatGPT screenshot, you are not debugging. You are guessing.
What Content Vanishes When JS Is The Only Delivery Path
This is where the technical issue becomes a content issue.
If your important facts are injected by client-side JavaScript, the assistants in the raw-HTML group of Alpar's test cannot use them to ground an answer. The list of vulnerable surfaces is uncomfortably long for most production sites:
- Product titles, descriptions, and specs that hydrate after route load.
- Pricing, discounts, and stock availability fetched from an API.
- FAQ accordions that only render after a tab click.
- Comparison tables built by a client-side framework.
- Customer reviews and rating snippets pulled from a third-party widget.
- Internal links inside hydrated components that never appear in raw HTML.
- Author bios, credentials, and trust signals injected by a CMS plugin.
- JSON-LD schema added by a tag manager after page load.
- Tabbed or filtered content that only exists once a user interacts.
That hits ecommerce product pages, SaaS pricing pages, comparison pages, documentation portals, marketplaces, and local-service pages especially hard. The content that is most likely to earn an AI citation is the content most teams hide behind interaction layers.
This is where "AI visibility" stops being a prompt-tracking exercise. Your content has to be good, but it also has to be delivered in a representation the retrieval system can actually read.
The Audit Workflow I Recommend This Week
You do not need a research budget to start. You need ten minutes per important page and access to the server logs.
Step 1. View Source on your top cited pages
Open your highest-value commercial and editorial pages. View Source. Search for the actual sentences and numbers you want assistants to cite.
If your H1, intro paragraph, prices, specs, comparison points, FAQ answers, or schema are missing from the raw HTML, flag the page.
Step 2. Run curl and confirm what the server actually sends
Use a single command from any terminal:
curl -L -A "Mozilla/5.0" https://www.example.com/your-page/ | lessThis is what a non-rendering reader receives. If a smart human cannot answer a basic question from this output, an assistant that does not execute JavaScript cannot either.
Step 3. Disable JavaScript and reload
Open the page in Chrome DevTools, open the command menu, type "Disable JavaScript," and reload. You are not perfectly simulating any specific assistant. You are looking for the failure mode of a text-first reader. If the page collapses into a skeleton, the page is at risk.
Step 4. Segment server logs by user agent
Pull the last 30 days of access logs and filter by the real bot user agents that matter for AI visibility. Separate them by intent.
| Vendor | Background indexer | User-triggered fetcher |
|---|---|---|
| OpenAI | GPTBot, OAI-SearchBot | ChatGPT-User |
| Anthropic | ClaudeBot, anthropic-ai | Claude-User class fetchers |
| Perplexity | PerplexityBot | Perplexity-User |
For each layer, log the URL, the status code, whether the linked JS file was requested, and whether any downstream API endpoint was hit. That tells you what every retrieval layer actually saw, not what a chatbot said it saw.
Step 5. Build your own canary
You do not need to copy Alpar's exact decoy design. You need one safe test URL where you can compare the value in raw HTML, the value in the rendered DOM, and the values that appear in actual assistant answers when you prompt with that URL. Track it for a few weeks. The pattern you find will outlast any single article.
What To Fix, And In What Order
The temptation after a test like this is to build a bot-only version of the site through dynamic rendering. Google's own dynamic rendering documentation calls it a workaround rather than a recommended long-term solution because it adds maintenance cost and can drift over time.
Fix delivery for users first. The same fix usually covers AI assistants.
| Symptom | Preferred fix | Why this works for AI visibility |
|---|---|---|
| Main copy is rendered only after hydration | Server-side rendering, static generation, or incremental static regeneration | Every retrieval layer reads meaningful HTML on first byte. |
| Pricing and stock are fetched after page load | Inject canonical price and availability server side, then refresh client side | Assistants can quote a price without running the app. |
| FAQ and product specs live inside accordions | Render full content in HTML, use CSS or progressive enhancement for UI | Answers are present even when interaction layers are skipped. |
| JSON-LD is injected by a tag manager | Output schema in the initial HTML response | Entities, products, FAQs, and breadcrumbs are visible to text-only readers. |
| Navigation depends on JavaScript click handlers | Use real anchor tags with crawlable href values | Discovery still works when the click handler never fires. |
Treat dynamic rendering as a compatibility patch for legacy stacks, not as the destination.
Why AI Visibility Is Now A Delivery Problem
Most AI visibility programs still live at the content layer: write tighter answers, add schema, build authority, request citations, monitor prompts. Those tactics still matter.
What Alpar's test exposes is the layer below all of that. If your best answer never reaches the assistant in the initial HTML response, the rest of the program cannot rescue it. A great paragraph hidden inside a React component is invisible to a raw-HTML reader. A great FAQ behind an accordion is invisible if the accordion never opens for the fetcher. A great product spec rendered by an API call is invisible if the call is never made.
This connects directly to other measurement and crawler questions I have written about, including how OpenAI's separate crawler agents change technical SEO audits, how Bing's first-party AI visibility reporting reshapes measurement, and why prompt-based trackers cannot replace server logs.
HTML is not a legacy concern. It is the floor of AI visibility.
The practical standard is simple: if a text-only reader cannot understand the page from the first response, assume at least some assistant retrieval paths will struggle too.
Bottom Line
You can keep your React stack. You can keep your hydrated UI. You can keep your interactive product configurator and your filterable comparison tables. None of that is the problem.
The problem is treating the first HTML response as a shell instead of as a document. For important pages, the first response should already carry the headline, the key facts, the prices, the specs, the schema, and the internal links. JavaScript can then enhance that document, not replace it.
And when an AI assistant tells you what it did with your page, do not write that down as evidence. Open the log and check.
FAQ
Do all AI assistants fail to render JavaScript?
No. In Andre Alpar's June 2026 test, five non-US assistants (DeepSeek, ERNIE, Qwen, Kimi, Mistral) executed the script and reported the rendered value. Six major US assistants (ChatGPT, Claude, Gemini, Perplexity, Meta AI, Microsoft Copilot) answered from the raw HTML. Grok executed the script and still answered from the raw HTML. The behavior also varies by retrieval path and can change over time.
Does Google Search render JavaScript?
Yes. Google Search uses a headless Chromium pipeline that can crawl, render, and index JavaScript content. The pipeline can be delayed or resource-bound, which is why server-side rendering is still recommended for important content, but Googlebot is not the same as a raw-HTML reader.
How do I know which AI assistants fetched my page?
Filter your server access logs by AI user agent and segment them by purpose. Treat background crawlers (GPTBot, ClaudeBot, PerplexityBot) separately from user-triggered fetchers (ChatGPT-User, Perplexity-User). Log status codes, request paths, and whether linked JavaScript or API endpoints were hit.
Is dynamic rendering the right long-term answer?
Usually no. Google frames dynamic rendering as a workaround for crawlers that struggle with JavaScript. For durable AI visibility, prefer server-side rendering, static generation, incremental static regeneration, or progressive enhancement so that important content is already present in the first response.
Should I trust a chatbot when it says it could or could not read my page?
No. Treat assistant self-reports as clues, not evidence. Perplexity reportedly told users it could not access Alpar's test page while server logs showed PerplexityBot fetched the URL with a 200 response. Use logs, canary URLs, and rendered-versus-raw comparisons to verify behavior.
About the Author
Francisco Leon de Vivero is VP of Growth at Growing Search, with 15+ years of SEO experience across ecommerce, adult, international, and enterprise search. He worked as SEO Lead at Shopify for more than seven years and spent more than four years working on SEO for Pornhub.