Client-Side Rendering (CSR)

Was ist Client-Side Rendering (CSR)?

Client-Side Rendering (CSR) ist ein Verfahren, bei dem der Browser JavaScript ausführt und daraus den sichtbaren Seiteninhalt erzeugt. Der Webserver liefert zunächst meist ein HTML-Grundgerüst sowie Skriptdateien. Erst nach deren Download und Verarbeitung entstehen Texte, Navigation, Links und interaktive Elemente im Document Object Model des Browsers.

So funktioniert Client-Side Rendering

Client-Side Rendering (CSR), deutsch: clientseitiges Rendering, verlagert die Seitenerzeugung vom Webserver in den Browser. Beim ersten Aufruf erhält der Browser häufig nur ein schlankes HTML-Dokument mit Verweisen auf JavaScript-Dateien. Das JavaScript lädt anschließend Daten über Schnittstellen und setzt daraus die sichtbare Seite zusammen.

Der typische Ablauf besteht aus mehreren voneinander abhängigen Schritten:

Der Browser fordert eine URL beim Server an.
Der Server liefert das HTML-Grundgerüst und Verweise auf JavaScript-Dateien.
Der Browser lädt, analysiert und führt die Skripte aus.
Das JavaScript ruft bei Bedarf Produkt-, Nutzer- oder Inhaltsdaten über eine API ab.
Die Anwendung ergänzt den Document Object Model, kurz DOM, um Texte, Links und Bedienelemente.

Ein HTTP-Statuscode 200 beweist bei Client-Side Rendering noch nicht, dass der relevante Inhalt verfügbar ist. Der Server kann eine technisch erfolgreiche Antwort senden, obwohl der ursprüngliche HTML-Quellcode nur einen leeren Container enthält. Schlägt danach ein Skript oder API-Aufruf fehl, bleibt die Seite für Nutzer und Crawler unvollständig. Prüfe deshalb neben dem Statuscode immer den gerenderten DOM.

Ein vereinfachtes Beispiel: Der Server liefert nur <div id='app'></div>. Erst JavaScript ergänzt Produktname, Preis, Beschreibung und Links. Ist die Skriptdatei blockiert oder fehlerhaft, enthält die Serverantwort weiterhin den Statuscode 200, die eigentlichen Produktinformationen fehlen jedoch.

Client-Side Rendering und SEO

Suchmaschinen müssen eine CSR-Seite zunächst crawlen, anschließend JavaScript ausführen und danach den gerenderten Inhalt auswerten. Crawling und Rendering sind getrennte Verarbeitungsschritte. Eine URL kann deshalb erreichbar sein, während wichtige Texte oder Links im gerenderten Ergebnis fehlen und folglich nicht zuverlässig für die Indexierung zur Verfügung stehen.

Google kann viele moderne JavaScript-Anwendungen verarbeiten. Diese Fähigkeit ist jedoch kein Freibrief für ein beliebiges technisches Setup. Externe Skripte, blockierte Ressourcen, fehlerhafte API-Aufrufe, notwendige Nutzeraktionen oder lange Verarbeitungsketten können verhindern, dass Google denselben Inhalt erhält wie ein realer Besucher. Ein technischer SEO-Audit sollte deshalb Roh-HTML, gerenderten DOM und indexierte Inhalte miteinander vergleichen.

Links müssen crawlbar bleiben

Interne Links aus Client-Side Rendering sollten als echte HTML-Links mit einem href-Attribut im gerenderten DOM stehen. Klickflächen mit reinen JavaScript-Ereignissen oder Navigationen, die erst nach einer Auswahl beziehungsweise Interaktion entstehen, sind für Crawler weniger verlässlich. Fehlt ein crawlbarer Link, kann eine inhaltlich wertvolle Unterseite trotz funktionierender Navigation für Nutzer schwer auffindbar bleiben.

Metadaten brauchen stabile Signale

Title, Meta Description, Canonical Tag und Robots-Angaben können durch JavaScript verändert werden. Problematisch wird das, wenn das ursprüngliche HTML und der gerenderte DOM widersprüchliche Signale enthalten. Ein Canonical Tag im Roh-HTML, das nach dem Rendering auf eine andere URL zeigt, erschwert die technische Bewertung. Lege indexierungsrelevante Angaben möglichst bereits serverseitig eindeutig fest.

