Client-Side Rendering (CSR)

Client-Side Rendering ist eine Auslieferungsmethode für Webseiten. Nach einer ersten HTML-Antwort führt der Browser JavaScript aus, das die Seiteninhalte zusammensetzt.

Bedeutung und Umfang

Bei CSR kann der Server ein schlankes HTML-Grundgerüst zurückgeben, und JavaScript lädt oder erzeugt die eigentlichen Inhalte im Browser. Das kann bei stark interaktiven Anwendungen sinnvoll sein, schafft aber eine zusätzliche Abhängigkeitskette: HTML, Skripte, APIs und Rendering-Logik müssen alle funktionieren, damit Crawler und Besucher denselben wichtigen Inhalt erhalten.

Illustration des Mechanismus, der bei Client-Side Rendering (CSR) behandelt wird.

Praktischer Ablauf

Beginnen Sie mit den Anforderungen, die für Nutzer und Crawler sichtbar sein müssen. Prüfen Sie, ob Title, Haupttext, Canonical-Tag, robots-Anweisungen, interne Links, Bilder und strukturierte Daten bereits im ersten HTML stehen oder erst nach der Ausführung von JavaScript erscheinen. Wird wichtiger Inhalt für die Auffindbarkeit verzögert, wählen Sie eine Architektur, die ihn zuverlässig liefert, etwa Server-Rendering, statische Generierung oder einen getesteten Hybridansatz.

Was Sie prüfen sollten

Vergleichen Sie einen rohen HTML-Abruf mit einer gerenderten Prüfung für eine Auswahl typischer Templates. Stellen Sie sicher, dass JavaScript-Ressourcen nicht blockiert werden, Datenanfragen ohne private Session erfolgreich sind, die Canonical-Angabe stabil bleibt und Fehlerzustände den Hauptinhalt nicht ersetzen. Google empfiehlt, JavaScript-Anwendungen zu testen, statt anzunehmen, dass der Name eines Frameworks die Crawlbarkeit garantiert.

Grenzen und typische Fehler

Bezeichnen Sie CSR nicht pauschal als schlecht für SEO und gehen Sie nicht davon aus, dass ein Crawler nichts sieht. Entscheidend ist, ob die benötigten Inhalte und Metadaten nach dem tatsächlichen Rendering-Pfad durchgehend verfügbar sind. Vermeiden Sie eine separate Variante nur für Bots, es sei denn, sie bleibt gleichwertig und wartbar.

Rendering-Prüfungen anhand eines konkreten Routenbeispiels

Nehmen Sie eine Route wie /guides/rendering. Rufen Sie sie ohne Browserstatus ab und speichern Sie den Antwortkörper. Laden Sie dann dieselbe Route in einer sauberen Browsersitzung und prüfen Sie das gerenderte DOM, die Konsole und das Netzwerk-Panel. Beide Ansichten müssen nicht byte-identisch sein, aber der Zweck der Route muss erhalten bleiben: Ein brauchbarer Title, die Hauptüberschrift, der zentrale Text, die Canonical-Angabe, crawlbare Links und wichtige strukturierte Daten sollten ohne authentifizierten API-Aufruf, Timing-Problem oder clientseitige Exception verfügbar sein.

html
<a href="/guides/rendering">Rendering guide</a>\n<link rel="canonical" href="https://example.test/guides/rendering">

Bei einem App-Shell-Fehler enthält das initiale HTML möglicherweise nur ein Root-Element, während die Datenanfrage mit 401, 403, 404 oder einer JavaScript-Exception scheitert. Ein Mensch sieht nach dem Login vielleicht eine gecachte Seite, während ein sauberer Renderer eine leere Hülle sieht. Die Route darf nicht als erfolgreiche 200-Antwort dargestellt werden. Stattdessen gilt es, den Fehlerpfad einzuordnen, die nötigen öffentlichen Daten für diese Route bereitzustellen oder für Inhalte, die sofort ausgeliefert werden müssen, Server- oder statisches Rendering zu wählen.

Google dokumentiert eine Pipeline aus Crawling, Rendering und Indexierung für JavaScript-Seiten. Eine 200-Antwort kann in die Rendering-Warteschlange gelangen, aber blockierte Seiten oder blockierte JavaScript-Ressourcen werden nicht gerendert. Google empfiehlt außerdem das URL-Prüftool oder den Rich-Results-Test, um geladene Ressourcen, Konsolenausgaben, Exceptions und das gerenderte DOM zu prüfen. Nutzen Sie diese Werkzeuge als unterstützenden Hinweis und vergleichen Sie sie mit einem aktuellen anonymen Browsertest. Client-Analytics bildet die Rendering-Aktivität des Googlebots nicht vollständig ab.

Vermeiden Sie dynamisches Rendering als Standardlösung für die Architektur. Google beschreibt es als Notbehelf, nicht als langfristige Lösung. Verzichten Sie auf Cloaking: Inhalte, die an einen Crawler ausgeliefert werden, müssen dem entsprechen, was ein Nutzer erhält. Halten Sie Route, Nutzerstatus, rohe Antwort, gerendertes Ergebnis und den Status fehlgeschlagener Ressourcen fest, damit ein späteres Framework-Update anhand derselben Belege geprüft werden kann.

FAQ

Kann Google JavaScript-gerenderte Inhalte indexieren?
Ja, aber die benötigten Ressourcen und Inhalte müssen erreichbar sein und fehlerfrei rendern.
Wann sollte Server-Rendering in Betracht gezogen werden?
Ziehen Sie es in Betracht, wenn wichtige öffentliche Inhalte unzuverlässig sind oder sich vor der Ausführung clientseitiger Skripte nur schwer finden lassen.