Server-side rendering (SSR) for AI crawlers
Server-side rendering means the server returns fully-formed HTML containing your content, rather than a JavaScript shell the browser fills in afterwards. It matters for AI search because most AI crawlers do not execute JavaScript: analysis of large-scale crawl logs found no evidence that OpenAI's GPTBot does. A product page whose specifications and JSON-LD are injected client-side is, to those crawlers, a page with no product on it.
The gap between Googlebot and everyone else
Google runs crawling, rendering and indexing as separate phases and will execute your JavaScript before indexing, which is why client-side rendering has been survivable for classic SEO (JavaScript SEO basics).
AI crawlers generally do not do this. Crawl-log analysis found no evidence that GPTBot executes JavaScript, and the safe operating assumption across OAI-SearchBot, PerplexityBot, ClaudeBot and the rest is that they read the initial HTML response and nothing more.
So a rendering choice that has cost you very little in Google for years can cost you everything on the AI surfaces, silently, with no error and no report.
The hydration gap
"Hydration gap" is the informal name for the window between the server response and the point at which client-side JavaScript has attached and populated the page. For a browser it is milliseconds and invisible. For a crawler that never runs the JavaScript, it is permanent.
The practical shape of the failure in a catalog: the title and a skeleton render server-side, but the specification table, the price, the stock indicator, the Q&A block and the JSON-LD all arrive from an API call after mount. A crawler sees a product page with a name and nothing else, indexes that, and your 60 populated attributes never enter any index anywhere.
Checking what you actually serve
One command, and it settles most AI-visibility arguments:
curl -s https://example.com/product/HB-150-50K | grep -o 'application/ld+json'
curl -s https://example.com/product/HB-150-50K | grep -i 'lumens\|voltage\|IP65'
If the JSON-LD block is absent or the spec values do not appear in the raw response, that is what every AI crawler receives. View-source in a browser works too, as long as you read the source rather than the rendered DOM in devtools, which shows the post-JavaScript state and will mislead you.
Run it on a product page, not the homepage. Catalog templates are usually the most JavaScript-heavy part of a site and the most likely to fail this test.
The options, in rough order of effort
- Static generation. Pre-render product pages at build time. Best result, hardest to run against a catalog with live pricing and 400,000 SKUs.
- Server-side rendering. Render per request. The standard answer for large catalogs, and what most modern frameworks support natively.
- Incremental static regeneration. Serve a cached pre-rendered page, regenerate on a schedule. A good fit for catalogs where specs are stable and only price and stock move.
- Dynamic rendering. Serve pre-rendered HTML to bots and the app to browsers. Google has treated this as a workaround rather than a recommendation for years, and it introduces a permanent parity risk between what bots see and what users see. Sometimes the pragmatic answer for a legacy platform.
A partial fix that is worth doing on any stack: emit the JSON-LD and a plain server-rendered spec table in the initial HTML even if the interactive parts of the page hydrate later. The facts do not need to be interactive.
Frequently asked questions
Do AI crawlers execute JavaScript?
Generally no. Analysis of large-scale crawl logs found no evidence that OpenAI's GPTBot does, and the same assumption should be applied to other AI crawlers. Content that only appears after client-side JavaScript runs should be treated as invisible to them.
How do I check whether my product data is server-rendered?
Fetch the page with curl and search the raw response for your JSON-LD block and a few specification values. If they are not in that response, they are not in what AI crawlers receive. Devtools will mislead you here, since it shows the DOM after JavaScript has run.
Is client-side rendering also a problem for Google?
Much less so. Google runs a separate rendering phase that executes JavaScript before indexing. That is exactly why the problem goes undetected: a site can rank acceptably in Google for years while being effectively blank to every AI crawler.
What is the minimum fix if we cannot re-architect the storefront?
Emit the JSON-LD Product block and a plain specification table in the initial server response, even if the rest of the page hydrates client-side. The facts do not need to be interactive, and getting them into the first HTML response is most of the benefit.