Ladezeit bei CSR richtig bewerten

Client-Side Rendering verursacht nicht automatisch schlechte Core Web Vitals. Umfangreiche JavaScript-Pakete können jedoch den Hauptthread des Browsers länger belegen und die Darstellung des größten sichtbaren Elements verzögern. Zusätzliche API-Anfragen verlängern die Abhängigkeitskette weiter. Entscheidend sind daher Skriptmenge, Ausführungsdauer, Serverantworten, Caching und die Reihenfolge der geladenen Ressourcen.

Messbar ist das zum Beispiel so: Vergleiche das ursprüngliche HTML mit dem gerenderten DOM, deaktiviere testweise JavaScript und kontrolliere, welche Inhalte und Links übrig bleiben. Ein Technik-Crawler mit anpassbarem JavaScript-Crawling kann technische Ressourcen, gerenderte Elemente und Crawl-Fehler systematisch prüfen.

Prüfe ergänzend die Ladezeit der wichtigsten Seitentypen unter mobilen Bedingungen:

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)

Rendering-Verfahren im Vergleich

Der Unterschied zwischen Client-Side Rendering und Server-Side Rendering liegt im Zeitpunkt und Ort der Seitenerzeugung. CSR erzeugt den wesentlichen Inhalt im Browser. Server-Side Rendering, kurz SSR, erzeugt das fertige HTML bei der Anfrage auf dem Server. Static Site Generation, kurz SSG, erstellt HTML-Dateien bereits vor dem Seitenaufruf.

Verfahren	Erzeugung des HTML	Typischer Vorteil	Technische SEO-Prüfung
Client-Side Rendering	Im Browser nach dem Laden von JavaScript	Interaktive Anwendung ohne vollständige Seitenwechsel	Roh-HTML und gerenderten DOM vergleichen
Server-Side Rendering	Auf dem Server bei jeder Anfrage	Inhalt steht früh als HTML bereit	Serverantwort, Canonicals und Statuscodes prüfen
Static Site Generation	Vorab während des Build-Prozesses	Schnelle Auslieferung fertiger HTML-Dateien	Aktualisierung und Vollständigkeit des Builds prüfen
Hydration	HTML vom Server, Interaktivität im Browser	Früh sichtbarer Inhalt plus JavaScript-Funktionen	Abweichungen vor und nach der Hydration kontrollieren

Eine Single Page Application, kurz SPA, ist nicht mit Client-Side Rendering gleichzusetzen. Eine SPA lädt bei der Navigation meist kein vollständiges neues HTML-Dokument. Sie kann trotzdem serverseitig vorgerendert oder hybrid ausgeliefert werden. CSR beschreibt die Rendering-Methode, während SPA die Architektur und Navigation der Webanwendung bezeichnet.

Typische CSR-Fehler beheben

Technische Probleme entstehen oft an der Schnittstelle zwischen Serverantwort, JavaScript und Datenquelle. Bei umfangreichen Onlineshops betrifft ein Fehler schnell zahlreiche Produkt- oder Kategorieseiten, weil dieselbe Komponente in mehreren Templates eingesetzt wird. Die laufende Kontrolle technischer SEO-Fehler sollte daher wichtige Seitentypen und nicht nur die Startseite abdecken.

Leeres Roh-HTML: Stelle zentrale Texte und Navigation bereits im ausgelieferten HTML oder über SSR bereit.
Blockierte Skripte: Erlaube Suchmaschinen den Zugriff auf JavaScript-, CSS- und API-Ressourcen, die für das Rendering erforderlich sind.
Fehlende HTML-Links: Verwende crawlbare Verweise mit vollständigem href-Attribut.
Inhalte erst nach Interaktion: Lade indexierungsrelevante Informationen ohne Scrollen, Klick oder Formulareingabe.
Unklare Fehlerzustände: Liefere für nicht vorhandene Inhalte einen passenden HTTP-Statuscode statt einer leeren Anwendung mit Statuscode 200.

