Server-Side Rendering (SSR)

Was ist Server-Side Rendering (SSR)?

Server-Side Rendering (SSR) bezeichnet die Erzeugung einer vollständigen HTML-Seite auf dem Server, bevor sie an den Browser oder einen Crawler übertragen wird. Dadurch stehen zentrale Inhalte, Links und Metadaten bereits in der ersten Serverantwort bereit. JavaScript ergänzt anschließend meist interaktive Funktionen im Browser.

Server-Side Rendering (SSR), auf Deutsch serverseitiges Rendering, verlagert die anfängliche Seitenerzeugung vom Browser auf den Webserver. Ruft ein Nutzer eine URL auf, verarbeitet der Server die benötigten Daten und Komponenten, erzeugt daraus HTML und sendet dieses Dokument an den Browser. Der Besucher kann den Inhalt deshalb häufig sehen, bevor das gesamte JavaScript ausgeführt wurde.

So funktioniert Server-Side Rendering

Bei Server-Side Rendering (SSR) beginnt jeder Seitenaufruf mit einer HTTP-Anfrage. Der Server lädt beispielsweise Produktdaten, redaktionelle Inhalte oder Kontoinformationen, setzt daraus das HTML-Dokument zusammen und liefert es mit einem HTTP-Statuscode wie 200 aus. Der Browser verarbeitet anschließend HTML und CSS und lädt die für Interaktionen benötigten Skripte.

Viele moderne JavaScript-Anwendungen verwenden nach der HTML-Auslieferung eine sogenannte Hydration. Dabei verbindet das JavaScript im Browser den bereits sichtbaren HTML-Code mit Ereignissen und Anwendungslogik. Ein Produktfilter kann beispielsweise schon als HTML angezeigt werden, reagiert aber erst nach der Hydration auf Eingaben.

Der Server empfängt die Anfrage für eine URL.
Die Anwendung ruft die erforderlichen Inhalte und Daten ab.
Der Server erzeugt daraus ein vollständiges HTML-Dokument.
Der Browser stellt das HTML dar und lädt zusätzliche Ressourcen.
JavaScript aktiviert anschließend dynamische und interaktive Funktionen.

Ein einfaches Prüfbeispiel: Öffne den ursprünglichen Seitenquelltext einer URL und suche dort nach einer zentralen Überschrift oder einem Produktnamen. Ist der Inhalt bereits im ausgelieferten HTML vorhanden, wurde er serverseitig oder vorab erzeugt. Erscheint der Inhalt erst in den Entwicklertools nach der JavaScript-Ausführung, stammt er wahrscheinlich aus clientseitigem Rendering.

SSR im technischen SEO

Server-Side Rendering (SSR) erleichtert Suchmaschinen den Zugriff auf Inhalte, weil Überschriften, Texte, interne Links, Canonical Tags und strukturierte Daten bereits in der ersten HTML-Antwort enthalten sein können. Ein Crawler muss dann nicht zwingend auf eine spätere JavaScript-Ausführung warten, um die Kernaussage und Verlinkung einer Seite zu erfassen.

Der häufigste Denkfehler lautet, Server-Side Rendering (SSR) garantiere automatisch eine vollständige Indexierung. SSR verbessert lediglich die technische Bereitstellung. Eine URL kann trotzdem von der Indexierung ausgeschlossen bleiben, wenn sie einen Noindex-Hinweis enthält, durch die robots.txt blockiert wird, einen ungeeigneten Canonical Tag besitzt oder keine crawlbaren internen Links erhält. Prüfe deshalb nicht nur den gerenderten Inhalt, sondern auch Statuscode, Indexierungsanweisungen und interne Verlinkung.

Für GEO, also Generative Engine Optimization, schafft Server-Side Rendering (SSR) ebenfalls eine belastbare technische Grundlage. Wenn Definitionen, Tabellen, Produktinformationen und strukturierte Daten direkt im HTML stehen, können unterschiedliche Crawler diese Informationen leichter extrahieren. Ob eine Seite in Antworten von ChatGPT, Perplexity, Gemini oder Grok verwendet wird, hängt zusätzlich von Relevanz, inhaltlicher Klarheit, Autorität und Zugänglichkeit ab.

SSR und Client-Side Rendering

Der Unterschied zwischen Server-Side Rendering (SSR) und Client-Side Rendering liegt im Ort der ersten Seitenerzeugung. SSR liefert bereits ausgefülltes HTML vom Server. Beim Client-Side Rendering erhält der Browser häufig zunächst ein schlankes HTML-Grundgerüst und erzeugt den sichtbaren Inhalt erst durch JavaScript und nachgeladene Daten.

