If AI retrieval bots don't execute client-side JavaScript, any page content that only appears after JS runs — common in single-page applications — is effectively invisible to them, regardless of how good the content is. This is testable with a purpose-built site and hasn't been tested rigorously in public. This page registers that experiment.
The most consequential unanswered technical question
Nearly every content-tactic question on this site is about optimization at the margin. This one is binary and foundational. If the answer is no, an entire category of modern web architecture, client-rendered SPAs, JS-injected content blocks, may be structurally excluded from AI citation, no matter what the content says. That's a much bigger deal than any single ranking factor.
What is known
Separate live-fetch tests found five major AI systems extracting only visible HTML during direct retrieval, ignoring information present only in JSON-LD structured data. That's a related, but not identical, question to whether JavaScript itself executes.
Do AI retrieval bots specifically execute client-side JavaScript to reveal dynamically-injected text content? Nobody has directly, publicly tested that with a controlled experiment yet.
CSR, SSR, and hydration, briefly
For readers less immersed in front-end architecture: client-side rendering (CSR) means a server sends a mostly-empty HTML shell plus a JavaScript bundle. The browser builds the actual page content by executing that JavaScript after load. That's the classic single-page-application pattern.
Server-side rendering (SSR) means the server itself executes the rendering logic and sends fully-formed HTML, with JavaScript then "hydrating" that markup to make it interactive. Static generation, this site's own approach, bakes the HTML at build time rather than per-request. A bot that doesn't execute JavaScript sees full content immediately under SSR or static generation, and sees only the empty shell under pure CSR. That's precisely the distinction this experiment's two page variants are built to isolate.
The classic-SEO precedent: Googlebot's own JS journey
This isn't a new question in web technology generally. It's a rerun, for AI bots, of a debate classic SEO already lived through with Googlebot itself. For years after JavaScript frameworks became common, Googlebot was widely understood not to reliably execute JavaScript. "Make sure your content is in the initial HTML" was standard technical-SEO advice.
Google eventually invested in a rendering pipeline that does execute JavaScript for indexing purposes. Even that solution introduced its own well-documented complication: a two-wave indexing process, where the initial crawl indexes the raw HTML and a second, delayed rendering pass picks up JavaScript-dependent content. That means even Googlebot's JS-rendered content can lag behind its raw-HTML content by a meaningful margin. Does any AI-search company make a comparable engineering investment for their own retrieval bots, which face different latency and cost constraints than a batch web-index crawler? That's exactly what this experiment is designed to find out empirically, not by analogy.
Experiment design
- 01 Build a test site Instrumented, controlled content
- 02 Vary rendering Server-rendered vs. client-only per page
- 03 Log every fetch Per bot, full request/response
- 04 Check citation Does content only in JS get cited?
- 05 Publish per-bot results Not a blended average
A small, purpose-built test site with matched pages: identical content, one version rendered server-side (visible in raw HTML), one requiring client-side JavaScript execution to appear. Server logs capture exactly what each bot fetches; citation checks confirm whether the JS-only content ever surfaces in an engine's answer.
A worked test-page example
Here's the design made concrete. One matched pair of test pages might both describe, in identical wording, a specific and citable fact, say, a made-up but plausible statistic used purely as a tracer, unique enough that any citation of it can be traced unambiguously back to this test site. The server-rendered version places that sentence directly in the initial HTML response. The client-only version withholds it, injecting the identical sentence into the DOM only after a JavaScript function runs following page load.
Both pages are otherwise indistinguishable to a human visitor. If an engine cites the tracer fact after querying a question the JS-only page answers, that's direct evidence the bot behind that engine executed the JavaScript. If it never does, despite querying the equivalent server-rendered page successfully, that's direct evidence it didn't.
Pre-registered hypotheses
| # | Hypothesis | Prediction |
|---|---|---|
| JS1 | Retrieval bots (OAI-SearchBot, PerplexityBot, Claude-SearchBot) do not execute JavaScript and never cite JS-only content | Supported |
| JS2 | Googlebot (feeding AI Overviews/AI Mode) does render JavaScript, unlike the non-Google retrieval bots | Supported |
If AI retrieval bots don't execute JavaScript, any content that only appears client-side is invisible to them — full stop, regardless of how good it is. This has never been directly tested with a controlled experiment. We're registering the one that would.
Share on XWhich architectures are most exposed
Suppose JS1 is confirmed. The sites most exposed are single-page applications built with a pure client-side rendering pattern and no server-rendered fallback, common in certain React, Vue, and Angular implementations that prioritize interactivity over initial-load content. Also exposed: any page that injects its primary text content via client-side JavaScript for reasons unrelated to interactivity, lazy loading, third-party widget embeds, client-side personalization logic that determines what text renders at all.
Sites already built with server-side rendering, static generation, or a documented hybrid approach would be unaffected regardless of the result, since their content never depended on client-side execution in the first place.
Mitigation options, regardless of the result
Notably, none of these mitigations are exotic or new. They're long-standing technical-SEO practices that predate AI search entirely, developed originally to address the identical concern for classic search crawlers. A site that already adopted one of them for that reason gets AI-citation eligibility as a side benefit, at no additional cost. A site that hasn't would face the same remediation work this experiment's confirmed result would recommend, regardless of the specific numbers it produces.
What this means for JS-heavy sites, if confirmed
A confirmed JS1 result would mean server-side rendering, or at minimum, a server-rendered content fallback, isn't just a performance best practice for JS-heavy sites. It becomes a prerequisite for AI citation eligibility at all. That's a much higher-stakes finding than most tactical GEO advice.
A five-minute check for your own site
Before this study publishes, you can run a rough version of it yourself. Fetch your own most important page with a plain HTTP request, no browser, and search the raw response for your key content.
If it's there, you're likely safe under this hypothesis, regardless of the final result. If it's missing, and only shows up when you load the page in an actual browser, that content is at risk exactly the way this experiment is designed to measure. Fixing it, via server-side rendering or static generation, costs nothing extra to try in the meantime.
Limitations
- A single test site's results may not generalize across every possible JS implementation pattern — this is a first, foundational test, not an exhaustive one.
- Bot rendering behavior could change without notice, making this a snapshot rather than a permanent architectural fact.
Namdev, R. (2026). Do AI crawlers render JavaScript? (v1). Retrieved from https://ritiknamdev.com/blog/do-ai-crawlers-render-javascript Published under CC BY 4.0 — reuse freely with attribution.
Relevant background in the schema RCT's live-fetch findings; see the schema study and the AI Bot Registry.