JavaScript SEO: What Googlebot Renders, What AI Crawlers Don't

Googlebot renders JavaScript. It uses a headless Chrome-based rendering system and, per Vercel and MERJ's research, fully rendered 100% of eligible pages tested. A separate joint study by the same two organizations tracked over 500 million GPTBot fetches and found zero evidence of JavaScript execution. The same held for ClaudeBot and PerplexityBot. A page built entirely on client-side rendering can rank on Google and be functionally invisible to every major AI crawler at the same time.

Does Google render JavaScript?

Yes, and thoroughly. Google uses a two-phase indexing process: an initial crawl of the raw HTML, followed by a rendering pass using a headless, evergreen Chromium-based engine that executes JavaScript much the way a real browser would. Vercel and MERJ's analysis of Googlebot's behavior found it fully rendered 100% of eligible pages tested, including complex client-side applications. Rendering isn't instant, though: the median gap between crawl and completed render was around 10 seconds in that dataset, the 90th percentile stretched to roughly 3 hours, and at the 99th percentile it reached as long as roughly 18 hours. That tail is the exception, not the typical case; most pages in the dataset rendered within seconds to minutes. A slow, JavaScript-dependent page doesn't fail to render on Google; it just gets indexed later than a fast one, and for the vast majority of pages that delay is measured in seconds, not hours.

Do AI crawlers render JavaScript?

This is where it diverges sharply from Google. A joint Vercel and MERJ study analyzing over 500 million GPTBot fetches found zero evidence of JavaScript execution. Not reduced execution, none.

These crawlers download the file and treat it as text, not as code to execute. A single-page application that relies on client-side rendering to inject its actual content (the pattern common in React, Vue, and Angular apps without server-side rendering) hands these crawlers an empty shell. Gemini is the one exception among AI systems, and specifically because it rides on Googlebot's own Web Rendering Service rather than running a separate rendering pipeline. The reason the gap exists at all isn't an oversight: AI crawlers work under tight fetch timeouts, often a few seconds per request, and running a full browser engine at the scale they crawl would be far more expensive than pulling raw text. Skipping rendering is a deliberate cost and speed tradeoff, not a temporary limitation these systems are racing to close.

How do I check what's actually in the initial HTML?

Two quick tests catch most cases. First, view page source (not "inspect element", which shows the post-render DOM) and check whether the real content is present in the raw response. Second, disable JavaScript in the browser and reload the page. Whatever disappears is exactly what a non-rendering crawler never sees. For Google specifically, Search Console's URL Inspection tool has a "View Crawled Page" option that shows the actual rendered HTML Google produced, which is the more precise check for that one crawler.

How do you test what a specific crawler actually sees?

The two checks above confirm whether content is rendered at all, but confirming visibility to a particular crawler takes one more step, and it's worth doing before assuming a fix worked.

• For Google: use URL Inspection's live test and open "View Tested Page." It shows the actual rendered HTML, a screenshot of what Googlebot saw, and any JavaScript console errors logged during rendering, which is the most direct evidence available short of checking Search Console's indexing status days later. Google's Rich Results Test offers a similar rendered view and is useful for a quick check outside Search Console, though its scope has narrowed as Google has retired some of its structured-data checks in 2026.
• For non-rendering AI crawlers (GPTBot, ClaudeBot, PerplexityBot, and similar): since none of them execute JavaScript, what they see is, for practical purposes, identical to what a plain HTTP request returns with no browser engine involved at all. Fetching a URL with a command-line HTTP client and reading the raw response body shows almost exactly what these crawlers receive. If the content that matters (the actual article text, product details, or answer content) isn't present in that raw response, it isn't present for GPTBot or ClaudeBot either, regardless of what a human sees in a normal browser tab.
• A quick differential check: compare the raw HTTP response against the browser's rendered DOM (view page source versus inspect element, as above) for the same URL. Content present in one but not the other is exactly the gap between what a rendering crawler sees and what a non-rendering one sees, made visible without waiting for either crawler to actually visit.