Kriterium	Server-Side Rendering	Client-Side Rendering
Erstes HTML	Enthält wesentliche Seiteninhalte	Enthält häufig nur ein Grundgerüst
Rechenarbeit	Erfolgt zunächst auf dem Server	Erfolgt stärker im Browser
Crawling	Inhalte sind direkt in der Antwort verfügbar	Inhalte können eine JavaScript-Ausführung erfordern
Interaktivität	Wird häufig durch Hydration ergänzt	Wird vollständig im Browser aufgebaut
Serverbelastung	Kann bei vielen dynamischen Aufrufen steigen	Ein Teil der Verarbeitung liegt beim Endgerät

Server-Side Rendering (SSR) ist außerdem von Static Site Generation abzugrenzen. Bei SSR entsteht das HTML typischerweise zur Anfragezeit oder aus einem serverseitigen Cache. Bei Static Site Generation werden HTML-Dateien bereits während eines Build-Prozesses erzeugt. Statische Seiten lassen sich dadurch schnell ausliefern, müssen bei Inhaltsänderungen aber je nach System neu generiert werden.

Performance richtig bewerten

Server-Side Rendering (SSR) verbessert die Ladezeit nicht automatisch. Die serverseitige Verarbeitung kann den sichtbaren Inhalt früher bereitstellen, erhöht jedoch bei langsamen Datenbanken, komplexen Schnittstellen oder fehlendem Caching die Time to First Byte, kurz TTFB. Die TTFB misst die Zeit vom Beginn der Anfrage bis zum Empfang des ersten Datenbytes und erfasst damit Netzwerkweg, Serververarbeitung und Antwortbeginn.

Für die Nutzererfahrung zählt neben der ersten HTML-Antwort auch, wann der Hauptinhalt erscheint und wann die Seite reagiert. Als gute Core-Web-Vitals-Werte gelten ein Largest Contentful Paint von höchstens 2,5 Sekunden, ein Interaction to Next Paint von höchstens 200 Millisekunden und ein Cumulative Layout Shift von höchstens 0,1. Bewertet wird jeweils das 75. Perzentil der Seitenaufrufe. Vergleiche SSR-Varianten deshalb anhand realer Nutzerdaten und nicht nur anhand eines einzelnen Labortests.

Messbar ist Server-Side Rendering (SSR) durch den Vergleich von ursprünglichem HTML, gerendertem DOM, TTFB, Largest Contentful Paint und JavaScript-Fehlern. Der Technik-Crawler der Performance Suite kann technische Seitenmerkmale automatisiert prüfen und das Crawling von JavaScript an das Projekt anpassen. Für die Indexierung bleibt zusätzlich die URL-Prüfung in der Google Search Console relevant.

Prüfe die Ladeleistung einer betroffenen URL mit dem kostenlosen Test:

Mit Nutzung dieses PageSpeed-Checks erklären Sie, dass Sie die Datenschutzerklärung zur Kenntnis genommen haben und damit einverstanden sind, dass die von Ihnen angegebenen Daten elektronisch erhoben und gespeichert werden. Ihre Daten werden dabei nur streng zweckgebunden zur Bearbeitung des PageSpeed-Checks benutzt. Mit der Nutzung dieses PageSpeed-Checks erklären Sie sich mit der Verarbeitung einverstanden.

Ladezeiten-Score: N/A von 100

i Ladezeiten (Desktop):	N/A
i Ladezeiten (Mobile):	N/A
i PageSpeed (Desktop):	N/A
i PageSpeed (Mobile):	N/A
i CMS:
i Gehosted bei:
i WordPress Theme:

Ladezeiten (Desktop)

Ladezeiten (Mobile)

Typische SSR-Fehler vermeiden

Ein kritischer SSR-Fehler entsteht, wenn Server und Browser unterschiedliche Inhalte erzeugen. Stimmt das serverseitige HTML nicht mit dem Ergebnis der Hydration überein, kann die Anwendung Elemente neu aufbauen, Fehlermeldungen ausgeben oder Interaktionen verlieren. Ursachen sind unter anderem zufällige Werte, abweichende Datumsformate, nicht synchronisierte Daten oder Browser-Funktionen, die auf dem Server nicht verfügbar sind.

Prüfe niemals nur die sichtbare Browseransicht. Eine Seite kann für Nutzer vollständig aussehen, während wichtige Texte oder Links im ursprünglichen HTML fehlen und erst nach einer fehleranfälligen JavaScript-Ausführung erscheinen. Vergleiche deshalb Quelltext, gerendertes DOM und die von Suchmaschinen erkannte Version derselben URL.

Weitere Probleme entstehen durch langsame Schnittstellen, fehlendes Caching und eine zu große JavaScript-Menge. Auch bei Server-Side Rendering (SSR) muss der Browser häufig umfangreiche Skripte herunterladen und ausführen. Eine schnelle HTML-Antwort verliert ihren Nutzen, wenn die Navigation oder ein Warenkorb erst nach mehreren Sekunden bedienbar wird.

