Hauptbereich
Agency
technisches-seo

SSR, CSR, SSG und Hydration — Rendering-Strategien und ihre SEO-Folgen

Redaktion ·

SSR, CSR, SSG und Hydration — Rendering-Strategien und ihre SEO-Folgen

Wo dein HTML entsteht — auf dem Server, beim Build oder erst im Browser — entscheidet darüber, was Googlebot beim ersten Blick sieht und wie schnell deine Seite für echte Nutzer steht. Vier Begriffe tauchen dabei immer wieder auf: SSR, CSR, SSG und Hydration. Sie klingen nach Framework-Detail, sind aber direkt ranking-relevant. Dieser Artikel erklärt, was jede Strategie konkret bedeutet, wo sie technisch hakt und welche heute der saubere Default ist.

Die Kurzfassung vorweg: Reines Client-Side-Rendering ist für indexierungsrelevante Seiten ein Risiko, weil der Inhalt erst nach JavaScript-Ausführung existiert. Server-gerendertes oder statisch vorgebautes HTML ist der sichere Weg. Und Hydration — der Schritt, der statisches HTML interaktiv macht — ist der häufigste Grund für schlechte INP-Werte. Jetzt im Detail.

Was „rendern” überhaupt heißt

Rendern bedeutet hier: aus deinem Anwendungs-Code wird das HTML, das ein Browser oder Crawler tatsächlich anzeigt. Die Frage ist nur — wann und wo passiert dieser Schritt. Drei Orte stehen zur Wahl:

  • Auf dem Server, pro Request — das ist SSR.
  • Beim Build, einmal für alle — das ist SSG.
  • Im Browser des Nutzers, per JavaScript — das ist CSR.

Alles andere — ISR, Hydration, Islands — sind Varianten und Kombinationen dieser drei Grundideen. Wer die drei Orte versteht, versteht den Rest fast von selbst.

SSR — Server-Side Rendering

Beim Server-Side Rendering baut der Server bei jedem Request das vollständige HTML und schickt es an den Browser. Der Nutzer — und der Crawler — bekommt sofort eine fertig befüllte Seite. JavaScript wird danach geladen, um die Seite interaktiv zu machen, aber der Inhalt steht schon da.

SEO-Folge: Bester Fall für die Crawlbarkeit. Googlebot sieht den kompletten Content in der ersten Antwort, ohne auf eine Render-Welle warten zu müssen. Der Inhalt landet schnell und zuverlässig im Index.

Der Haken: SSR braucht Server-Rechenzeit pro Anfrage. Das macht den TTFB tendenziell schlechter als bei statischem HTML — bei jedem Request muss erst gerendert werden. Ohne Caching und ohne CDN davor wird SSR unter Last langsam. Klassische SSR-Frameworks: Next.js (im Server-Modus), Nuxt, SvelteKit, Remix.

SSG — Static Site Generation

Bei Static Site Generation passiert das Rendering einmal beim Build. Das Ergebnis sind fertige HTML-Dateien, die ein CDN ausliefert — ohne dass pro Request irgendetwas berechnet wird. Genau das, was du gerade liest, ist statisch vorgebaut.

SEO-Folge: Ebenfalls bester Fall für Crawler — vollständiges HTML in der ersten Antwort. Und beim TTFB schlägt SSG sogar SSR: Eine statische Datei vom CDN liefert konstant niedrige Antwortzeiten, typischerweise 50–150 ms, weil nichts mehr gerechnet werden muss. Das hilft direkt dem LCP.

Der Haken: Die Build-Zeit wächst mit der Seitenzahl. Bei zehntausenden Seiten dauert ein voller Build lange, und jede Inhaltsänderung braucht im Zweifel einen neuen Build. Für stark dynamische Inhalte (Live-Preise, personalisierte Ansichten) ist reines SSG ungeeignet. Frameworks: Astro, Hugo, Eleventy, Next.js (Static Export), Gatsby.

ISR — Incremental Static Regeneration

ISR ist der Versuch, die Build-Schwäche von SSG zu lösen, ohne auf statisches HTML zu verzichten. Die Idee: Seiten werden statisch ausgeliefert, aber im Hintergrund nach einem definierten Zeitfenster neu gebaut — ohne kompletten Full-Build. Eine Seite kann beim ersten Aufruf generiert und dann gecacht werden; nach Ablauf einer Revalidierungs-Frist baut der Server die nächste Version neu.

SEO-Folge: Für den Crawler verhält sich ISR wie SSG — er bekommt fertiges HTML. Der Vorteil liegt in der Aktualität bei großen Sites: Du musst nicht 50.000 Seiten neu bauen, nur weil sich zehn geändert haben.

