Client-Side Rendering: Wenn Menschen alles sehen und Maschinen nur eine leere Seite

Was bedeutet Client-Side Rendering?

Bei klassisch servergerenderten Websites liefert der Server bereits eine HTML-Seite, die wesentliche Inhalte enthält.

Beim Client-Side Rendering, kurz CSR, kann der Server dagegen zunächst hauptsächlich ein technisches Grundgerüst ausliefern. Erst JavaScript lädt anschliessend Inhalte und baut daraus die sichtbare Seite.

Für einen Menschen im modernen Browser kann das hervorragend funktionieren.

Für Crawler ist die Situation weniger eindeutig.

Warum Websites CSR einsetzen

Client-Side Rendering hat legitime Vorteile.

Komplexe Anwendungen können sehr interaktiv reagieren. Teile der Seite lassen sich aktualisieren, ohne eine komplette neue Seite vom Server zu laden. Frontend-Teams können anspruchsvolle Nutzeroberflächen und App-ähnliche Anwendungen entwickeln.

Für eingeloggte Anwendungen und Software-Dashboards kann das eine ausgezeichnete Architektur sein.

Client-Side Rendering und Maschinenlesbarkeit müssen kein Widerspruch sein. Die zentrale Architekturfrage ist, wie eine interaktive Nutzeroberfläche mit Inhalten verbunden wird, die für Crawler und KI-Systeme zuverlässig verfügbar bleiben.

Entscheidend ist deshalb weniger das verwendete Framework als der tatsächliche Output: Welche Informationen liefert der Server bereits mit dem ersten HTML und welche entstehen erst nach JavaScript-Ausführung?

Google kann JavaScript ausführen. Das löst aber nicht jedes Problem.

Google verarbeitet JavaScript und rendert moderne Websites. Eine clientseitig gerenderte Seite ist deshalb nicht automatisch unsichtbar für Google.

Die Verarbeitung erfolgt jedoch in mehreren Phasen. Zunächst wird die Seite gecrawlt, danach kann sie gerendert und anschliessend indexiert werden.

Nicht jeder Crawler verfügt über dieselben Rendering-Fähigkeiten. Und selbst bei Google kann JavaScript zusätzliche Fehlerquellen schaffen.

Für AI Recommendation Measurement ist dieser Unterschied besonders relevant: Das Ökosystem besteht nicht aus einem einzigen Crawler mit einer einzigen Rendering Engine.

Das typische Problem

Ein Produktshop zeigt im Browser:

• Produktname
• Preis
• Verfügbarkeit
• Varianten
• Versandinformationen
• Produktbeschreibung

Der initiale HTML-Response enthält aber möglicherweise nur Navigation, leere Container und JavaScript-Bundles.

Erst nachdem JavaScript geladen und ausgeführt wurde, erscheinen die Produktinformationen.

Für den Nutzer ist alles vorhanden.

Für einen Client, der kein JavaScript ausführt oder den Rendering-Prozess nicht vollständig abschliesst, existiert praktisch kein Produkt.

CSR ist kein binäres SEO-Kriterium

Eine Website sollte nicht allein danach bewertet werden, ob sie React, Salesforce LWR oder ein anderes JavaScript Framework verwendet.

Entscheidend ist der tatsächliche Output.

Wir prüfen deshalb zwei Zustände getrennt:

Initial HTML

Was erhält ein Client direkt vom Server?

Rendered DOM

Was existiert nach vollständiger Ausführung der Seite?

Die Differenz zwischen beiden Zuständen ist oft aufschlussreicher als der verwendete Technologie-Stack.

Wie lässt sich das Problem sauber lösen?

1. Kritischen Content serverseitig ausliefern

Produktname, Preis, Verfügbarkeit, Leistungsbeschreibung oder zentrale Kaufbedingungen sollten nach Möglichkeit bereits im ausgelieferten HTML vorhanden sein.

2. Server-Side Rendering, Prerendering oder Hybrid-Ansätze nutzen

