Was ist Server Side Rendering?

Server Side Rendering (SSR) ist ein Verfahren, bei dem der Webserver das vollständige HTML einer Seite erzeugt, bevor er es an Browser oder Crawler schickt. Text, Links und strukturierte Daten stehen damit bereits in der ersten Antwort des Servers und sind ohne JavaScript lesbar. Das Gegenstück ist Client Side Rendering, bei dem erst JavaScript im Browser den Inhalt der Seite aufbaut.

Kurzprofil des Begriffs

Wie funktioniert Server Side Rendering?

Server Side Rendering läuft in 4 Schritten ab: Anfrage, Erzeugung auf dem Server, Auslieferung des fertigen HTML und Aktivierung im Browser. Der entscheidende Schritt ist der zweite, weil dort der Inhalt entsteht, bevor irgendein JavaScript beim Besucher läuft.

1. Schritt 1, Anfrage: Ein Browser oder ein Crawler fordert eine URL an.
2. Schritt 2, Erzeugung: Der Server lädt die Daten aus der Datenbank, setzt sie in die Vorlage ein und erzeugt daraus das vollständige HTML der Seite.
3. Schritt 3, Auslieferung: Der Server schickt das fertige HTML. Browser zeigen den Inhalt sofort an, Crawler können ihn sofort lesen.
4. Schritt 4, Aktivierung: Moderne JavaScript-Frameworks laden anschließend ihren Code und machen die Seite interaktiv. Diesen Schritt nennt man Hydration.

Klassische Content-Management-Systeme rendern seit jeher serverseitig. WordPress erzeugt jede Seite mit PHP auf dem Server, auch wenn ein Seitenbaukasten das Layout gestaltet. Ein Beispiel aus diesem Glossar: Der Beitrag zu JavaScript-SEO liefert seine rund 1.200 Wörter bereits im ersten HTML-Dokument aus, gemessen am 5. Oktober 2026 ohne ausgeführtes JavaScript.

Was ist der Unterschied zwischen Server Side Rendering und Client Side Rendering?

Beim Server Side Rendering baut der Server die Seite, beim Client Side Rendering baut sie der Browser mit JavaScript. Beim Client Side Rendering liefert der Server zunächst eine fast leere HTML-Hülle und ein JavaScript-Paket; erst wenn das Skript gelaufen ist, erscheinen Text und Links.

Was es für Suchmaschinen bedeutet, wenn Inhalte erst per JavaScript entstehen, vertieft der Beitrag zu JavaScript-SEO.

Welche Rendering-Arten gibt es?

Es gibt 5 verbreitete Rendering-Arten: Server Side Rendering, Client Side Rendering, Static Site Generation, Hydration als Kombination und Dynamic Rendering. Sie unterscheiden sich darin, wann und wo das HTML entsteht.

1. Server Side Rendering: Das HTML entsteht bei jeder Anfrage neu auf dem Server.
2. Client Side Rendering: Das HTML entsteht im Browser des Besuchers durch JavaScript.
3. Static Site Generation: Das HTML entsteht einmal beim Veröffentlichen und liegt danach als fertige Datei bereit. Static Site Generation ist für Crawler genauso gut lesbar wie Server Side Rendering und meist schneller.
4. Hydration: Der Server liefert fertiges HTML, das JavaScript macht es danach interaktiv. Google nennt Hydration ausdrücklich als empfohlene Lösung.
5. Dynamic Rendering: Der Server liefert Crawlern eine vorgerenderte Fassung und Besuchern die JavaScript-Fassung. Google bezeichnet Dynamic Rendering in seiner Dokumentation als Übergangslösung, die zusätzliche Komplexität schafft, und empfiehlt Server Side Rendering, Static Rendering oder Hydration.

Warum ist Server Side Rendering für SEO wichtig?

Server Side Rendering sorgt dafür, dass Google den Inhalt einer Seite beim ersten Abruf vollständig sieht und keine zweite Verarbeitungsstufe abwarten muss. Google kann JavaScript ausführen, erledigt das aber in einem eigenen Rendering-Schritt nach dem Crawling.

Eine Untersuchung von Vercel und MERJ hat im April 2024 über 100.000 Abrufe von Googlebot ausgewertet. Google renderte dort alle HTML-Seiten vollständig, auch Seiten mit aufwendigem JavaScript. Die Verzögerung bis zum Rendern lag im Median bei 10 Sekunden, beim 90. Perzentil aber bei rund 3 Stunden und beim 99. Perzentil bei rund 18 Stunden. Für die Indexierung heißt das: Clientseitig gerenderte Inhalte kommen bei Google an, oft aber später, und jeder Fehler im Skript kann den Inhalt ganz verhindern.

Google selbst empfiehlt serverseitiges Rendern oder Vorrendern weiterhin, weil es Websites für Nutzer und Crawler schneller macht und weil nicht jeder Bot JavaScript ausführt. Liefert eine JavaScript-Anwendung für fehlende Seiten eine leere Hülle mit Statuscode 200, entstehen außerdem leicht Soft 404, die Google aus dem Index nimmt.

