Do AI crawlers run JavaScript? No, and it caps everything else
No. The major AI crawlers fetch raw HTML and do not execute JavaScript. Analyses of hundreds of millions of GPTBot requests by Vercel and MERJ found no JavaScript rendering by OpenAI's, Anthropic's, or Perplexity's crawlers; only Google's Gemini benefits from Google's rendering pipeline. If your content only exists after client-side rendering, most AI engines see an empty page, and no amount of content optimization on top will fix it.
Disclosure: BeCited audits check exactly this (server-rendered content is part of the CITE score's trust dimension), so we have a product interest in the topic. The external numbers below are from public analyses; the behavior is also directly testable on your own site, and we show how.
What do AI crawlers actually see?
They see what curl sees: the HTML your server returns, before any script runs. A joint analysis by Vercel and MERJ of over 500 million GPTBot fetches concluded that OpenAI's crawlers fetch JavaScript files but do not execute them. The same analysis found ClaudeBot and PerplexityBot behave the same way. The one systematic exception is Google: Gemini and AI Overviews sit on Google's index, and Googlebot has rendered JavaScript for years.
The consequence is blunt. A React or Vue single-page app that ships an empty <div id="root"> and builds the page in the browser is, to ChatGPT's and Claude's crawlers, a blank document with a title.
How do I test my own site in 60 seconds?
Fetch your page without a browser and look for your actual content in the response. If your product description, pricing, or article text appears in the raw HTML, AI crawlers can read it. If the body is a script tag and an empty container, they cannot.
Two checks that require no tooling:
- In the terminal:
curl -s https://yourdomain.com | grep "a sentence from your page". A match means the content is server-rendered. - In the browser: view source (not inspect element; view source shows what the server sent) and search for the same sentence.
BeCited's free audit runs this check on every page it measures and vetoes the trust dimension when content depends on JavaScript, because in our scoring a page AI bots cannot read has no citable surface at all.
Does this mean I have to abandon my framework?
No. It means rendering strategy, not framework choice, decides your AI visibility. Next.js, Nuxt, SvelteKit, Astro, and plain server templates can all serve full HTML on first response. What fails is client-only rendering: SPAs without server-side rendering or prerendering.
The fixes, in rough order of effort:
- Server-side rendering (SSR) or static generation for every page whose content should be citable: marketing pages, docs, blog, pricing.
- Prerendering as a fallback when you cannot adopt SSR: build-time HTML snapshots for public pages.
- Progressive enhancement for the interactive parts: ship the content as HTML, hydrate the widgets on top.
What does not work: serving crawlers a different page than humans (cloaking risks penalties in classic search and trust loss everywhere), and llms.txt files as a substitute for readable HTML (what llms.txt actually does).
Why is this the most damaging GEO mistake?
Because it is silent and it caps everything else at zero. A thin page can still be cited for the one thing it says well; a client-rendered page cannot be cited for anything, no matter how good the writing is. Every hour spent on content structure, schema, or entity signals is multiplied by whether the crawler can read the page at all. Rendering is the multiplicand.
It also explains a pattern we see in audits: sites that rank fine on Google (whose crawler renders) while being invisible to ChatGPT and Perplexity (whose crawlers do not). The team concludes AI engines dislike their brand; the real cause is that most engines never saw the content (why brands go missing on ChatGPT).
Run the free report to see the rendering check on your own domain, next to the rest of the citability audit.