Drei Wege führen zum selben Ziel. Server-Side Rendering erzeugt das HTML bei jeder Anfrage auf dem Server. Prerendering, auch Static Rendering genannt, erzeugt es bereits beim Build; für Katalog- und Informationsseiten, die sich selten ändern, reicht das oft aus. Hybrid-Ansätze kombinieren beides: Der Server liefert die Inhalte, der Browser hydriert nur die interaktiven Teile.

Moderne Frameworks unterstützen diese Mischformen. Inhalte werden serverseitig oder statisch erzeugt und danach im Browser hydriert und interaktiv gemacht. Damit muss man sich nicht zwischen Maschinenlesbarkeit und moderner UX entscheiden.

3. Progressive Enhancement

Die Grundinformation funktioniert ohne JavaScript. JavaScript verbessert anschliessend Interaktion und Darstellung.

Dieses Prinzip soll auch auf der Aions-Website selbst eingehalten werden.

4. Inhalte im HTML maschinenlesbar strukturieren

Inhalt im ersten HTML ist die Voraussetzung, aber noch keine Garantie dafür, dass Maschinen ihn richtig verstehen. Zentrale Informationen sollten als echter Text vorliegen, nicht als Bild oder Canvas, und semantisch ausgezeichnet sein: Überschriften für die Gliederung, Listen und Tabellen für Preise, Varianten und Lieferbedingungen, eindeutige Bezeichnungen statt reiner Icons.

Was für Menschen im Layout erkennbar ist, muss für Maschinen im Markup erkennbar sein.

5. Strukturierte Daten nicht von einer fragilen Rendering-Kette abhängig machen

Structured Data kann zwar auch über JavaScript erzeugt werden. Bei zentralen Informationen erhöht jede zusätzliche Rendering-Abhängigkeit jedoch die Zahl möglicher Fehlerquellen.

Sichtbare und strukturierte Informationen sollten aus derselben fachlichen Datenquelle stammen.

6. Rendering nach Releases erneut prüfen

Auch eine heute gut lesbare Website kann nach einem Theme-, Framework-, App- oder Template-Update wichtige Inhalte wieder erst clientseitig ausliefern. Initial HTML und Rendered DOM sollten deshalb nach relevanten Releases erneut geprüft werden.

Besonders kritisch sind Produktdaten, Preise, Verfügbarkeit, strukturierte Daten und zentrale Informationsseiten.

Relevant sind dabei mindestens:

• Raw HTML Response
• Rendered DOM
• Google URL Inspection bzw. geeignete Rendering-Tests
• Structured Data
• tatsächliche Responses relevanter Bots, soweit verfügbar

Und was ist mit Prerendering nur für Bots?

Zu unterscheiden ist das Prerendering beim Build, bei dem alle Clients dieselbe fertige Seite erhalten, vom sogenannten Dynamic Rendering. Dynamic Rendering wurde früher oft als Workaround verwendet: Nutzer erhalten die JavaScript-Version, bestimmte Bots eine vorgerenderte HTML-Version.

Google beschreibt Dynamic Rendering heute als Workaround und nicht als bevorzugte langfristige Lösung.

Server-Side Rendering, Static Rendering oder Hydration sind grundsätzlich robustere Ansätze.

Wenn unterschiedliche Versionen ausgeliefert werden, müssen sie inhaltlich gleichwertig bleiben.

Die pragmatische Antwort

Nicht jede CSR-Website braucht einen Architekturumbau.

Wenn eine bestehende Seite von den relevanten Systemen vollständig gelesen wird, gibt es keinen Grund, allein wegen des Technologie-Labels alles neu zu bauen.

Wenn aber entscheidende Inhalte im initialen HTML fehlen und relevante Crawler sie nicht zuverlässig erfassen, wird Rendering zum geschäftlichen Problem.

Die Entscheidung sollte deshalb nicht über die Technologie fallen, sondern über den Informationsstand: Welche Inhalte müssen für Menschen und Maschinen zuverlässig verfügbar sein, und in welchem Zustand sind sie tatsächlich vorhanden?

Genau das lässt sich messen.

Welche KI-Crawler JavaScript nicht ausführen und was das für die Suche von KI-Systemen heisst: Was suchen KI-Systeme, bevor sie antworten, und was heisst das für SEO?