- Vercel's analysis of over 500 million GPTBot fetches found zero evidence of JavaScript execution. GPTBot requests .js files as plain text roughly 11.5% of the time but never runs them.
- Independent checks from MERJ, Passionfruit, and Oncrawl confirm the same non-execution pattern for ClaudeBot and PerplexityBot specifically, meaning this isn't a quirk unique to one lab's crawler.
- Google's crawlers are the one documented exception: Googlebot and Gemini-related fetches do render JavaScript, inheriting Google's long-standing rendering infrastructure built for classic search.
- For a client-side-rendered single-page application, this means the actual visible content can be effectively invisible to every major non-Google AI crawler, receiving an empty or near-empty HTML shell instead of what a human visitor actually sees.
- This is a separate, additional failure mode from the robots.txt and CDN/WAF access questions covered elsewhere on this site: a page can pass every access check (allowed in robots.txt, reachable past any CDN rule, returning a clean 200) and still be functionally unreadable if its content only exists after client-side JavaScript runs.
Confirming that an AI crawler can reach a page is necessary but not sufficient. If the page's actual content depends on JavaScript running after the initial HTML loads, reaching it and reading it are two different problems, and the evidence says most AI crawlers only solve the first one.
Do the major AI crawlers actually execute JavaScript?
No, with one clear exception. Vercel's analysis of a large dataset, over 500 million GPTBot fetches, found zero evidence of JavaScript execution anywhere in that sample. GPTBot does request .js files directly roughly 11.5% of the time, but the same analysis found no indication those files are ever actually run; the requests look more like general crawling behavior than any rendering step. Independent checks from three separate sources, MERJ, Passionfruit, and Oncrawl, each report the same non-execution pattern specifically for ClaudeBot and PerplexityBot, meaning this isn't an idiosyncrasy of OpenAI's crawler alone; it appears to be the default behavior across the major non-Google AI crawlers.
Google is the documented exception. Googlebot and Gemini-related fetches do render JavaScript, which makes sense given Google's long-standing investment in a full rendering pipeline for classic web search, infrastructure its newer AI features appear to draw on rather than rebuild separately.
Why does this matter more than it sounds like it should?
Because a growing share of the modern web is built as a client-side-rendered single-page application, where the server's initial HTML response is often close to an empty shell, a <div id="root"></div> or equivalent, with the actual visible content generated entirely by JavaScript running in the browser after that shell loads. A human visitor never notices this, because their browser runs the JavaScript automatically and the page fills in within a fraction of a second. A crawler that doesn't execute JavaScript at all receives exactly that empty shell and nothing more, regardless of how well-written, well-structured, or extractable the eventual rendered content would have been.
That's a meaningfully different, and in some ways more severe, failure mode than the access problems covered elsewhere on this site. A page can pass a full three-layer access check (allowed in robots.txt, no CDN/WAF override, a clean 200 response code in server logs) and still be functionally unreadable to GPTBot, ClaudeBot, or PerplexityBot, because none of those three checks says anything about whether the content actually exists in the raw HTML response those crawlers receive.
What's the practical fix?
Server-side rendering (SSR) or static site generation, where the full, final HTML (including the actual content) is generated on the server and sent in the initial response, rather than assembled client-side after the fact. A crawler that doesn't execute JavaScript still receives the complete, real content in that case, because the content was never dependent on client-side execution in the first place. This is the same underlying architecture choice that already benefits classic SEO for the same reason (search crawlers, before Google's own JS-rendering investment, had the identical limitation), so a site built with SSR or static generation for other reasons is very likely already handling this correctly without having specifically targeted AI crawlers at all. A pure client-side-rendered SPA with no server-rendering layer is the configuration genuinely at risk here.
How would you actually check whether this is happening on your own site?
Fetch a page's raw HTML directly, without a browser rendering it, and compare what's actually in that response against what a human visitor sees in a browser. A simple curl request against the page, read as plain text, shows exactly what a non-rendering crawler receives. If the meaningful content is missing from that raw response and only appears after the browser runs the page's JavaScript, that's the gap: real to a human, invisible to GPTBot, ClaudeBot, and PerplexityBot, and only visible to Google's own crawlers among the major AI platforms.
Frequently asked questions
Do GPTBot, ClaudeBot, and PerplexityBot execute JavaScript?
No, per the available evidence. Vercel's analysis of over 500 million GPTBot fetches found zero evidence of JavaScript execution. Independent checks from MERJ, Passionfruit, and Oncrawl report the same pattern for ClaudeBot and PerplexityBot specifically: these crawlers fetch the raw HTML response and don't run any client-side script against it.
Does any major AI crawler execute JavaScript?
Google's own crawlers are the documented exception. Googlebot and Gemini-related fetches do render JavaScript, consistent with Google's long-standing general web-rendering infrastructure for classic search, which its AI features appear to inherit rather than build separately.
What does this mean for a single-page application (SPA) built with client-side rendering?
Potentially serious: if a page's actual content only appears after JavaScript runs in a browser, and a given AI crawler doesn't execute that script, the crawler may receive an empty or near-empty HTML shell instead of the real content. For GPTBot, ClaudeBot, and PerplexityBot specifically, that means a client-rendered page's visible content can be functionally invisible to them regardless of how well the content itself is written.
Does GPTBot ever request a site's JavaScript files at all?
Yes, but not to run them. Vercel's data found GPTBot requests .js files as plain text roughly 11.5% of the time, likely as part of general crawling rather than any rendering step, since the same analysis found no evidence those files are ever actually executed.
Sources referenced
- Vercel: GPTBot fetch analysis (500M+ fetches)
- MERJ, Passionfruit, and Oncrawl independent JavaScript-execution checks on ClaudeBot and PerplexityBot
For the full three-layer crawler-access check this issue sits alongside, see how to check AI crawler access. For the user-agent audit covering every major crawler's identity string, see GPTBot, ClaudeBot, PerplexityBot: how to audit your access logs.
