Bei einem Relaunch mit React, Vue oder Angular kommt früher oder später die Frage auf, wo die Seiten entstehen sollen: im Browser des Besuchers oder auf dem Server. Für Entwickler ist das eine Architekturfrage. Für die Suchmaschinenoptimierung entscheidet sie darüber, wie schnell Google Ihre Inhalte sieht, ob andere Crawler sie überhaupt sehen und wie flüssig sich die Seite auf schwächeren Geräten bedienen lässt. Diese Seite vergleicht Client-Side und Server-Side Rendering aus SEO-Sicht und nennt, was Google selbst dazu schreibt.
Kurze Definitionen finden Sie im Glossar unter Client-Side Rendering und Server-Side Rendering.
Die Begriffe
Die Entwicklerseite web.dev von Google beschreibt Server-Side Rendering als das Rendern einer Anwendung auf dem Server, um HTML statt JavaScript an den Client zu senden. Client-Side Rendering ist dort das Rendern im Browser, wobei JavaScript das DOM verändert [2]. Dazwischen gibt es Mischformen. Beim statischen Rendering entsteht für jede Adresse schon beim Erstellen der Website eine fertige HTML-Datei. Bei der Hydration übernimmt JavaScript im Browser eine vom Server gelieferte Seite und macht sie interaktiv [2].
Für Besucher sehen alle Varianten am Ende gleich aus. Der Unterschied liegt darin, was im ersten Abruf ankommt. Beim Server-Side Rendering ist der Inhalt schon im HTML. Beim reinen Client-Side Rendering enthält die erste Antwort oft nur ein leeres Gerüst und Verweise auf Skripte.
Wie Google JavaScript-Seiten verarbeitet
Google beschreibt drei Phasen: Crawling, Rendering und Indexierung [1]. Der Googlebot ruft eine Adresse ab, liest das HTML und reiht die Seite für das Rendering ein. Laut Google werden Seiten mit dem Statuscode 200 an die Rendering-Warteschlange gesendet, unabhängig davon, ob JavaScript vorhanden ist, sofern kein robots-Meta-Tag und kein Header die Indexierung untersagt [1]. Zur Wartezeit heißt es: "Die Seite verbleibt möglicherweise nur einige Sekunden in dieser Warteschlange, es kann jedoch auch länger dauern." [1] Erst danach wertet Google das gerenderte HTML aus, findet darin weitere Links und nutzt es für die Indexierung.
Für Client-Side Rendering heißt das: Google kann die Inhalte sehen, aber erst nach einem zusätzlichen Schritt. Für Server-Side Rendering heißt es: Die Inhalte und Links sind schon im ersten Abruf da.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Was Google empfiehlt
Google schreibt in den Grundlagen zu JavaScript-SEO: "Serverseitiges oder Pre-Rendering ist trotzdem eine sehr gute Option," und begründet das damit, dass die Website für Nutzer und Crawler schneller wird und nicht alle Bots JavaScript ausführen können [1]. Das zweite Argument wird oft unterschätzt. Google rendert JavaScript, aber nicht jeder andere Dienst, der Ihre Seiten abruft, tut das.
Deutlich ist Google auch beim dynamischen Rendering, also der Auslieferung einer vorgerenderten Fassung nur an Crawler: "Dynamisches Rendering ist eine Behelfslösung und stellt keine empfohlene Lösung dar" [3]. Google empfiehlt stattdessen serverseitiges Rendering, statisches Rendering oder Hydration [3]. Mehr dazu im Ratgeber dynamisches Rendering.
Vergleich aus SEO-Sicht
| Punkt | Client-Side Rendering | Server-Side oder statisches Rendering |
|---|---|---|
| Inhalt im ersten Abruf | oft nur Gerüst | vollständig |
| Verarbeitung durch Google | nach dem Rendering | Inhalt schon im HTML, Rendering folgt trotzdem |
| Crawler ohne JavaScript | sehen wenig oder nichts | sehen den Inhalt |
| Interaktion (INP) | JavaScript wächst mit der Anwendung | meist weniger JavaScript im Browser |
| Serverlast | gering | höher bei Rendering je Anfrage, gering bei statischen Dateien |
Die Zeilen zur Leistung stützen sich auf web.dev. Dort heißt es, dass beim Client-Side Rendering die Menge an JavaScript mit der Anwendung tendenziell wächst, was die Interaktion verschlechtern kann. Server-Side Rendering führt meist zu einem schnellen ersten Bild und weniger JavaScript im Browser, kann aber die Antwortzeit des Servers erhöhen, wenn jede Seite bei der Anfrage erzeugt wird [2].
Fallen bei clientseitigem Rendering
Unabhängig von der Rendering-Art nennt Google einige Regeln für JavaScript-Websites [1]. Sie sind bei Client-Side Rendering besonders wichtig:
- Links müssen als a-Element mit href vorliegen. Navigation über Klick-Ereignisse findet Google nicht zuverlässig.
- Single-Page-Anwendungen sollen die History API statt Fragmenten mit Rautezeichen für ihre Adressen nutzen.
- Fehlerseiten brauchen einen echten Fehlerstatus, etwa über eine Weiterleitung auf eine Adresse mit 404 oder ein per JavaScript gesetztes noindex. Sonst entstehen Soft-404-Fehler.
- Steht noindex im ausgelieferten HTML, überspringt Google womöglich das Rendering. Ein späteres Entfernen per JavaScript hilft dann nicht.
- Ein per JavaScript gesetzter Canonical darf nicht von dem im HTML abweichen.
Mehr zu Links in JavaScript-Anwendungen steht im Ratgeber JavaScript Links und Navigation.
Die Mischformen in der Praxis
Viele aktuelle Frameworks erlauben Server-Side Rendering, statische Erzeugung und clientseitige Teile im selben Projekt. Damit lässt sich je Seitentyp entscheiden. Web.dev rät, zuerst die Engpässe zu messen und statisches oder serverseitiges Rendering zu prüfen, bevor man schwerere Ansätze wählt. Je nach Seite kann eine Mischung sinnvoll sein [2].
Eine Warnung gilt der Hydration. Laut web.dev kann sie den ersten sichtbaren Inhalt beschleunigen, die Interaktion aber deutlich verschlechtern, weil die Seite fertig aussieht, bevor sie auf Eingaben reagiert [2]. Für Besucher wirkt das wie eine hängende Seite. In den Core Web Vitals zeigt sich das als schlechter INP, siehe Core Web Vitals auf Mobilgeräten.
Nach unserer Erfahrung brauchen Inhaltsseiten wie Ratgeber, Leistungsseiten und Kategorien kaum clientseitige Logik. Für sie ist statisches oder serverseitiges Rendering fast immer die einfachere Wahl. Clientseitiges Rendering lohnt sich für Bereiche, die ohnehin nicht in die Suche gehören, etwa Kundenkonten, Konfiguratoren oder interne Werkzeuge.
Umstellung von CSR auf SSR
Wer eine bestehende clientseitige Anwendung auf serverseitiges Rendering umstellt, ändert für Google mehr, als es auf den ersten Blick scheint. Title, Meta-Beschreibung, Canonical und strukturierte Daten kommen danach aus dem Server und nicht mehr aus einem Skript. Vergleichen Sie deshalb vor dem Livegang für jeden Seitentyp das bisher gerenderte HTML mit dem neuen Quelltext. Die Adressen sollten gleich bleiben. Falls sie sich ändern, brauchen Sie Weiterleitungen, wie im Ratgeber Canonical oder 301 beschrieben. Achten Sie auch darauf, dass die Testumgebung nicht von Suchmaschinen gecrawlt werden kann.
So prüfen Sie Ihre Website
Rufen Sie eine wichtige Seite auf und lassen Sie sich den Quelltext anzeigen, nicht das Element-Fenster der Entwicklerwerkzeuge. Steht dort Ihr Haupttext? Dann ist er im ersten Abruf enthalten. Steht dort nur ein leeres Element und eine Liste von Skripten, rendert die Seite clientseitig. Danach vergleichen Sie im URL-Prüftool der Search Console das gerenderte HTML mit dem, was Sie im Browser sehen. Fehlen dort Inhalte oder Links, sieht Google sie auch nicht.
Wie Google selbst rendert und welche Grenzen es dabei gibt, beschreibt der Ratgeber Rendering durch Google. Einen Überblick über Frameworks gibt JavaScript-Frameworks und SEO.
Steht bei Ihnen ein Relaunch mit einem JavaScript-Framework an und Sie möchten die Rendering-Frage vorher klären? Stellen Sie sie in der gratis Sprechstunde. Die Begleitung des Relaunchs aus SEO-Sicht übernimmt SEO NW im Rahmen der Website-Migration.
- Organisation Grundlagen von JavaScript-SEO. Google Search Central. Stand 04.03.2026. abgerufen am 31.10.2026
- Organisation Rendering on the Web. web.dev (Google), Addy Osmani, Jason Miller. Stand 05.01.2026. abgerufen am 31.10.2026
- Organisation Dynamisches Rendering als Behelfslösung. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
Häufige Fragen
Kann Google clientseitig gerenderte Seiten indexieren?
Ja. Google rendert Seiten mit dem Statuscode 200 und indexiert das gerenderte HTML. Das geschieht aber in einem zusätzlichen Schritt nach dem Crawling, und die Wartezeit kann von einigen Sekunden bis länger reichen.
Warum empfiehlt Google trotzdem serverseitiges Rendering?
Google nennt zwei Gründe: Die Website wird für Nutzer und Crawler schneller, und nicht alle Bots können JavaScript ausführen.
Ist dynamisches Rendering noch eine Lösung?
Google bezeichnet es als Behelfslösung und nicht als empfohlene Lösung. Empfohlen werden serverseitiges Rendering, statisches Rendering oder Hydration.
Wie sehe ich, ob meine Seite clientseitig rendert?
Im Quelltext der Seite. Steht dort der Haupttext, ist er im ersten Abruf enthalten. Das gerenderte HTML aus Sicht von Google zeigt das URL-Prüftool der Search Console.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.