Stelle sicher, dass Hauptinhalt, interne Links und Metadaten im ausgelieferten HTML stehen.
Kontrolliere, ob Server und Browser denselben Inhalt und dieselben Attribute erzeugen.
Nutze Caching für Seiten oder Daten, die nicht bei jedem Aufruf neu berechnet werden müssen.
Begrenze JavaScript auf Funktionen, die tatsächlich Interaktivität benötigen.
Überwache Statuscodes, Ladezeiten und Indexierungszustände nach jedem größeren Release.

Wann eignet sich SSR?

Server-Side Rendering (SSR) eignet sich besonders für öffentlich zugängliche Seiten, deren Inhalte schnell sichtbar, crawlbar und teilbar sein sollen. Dazu gehören Produktseiten, Kategorien, redaktionelle Beiträge, Stellenanzeigen und B2B-Landingpages. Bei personalisierten Anwendungen hinter einem Login kann Client-Side Rendering ausreichen, wenn Suchmaschinenzugriff und eine sofortige HTML-Darstellung keine Anforderungen sind.

Die Architektur sollte sich am Seitentyp orientieren. Ein Onlineshop kann Kategorien und Produkte serverseitig ausliefern, während Filter, Merklisten und Warenkorbinteraktionen im Browser arbeiten. Dieses hybride Modell verbindet direkt verfügbares HTML mit dynamischen Funktionen. Bei einem Relaunch sollte die Rendering-Strategie bereits vor der Entwicklung geprüft werden, weil nachträgliche Architekturänderungen deutlich mehr Aufwand verursachen können. Die Checkliste für einen SEO-sicheren Website-Relaunch zeigt weitere technische Prüfpunkte.

Eine strukturierte Analyse sollte außerdem klären, welche Seitentypen Google crawlt, welche Inhalte im HTML fehlen und wo Ladezeit oder Hydration auffällig sind. Ein technisches SEO-Audit verbindet diese Befunde mit konkreten Prioritäten. Ergänzende Grundlagen findest du im Ratgeber zum Management technischer SEO-Fehler.

Häufige Fragen zu SSR

Ist Server-Side Rendering gut für SEO?

Server-Side Rendering kann SEO erleichtern, weil Inhalte, Links und Metadaten direkt im HTML verfügbar sind. Gute Rankings entstehen daraus allein nicht. Inhaltliche Relevanz, interne Verlinkung, Indexierungssteuerung, Ladeleistung und externe Signale bleiben erforderlich.

Kann Google clientseitig gerenderte Seiten indexieren?

Google kann viele JavaScript-Seiten rendern und indexieren. Fehlerhafte Skripte, blockierte Ressourcen oder lange Ladeprozesse können die Verarbeitung jedoch erschweren. Wichtige Inhalte und Links sollten deshalb möglichst zuverlässig und früh verfügbar sein.

Was bedeutet Hydration bei SSR?

Hydration bezeichnet die Aktivierung eines bereits serverseitig erzeugten HTML-Dokuments durch JavaScript. Der Browser verbindet dabei sichtbare Komponenten mit Ereignissen und Anwendungslogik, damit beispielsweise Filter, Menüs oder Formulare interaktiv werden.

Ist SSR immer schneller als Client-Side Rendering?

SSR ist nicht grundsätzlich schneller. Eine schnelle Serverantwort kann Inhalte früh anzeigen, während langsame Datenabfragen die TTFB erhöhen. Umfangreiches JavaScript kann die Interaktivität zusätzlich verzögern. Entscheidend sind reale Messwerte für den jeweiligen Seitentyp.

Wie erkenne ich, ob eine Website SSR verwendet?

Öffne den ursprünglichen Seitenquelltext und suche nach einer sichtbaren Überschrift oder einem zentralen Text. Ist der Inhalt bereits dort vorhanden, wurde er serverseitig oder statisch erzeugt. Das verwendete Framework lässt sich daraus nicht immer eindeutig bestimmen.

Was ist der Unterschied zwischen SSR und Pre-Rendering?

SSR erzeugt HTML üblicherweise bei einer Anfrage oder liefert eine zwischengespeicherte Antwort aus. Pre-Rendering erzeugt Seiten bereits vor dem Aufruf, beispielsweise während eines Build-Prozesses. Beide Verfahren stellen Crawlern und Browsern vollständiges HTML bereit.

Wenn du klären möchtest, ob deine Rendering-Architektur Inhalte zuverlässig an Google und andere Crawler ausliefert, kannst du die technische Ausgangslage unverbindlich prüfen lassen.

Kostenlosen Potenzialcheck anfragen

Sie haben noch Fragen?

Kontaktieren Sie uns