Do AI crawlers render JavaScript?

This is the shift that has changed JavaScript SEO more than anything in years. For a long time the reassurance was "Google renders JavaScript fine, so we're covered". That was always about one unusually capable crawler — and as more discovery moves to AI assistants and answer engines, it stops being enough, because those crawlers behave nothing like Googlebot.

Why AI crawlers don't render

Rendering JavaScript means running a headless browser for every page — an expensive, slow operation at web scale. Google built and operates that infrastructure over many years. The companies behind AI crawlers, for the most part, have not: their crawlers issue a single HTTP request, take whatever HTML comes back, extract the text, and move on.

A useful detail that makes the behaviour concrete: these bots sometimes download JavaScript without ever running it. Public crawl-data analysis has reported GPTBot fetching JavaScript files in roughly one in nine requests and ClaudeBot in roughly a quarter of requests, while executing none of it. Fetching is not rendering. The script arrives and is never run, so anything it would have produced never exists for that crawler.

AI crawlers are not one thing

Most explanations treat "AI crawlers" as a single category. They are not, and the distinction matters for both configuration and strategy. There are three broad types, and a single company often runs one of each.

The one thing they share is the constraint that matters here: with the Gemini exception below, none of them run your JavaScript. Whatever their purpose, they all read the raw HTML and nothing more.

Crawler by crawler

The major crawlers as of 2026, grouped by what each is for. This is a fast-moving area — vendors add crawlers and occasionally change behaviour — so treat this as a snapshot and verify against current data for anything load-bearing.

The Gemini exception

"AI crawlers don't render JavaScript" is very nearly true, and the nearly is important. Google's Gemini is the one major AI system that doesexecute JavaScript, because it inherits Googlebot's Web Rendering Service rather than using a separate crawler. It carries the same caveats that apply to Googlebot — the render queue, timeouts, the delay — but it can see client-rendered content that the others cannot.

This produces a genuinely confusing situation that sends people looking for answers: a client-rendered single-page app can rank on Google and show up in Gemini, while being completely invisible to ChatGPT, Claude and Perplexity. The same page, four AI engines, two entirely different outcomes — decided purely by which ones run JavaScript. If your content appears in one AI answer engine but not the others, this is usually why.

What client rendering actually costs you here

The cost is not a delay, the way it is with Googlebot. It is absence. There is no second pass to eventually catch up, so client-rendered content is not seen late — it is not seen at all.

The strategic rule that falls out of this is simple: optimise for the weakest reader, not the strongest. If you build for the crawlers that render JavaScript, you concede every crawler that doesn't — and because different engines cite different sources, conceding even one is a real loss of reach.

How to be visible to all of them

There is nothing AI-crawler-specific about the fix, which is the reassuring part. Everything that makes your content readable by a first-pass Google crawl makes it readable by AI crawlers too, because both come down to the same thing: is the content in the initial HTML?

Serve your real content through server-side rendering, static generation or incremental regeneration, so the main content, links and metadata are in the first response. Keep the crawlers unblocked in robots.txt — these bots honour it reliably, which means they honour your mistakes too, so an accidental disallow silently removes you. Beyond that, there is no special configuration and no per-bot workaround worth maintaining. Complete HTML serves everyone at once.

This is also why dynamic rendering is a poor answer for AI visibility: it keys off a user-agent allowlist that often doesn't include AI crawlers, so it leaves exactly these bots seeing the empty app. Server rendering needs no allowlist and covers all of them.

Where llms.txt fits

You may have seen llms.txt proposed as part of the answer. It is worth understanding precisely, because it solves a different problem than the rendering one. llms.txt is a file at your site root that points AI systems at your most important content in clean, structured form — a curated map, in the spirit of a sitemap for language models.

It is a genuine early-mover advantage and cheap to add. But it complements server rendering rather than replacing it: it helps well-formed content get found and understood, and does nothing for content that isn't in the HTML to begin with. Fix the rendering first so there is real content to point at, then add llms.txt to help the right crawlers make the most of it.

See exactly what an AI crawler sees

An AI crawler's view of your page is, almost exactly, the raw HTML your server returns before any JavaScript runs — which is precisely the first of the two fetches this tool makes. Run any URL and the raw pane is, for practical purposes, what GPTBot, ClaudeBot and PerplexityBot receive. If your content is there, they can read it. If the pane is an empty shell, they can't.