Do AI crawlers render JavaScript?

Three tests, twenty months apart, one answer

This is not a theory anyone has to take on trust. It has been measured three times, by three unrelated parties, using three different methods, and the results line up.

Vercel went first. Working from crawler logs across its network, it published the numbers on 17 December 2024 and put the finding plainly: "none of the major AI crawlers currently render JavaScript", covering OpenAI’s GPTBot, OAI-SearchBot and ChatGPT-User along with Anthropic’s crawler. The detail worth keeping is the one that trips people up in a log review. Claude’s crawler does request JavaScript files, at 23.84% of its total requests. It just never executes them. So a log full of .js fetches is not evidence that anything got rendered, and a developer who checks the access log and reports back that the bot is loading the bundle has proved nothing at all.

Vercel also measured the size of each crawler against Google, on its own property. Googlebot made 4.5 billion fetches in a month. GPTBot made 569 million, Anthropic’s crawler 370 million, AppleBot 314 million and PerplexityBot 24.4 million. Those are one site’s figures rather than a market share, but the shape is useful: the AI crawlers are now a real fraction of who is reading your site, and the largest of them is reading it with scripting switched off.

Eight months later, Glenn Gabe ran the experiment from the other end. He took a site that was fully client-side rendered and asked the engines what they could see, in a case study published on 11 August 2025. ChatGPT answered that it could not read the content of the page because it relied on JavaScript-based rendering. Perplexity returned an access error despite there being no robots.txt block anywhere near it. Claude reported the URL came back without any visible content. Server-rendered control pages on other sites came back fine, which is what turns this from an anecdote into a test.

The visual tells in that study are worth memorising, because they are how you spot this from the outside without any log access at all. The site got a generic favicon instead of its own, because the favicon was being injected by script. Where it did appear, it was pushed into the "More" section in ChatGPT and the "Reviewed" section in Perplexity rather than cited as a primary source. And it showed a title with no snippet under it, because there was no text to take a snippet from.

The navigation experiment is the one to read

The most recent test is also the most specific, and it moves the problem somewhere most audits never look. Vinicius Stanula ran a 41-day controlled experiment on a Brazilian business directory of roughly 2,400 pages and published it in Search Engine Land on 19 August 2026. He split the navigation: 11 sections linked with ordinary HTML anchors, 10 sections linked by JavaScript injection. Same site, same content, same server, one variable.

GPTBot swept every HTML-linked page in a single day. Over 27 days it found zero of the JavaScript-linked ones. So did ClaudeBot, Bingbot, PerplexityBot, and Meta’s and Amazon’s crawlers. Not fewer. Zero. Googlebot, which does render, still only reached 2% of the JavaScript-linked pages, and while GoogleOther covered 48% of that hierarchy, GoogleOther is not the crawler that builds the search index.

Then he fixed it on day 27, converting the JavaScript links to real anchors, and the recovery is the part that should change how you sequence a fix. GPTBot picked up 250 previously unreachable pages in one sweep lasting under three hours. ClaudeBot, still visiting the site, never picked up a single one of the newly linked pages before the experiment ended. Googlebot barely moved by day 41.

Two things follow from that asymmetry. Recovery is not automatic and it is not uniform, so the cost of this defect is not simply the days it existed. And a fix verified against one crawler tells you nothing about the others, which is why checking "is it back in ChatGPT" and declaring victory is the wrong test.

Why ranking in Google proves nothing here

The sentence that keeps this problem alive inside companies is "we rank fine, so the bots can obviously read us". It sounds like common sense and it is wrong, for a mechanical reason.

Googlebot renders JavaScript, on a deferred pass, using an infrastructure Google has spent more than a decade building. Gemini inherits that infrastructure, which is why Gemini is one of the two exceptions on this page. GPTBot and ClaudeBot inherit nothing. They are HTTP clients that fetch a document and read it. There is no second pass, no queue, no headless browser waiting for hydration to finish. Whatever is in the response body is the whole of what they know about you.

So Google ranking and AI citation have stopped being the same measurement, and a site can sit comfortably on page one while being functionally absent from the engines people now use to build a shortlist. If you are working through why a weaker competitor keeps getting named ahead of you, this belongs near the top of the list, above content quality and well above link counts. It is also the failure mode that survives an access review: letting the right crawlers in settles whether a bot can reach the page, and says nothing about whether the page it reaches has any words in it.

The same logic applies to your structured data, and this one catches people who have done everything else right. If your JSON-LD is injected by a tag manager or written into the DOM by a framework after load, it does not exist as far as GPTBot is concerned. Schema only earns you citations when it is in the initial HTML response. Andrea Schultz made the same point in Search Engine Land on 19 August 2026, alongside the flat statement that none of the main AI crawlers render JavaScript: schema markup has to be delivered server-side in the initial response, and single-page applications with client-side content stay invisible.

The second bill: crawl waste

