Main area
Agency
technisches-seo

SSR, CSR, SSG and Hydration — Rendering Strategies and Their SEO Impact

Redaktion ·

SSR, CSR, SSG and Hydration — Rendering Strategies and Their SEO Impact

Where your HTML is built — on the server, at build time, or in the browser — decides what Googlebot sees on first look and how fast your page is ready for real users. Four terms come up again and again: SSR, CSR, SSG and hydration. They sound like framework trivia, but they are directly ranking-relevant. This article explains what each strategy actually means, where it breaks technically, and which one is the clean default today.

Short version up front: pure client-side rendering is a risk for indexing-relevant pages, because the content only exists after JavaScript runs. Server-rendered or statically pre-built HTML is the safe path. And hydration — the step that makes static HTML interactive — is the most common cause of poor INP scores. Now the detail.

What “rendering” actually means

Rendering here means: your application code is turned into the HTML a browser or crawler actually displays. The only question is — when and where does this step happen. There are three possible places:

  • On the server, per request — that’s SSR.
  • At build time, once for everyone — that’s SSG.
  • In the user’s browser, via JavaScript — that’s CSR.

Everything else — ISR, hydration, islands — are variants and combinations of these three core ideas. Understand the three places, and the rest almost follows by itself.

SSR — Server-Side Rendering

With server-side rendering, the server builds the complete HTML on every request and sends it to the browser. The user — and the crawler — get a fully populated page immediately. JavaScript is loaded afterwards to make the page interactive, but the content is already there.

SEO impact: Best case for crawlability. Googlebot sees the full content in the first response, without waiting for a render pass. The content lands in the index quickly and reliably.

The catch: SSR needs server compute per request. That tends to make TTFB worse than with static HTML — every request has to render first. Without caching and without a CDN in front, SSR gets slow under load. Classic SSR frameworks: Next.js (server mode), Nuxt, SvelteKit, Remix.

SSG — Static Site Generation

With static site generation, rendering happens once, at build time. The result is finished HTML files served by a CDN — with nothing computed per request. The very page you are reading is statically pre-built.

SEO impact: Also best case for crawlers — complete HTML in the first response. And on TTFB, SSG even beats SSR: a static file from a CDN delivers consistently low response times, typically 50–150 ms, because nothing has to be computed anymore. That helps LCP directly.

The catch: Build time grows with page count. With tens of thousands of pages a full build takes long, and every content change may need a new build. For highly dynamic content (live prices, personalized views) pure SSG is unsuitable. Frameworks: Astro, Hugo, Eleventy, Next.js (static export), Gatsby.

ISR — Incremental Static Regeneration

ISR tries to solve SSG’s build weakness without giving up static HTML. The idea: pages are served statically but rebuilt in the background after a defined time window — without a full build. A page can be generated on first request and then cached; once a revalidation window expires, the server rebuilds the next version.

SEO impact: To the crawler, ISR behaves like SSG — it receives finished HTML. The benefit is freshness on large sites: you don’t have to rebuild 50,000 pages just because ten changed.

The catch: ISR is not an official web standard but a framework feature (coined by Next.js). It couples you more tightly to platform and hosting, and the cache behaviour can get tricky — a stale variant may briefly be in circulation until revalidation kicks in. If you use ISR, set the revalidation window deliberately.

CSR — Client-Side Rendering

With client-side rendering, the server sends almost empty HTML — often just a <div id="app"></div> plus a JavaScript bundle. The actual content is only assembled in the browser, after the JavaScript has loaded, parsed and executed. The classic React or Vue single-page app without an SSR layer works this way.

Why pure CSR is an SEO risk: Googlebot processes JavaScript in three phases — crawling, rendering, indexing. The key point: rendering does not happen instantly. Pages land in a render queue where a headless Chromium executes the JavaScript (Google, as of 2026). This delay can take seconds, but according to Google it can also take longer. Until then, the index only knows the empty HTML skeleton — practically no content.

This is what tech SEO describes as the “rendering budget”: JavaScript rendering is expensive, and Google does not do it reliably and immediately on every crawl. If you serve important content exclusively via CSR, you risk it being indexed late or incompletely. For the mechanism: JavaScript rendering by Googlebot and the distinction SSR vs. CSR.

Google itself puts it clearly: server-side or pre-rendering is still a great idea, because it makes the page faster for users and crawlers — and not every bot can run JavaScript (Google JavaScript SEO Basics, as of 2026).

Where CSR still fits: areas that have no business being in the index — login areas, dashboards, configurators, interactive tools behind auth. There the missing crawlability is not a problem, and often even desired.

Hydration — when static HTML wakes up

