JavaScript SEO for AI Crawlers: What GPTBot Never Sees

By Muntazir · Published 22 October 2026

Request a product page built as a single-page app without running anything on it, and the response can be a title tag, a stylesheet link, and one empty container — nothing else. Open the same URL in a browser and everything shows up: photos, price, three reviews, an add-to-cart button, all of it put there by a script that ran after the page loaded. The two versions of that page are completely different documents, and which one a visitor gets depends entirely on whether something executed the script in between.

Google’s crawler is one of the few that does. Most of the crawlers now deciding whether a brand gets mentioned in an AI answer are not.

Why did JavaScript stop being an SEO problem, and why is it one again?

For years, “does Google render JavaScript” had a settled answer: yes. In May 2019, Google announced that Googlebot had moved from a rendering engine based on the aging Chrome 41 to an “evergreen” version of Chromium, kept continuously up to date from then on. That one change absorbed most of the JavaScript-SEO problem for the search engine site owners cared about most: a single-page app that once needed a server-rendering workaround to rank in Google could, from that point, mostly just work.

That lesson has not aged well for an audience that didn’t exist when it was written. Vercel and MERJ’s analysis of over 500 million GPTBot requests found no evidence of it ever executing JavaScript, and more recent testing finds ClaudeBot and PerplexityBot behaving the same way: all three sometimes fetch a page’s script files, but nothing suggests any of them runs what’s inside. A roundup published in October 2026 adds a complication worth keeping rather than resolving: one developer reported OpenAI’s crawlers starting to render pages in late September, with no public announcement from OpenAI confirming it either way. Even the current picture here carries an asterisk.

What does client-side rendering actually hide from a crawler that can’t run scripts?

A page can be built three different ways, and the difference is invisible to a person looking at it in a browser. Server-side rendering and static site generation both produce a finished HTML document on the very first response — a browser adds interactivity afterward, but the words are already there. Pure client-side rendering ships a near-empty shell and a script, and the words exist only once that script finishes running. Whether a page ever turns up inside an AI answer depends on a crawler reaching, parsing and then trusting it, in that order, and a crawler that can’t run the script never gets past “parse” — nothing else about the page, however good, gets a chance to matter.

A framework chosen for developer convenience, a migration to a heavier component library, or even one product-listing template quietly rebuilt as a client-rendered widget can move a section of a site from the first category into the second, with nothing visible in a browser to show that it happened.

How much of a page can actually disappear, and how would anyone know?

Answering that means rendering the same URL twice — once with nothing executed, once in a full browser — and comparing the text that survives. This product’s own audit runs exactly that comparison on its paid tier, and treats the gap as a scale rather than a single verdict: under roughly 30% of the rendered page’s text surviving in the raw HTML gets flagged as critical, and a gap between 30% and 70% gets flagged as smaller but real.

The free tier of the same audit can’t run this check at all, because the comparison needs an actual browser render to measure against, and that step only exists on the paid tier. That’s not a softer result — it’s no result, which is its own kind of warning for a site that has never had this measured. There’s no published figure yet for how often the critical threshold actually fires across the sites that get scanned; that’s a genuine gap in what’s known here, not a number being withheld.

Which rendering approaches keep content visible without running any script?

Server-rendering frameworks — Next.js, Nuxt, SvelteKit, and Astro’s own default — produce finished HTML on the server for every request, so there’s nothing for a non-executing crawler to miss. Static site generators go further and build that HTML once, ahead of time, which is why a blog or marketing site built this way rarely has this problem. A single-page app built client-only is the one architecture where the fix isn’t a setting: it needs either a rendering layer added in front of the app (sometimes called dynamic or hybrid rendering) or a rebuild of whatever slice of it search and AI traffic actually touch — usually the marketing pages and content, not the logged-in product behind them.

Does rendering fine for Google prove anything about an AI crawler’s experience?

No, and that’s the complication a lot of migration checklists miss. A site that ranks well, passes its Core Web Vitals, and looks perfect in Google’s own testing tools has only proven that one specific piece of software — Google’s evergreen renderer — can get past the shell. OAI-SearchBot, GPTBot and ClaudeBot are three separate crawlers built by three separate companies, and none of them has published the kind of rendering guarantee Google made in 2019. A page can pass every check a developer normally runs and still be functionally blank to the systems deciding whether a brand gets mentioned in an AI answer — a gap that, outside of a direct render comparison, leaves no trace a browser would ever show.

That gap closes the moment any one crawler adds rendering, and per the unconfirmed September report above, it may already be closing for at least one of them. Until a company says so directly, the safer assumption for anything meant to be read by a machine stays the older one: put the words in the HTML, and treat the script as decoration.