Der Haken: ISR ist kein offizieller Web-Standard, sondern ein Framework-Feature (geprägt durch Next.js). Es koppelt dich enger an Plattform und Hosting, und das Cache-Verhalten kann tricky werden — eine veraltete Variante kann kurzzeitig im Umlauf sein, bis die Revalidierung greift. Wer ISR nutzt, sollte das Revalidierungs-Fenster bewusst setzen.

CSR — Client-Side Rendering

Beim Client-Side Rendering schickt der Server fast leeres HTML — oft nur ein <div id="app"></div> plus ein JavaScript-Bundle. Der eigentliche Inhalt wird erst im Browser zusammengebaut, nachdem das JavaScript geladen, geparst und ausgeführt wurde. Die klassische React- oder Vue-Single-Page-App ohne SSR-Layer funktioniert so.

Warum reines CSR ein SEO-Risiko ist: Googlebot verarbeitet JavaScript in drei Phasen — Crawlen, Rendern, Indexieren. Der entscheidende Punkt: Das Rendering passiert nicht sofort. Seiten landen in einem Render-Queue, in dem ein Headless-Chromium das JavaScript ausführt (Google, Stand 2026). Diese Verzögerung kann Sekunden dauern, laut Google aber auch länger. Bis dahin kennt der Index nur das leere HTML-Skelett — also praktisch keinen Inhalt.

Das ist das, was im Tech-SEO als „Rendering-Budget” beschrieben wird: Das JavaScript-Rendering ist teuer, Google macht es nicht bei jedem Crawl zuverlässig und sofort. Wer wichtige Inhalte ausschließlich per CSR ausliefert, geht das Risiko ein, dass sie verzögert oder unvollständig indexiert werden. Details zum Mechanismus: JavaScript-Rendering durch Googlebot und die Abgrenzung SSR vs. CSR.

Google selbst formuliert es klar: Server-seitiges oder Pre-Rendering bleibt eine gute Idee, weil es die Seite für Nutzer und Crawler schneller macht — und nicht jeder Bot kann JavaScript ausführen (Google JavaScript SEO Basics, Stand 2026).

Wofür CSR trotzdem passt: Bereiche, die im Index nichts verloren haben — Login-bereiche, Dashboards, Konfiguratoren, interaktive Tools hinter Auth. Dort ist die fehlende Crawlbarkeit kein Problem, sondern oft sogar erwünscht.

Hydration — wenn statisches HTML aufwacht

Hydration ist der Schritt, der server-gerendertes oder statisches HTML im Browser interaktiv macht. Das HTML ist schon da und sichtbar — aber „tot”: Buttons reagieren nicht, State existiert nicht. Das JavaScript-Bundle wird geladen, hängt Event-Handler an, baut den Komponenten-State auf und gleicht das Virtual DOM mit dem realen DOM ab. Erst danach ist die Seite klickbar.

Die Kosten: Hydration läuft auf dem Main-Thread. Bei großen Bundles blockiert sie den Browser genau in dem Moment, in dem der Nutzer die Seite schon sieht und anfassen will. Das Resultat ist der typische Zustand „sieht geladen aus, reagiert aber nicht” — und das schlägt direkt auf den INP (Interaction to Next Paint) durch. web.dev nennt das Problem „one app for the price of two”: Die App wird einmal auf dem Server und einmal im Browser aufgebaut.

Eine schöne Eigenschaft bleibt: Der LCP ist gut, weil das HTML sofort da ist. Aber ein guter LCP bei katastrophalem INP ist ein verbreitetes Muster — Seite erscheint schnell, lässt sich aber eine Sekunde lang nicht bedienen. Mehr zum Mechanismus: Hydration.

Islands-Architektur — Hydration nur dort, wo nötig

Der Ausweg aus dem Hydration-Problem heißt partielle Hydration oder Islands-Architektur. Die Idee: Der Großteil der Seite bleibt statisches HTML, das nie JavaScript braucht. Nur die wirklich interaktiven Teile — eine Suchleiste, ein Karussell, ein Formular — werden als isolierte „Inseln” hydratisiert. Der Rest des Main-Threads bleibt frei.

Astro hat dieses Modell zum Standard gemacht: Komponenten sind per Default statisch und werden nur mit einer expliziten Direktive (etwa client:load, client:visible) interaktiv. Das senkt das ausgelieferte JavaScript drastisch und damit das INP-Risiko. Auch React adressiert die Richtung mit Server Components, die gar nicht erst hydratisiert werden müssen.

SEO-Folge: Bestes aus beiden Welten — fertiges HTML für den Crawler, minimale Hydration für gute Interaktivitätswerte. Für inhaltsgetriebene Sites (Blogs, Doku, Marketing, Magazine) ist das heute der sauberste Default.

Die Strategien im direkten Vergleich