Warum entscheidet Server Side Rendering über die Sichtbarkeit in KI-Systemen?

Die meisten KI-Crawler führen kein JavaScript aus und lesen nur das HTML, das der Server direkt liefert. Was erst im Browser entsteht, existiert für sie nicht. Das zeigt eine Auswertung von Vercel vom Dezember 2024:

• Kein Rendering: Keiner der großen KI-Crawler von OpenAI, Anthropic, Meta, ByteDance und Perplexity rendert JavaScript.
• Skripte geladen, nicht ausgeführt: Der Crawler von ChatGPT ruft bei 11,50 Prozent seiner Abrufe JavaScript-Dateien ab, der von Claude bei 23,84 Prozent. Ausgeführt wird der Code nicht.
• Großes Volumen: GPTBot kam im Untersuchungszeitraum auf 569 Millionen Abrufe im Monat, der Crawler von Claude auf 370 Millionen. Googlebot lag bei 4,5 Milliarden.
• Ausnahmen: Applebot rendert JavaScript über einen browserbasierten Crawler. Gemini nutzt die Infrastruktur von Googlebot.

Eine Website, die ihre Inhalte clientseitig rendert, ist für ChatGPT, Claude und Perplexity damit eine leere Seite. Sie kann in deren Antworten weder zitiert noch empfohlen werden, egal wie gut der Inhalt ist. Welche KI-Crawler es gibt und wie du sie über die robots.txt steuerst, beschreibt der Ratgeber KI-Crawler steuern.

Wie prüfst du, ob deine Website serverseitig rendert?

Ob eine Website serverseitig rendert, zeigen 3 einfache Tests, die alle das HTML vor dem JavaScript betrachten. Steht der Text der Seite dort bereits, ist die Seite für Crawler ohne JavaScript lesbar.

1. Quelltext ansehen: Mit Strg + U oder dem Präfix view-source: vor der URL zeigt der Browser das HTML, das der Server geschickt hat. Such dort nach einem Satz aus dem sichtbaren Text.
2. JavaScript abschalten: In den Entwicklerwerkzeugen des Browsers lässt sich JavaScript deaktivieren. Bleibt die Seite danach leer, rendert sie clientseitig.
3. Abruf ohne Browser: Ein Abruf per Kommandozeile zeigt die Rohantwort genau so, wie ein KI-Crawler sie erhält:

curl -s https://www.deine-domain.de/ | grep -c "Ein Satz aus deinem Text"

Ergibt der Befehl 0, steht der Satz nicht im gelieferten HTML. Die URL-Prüfung der Google Search Console ergänzt die Tests: Sie zeigt das gerenderte HTML aus Sicht von Googlebot und damit, was Google nach dem Rendering-Schritt sieht.

Welche Nachteile hat Server Side Rendering?

Server Side Rendering verlagert Arbeit auf den Server und erhöht dadurch die Serverlast und oft die Antwortzeit. Drei Punkte gehören zur Planung:

• Antwortzeit: Erzeugt der Server jede Seite bei jedem Abruf neu, steigt die Time to First Byte. Ein Seiten-Cache oder ein Content Delivery Network liefert fertig erzeugte Seiten aus und gleicht das aus.
• Interaktivität: Bei der Hydration lädt das JavaScript nach dem HTML. Große Skriptpakete verzögern, wann die Seite auf Eingaben reagiert, obwohl der Inhalt schon sichtbar ist.
• Komplexität: Frameworks im SSR-Modus brauchen einen Server, der JavaScript ausführen kann, und eine durchdachte Cache-Strategie.

Für die Ladezeit wiegt der Vorteil meist schwerer. Weil der Inhalt mit der ersten Antwort kommt, erscheint das größte sichtbare Element früher, und der Largest Contentful Paint sinkt. Websites, die für Suchmaschinen und KI-Systeme gleichermaßen lesbar sein sollen, bauen wir deshalb serverseitig gerendert, beschrieben auf unserer Seite zum SEO-Webdesign.

Häufige Fragen zu Server Side Rendering

Rendert WordPress serverseitig?
WordPress rendert serverseitig, weil PHP jede Seite auf dem Server erzeugt. Ausnahmen sind einzelne Plugins oder Widgets, die ihre Inhalte erst per JavaScript nachladen.

Ist Dynamic Rendering noch zu empfehlen?
Google bezeichnet Dynamic Rendering als Übergangslösung und empfiehlt es nicht mehr. Server Side Rendering, Static Site Generation oder Hydration sind die langfristigen Lösungen.

Braucht jede Website Server Side Rendering?
Jede Website, deren Inhalte in Suchmaschinen und KI-Antworten erscheinen sollen, profitiert von serverseitig gerendertem oder statisch erzeugtem HTML. Anwendungen hinter einem Login, die gar nicht gefunden werden sollen, kommen mit Client Side Rendering aus.