What Is Server-Side Rendering (SSR)?

In one sentence

Server-side rendering means the server builds complete HTML before sending it, so any crawler receives your full content without executing JavaScript.

What Server-Side Rendering means

With SSR, the server assembles the page — content, data, markup — and sends finished HTML. The browser can then hydrate it with interactivity, but the content is already there in the response.

The alternative, client-side rendering, sends a near-empty shell plus JavaScript that fetches and builds the content in the browser. Crawlers that don't execute JavaScript see the shell and nothing else.

Why it matters for AI search

SSR is the single most effective fix for AI visibility on modern JavaScript sites. It converts an invisible page into a fully readable one without changing a word of content.

It usually improves perceived performance too, since users see content before JavaScript finishes loading.

See it in action

The same component, rendered two ways.

Client-side vs server-side

Response comparison
Client-side rendered before
HTML response size4 kb
Content in responsenone
GPTBot seesempty shell
PerplexityBot seesempty shell
Googlebot seesrenders it eventually
Time to first content1.8s

Same page, same content, completely different visibility.

This is a configuration decision in most modern frameworks rather than a rewrite. Next.js, Nuxt, SvelteKit and Remix all support it natively.

How to get it right

Moving to SSR

  • Identify which templates render client-side by fetching them without JavaScript
  • Use your framework's native SSR or static generation rather than bolting on a workaround
  • Static generation is even better where content doesn't change per request
  • Verify per template after deploying, not just on the homepage
  • Watch for hydration mismatches, which can strip content after load

Common questions

Is SSR necessary if Googlebot renders JavaScript?

For Google alone, often not. For AI search, yes — several major AI crawlers don't execute JavaScript at all.

This is why sites rank fine in Google and stay invisible in ChatGPT and Perplexity.

Is static generation better than SSR?

For content that doesn't change per request, usually yes — it's faster and simpler. SSR suits pages needing per-request data.

Both solve the crawler problem equally well; the choice is about performance and infrastructure.

Does SSR slow down our server?

It adds server work per request, which caching largely offsets. Static generation avoids it entirely.

In practice the performance tradeoff is far smaller than the visibility gain.

These come up alongside Server-Side Rendering constantly.

Free 12-point check

Send Ron your site

Two fields. We’ll crawl your site as GPTBot, ClaudeBot and PerplexityBot, benchmark a sample of your category’s prompts, and send you what we find.

  • What each AI crawler actually receives from your site
  • Whether models resolve your brand as a real entity
  • A sample of category prompts and who gets cited
  • The three fixes we’d prioritise first

No commitment, no sales sequence. If we’re not a fit, we’ll say so.

We’ll pull your favicon so you know we found the right site.

We reply from a real address. No sequence, no newsletter.