Short answer: some do, most don’t, and the ones that matter most for a sale — the crawl-based fetchers that build the index an assistant cites from — generally don’t. If your product page is an empty <div id="root"> until JavaScript fills it in, you’re betting your catalog on the rendering behavior of every AI vendor at once. Google’s own documentation, the one primary source that states this plainly, puts it in one sentence: server-side or pre-rendering is worthwhile “because it makes your website faster for users and crawlers, and not all bots can run JavaScript” (Google Search Central — Understand JavaScript SEO Basics).

Two different jobs, two different renderers

Google’s own JS SEO guide describes its own crawler’s process as three phases — crawl, render, index — where Googlebot fetches the raw HTML first, queues it, and only later “a headless Chromium renders the page and executes the JavaScript” for pages that return a 200 status. That’s Google going out of its way to run a full browser engine against every indexable page. The same document is explicit that this is not universal: “other search engines may choose to ignore JavaScript and won’t see JavaScript-generated content.”

The AI-specific fetchers merchants actually get hit by are simpler than Googlebot. Per each vendor’s own documentation, OpenAI runs three: GPTBot (training crawl), OAI-SearchBot (the index behind ChatGPT search), and ChatGPT-User (a live fetch triggered by a user’s question) — described throughout as requests and IP-published “crawlers,” not browser sessions (OpenAI — Overview of OpenAI Crawlers). Anthropic documents ClaudeBot, Claude-User and Claude-SearchBot the same way (Claude Help Center), and Perplexity documents PerplexityBot and Perplexity-User as fetchers that “surface and link websites in search results” (Perplexity — Perplexity Crawlers). None of the three describes its crawler as running a browser or executing JavaScript — a meaningful silence given how explicit Google is about the opposite for its own bot.

Browser agents are the exception, not the rule

There is one class of AI agent that reliably sees your rendered page: the kind that is, literally, a browser. Google’s own guide to agentic experiences draws this line directly — “browser agents may access your website to gather the data they need to complete these tasks, such as analyzing visual renderings (like screenshots), inspecting the DOM structure, and interpreting the accessibility tree” (Google — Optimizing for Generative AI Search). That’s the Claude-in-Chrome, ChatGPT-Atlas, browser-buyer category: it drives a real browser, so it renders like one. The crawl-based fetchers that build citations and search indexes are a different, larger population, and the docs above give no reason to assume they do the same.

The fix is not “detect the bot and serve it something else”

Google used to document a workaround for exactly this gap — dynamic rendering, where a server detects a bot’s user-agent and serves it a pre-rendered version while users get the client-rendered one. That page now opens with a correction: “Dynamic rendering was a workaround and not a long-term solution… we recommend that you use server-side rendering, static rendering, or hydration as a solution” (Google — Dynamic Rendering as a Workaround). The same page notes dynamic rendering itself isn’t cloaking as long as bots and users see equivalent content — but the safer, now-recommended fix skips the bot-detection branch entirely: render the content once, on the server, and every fetcher gets the same HTML a browser would.

How we test it

Every AgentReady scan runs this exact check: it fetches a product page and counts the visible text (and JSON-LD) present in the raw HTML response, before any script runs. Above roughly 800 characters, or a parseable product JSON-LD block, it passes; a near-empty shell fails outright. It’s a blunt proxy for the same fact Google states directly — a crawler that never executes your bundle only ever sees what’s in that first response. The full robots.txt allowlist for these same fetchers is the other half of getting found; this is what determines whether being found means being read.

FAQ

Do GPTBot, ClaudeBot and PerplexityBot execute JavaScript?

Their own documentation doesn’t say they do. OpenAI, Anthropic and Perplexity each describe their crawlers as fetchers identified by a user-agent string and a published IP range, with no mention of browser rendering — in contrast to Google’s JS SEO docs, which state outright that Googlebot renders JavaScript with a headless Chromium instance for its own crawl.

Does this mean I need dynamic rendering to support AI bots?

No — Google’s current guidance retired dynamic rendering as “a workaround and not a long-term solution” and recommends server-side rendering, static rendering, or hydration instead. Serving one rendered HTML response to everyone is simpler than maintaining a bot-detection branch, and it avoids any risk of that branch drifting into serving different content to bots than to users.

Will my product still show up if I only fix this for AI bots and not for SEO?

Fixing it once fixes it for both: the same server-rendered HTML that lets a non-JS AI fetcher read your price and availability is exactly what Google’s own guide says search crawlers need for pages using an app-shell model, since “Google needs to execute JavaScript before being able to see the actual page content” on those pages too.

Sources

A store can rank perfectly and still fail the transaction: if the crawler that indexes you can’t render the page, it never saw the price it’s about to be asked to quote.