Server-side vs client-side rendering: what does an SEO agency choose?

For SEO, use SSR or SSG on every page that has to generate leads. Both put your content in the raw HTML, so Google and AI crawlers such as GPTBot, ClaudeBot and PerplexityBot can read it right away.

CSR only builds content in the browser. Dynamic rendering is a patch.

Why is rendering an SEO question, not just a developer one?

Because it decides whether you can be found at all. A search engine or AI crawler can only rank and cite what it actually reads.

What a crawler reads depends on when and where your content is built: on the server, during the build, or only in the visitor’s browser. For the broader context, see our pillar on SEO.

The difference between raw HTML and rendered HTML is the dividing line. Raw HTML is what the server returns. Rendered HTML is what you see after JavaScript has run.

Googlebot does render JavaScript, but in a separate, deferred step that can go wrong. Google’s JavaScript SEO basics describe three phases: crawling, rendering and indexing. Pages can wait in a render queue, and Google still calls server-side or pre-rendering “a great idea”.

The major AI crawlers don’t perform that step at all. Vercel’s analysis of the rise of the AI crawler found that none of them, GPTBot, ClaudeBot and PerplexityBot included, currently render JavaScript.

That’s why an SEO specialist puts rendering on the table early. Every other optimisation rests on it.

Same page, two outcomes: readable for Google, blank for ChatGPT.

Is client-side rendering (CSR) bad for SEO?

For the pages you want found, yes. With client-side rendering, the server sends an almost empty HTML page and JavaScript builds the real content in the browser.

The visitor first gets a bare skeleton. Only when the scripts are ready does the full page appear. Many single-page applications work this way by default.

For a human this is invisible: the script runs in a fraction of a second. The problem is the automated visitor.

A crawler that fetches the page but doesn’t execute JavaScript stays stuck on that empty skeleton. For Google, that’s an extra render step with delay and risk. For AI search tools, your content simply doesn’t exist.

We work out this scenario in why JavaScript websites are invisible to AI search engines.

CSR does have a legitimate place, for example interactive dashboards behind a login, or apps where no crawler has anything to look for. But your service pages, landing pages and knowledge articles are different.

For pages you want found, CSR is a structural risk.

Is server-side rendering (SSR) better for SEO?

Yes: with SSR, every crawler gets the complete page in the raw HTML. The server assembles the full page and sends ready-made HTML to both the visitor and the crawler.

No deferred render step is needed, so nothing can go wrong in a bot’s browser. What the server returns is already the complete page.

That makes SSR strong for SEO and essential for AI visibility. Your most important content sits directly in the raw HTML: titles, H1s, service descriptions and internal links. Every crawler sees the same page, whether it runs JavaScript or not.

SSR suits content that changes often or differs per user. Think of a product catalogue with live stock, personalised overviews, or pages that vary by region.

You do pay something for it. The server does more work per request, so caching and server speed need attention. That ties directly into your hosting and speed and your Core Web Vitals.

A slow server that rebuilds every page can hurt your Core Web Vitals.

When is static site generation (SSG) the best choice for SEO?

When your content doesn’t change every second. With static site generation, your pages are turned into static HTML files during the build.

Every visitor, human or crawler, gets the complete page directly. The server doesn’t have to assemble anything per request.

For SEO, that’s often the most comfortable choice. Your content is guaranteed to be in the raw HTML. Pages load very fast, because the server only returns a ready-made file. And there’s no render risk anywhere.

That makes SSG ideal for service pages, knowledge articles, cases and landing pages. Those are exactly the pages that count for B2B visibility.

The downside: every content change needs a rebuild. For a site with thousands of pages that change constantly, that gets impractical.

Many modern setups therefore combine SSG for stable content with SSR or incremental rebuilds for the parts that change. A headless CMS supports that hybrid well, though you don’t need one.

Mix SSG for stable pages with SSR for the parts that change.

Is dynamic rendering still a good fix?

Only as a bridge. With dynamic rendering, you serve crawlers a pre-rendered HTML version, while ordinary visitors get the client-side variant.

Your server checks who’s asking and sends the bot a clean, readable page. On paper, that solves visibility without rebuilding your frontend.

In practice, it’s an emergency measure. You maintain two versions of your site and depend on a separate render service that can stutter. You also serve crawlers something different from visitors.

Google itself calls dynamic rendering a workaround, not a long-term solution. It recommends server-side rendering, static rendering or hydration instead.

Dynamic rendering can make sense if you’re stuck with an existing CSR app and need to repair visibility now.

But if you’re planning a new site or a bigger overhaul, choose SSR or SSG right away. You’ll spare yourself the double maintenance.

A patch stops the bleeding. Don’t build a site that needs one permanently.

How do you choose between SSR, CSR and SSG for each page?

We don’t start with the framework, but with the pages. The question is always the same: which pages generate leads, and how often does their content change?

• Stable, commercially important pages (service and landing pages, knowledge articles): SSG or SSR. No render risk is acceptable here, because every invisible page costs leads.
• Frequently changing or personalised content (catalogues, regional pages, account-specific overviews): SSR, with attention to caching and server speed.
• Purely functional, gated parts (dashboards, applications behind a login): CSR is fine, because no crawler searches there.
• Existing CSR site that needs visibility now: dynamic rendering as a bridge, with a plan to migrate to SSR or SSG.

That choice rarely stands on its own. Rendering is tied to your website architecture and SEO, your hosting and the way your team manages content.

So we look at each case as a whole, rather than picking one method for everything.

One test counts: is the content that should make money in the raw HTML?

Frequently asked questions

Is SSR good for SEO?

Yes. The server sends ready-made HTML, so every crawler sees titles, H1s, copy and internal links without running JavaScript. Mind server speed and caching.

Can Google index client-side rendered pages?

Usually, but only after a separate, deferred render step that can go wrong. AI crawlers skip that step entirely.

Is SSG better than SSR for SEO?

For stable pages, often yes: guaranteed raw HTML and very fast loads. For content that changes constantly, SSR or incremental rebuilds fit better.

Should I use dynamic rendering?

Only as a bridge for an existing CSR site, with a plan to move to SSR or SSG.

Which of your pages should you fix first?

Not sure which rendering approach suits your site in Google and AI search tools? Send us your site and we’ll tell you which pages to fix first.