US AI Assistants Can't See Your JavaScript, and They Won't Tell You
Andre Alpar, a veteran SEO practitioner, ran a simple test on twelve AI assistants. He built a page where the real content loaded through JavaScript and planted a decoy placeholder value in the raw HTML. Then he asked each assistant to report what the page said. Every top-tier US system returned the decoy. ChatGPT, Claude, Gemini, Perplexity, Meta AI, and Copilot all read the bare HTML and reported the placeholder as fact. Four Chinese models and Mistral rendered the JavaScript and returned the real content.
This is one practitioner running one pass per assistant, in June 2026. Model behavior changes. But the result is specific enough to act on, and it exposes a failure mode most teams never check: what the AI sees of your page is not what your users see.
The Test, and What Broke
Six US systems failed the same way. They fetched the page, parsed the raw HTML, and stopped. JavaScript that would have replaced the placeholder with the real text never ran. The assistant reported the decoy with full confidence and no caveat.
Five systems passed: DeepSeek, ERNIE, Qwen, Kimi, and Mistral. They executed the page’s JavaScript and read the rendered output, the same content a browser shows a human.
Two edge cases are worth the detail. Grok executed the JavaScript but then ignored the rendered result, reading the raw HTML anyway. Copilot downloaded the script file but never ran it. As Alpar put it, downloading is not executing. Both behaviors land in the same place as the outright failures: the assistant returns content the user would never see.
The Decoy Problem
A blank result would be honest. The assistant would say it found nothing, and you would know something was wrong. The decoy is worse because it produces a confident, specific, wrong answer.
This matters for any page where content arrives after the initial HTML load. Single-page apps render almost everything in JavaScript. Product catalogs, pricing tables, documentation built on modern frameworks, dashboards, anything hydrated client-side. To a human with a browser, these pages are complete. To six of the most-used US AI assistants, they are skeletons with whatever placeholder text the framework shipped in the initial payload.
If an AI assistant is summarizing your pricing page, citing your documentation, or grounding an answer in your product copy, and that content loads through JavaScript, the assistant may be reading and repeating a value that exists nowhere on the page a customer sees.
The Self-Report Failure Is the Real Risk
The rendering blind spot has a known workaround: server-side rendering. The deeper problem has no easy fix, because the assistants misreport their own behavior.
In Alpar’s test, Perplexity claimed it could not access a page. The server logs showed Perplexity had fetched that page successfully. The system’s account of what it did contradicted what it actually did.
This breaks the natural defense. If you could ask an assistant “can you see the JavaScript-rendered content on this page?” and trust the answer, you could route around the limitation. You cannot trust the answer. The assistant that silently returns a decoy is the same assistant that will tell you it did or did not access a page, with the same unwarranted confidence. Self-reported capability is not a reliable signal of actual capability.
This connects directly to a pattern we have written about before in The AI Verification Debt: teams trust AI output they have not verified. Here the failure sits one layer earlier. It is not that the AI generated something wrong from good input. The input itself was wrong, and the AI had no idea, and could not tell you even when asked.
Why This Is an Input Problem, Not an Output Problem
Most AI governance work focuses on the output: is the generated code correct, is the summary accurate, did the agent do what it claimed. That work assumes the model saw the same thing a person would.
This test breaks that assumption at the source. The model’s view of your content is a degraded version of reality, and the degradation is invisible from inside the conversation. You can verify an output against a source only if you know what source the model actually read. When the model reads a JavaScript-blind version of the page and reports it as the real page, your verification is checking the output against the wrong baseline.
For agentic systems that fetch and ground on live web content, this is structural. An agent that browses, reads, and acts on what it finds is exposing the same blind spot at machine scale and machine speed. We have covered how agents game verification at scale; a fetch-and-ground agent that cannot render JavaScript and cannot accurately report what it fetched is a different version of the same governance problem, sitting on the input side.
It also reshapes how content needs to be built for AI discovery. The hard signals that AI search systems can actually parse are not the ones that look good in a browser, a point we made in AI search governance and hard signals. If the signal lives in JavaScript, six US assistants never see it.
Do This Now
Test your own pages. Pick the pages that matter for AI discovery and grounding: pricing, product, documentation, anything you want an AI assistant to cite correctly. Fetch each one with JavaScript disabled, or pull the raw HTML with a plain HTTP request, and read what comes back. That raw view is roughly what six top US assistants see.
If the content you care about is missing from the raw HTML, you have three moves. Server-side render or statically generate the critical content so it ships in the initial HTML. Add structured data and meta tags that carry the key facts outside the JavaScript layer. And stop trusting any assistant’s self-report of what it accessed; verify against your own server logs and your own raw-HTML view, not against the model’s account of its work.
The assistants will not tell you they are blind. The fix starts with checking for yourself.
This analysis synthesizes Do AI Assistants Actually Render Your JavaScript When Grounding? (Search Engine World, June 2026), an independent single-run test of twelve AI assistants by Andre Alpar.
Victorino Group helps engineering teams govern what AI systems read and act on, not just what they produce. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation