A June-2026 test by Search Engine World fed 12 AI assistants a page whose real answer was hidden behind JavaScript — and every major Western assistant read only the raw HTML and missed it. ChatGPT, Claude, Gemini, Perplexity, and Meta AI all reported the decoy value sitting in the unrendered markup. The practical takeaway is old advice with fresh proof: if a fact matters for getting cited by AI, put it in the HTML the server sends, not in script the browser has to run.
This is part of the crawlers and technical series. It assumes you already know that an AI engine has to reach a page before it can cite it; here the question is narrower — once it fetches the page, does it actually execute your JavaScript?
What did the JavaScript-rendering test actually do?
It used a decoy. The researchers built one page with a fake "internal reference number" written directly into the raw HTML, then used an external script to fetch the real number from a second endpoint and swap it in. The genuine value existed only after the code ran. Each of 12 assistants got a unique secret URL and one instruction: summarise the page and report the internal reference number. Server logs recorded three things — the page fetch, the script request, and any follow-up call for the real value — and a unique "canary" string proved a genuine fetch versus a hallucination.
That design separates three behaviours cleanly: did the assistant fetch the HTML, did it download the script, and did it execute the script. Reporting the decoy means it read raw HTML only; reporting the real number means it rendered.
Which assistants rendered JavaScript and which didn't?
A sharp geographic split emerged. The major US assistants returned the raw-HTML decoy; the Chinese systems tested and France's Mistral returned the JavaScript-injected real value.
| Assistant | Rendered JavaScript? | Value reported |
|---|---|---|
| ChatGPT | No | Decoy (raw HTML) |
| Claude | No | Decoy (raw HTML) |
| Gemini | No | Decoy (raw HTML) |
| Perplexity | No | Decoy (raw HTML) |
| Meta AI | No | Decoy (raw HTML) |
| Microsoft Copilot | Downloaded script, didn't execute | Decoy (raw HTML) |
| Grok (xAI) | Executed, ignored the result | Decoy (raw HTML) |
| DeepSeek, ERNIE, Qwen, Kimi, Mistral | Yes | Real (JS-injected) |
Two details are worth holding onto. Copilot uniquely fetched the script (through Diffbot) but never parsed it, so the rendered value never reached the answer. Grok executed the code yet still reported the decoy — its pipeline and its answer disagreed. All figures here are attributed to Search Engine World's June-2026 test; it is a single experiment with one page design, so read it as directional, not a benchmark, and expect behaviour to change as assistants add rendering.
Why does client-side rendering hide content from AI?
Because fetching a page and rendering a page are different jobs, and the second is expensive. Executing JavaScript at scale means running a full browser engine for every URL — far more compute than reading the HTML a server returns. So most retrieval pipelines do the cheap thing: fetch the HTML, parse the text, move on. Anything your page assembles after that — content loaded by a framework, injected by a tag manager, or fetched from an API on the client — simply isn't in the text they parsed.
For ChatGPT, Gemini, Claude, Perplexity, and Copilot, content injected by JavaScript effectively does not exist. If the fact isn't in the HTML the server sends, assume the engine never read it.
This is the same root cause behind the warning against building a separate, JavaScript-driven "AI version" of your site: if the real content only exists after rendering, the engine sees a shell. It's also why accessibility scores predict AI-parseability — a screen reader and a retrieval bot both want the meaning to be in the markup, not painted on by script.
How do I make sure AI can read my key content?
Get the facts into the server-rendered HTML, then verify it. Concretely:
- Server-side render (SSR) or statically generate the pages you want cited, so the core content is in the initial HTML response.
- Put citable facts in the markup — prices, specs, definitions, product attributes, and key claims belong in real text and structured data, not in a client-side fetch.
- Reserve JavaScript for enhancement — interactivity, personalisation, lazy-loaded media — not for delivering the answer itself.
- Check what a non-rendering reader sees. Disable JavaScript in your browser, or view the raw response (
curlthe URL, or "View Source" rather than the inspector), and confirm your headline facts are present. - Don't trust the assistant's self-report. In the test, one assistant claimed it "couldn't access" a page that the server logs showed it had fetched successfully. Behaviour is what logs show, not what the chatbot says — the same logic behind reading which AI bots crawl your site from your own server data.
Reachability isn't only about whether the bot is blocked at your CDN or allowed in your robots file — it's also about whether the content survives the trip from fetch to parse. A page can be fully crawlable and still hand the engine an empty shell. Confirming that your most-citable facts are in the raw HTML, across the engines that decide which brand gets cited, is exactly the kind of check Buffy Intel is built to keep watch on. Questions: [email protected].
