If you are looking for a straight answer on which AI crawlers execute JavaScript, you will find the same table repeated across dozens of articles. Google renders, Apple renders, everyone else does not.
That table traces to a single independent experiment published in December 2024, and almost nobody citing it says so. Twenty months later it is still quoted as though the AI companies confirmed it. They did not. Most of them have never addressed the question at all, and the study it comes from tested fewer crawlers than the conclusion implies.
Here is what is actually on the record, separated from what has only been observed.
What the vendors actually document
Three organisations address rendering at all. The rest are silent.
| Crawler | Vendor documents rendering? | What the docs say |
|---|---|---|
| Googlebot | Yes | Crawls, queues for rendering in headless Chromium, then indexes |
| Applebot | Yes | ”Applebot may render the content of your website within a browser” |
| GPTBot, OAI-SearchBot, ChatGPT-User, OAI-AdsBot | Not addressed | Bot docs cover purpose and robots.txt only |
| ClaudeBot, Claude-SearchBot, Claude-User | Not addressed | Docs cover robots.txt and crawl-delay only |
| PerplexityBot, Perplexity-User | Not addressed | Docs cover purpose and user agents only |
| CCBot (Common Crawl) | Yes, documents the negative | ”Currently, JavaScript is not executed and Cookies are not used” (FAQ) |
Google’s JavaScript SEO basics describes a three phase process: crawl, render, index. Googlebot queues every page returning a 200 status for rendering, then a headless Chromium instance executes the JavaScript. Worth noting for anyone assuming rendering is instant: Google says a page “may stay on this queue for a few seconds, but it can take longer than that.”
Apple’s Applebot documentation is briefer and hedged. The word is “may”, not “does”.
For OpenAI, Anthropic and Perplexity, I read the current bot documentation for each. OpenAI, Anthropic and Perplexity all describe what their crawlers are for and how to control them with robots.txt. None mentions JavaScript, rendering, or headless browsing. The absence is consistent enough to look deliberate.
What has been measured rather than documented
The evidence everyone actually relies on is Vercel’s The rise of the AI crawler, published 17 December 2024. Vercel found that OpenAI, Anthropic, Meta, ByteDance and Perplexity crawlers do not render JavaScript, and that ChatGPT’s and Claude’s crawlers fetch JavaScript files without executing them.
The headline numbers are worth quoting carefully. On Vercel’s nextjs.org sample, ChatGPT’s crawler pulled JavaScript on 11.50% of its requests and Claude’s on 23.84%, and neither ran any of it. Note the site: a JavaScript framework’s documentation is close to the worst place to measure a crawler’s JavaScript-fetch ratio, so read those percentages as evidence that the crawlers fetch scripts at all, not as a rate that transfers to your site.
That finding is credible and it is the best public evidence available. Three caveats belong with every citation of it:
- It is an observation, not a commitment. Nothing stops any of these companies from shipping a renderer next quarter without announcing it.
- It predates crawlers that now exist. OpenAI’s current documentation lists OAI-AdsBot, which validates pages submitted as ads. Anthropic now lists Claude-SearchBot alongside ClaudeBot and Claude-User. Neither appears in a December 2024 dataset, because neither existed.
- It tested eight operators, not the field. The study covered OpenAI, Anthropic, Meta, ByteDance, Perplexity, Google, Apple and Common Crawl. It did not test DeepSeek, Grok, Bing Copilot or Mistral. The line you will read everywhere, that no AI crawler renders JavaScript, is Vercel’s own summary rather than a downstream distortion, and it generalises past the eight operators actually observed.
The page carries no update note or revision date. It still reads as published in December 2024, which is exactly how it should be cited.
So the honest version is this: two vendors document that they render, one documents that it does not, six say nothing at all, and a single experiment from late 2024 covering part of the field is doing all the remaining work.
Why this breaks sites in a specific way
The failure mode is not subtle degradation. It is total absence.
A crawler that does not execute JavaScript receives your initial HTML response and nothing else. If your page ships a near empty container and fills it from an API, the crawler sees the empty container. Not a partial product listing. No product listing.
This lands hardest on:
- Ecommerce. Prices, stock status and variants are the fields most often loaded client side, and the most decisive when someone asks an assistant to compare options.
- Single page applications. If routing is client side, the routes may not exist as fetchable URLs at all, so there is nothing to crawl in the first place.
- Anything behind an interaction. Content revealed by a tab, accordion or “load more” click is invisible to something that never clicks.
The compounding problem is that this is silent. Nothing errors. Your analytics look normal. You simply do not appear in answers where competitors do, and there is no dashboard anywhere telling you why.
How to test your own site
Three methods, in ascending order of rigour.
Disable JavaScript and reload. In Chrome DevTools, open the command menu with Ctrl+Shift+P, type “Disable JavaScript”, then reload. What survives is roughly what a non-rendering crawler receives. This takes ten seconds and catches most problems.
Fetch the raw HTML. Run curl -s https://yoursite.com/your-page | less and read what comes back. This is exactly the bytes a crawler gets before any script runs. Search it for a phrase that should be in your main content. If the phrase is missing, so is your content.
Run a rendering beacon. For a definitive per crawler answer, serve a page whose JavaScript requests a second URL, then check which user agents requested it. One trap makes the difference between a real result and a wrong one: build the beacon URL at runtime by assembling it from fragments, rather than writing it as a literal string in the script. Vercel’s finding that crawlers download JavaScript without executing it means a bot can parse your script as text and follow any URL it finds there. If your beacon URL is a literal, you will record rendering that never happened.
What to do about it
The fix is not to abandon your framework. It is to make sure your important content exists in the initial HTML response.
Server-side rendering generates complete HTML before it reaches the client. Next.js, Nuxt and SvelteKit all support it directly, and it solves the problem for every crawler at once regardless of what each one can execute.
Static site generation goes further by pre-building pages as files. For content that does not change per user, this is the most robust option available and the cheapest to serve.
Progressive enhancement is the discipline underneath both. Ship meaningful HTML, then layer JavaScript on top for interactivity. A product listing that renders server side and is then enhanced with client side filtering works for crawlers, for screen readers, and for anyone on a bad connection.
Whichever you choose, the acceptance test is the same one from the section above: disable JavaScript, reload, and confirm your content is still there.
The short version
Google and Apple document that they render. Common Crawl documents that it does not. OpenAI, Anthropic and Perplexity do not address it at all, and the widely repeated “no” for those three traces back to one Vercel experiment from December 2024 that predates several crawlers now in the wild and never tested several assistants that were.
That uncertainty is an argument for server-side rendering rather than against it. If you cannot get a straight answer from the vendor, and the vendor can change behaviour without telling you, the only durable position is content that does not require anyone’s renderer to be readable.
Test your own pages with JavaScript off. It takes ten seconds, and it is the only answer that is definitely current.
If you want to know whether AI engines are actually citing your pages once they can read them, that is what Fokal measures. Related reading: AI crawler access, which covers the separate question of which crawlers you should let in at all.