There is a quieter cost in the Vercel data that almost nobody audits for, and it changes how much your ordinary technical debt is worth fixing.

ChatGPT’s crawler spent 34.82% of its fetches on 404 pages and another 14.36% following redirects. Anthropic’s ran at 34.16% on 404s. Googlebot, on the same property, spent 8.22% on 404s and 1.49% on redirects. Roughly a third of what the AI crawlers do on a site is wasted against under a tenth for Google.

Read that next to the fact that these crawlers do not render, and a pattern appears. They are not sophisticated readers. They do not recover well from a messy site the way Googlebot has learned to. Broken internal links, stale sitemap entries and redirect chains that Google absorbs without complaint are, for GPTBot, most of the visit. Every dead URL it fetches is a real page it did not.

Which means the unglamorous half of technical SEO, the redirect map and the sitemap hygiene and the orphan pages, is worth more now than it was two years ago, and worth it for a reason that has nothing to do with rankings. The same argument applies during a replatform, where the redirect layer is the asset you cannot recreate afterwards.

How to check your own site in about ten minutes

Four checks, in this order. None needs a tool you do not have.

1. Read the raw response, not the page. Run curl -sL https://yoursite.com/your-best-page or open view-source in the browser. View-source shows the document as delivered. DevTools shows the DOM after scripts have run, which is the view that hides this problem, so do not use the inspector for this.
2. Search that raw response for your actual words. Take a distinctive sentence from the middle of the page body and look for it. Then look for your H1, your navigation links and your JSON-LD block. Anything missing from the raw HTML does not exist for an AI crawler.
3. Check that your links are links. Every navigation item, pagination control and faceted filter you want crawled has to be an anchor tag with a real href attribute. A div with a click handler is not a link. This is the exact defect Stanula isolated, and it is invisible in a browser because the click still works.
4. Ask the engines directly. Paste a URL into ChatGPT, Claude and Perplexity and ask each what the page says. This is Gabe’s method and it is still the fastest confirmation you will get. If the answers come back vague, generic or refusing, you have your result. Watch the favicon and the citation placement too.

Run those four on your three highest-value pages before you run them anywhere else. If the raw HTML is full, you can stop; this is not your problem and something else is. If it is close to empty, you have found the reason nothing else you tried worked, and no amount of citation measurement will improve while the page has nothing to cite.

What the fix actually is

Server-side rendering, static generation, or a prerender layer in front of the crawlers. That is the whole list. Every framework in common use supports at least one of them, and the work is a build configuration change far more often than a rewrite.

Three details decide whether the fix holds. Critical content has to be in the first response, which means the headline, the body copy and the primary calls to action, not just the shell around them. Structured data has to be rendered server-side with everything else, because schema written by a client-side tag manager is invisible to the crawlers that most need it. And navigation has to be real anchors, since discovery fails before rendering ever becomes the question.

What you should not do is build a separate stripped-down version of each page for bots. Serving materially different content to crawlers than to people is cloaking, it has been against Google’s guidelines for as long as the guidelines have existed, and the risk is not worth it when the supported fix is a rendering mode you already have.

One honest note on priority. If your site is server-rendered already, and most WordPress, Shopify, Webflow and plain HTML sites are, none of this applies to you and you can spend the attention elsewhere. This is a defect of single-page applications and heavily client-rendered React, Vue and Angular builds. It is worth ten minutes of checking precisely because the sites that have it usually have no idea, and the sites that do not have it can rule it out for good in one curl.

What we could not verify

No AI company publishes an official statement of how its crawler handles JavaScript. Every finding on this page is external observation of behaviour, which means it is accurate as of the dates given and could change without an announcement from anyone. That is a real limitation and worth re-testing your own site against rather than assuming this page stays true.

The Vercel fetch-mix and 404 figures come from one property, so treat the ratios as illustrative of the difference between AI crawlers and Googlebot rather than as your site’s numbers. The Search Engine Land experiment reports both that the AI crawlers found exactly zero JavaScript-linked pages and, separately, that JavaScript-linked pages were discovered 18% to 27% later than HTML-linked ones, and the article does not explain how those two measurements relate, so only the zero-discovery finding is used here. And Google’s own documentation on rendering is characterised above from Vercel’s and Search Engine Land’s reporting rather than quoted from Google directly.

Sources

Crawler rendering behaviour, fetch mix, monthly volumes and the 404 and redirect rates come from Vercel, The rise of the AI crawler, 17 December 2024. The client-side rendering case study is Glenn Gabe, AI Search and JavaScript Rendering, GSQi, 11 August 2025. The 41-day navigation experiment is Vinicius Stanula, JavaScript links can make your pages invisible to AI search, Search Engine Land, 19 August 2026. The server-side schema requirement is Andrea Schultz, Technical SEO for AI search: 4 fundamentals that matter, Search Engine Land, 19 August 2026.

Common questions