Ein verbreiteter Prüfungsfehler besteht darin, nur den sichtbaren Browserinhalt zu kontrollieren. Browsererweiterungen, Cookies oder bereits gespeicherte Daten können eine funktionierende Seite zeigen, obwohl ein Crawler beim ersten Aufruf leeres HTML erhält. Teste wichtige URLs deshalb in einer neuen Sitzung und mit einem Rendering-Crawler.

Wann ist CSR sinnvoll?

Client-Side Rendering eignet sich für Anwendungen mit häufigen Zustandsänderungen und intensiver Interaktion, etwa Dashboards, Konfiguratoren oder geschützte Kundenbereiche. Für öffentlich auffindbare Produktseiten, Kategorien, Ratgeber und Landingpages ist eine serverseitige oder hybride Ausgabe oft robuster, weil zentrale Inhalte direkt im HTML vorliegen.

Die Wahl des Rendering-Verfahrens sollte sich nach Seitentyp und Suchintention richten. Eine Website kann mehrere Verfahren kombinieren: Indexierungsrelevante Inhalte kommen vom Server, während Filter, Warenkorb oder persönliche Einstellungen im Browser aktualisiert werden. Bei einer Website-Entwicklung mit SEO-Fokus sollte diese Zuordnung vor der technischen Umsetzung feststehen.

Client-Side Rendering betrifft auch GEO, also Generative Engine Optimization. KI-Crawler und andere automatisierte Systeme verfügen nicht zwingend über dieselben Rendering-Fähigkeiten wie Google. Wichtige Definitionen, Unternehmensinformationen, Produktdaten und semantische HTML-Strukturen sollten deshalb ohne komplexe Nutzerinteraktion abrufbar sein. JavaScript-only-Inhalte ohne Server-Fallback erschweren die Extraktion und Zuordnung.

Häufige Fragen zu Client-Side Rendering

Ist Client-Side Rendering schlecht für SEO?

Client-Side Rendering ist nicht grundsätzlich schlecht für SEO. Risiken entstehen, wenn Texte, Links oder Metadaten erst nach fehleranfälligen Skript- und API-Aufrufen verfügbar werden. Eine hybride oder serverseitige Ausgabe zentraler Inhalte erhöht die technische Stabilität.

Kann Google CSR-Seiten indexieren?

Google kann JavaScript ausführen und viele CSR-Seiten indexieren. Voraussetzung ist, dass benötigte Ressourcen erreichbar sind, das Rendering ohne Nutzeraktion funktioniert und der gerenderte Inhalt eindeutige Indexierungssignale enthält.

Wie erkenne ich Client-Side Rendering auf einer Website?

Vergleiche den Seitenquelltext mit dem DOM in den Entwicklertools des Browsers. Enthält der Quelltext nur wenige Container, während Texte und Links erst im DOM erscheinen, wird der betreffende Inhalt wahrscheinlich durch JavaScript erzeugt.

Ist eine React- oder Vue-Website immer Client-Side Rendering?

React, Vue und vergleichbare Frameworks können Inhalte im Browser, auf dem Server oder während eines Build-Prozesses erzeugen. Das eingesetzte Framework allein sagt deshalb nicht aus, welches Rendering-Verfahren eine Website verwendet.

Kann strukturiertes Daten-Markup per JavaScript eingefügt werden?

Strukturierte Daten können per JavaScript in den DOM eingefügt werden. Eine serverseitige Ausgabe ist robuster, weil das Markup bereits in der ersten HTML-Antwort vorliegt und nicht von einer erfolgreichen Skriptausführung abhängt.

Was bedeutet Hydration bei einer Website?

Bei der Hydration erhält der Browser bereits gerendertes HTML vom Server. JavaScript verbindet dieses HTML anschließend mit Ereignissen und Anwendungslogik, damit die Seite interaktiv wird. Fehler bei der Hydration können sichtbare Inhalte verändern oder Bedienelemente unbrauchbar machen.

Wenn du das Rendering deiner Website technisch einordnen und konkrete Fehler priorisieren möchtest, kannst du einen unverbindlichen Potenzialcheck anfragen.

Kostenlosen Potenzialcheck anfragen

Sie haben noch Fragen?

Kontaktieren Sie uns