Hydration is the step that makes server-rendered or static HTML interactive in the browser. The HTML is already there and visible — but “dead”: buttons don’t respond, there is no state. The JavaScript bundle loads, attaches event handlers, builds the component state and reconciles the virtual DOM with the real DOM. Only then is the page clickable.

The cost: Hydration runs on the main thread. With large bundles it blocks the browser exactly when the user already sees the page and wants to interact. The result is the typical state “looks loaded but won’t respond” — and that hits INP (Interaction to Next Paint) directly. web.dev calls the problem “one app for the price of two”: the app is built once on the server and once in the browser.

One nice property remains: LCP is good, because the HTML is there immediately. But a good LCP with catastrophic INP is a common pattern — the page appears fast but can’t be operated for a second. More on the mechanism: Hydration.

Islands architecture — hydration only where needed

The way out of the hydration problem is called partial hydration or islands architecture. The idea: most of the page stays static HTML that never needs JavaScript. Only the truly interactive parts — a search bar, a carousel, a form — are hydrated as isolated “islands”. The rest of the main thread stays free.

Astro made this model the default: components are static by default and only become interactive with an explicit directive (such as client:load, client:visible). That drastically lowers the shipped JavaScript and with it the INP risk. React addresses the same direction with Server Components, which don’t need to be hydrated at all.

SEO impact: best of both worlds — finished HTML for the crawler, minimal hydration for good interactivity scores. For content-driven sites (blogs, docs, marketing, magazines) this is the cleanest default today.

The strategies compared directly

| Strategy | What Googlebot sees immediately | TTFB | LCP | INP risk | Typical use | |---|---|---|---|---|---| | SSR | Complete HTML | medium | good | medium (hydration) | dynamic, personalized pages | | SSG | Complete HTML | very good | very good | low–medium | content sites, marketing | | ISR | Complete HTML | very good | very good | low–medium | large sites with partial updates | | CSR | Empty HTML skeleton | good | poor | high | apps behind login, dashboards | | Islands | Complete HTML | very good | very good | low | content + few interactive parts |

The table makes the pattern visible: anything that hands the crawler complete HTML immediately is in the green zone for SEO. CSR is the only strategy that hides the content from the bot — and exactly why it’s the only one to avoid for indexing-relevant pages.

The recommendation today

For SEO-relevant pages there is a clear default today: server-rendered or statically pre-built HTML with as little hydration as possible. Concretely:

  1. Content pages static (SSG) or via ISR. Best TTFB, best LCP, instantly crawlable. If nothing has to be personalized per user, there is no reason for CSR.
  2. Dynamic, personalized pages via SSR — with caching and a CDN in front, so TTFB doesn’t derail.
  3. Interactivity as islands, not as full hydration of the whole page. Every component that doesn’t need JavaScript should not get any.
  4. Pure CSR only for areas that should never be indexed — app, login, tools behind auth.

This order is reflected in Google’s stance and in the web.dev recommendations: prefer server-side or static rendering over full hydration. Build this way and you avoid most JavaScript-SEO problems in the first place — and can focus on crawl budget, canonicals and Core Web Vitals. The full technical arc is covered in Technical SEO — what Google has to crawl, render and index.

FAQ

Is client-side rendering automatically bad for ranking? No — but risky for indexing-relevant pages. CSR first hands the crawler empty HTML; the content only appears after JavaScript runs in a delayed render pass. For pages meant to rank, that’s a risk. For areas behind login that won’t be indexed anyway, CSR is perfectly fine.

What’s the difference between SSR and SSG if both deliver finished HTML? The timing. SSR re-renders on every request — flexible for personalized or constantly changing content, but with server load and a tendentially higher TTFB. SSG renders once at build time — the lowest TTFB possible, because a CDN just serves a finished file, but inflexible for dynamic data.

Why does hydration worsen INP? Hydration runs on the main thread, exactly when the user already sees the page and wants to use it. Large JavaScript bundles block the thread with long tasks, leaving clicks unanswered. INP measures this directly. Partial hydration (islands) reduces it by giving JavaScript only to interactive parts.

What is islands architecture and why does it help SEO? With islands architecture the page stays mostly static HTML; only individual interactive components are hydrated. The crawler gets complete HTML, the browser barely has to run JavaScript. The result: good crawlability, good LCP and low INP risk at the same time. Astro implements this model as its default.

Which strategy should I pick for a new content site? For a content-driven site (blog, docs, marketing) SSG or islands architecture is the cleanest default — fastest TTFB, instantly crawlable, minimal INP risk. SSR only pays off once content has to be personalized per request or constantly updated. Pure CSR belongs only in areas that should never be indexed.

Themenuebersicht

Technisches SEOJavaScript SEO