Server-side rendering (SSR): definition

Server-side rendering (SSR) is when the web server builds the full HTML of a page and sends it in the first response. The text, headings, prices and links are in that HTML before the browser runs any script.

The opposite is client-side rendering, where the server sends a thin HTML shell and JavaScript fills in the content in the browser. A close relative is static site generation, where the HTML is built ahead of time rather than on each request. For AI crawlers, SSR and SSG have the same useful property: the content is in the HTML.

This entry is a short definition. For the full picture, read the guide on JavaScript rendering and AI crawlers.

A request reaches the server. The server fetches the data, renders the page template and returns complete HTML. The browser shows that HTML right away.

Most modern frameworks then run JavaScript in the browser to make the page interactive. This step is called hydration. SSR does not mean a site has no JavaScript. It means the content does not depend on JavaScript to appear.

The test is simple. Fetch the page with JavaScript disabled and read what comes back. If your pricing, product names and key claims are in that raw HTML, the page is server rendered where it counts.

AI crawlers need to read a page before any engine can use it. Vercel's crawler study (published December 2024, updated February 2025) found that ChatGPT and Claude crawlers do fetch JavaScript files (11.50% and 23.84% of their requests) but do not execute them, so they cannot read client-side rendered content. Our summary of the Vercel study covers its method and limits, including that Vercel sells rendering infrastructure.

As of October 2026, the finding has been independently re-confirmed for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent and Bytespider. Googlebot and AppleBot are the exceptions: both render JavaScript.

What this means in practice:

• If a fact only appears after hydration, those crawlers never see it.
• Fixing that is in your control and mechanically checkable.
• It is the strongest-evidenced access fix in the GEO evidence base.

The next move is to run a raw HTML vs rendered DOM check on your highest-value pages and list what is missing from the raw version.

"SSR will get me cited more"

No evidence shows that. SSR decides whether your content exists for a crawler at all. Which pages an engine retrieves and cites is decided later, by the engine. A July 2026 critical survey of 45 GEO studies found no technique with a stable, cross-platform causal effect on discoverability. See whether SSR increases AI citations for the detail.

"SSR is essential for Google AI Overviews"

Googlebot renders JavaScript, so the crawler gap does not apply the same way there. Google says pages need to be indexed and eligible for a snippet, with no extra requirements. More in do AI Overviews need SSR.

"Downloading JavaScript means running it"

The Vercel data shows crawlers fetching script files without executing them.

"SSR and schema are interchangeable levers"

They are not. SSR removes a documented block. Schema has no credible evidence as an AI citation lever. The comparison of schema vs server-side rendering explains why.

• Client-side rendering (CSR): content built in the browser by JavaScript.
• Static site generation (SSG): HTML built at deploy time.
• Hydration: the browser step that makes server rendered HTML interactive.
• Prerendering: serving a pre-built HTML snapshot of a JavaScript page to crawlers.

Do I need to server-render my whole site? Usually not. What matters is the content you want AI engines to describe correctly: pricing, product names, feature lists, locations and one-line definitions of what you do. Start with the pages that carry those facts. If they already appear in the raw HTML, you may have nothing to fix. If they only appear after JavaScript runs, server-render or prerender those sections first.

Is static site generation as good as SSR for AI crawlers? For crawler access, yes. Both deliver finished HTML in the first response, so a crawler that does not run JavaScript can still read the content. The difference is when the HTML is built: SSG builds it at deploy time, SSR on each request. Choose based on how often your content changes, not on AI visibility.

Can content loaded through React Server Components be read? It depends on where the data lands. Vercel notes that JSON or React Server Component payloads included in the initial HTML response may still be indexed. Content fetched later, after the page loads, is a risk for crawlers that do not execute JavaScript. Check the raw response rather than assuming.

Does SSR fix every access problem? No. SSR only covers rendering. A crawler also needs robots.txt permission for its specific user agent, and your CDN or firewall must not block it. A page can be fully server rendered and still unreachable if the network layer returns a 403 to AI crawlers. Check each gate separately.