Hauptbereich
Agency
technisches-seo

JavaScript-Rendering bei Google — wie Googlebot deinen JS-Content sieht

Redaktion ·

Wenn deine Seite ihren Content erst per JavaScript im Browser zusammenbaut, stellt sich eine simple, aber harte Frage: Sieht Google den Content überhaupt? Die Antwort hängt davon ab, ob Google deine Seite nicht nur crawlt, sondern auch korrekt rendert. Und Rendering ist bei Google ein eigener Schritt mit eigenem Budget — keine Selbstverständlichkeit.

Der dreistufige Prozess: Crawlen, Rendern, Indexieren

Google verarbeitet JavaScript-Seiten in drei getrennten Phasen, die zeitlich auseinanderliegen können:

1. Crawlen. Googlebot holt die URL, prüft die robots.txt, liest das ausgelieferte HTML und sammelt Links aus href-Attributen. In dieser Phase sieht Google nur das rohe HTML, das der Server schickt — bei einer reinen Client-Side-App ist das oft ein fast leeres <div id="root">.

2. Rendern. Seiten mit HTTP-Status 200 wandern in eine Render-Queue. Dort führt der Web Rendering Service (WRS) das JavaScript mit einer Evergreen-Version von Chromium aus — also einem aktuellen, ständig aktualisierten Headless-Chrome. Erst nach dem Rendern entsteht das HTML, das Google tatsächlich bewertet.

3. Indexieren. Aus dem gerenderten HTML extrahiert Google Inhalte und weitere Links, indexiert die Seite und schickt neu gefundene URLs zurück in den Crawl.

Der Knackpunkt sitzt zwischen Schritt 1 und 2.

Warum Rendering ein eigenes Budget hat

Rendering ist teuer. Eine Seite zu crawlen heißt, eine HTTP-Antwort herunterzuladen — billig. Eine Seite zu rendern heißt, einen ganzen Browser zu starten, JavaScript auszuführen, auf Netzwerk-Requests zu warten und das Layout zu berechnen — um Größenordnungen teurer. Deshalb passiert Rendering nicht sofort beim Crawl, sondern verzögert, sobald Ressourcen frei sind.

In Googles eigenen Worten kann eine Seite „ein paar Sekunden” in der Queue bleiben — „es kann aber auch länger dauern”. In der Praxis reicht das von Sekunden bis zu Tagen, abhängig von der Popularität der Site und der Crawl-Demand. Für Indexierung bedeutet das: JS-abhängiger Content erscheint potenziell später im Index als serverseitig gelieferter — und bei kleinem Crawl-Budget auch unzuverlässiger.

Der Two-Wave-Indexing-Mythos

Lange galt das Bild der „zwei Wellen”: erste Welle indexiert das rohe HTML, zweite Welle Tage später das gerenderte. Google selbst hat dieses Modell relativiert — die zweite Welle kommt heute oft binnen Minuten, manchmal fast gleichzeitig. Aber: oft ist nicht garantiert. Sich auf schnelles Rendering zu verlassen ist eine Wette, kein Plan. Wer kritischen Content — Titel, Hauptüberschrift, Preise, kanonische Signale — ausschließlich per Client-JS erzeugt, riskiert, dass Google in der ersten Indexierung eine leere Hülle sieht.

Was typischerweise schiefgeht

Content nur per Client-JS. Das häufigste Problem. Steht der eigentliche Inhalt nicht im initialen HTML, hängt alles am erfolgreichen Rendering. Klappt das nicht, ist die Seite aus Google-Sicht inhaltsleer.

Blockierte JS-/CSS-Ressourcen in robots.txt. Der teuerste Fehler. Google sagt es deutlich: „Google Search won’t render JavaScript from blocked files or on blocked pages.” Wer seine /assets/- oder /_next/-Pfade per robots.txt sperrt, nimmt Google die Bausteine zum Rendern — der Content bleibt unsichtbar.

Fehlerhafte oder fehlende Hydration. Wenn das Framework beim Server-Markup und Client-Rendering auseinanderläuft, kann der gerenderte Zustand kaputt sein.

JavaScript-Fehler. Ein einziger unbehandelter Fehler im kritischen Pfad kann das Rendering abbrechen — der WRS sieht dann nur, was bis zum Crash entstand.

Identische Titel/Descriptions. SPAs setzen <title> und Meta-Description oft per JS pro Route. Passiert das fehlerhaft, indexiert Google für alle Routen denselben Titel.

Wie du es testest

URL-Prüfung in der Google Search Console. Das wichtigste Werkzeug. Es zeigt dir das gerenderte HTML, das Google tatsächlich sieht — plus Screenshot und etwaige Ladefehler bei Ressourcen. Vergleiche dieses gerenderte HTML mit dem, was im Browser sichtbar ist. Fehlt der Hauptinhalt im gerenderten HTML, hast du ein Rendering-Problem.

Rich Results Test. Zeigt ebenfalls das gerenderte HTML und prüft zusätzlich strukturierte Daten.

Roh vs. gerendert vergleichen. Schau dir das Server-HTML an (etwa über „Seitenquelltext anzeigen” oder curl) und vergleiche es mit dem gerenderten DOM. Die Differenz ist genau das, was vom Rendering abhängt — und damit das Risiko.

Die saubere Lösung: SSR statt Dynamic Rendering

Google empfiehlt selbst: „server-side or pre-rendering is still a great idea, because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” Genau das ist die nachhaltige Antwort — Server-Side-Rendering (SSR), statisches Pre-Rendering oder ein hybrider Ansatz, bei dem kritischer Content schon im initialen HTML steht.

Dynamic Rendering — also Bots eine vorgerenderte Version ausliefern, Nutzern die JS-Version — stuft Google ausdrücklich als Workaround ein, nicht als Dauerlösung. Es ist komplex, fehleranfällig und mit modernen SSR-Frameworks schlicht überflüssig. Den vollen Bogen von Crawling über Rendering bis Indexierung findest du im Überblick zu technischem SEO.

FAQ

Rendert Google JavaScript überhaupt? Ja. Googlebot rendert Seiten mit einer Evergreen-Version von Chromium im Web Rendering Service. Der Content aus Client-JS kann also indexiert werden — aber erst nach dem Rendering, das verzögert in einer eigenen Queue passiert.

Wie lange dauert das Rendering? Google nennt „ein paar Sekunden”, räumt aber ein, dass es länger dauern kann. In der Praxis reicht es von Sekunden bis zu Tagen, abhängig von Crawl-Budget und Popularität der Site.

Warum sieht Google meinen JS-Content nicht? Häufigste Ursachen: JS-/CSS-Ressourcen sind in der robots.txt blockiert, ein JavaScript-Fehler bricht das Rendering ab, oder der Content hängt an externen Requests, die der WRS nicht lädt. Die URL-Prüfung in der GSC zeigt, was Google tatsächlich rendert.

Brauche ich Dynamic Rendering? In der Regel nein. Google stuft Dynamic Rendering als Workaround ein, nicht als Dauerlösung. Server-Side-Rendering oder Pre-Rendering ist sauberer, schneller für Nutzer und löst das Problem an der Wurzel.

Wie teste ich, ob Google meinen Content rendert? Nutze die URL-Prüfung in der Google Search Console und vergleiche das gerenderte HTML mit dem sichtbaren Inhalt. Fehlt dort der Hauptinhalt, hast du ein Rendering-Problem. Der Rich Results Test ist eine zweite Quelle für das gerenderte HTML.

Themenuebersicht

Technisches SEOJavaScript SEO