| Strategie | Was Googlebot sofort sieht | TTFB | LCP | INP-Risiko | Typischer Einsatz | |---|---|---|---|---|---| | SSR | Vollständiges HTML | mittel | gut | mittel (Hydration) | dynamische, personalisierte Seiten | | SSG | Vollständiges HTML | sehr gut | sehr gut | niedrig–mittel | Content-Sites, Marketing | | ISR | Vollständiges HTML | sehr gut | sehr gut | niedrig–mittel | große Sites mit Teil-Updates | | CSR | Leeres HTML-Skelett | gut | schlecht | hoch | Apps hinter Login, Dashboards | | Islands | Vollständiges HTML | sehr gut | sehr gut | niedrig | Content + wenige interaktive Teile |

Die Tabelle macht das Muster sichtbar: Alles, was dem Crawler sofort vollständiges HTML liefert, ist SEO-seitig im grünen Bereich. CSR ist die einzige Strategie, die den Inhalt vor dem Bot versteckt — und genau deshalb die einzige, die man für indexierungsrelevante Seiten meiden sollte.

Die heutige Empfehlung

Für SEO-relevante Seiten gilt heute ein klarer Default: server-gerendertes oder statisch vorgebautes HTML mit so wenig Hydration wie möglich. Konkret:

  1. Inhaltsseiten statisch (SSG) oder per ISR. Beste TTFB, beste LCP, sofort crawlbar. Wenn nichts pro Nutzer personalisiert werden muss, gibt es keinen Grund für CSR.
  2. Dynamische, personalisierte Seiten per SSR — mit Caching und CDN davor, damit der TTFB nicht entgleist.
  3. Interaktivität als Inseln, nicht als Vollhydration der ganzen Seite. Jede Komponente, die kein JavaScript braucht, soll auch keins bekommen.
  4. Reines CSR nur für Bereiche, die nie in den Index sollen — App, Login, Tools hinter Auth.

Diese Reihenfolge spiegelt sich auch in Googles Haltung und in den web.dev-Empfehlungen wider: server-seitiges oder statisches Rendering vor Voll-Hydration bevorzugen. Wer so baut, hat den Großteil der JavaScript-SEO-Probleme gar nicht erst — und kann sich auf Crawl-Budget, Canonicals und Core Web Vitals konzentrieren. Den vollständigen technischen Bogen dazu liefert Technisches SEO — was Google crawlen, rendern und indexieren muss.

FAQ

Ist Client-Side-Rendering automatisch schlecht fürs Ranking? Nein — aber für indexierungsrelevante Seiten riskant. CSR liefert dem Crawler erst leeres HTML; der Inhalt entsteht erst nach JavaScript-Ausführung in einer verzögerten Render-Welle. Für Seiten, die ranken sollen, ist das ein Risiko. Für Bereiche hinter Login, die ohnehin nicht in den Index gehören, ist CSR völlig in Ordnung.

Was ist der Unterschied zwischen SSR und SSG, wenn beide fertiges HTML liefern? Der Zeitpunkt. SSR rendert bei jedem Request neu — flexibel für personalisierte oder ständig wechselnde Inhalte, aber mit Server-Last und tendenziell höherem TTFB. SSG rendert einmal beim Build — der niedrigste TTFB überhaupt, weil ein CDN nur eine fertige Datei ausliefert, dafür unflexibel bei dynamischen Daten.

Warum verschlechtert Hydration den INP? Hydration läuft auf dem Main-Thread, genau wenn der Nutzer die Seite schon sieht und bedienen will. Große JavaScript-Bundles blockieren den Thread mit langen Tasks, und Klicks bleiben so lange unbeantwortet. Das misst INP direkt. Partielle Hydration (Islands) reduziert das, indem nur interaktive Teile JavaScript bekommen.

Was ist die Islands-Architektur und warum hilft sie SEO? Bei der Islands-Architektur bleibt die Seite überwiegend statisches HTML; nur einzelne interaktive Komponenten werden hydratisiert. Der Crawler bekommt vollständiges HTML, der Browser muss kaum JavaScript ausführen. Das Ergebnis: gute Crawlbarkeit, guter LCP und niedriges INP-Risiko zugleich. Astro setzt dieses Modell als Default um.

Welche Strategie sollte ich für eine neue Content-Site wählen? Für eine inhaltsgetriebene Site (Blog, Doku, Marketing) ist SSG oder Islands-Architektur der sauberste Default — schnellstes TTFB, sofort crawlbar, minimales INP-Risiko. SSR lohnt sich erst, wenn Inhalte pro Request personalisiert oder ständig aktualisiert werden müssen. Reines CSR gehört nur in Bereiche, die nie indexiert werden sollen.

Themenuebersicht

Technisches SEOJavaScript SEO