Can ChatGPT and Other AI Assistants Read Content That Loads With JavaScript?
Many websites show their most important facts only after JavaScript runs in the visitor's browser. Pricing tables, product specs, review widgets and FAQ tabs are often filled in by scripts. Google has read that kind of content for years, so many SEO teams treat the problem as solved.
For AI assistants, it is not. The evidence points one way: for most AI assistants, if a fact is not in the HTML your server sends, it is not on the page. Google's AI Overviews and AI Mode are the likely exception, because they draw on Google Search's index. Yet even Gemini, when it read a link live, did not run scripts in a 2026 test.
The problem is also easy to miss. Standard web analytics count visits with JavaScript tags, so crawlers that skip JavaScript never show up in those reports. AI visibility platforms such as Genezio, Profound and Peec AI make the effect visible by testing assistants with buyer-style questions and tracking which pages the answers cite. They help you diagnose the problem and confirm a fix, but the fix itself is in how your pages are built. Our comparison of GEO solutions explains how the tools differ.
Why would JavaScript matter for AI visibility?
When someone opens a web page, the server first sends a file of HTML. This is the "raw HTML". On some sites, that file already contains all the text. This is called server-side rendering: the server builds the full page before sending it.
On other sites, the raw HTML is little more than an empty shell. The browser then runs JavaScript, which fetches the text and fills in the page. This is called client-side rendering. Apps built with frameworks such as React or Vue often work this way.
A human visitor sees the same result either way. A program that does not run the scripts sees only the shell.
AI assistants reach your pages in two main ways:
- Crawlers visit pages in the background, on their own schedule, to collect pages for training or for the assistant's search index.
- Live fetches happen when a user pastes a link or the assistant runs a web search while answering. The assistant reads the page on the spot. Our guide to query fan-out explains why assistants run their own searches before answering.
An assistant can only cite what it actually received. So the question is whether either path runs your JavaScript.
Do AI crawlers run JavaScript?
The most widely cited public look at this comes from server logs. In December 2024, Vercel, a web hosting company, and the consultancy MERJ analysed crawler traffic across Vercel's network. Their conclusion was direct: "none of the major AI crawlers currently render JavaScript."
To "render" here means to run the page's scripts the way a browser would and read the resulting text. The crawlers observed not doing this included:
- OpenAI's three bots: GPTBot, OAI-SearchBot and ChatGPT-User
- Anthropic's ClaudeBot
- PerplexityBot
- Meta's and ByteDance's crawlers
ChatGPT's and Claude's crawlers did download script files: about 12% and 24% of their requests, respectively. But they did not run them.
Two crawlers in the study did render JavaScript: Google's Gemini, which uses Googlebot's infrastructure, and AppleBot.
The AI companies do not document this; OpenAI's crawler documentation, for example, says nothing about JavaScript. The evidence comes from outside testing in late 2024, so it is not a permanent rule.
What about when a user asks an assistant to read a link?
A live fetch, when a user pastes a URL and says "summarise this", could behave differently from a crawler.
A controlled test published by Search Engine World in June 2026 checked exactly this. The setup was simple:
- The raw HTML showed a fake "internal reference number".
- A script replaced it with the real number, loaded from a separate address.
- Each of 12 assistants got its own unique URL and the prompt: "Summarize this page and report the internal reference number."
- Server logs recorded what each assistant actually requested.
An assistant that reported the fake number had read the raw HTML only. ChatGPT, Claude, Gemini, Perplexity, Meta AI and Microsoft Copilot all did. Grok did too, even though one of its servers ran the script. A few assistants did use the script's result, including Mistral and several Chinese assistants. The author summed up the result as "the entire US top tier reads raw HTML only."
The author states the limits. The test used one site, one prompt per assistant and one pass, at one point in time. It covered only the live "read this URL" path, not background crawlers.
A real-world case points the same way. In August 2025, SEO consultant Glenn Gabe described a client site that was rendered entirely in the browser. The site did not block AI bots. Yet ChatGPT, Perplexity and Claude all failed to read its pages. Pages from sites that did not depend on JavaScript were read without trouble.
So is Google the exception?
Partly. Google's Search crawler, Googlebot, does render JavaScript. Google's JavaScript SEO documentation says a headless Chromium browser runs the page's scripts, and Google uses the rendered result to index the page.
Google's AI Overviews and AI Mode draw on that same index. Google's guidance on AI features says a page only needs to be indexed and eligible to appear in Search with a snippet. There are no extra technical requirements.
Our inference from those two documents is that content added by JavaScript can reach AI Overviews and AI Mode once Google has rendered it. No public test has confirmed this directly.
But Gemini's live page read did not run the script in the 2026 test. The same split appears at Microsoft. Bing's crawler has run JavaScript using Microsoft Edge since 2019, yet Copilot's live page read did not.
What this means: the deciding factor is the path an assistant uses to get your page, not the company behind it. Because you rarely control which path is used, the safe assumption is that an assistant sees raw HTML only.
How do you check whether your pages are affected?
The test is whether your key facts are in the HTML before any script runs. This practical procedure is a checklist, not a tested method.
- List the facts you want AI to use. Think of prices, plan limits, specs and answers to common questions. Check tabs, accordions and review widgets closely.
- Look at the raw HTML. Use "View page source" in your browser, not "Inspect", which shows the page after scripts run. Or fetch the page with a command-line tool such as curl. Search for each fact. If it is there, it is visible, even on a JavaScript-heavy site.
- Turn JavaScript off and reload. Whatever disappears is content a non-rendering assistant would likely miss. Some tools automate this check across a site: Genezio's Website Analyzer says it checks whether content renders without JavaScript, and Profound's crawlability report flags JavaScript-heavy pages that AI bots cannot parse.
- Ask assistants to quote a specific fact from the URL. This is a quick sanity check, but do not rely on the assistant's own explanation. In the Search Engine World test, Perplexity said it "couldn't access" a page that the server logs showed it had fetched successfully. As the author put it: "Trust the server log, never the chatbot's claim."
- Watch the logs at scale. Your server or CDN logs record which bots request your pages, and some platforms read them for you. Profound's Agent Analytics tracks which AI bots access your content, when and how often. Peec AI's Crawl Insights shows which bots access which pages and the status codes they receive. Both connect to log sources such as Cloudflare and Vercel.
Logs have one limit: they show that a bot fetched a page, not what text it kept. A successful fetch of a client-rendered page still means the bot got only the shell, so steps 2 and 3 remain the direct test.
What should you change?
The fix is to move the facts you want cited into the HTML your server sends. Common ways to do this are:
- Server-side rendering: the server builds the full page for each request.
- Static generation: pages are built in advance as complete HTML files.
- Pre-rendering: the page is run through a browser ahead of time, and the finished HTML is what gets served.
Vercel, Search Engine World and Gabe all recommend this fix. Google's documentation also calls server-side rendering or pre-rendering "a great idea", noting that not all bots can run JavaScript.
You do not need to remove JavaScript. Client-side rendering is fine for interactive extras such as filters, configurators or animations. The rule is narrower: anything you want an assistant to read, quote or cite should be in the raw HTML, ideally near the top. Pricing, product and documentation pages are a sensible place to start.
Two cautions keep expectations realistic. First, making content readable is a precondition for being cited, not a guarantee. No source has measured how many citations a site gains by switching to server-side rendering. Second, access is the other half of the problem. A page in perfect HTML still cannot be read if robots.txt or a firewall blocks the assistant.
After you ship the change, track whether those pages start appearing in answers. Do it engine by engine, and run each prompt several times to separate a real change from normal variation. Profound and Peec AI run tracked prompts across assistants every day. Genezio instead simulates multi-turn conversations as customer personas and reports results per engine. All three report which sources the answers cite.
Citation data is most useful next to bot logs. A page that bots fetch but answers never cite deserves the raw-HTML check above.
The bottom line
Google rendering your JavaScript does not mean AI assistants will. Plan for raw HTML only: put the facts you want cited in the page your server sends. Then keep checking with server logs and citation tracking, not the assistants' own reports, because this behaviour can change without notice.