Client-Side vs Server-Side Rendering for AI Crawlers

The difference is where the page gets built.

• Server-side rendering (SSR) builds the HTML on the server. The crawler receives your headings, copy, prices and links in the first response.
• Client-side rendering (CSR) sends a thin HTML shell plus JavaScript. The browser runs the script, fetches data and then writes the content into the page.
• Static generation and prerendering build the HTML ahead of time. To a crawler, the result looks the same as SSR.

For a human with a browser, all three end up identical. For a crawler that does not run JavaScript, a client-side rendered page can be little more than an empty container. A server-side rendered page arrives with the text already in it.

Many modern frameworks mix the two. A React or Next.js site can server-render the layout and still load the pricing table, reviews or product specs on the client. That mixed case is where most sites lose content without noticing.

Vercel analysed AI crawler traffic and reported that ChatGPT and Claude crawlers do fetch JavaScript files (11.50% of ChatGPT requests and 23.84% of Claude requests), but they don't execute them. Its conclusion was blunt: they can't read client-side rendered content. The study was published in December 2024 and updated in February 2025. You can read the details in our summary of Vercel's AI crawler study.

Independent testing in June 2026 found the same pattern across a wider set: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent and Bytespider did not render JavaScript. Googlebot and AppleBot are the exceptions. Both render pages.

That split creates a blind spot. Google documents how it renders JavaScript as part of crawling, so your rankings and Search Console can look healthy. Meanwhile, the crawler behind ChatGPT search (OAI-SearchBot, per OpenAI's crawler docs) may receive a page with no product names and no prices.

Two honest caveats

• Vercel sells SSR hosting, and its sample was one month of traffic on nextjs.org, a site skewed toward Next.js. Microsoft Copilot was excluded because it lacked a unique user agent. The independent replication is why this finding still stands.
• Crawler behaviour changes. Treat this as true as of October 2026 and recheck it when engines update their crawlers.

One nuance from Vercel: JSON or React Server Components data embedded in the initial HTML response may still be picked up. Data that loads later, after the page boots, will not be.

You do not need to guess. Compare what a non-rendering crawler gets with what a browser shows.

1. List the pages that carry facts. Pricing, product and plan pages, about, locations, integrations and any page answering a buyer question.
2. Fetch the raw HTML. Request the URL with JavaScript disabled, or view the page source rather than the inspected DOM. This approximates what most AI crawlers receive.
3. Render the same URL. Load it in a headless browser and extract the visible text after scripts finish.
4. Diff the two. Note every heading, price, product name, entity mention and claim that exists only in the rendered version.
5. Check interaction content. Open tabs, accordions and infinite scroll. If their text loads by fetch on click, it is missing from the raw HTML too.
6. Check your directives. A robots meta tag injected by JavaScript may not be seen by crawlers that skip scripts.

Our raw HTML vs rendered DOM check walks through each step, and the guide to finding facts hidden behind JavaScript covers the interaction cases. For a quick first look at a single URL, use the free JavaScript rendering check.

Rendering is only one gate. A page can be fully server-rendered and still blocked by a firewall or CDN that returns 403 to AI crawlers. 99Visibility's AI Crawler Checker requests a page as each AI crawler and shows which ones get turned away.

Server-side rendering is an access fix. It decides whether your content exists in what the crawler stores. It does not decide whether an engine retrieves your page for a given question, or whether the model cites it.

The four stages make this clear:

• Parametric: what a model learned in training. Rendering changes nothing here this quarter.
• Access: whether a crawler can fetch and read the page. This is where SSR works.
• Retrieval: whether your page enters the model's context for a query. The engine controls this.
• Generation: which retrieved pages get used and cited. The model controls this.

A critical survey of 45 GEO studies (arXiv, July 2026) found no technique with a stable, cross-platform causal effect on discoverability. So expect SSR to remove a block, not to deliver a number. Our answer on whether SSR increases AI citations goes further.

One on-page point has positive support: a specific fact (a price, a number, a one-line definition) on a page that can be fetched gives an engine a sentence it can quote. That only works if the fact is in the HTML the crawler reads.

Use this as the decision rule.

• Server-render or prerender any page that states facts you want AI engines to get right: prices, plans, product names, specs, locations, founding details and comparison pages.
• Keep client-side rendering for logged-in areas, dashboards, carts and anything personalised. AI crawlers have no reason to read those.
• Use a hybrid when a framework makes full SSR costly. Server-render the core facts and let interactive widgets hydrate on the client.
• Don't prioritise SSR for Google alone. Googlebot renders, so Google surfaces are rarely the reason to switch. See whether AI Overviews need server-side rendering for the Google-specific view.

Start with the diff on your five most important pages. If key facts appear only after hydration, move them into the initial HTML first, then widen the rollout.