None of these tests require special tools or crawler access. They rely on the same distinction driving the whole problem: a rendering crawler processes a page closer to how a browser does, and a non-rendering one processes it closer to how a plain file download does. Testing against both perspectives directly is more reliable than inferring visibility from a framework's reputation.

What fixes this?

Server-side rendering (SSR), static site generation (SSG), or incremental static regeneration (ISR) all solve the same underlying problem: they put the actual content into the HTML response itself, before any client-side JavaScript runs. A crawler that never executes JavaScript still sees everything, because there's nothing left for JavaScript to inject. This isn't a JavaScript-avoidance argument. Interactive, JS-powered features are fine. The distinction that matters is whether the core content a reader (or a crawler) needs is present in the initial HTML, or only appears after a script runs client-side.

Does the specific framework matter?

Less than the rendering strategy does. A plain client-side React or Vue single-page application, with no server rendering step, produces an initial HTML response that's essentially an empty <div id="root"> until JavaScript runs. That's exactly the shell that non-rendering AI crawlers see, and nothing else. The same frameworks used with a server-rendering layer (Next.js, Nuxt, SvelteKit, Remix, and similar) produce a fully populated HTML response on the first request, because the framework itself runs the render on the server before sending anything to the browser. The framework name isn't the variable that determines crawler visibility; whether it's configured to render on the server or only in the browser is.

A quick way to tell which mode a given site is actually running in without reading its source code: view page source (not "inspect element") on any content-heavy page. If the real text and headings are present in that raw response, content-bearing routes are being server-rendered. If it's mostly empty markup and script tags, they're not, regardless of which framework built it.

What about hydration and partial rendering?

Modern frameworks increasingly mix strategies on a single page: server-rendered content that becomes interactive client-side (hydration), or a static shell with select components rendered dynamically at request time. This matters for JavaScript SEO because the crawler-visible content is whatever's present in that initial server response, not the fully hydrated, interactive version a browser user eventually sees. A page can legitimately have both a server-rendered article body (fully visible to any crawler) and a client-side-only comment widget or personalization block (invisible to non-rendering crawlers) without that being a problem, as long as the actual answer-bearing content lives in the part that's rendered server-side.

Newer patterns push this further. Streaming SSR sends a server-rendered shell immediately and streams in additional server-rendered content as it becomes ready, rather than waiting for the whole page to finish before responding, but the content still originates on the server either way, so crawler visibility isn't affected by the streaming itself. Islands architectures and React Server Components take a related but distinct approach: most of the page is rendered once on the server and shipped as plain HTML, with only small, deliberately chosen "islands" hydrated into interactive components on the client. For crawler visibility, the practical rule doesn't change with any of these patterns: check what's actually present in the raw server response for the specific content that matters, not what the architecture is named, because two sites using the same framework can land on opposite sides of the visibility gap depending on how a given route is configured.

Is dynamic rendering still a reasonable fix?

Dynamic rendering (detecting a crawler by its user agent and serving it a separately pre-rendered version of the page, while regular visitors get the normal client-rendered app) used to be Google's own recommended workaround for exactly this problem. That guidance has changed. Google's Rendertron project, the reference implementation it published for dynamic rendering, is now archived, and its own documentation states plainly that dynamic rendering isn't the recommended approach anymore and that better options exist.

The practical read: dynamic rendering, or a third-party prerendering service that does the same thing, is a reasonable retrofit for an existing JavaScript-heavy site that can't quickly migrate to real server-side rendering, and it also needs its bot-detection list actively maintained, since it typically has to be told about each AI crawler by name (GPTBot, ClaudeBot, PerplexityBot, and any new one that shows up) rather than recognizing them automatically. It isn't a foundation to build a new site on. For a new build, SSR, SSG, or a hybrid rendering strategy delivers the same crawler-visible HTML without maintaining a second rendering pipeline just to serve bots a different version of the page than everyone else sees.

Related: do AI crawlers actually read your site, robots.txt and AI crawlers, indexed but not ranking.