JavaScript-Rendering ist bei Google die zweite von drei Phasen, in denen JavaScript-Seiten verarbeitet werden: Auf das Crawling folgt das Rendering, danach das Indexing.[1] Die Rendering-Fähigkeit einer Seite beschreibt, ob ihr Inhalt und ihre Links nach dem Ausführen des JavaScripts vorliegen.
Als Rankingfaktor ist JavaScript-Rendering eine Voraussetzung: Es ist ein Verarbeitungsschritt vor der Indexierung.
- Ob JavaScript-Rendering bei dir der richtige Hebel ist, zeigt die Ausgangslage-Tabelle.
- Den Stand deiner Seite prüfst du mit dem Selbstaudit.
- Für die Umsetzung gibt es sechs Hebel, Quick Wins zuerst.
Definition und Einordnung
Was bedeutet JavaScript-Rendering genau?
Beim App-Shell-Modell (ein Grundgerüst, in das JavaScript den eigentlichen Inhalt erst einfügt) enthält das initiale HTML den Inhalt nicht, Google muss zuerst JavaScript ausführen, um ihn zu sehen.[1] Diese Aufgabe übernimmt der Web Rendering Service (WRS), die Rendering-Komponente von Googlebot.[2] Seiten mit dem HTTP-Status 200 kommen in die Render-Queue (die Warteschlange für das Rendering), auch wenn sie kein JavaScript enthalten, es sei denn, ein Robots-Meta-Tag oder -Header verbietet die Indexierung. Bei einem anderen Status kann das Rendering entfallen.[1]
Vier Begriffe beschreiben, wo gerendert wird. Server-Side Rendering (SSR) rendert die Anwendung auf dem Server und schickt HTML statt JavaScript an den Client. Client-Side Rendering (CSR) rendert im Browser und verändert den DOM per JavaScript. Prerendering führt eine Client-Anwendung zur Build-Zeit aus und hält ihren Anfangszustand als statisches HTML fest. Hydration ergänzt servergerendertes HTML um Client-Skripte, die Zustand und Interaktivität hinzufügen.[3] Die englische Bezeichnung in Googles Dokumentation lautet „JavaScript SEO“.[1]
Woher ist der Faktor bekannt und wie sicher ist die Evidenz?
Google beschreibt den Faktor selbst in der Search-Central-Dokumentation, die Aussagen sind damit von Google bestätigt. Die Dokumentation behandelt Rendering als Verarbeitungsschritt und nennt keine Gewichtung für Rankings.[1] [2] Zur Wartezeit in der Render-Queue heißt es nur, eine Seite könne dort wenige Sekunden bleiben, es könne aber auch länger dauern. Einen Grenzwert nennt Google nicht.[1]
Wie wichtig ist JavaScript-Rendering?
Ausgangslage: Ist JavaScript-Rendering dein Hebel?
Ob JavaScript-Rendering für deine Seite der richtige Hebel ist, hängt davon ab, wo sie gerade steht und ob der Faktor überhaupt zu deinem Ziel führt.
| Ausgangslage der Seite | Ist das der richtige Hebel? | Beleg |
|---|---|---|
| Wichtiger Inhalt fehlt im gerenderten HTML | Ja. Google indexiert auf Basis des gerenderten HTML, hier entscheidet das Rendering. | [1] |
| Klassische oder serverseitig gerenderte Seite, der Inhalt steht im HTML der Serverantwort | Eher nein. Crawling und HTML-Parsing funktionieren hier gut, weil die Antwort alle Inhalte enthält. | [1] |
| Die Seite oder ihre JavaScript-Dateien sind per robots.txt gesperrt | Zuerst die Sperre klären. Google rendert kein JavaScript aus blockierten Dateien oder auf blockierten Seiten und stellt für gesperrte URLs keinen HTTP-Request. | [1] |
| Die Seite trägt im Original-HTML ein noindex | Nein, hier geht es um Indexierbarkeit. Bei noindex kann Google Rendering und JavaScript-Ausführung überspringen. | [1] |
| Auch andere Suchmaschinen sollen deinen Inhalt sehen | Ja, prüfe deren Verhalten getrennt. Andere Suchmaschinen können JavaScript ignorieren und sehen per JavaScript erzeugten Inhalt dann nicht. | [4] |
Typische Missverständnisse
- „Google führt kein JavaScript aus.“ Google Search führt JavaScript mit einer evergreen Version von Chromium aus.[1] Per JavaScript nachgeladener Inhalt erscheint zusammen mit dem Inhalt aus dem HTML in Googles Sicht auf die Seite, Einschränkungen sind möglich.[4]
- „Per JavaScript eingefügte Links zählen nicht.“ Links per JavaScript in den DOM einzufügen ist in Ordnung, solange sie die Regeln für crawlbare Links erfüllen.[1]
- „Title und Meta Description dürfen nicht per JavaScript gesetzt werden.“ Google-Dokumentation: JavaScript darf beides setzen oder ändern.[1]
- „Dynamic Rendering ist Cloaking.“ Googlebot betrachtet Dynamic Rendering (die Auslieferung einer vorgerenderten Version an Bots) generell nicht als Cloaking (unterschiedliche Inhalte für Nutzer und Crawler), solange ähnlicher Inhalt entsteht. Völlig verschiedene Inhalte für Nutzer und Crawler können dagegen als Cloaking gelten.[4]
Messung und Diagnose
Selbstaudit: Wo steht deine Seite?
Sieben Prüfpunkte zeigen, ob Inhalt und Links nach dem Rendering bei Google ankommen.
| Prüfpunkt | Grün | Gelb | Rot | Beleg |
|---|---|---|---|---|
| Inhalt im gerenderten HTML | Text, Links und Meta-Angaben stehen im gerenderten HTML | Einzelne Bausteine fehlen im gerenderten HTML | Der Hauptinhalt fehlt im gerenderten HTML | [2] |
| Ankertext per JavaScript | Der eingefügte Ankertext steht im gerenderten HTML | Ankertext fehlt bei einzelnen Links | Ankertext fehlt bei allen per JavaScript erzeugten Links | [5] |
| Crawlbare Links und URLs | Links sind <a>-Elemente mit href, das Routing läuft über die History API (Browser-Schnittstelle, mit der die Adresse ohne Fragment wechselt) |
Einzelne Links nutzen javascript:-hrefs oder onclick. Google versucht sie teils zu parsen, empfohlen ist das nicht |
Links stützen sich auf Script-Events statt auf href, oder die Navigation nutzt Fragment-URLs (#/). Google kann solche URLs nicht zuverlässig auflösen, das AJAX-Crawling-Schema ist seit 2015 abgekündigt |
[5] [2] |
| Statuscodes von Fehlerseiten | Fehlerseiten antworten mit einem Fehlerstatus wie 404 | Nur ein Teil der Fehlerzustände liefert den passenden Status | Client-seitig behandelte Fehler melden 200 (Soft-404, eine Fehlerseite mit Status 200). Solche Seiten können indexiert und in den Ergebnissen ausgespielt werden | [2] |
| Dateigröße von HTML, JavaScript und CSS | Jede Datei bleibt unkomprimiert unter 2 MB | Einzelne Dateien liegen nahe an 2 MB | Eine Datei überschreitet 2 MB unkomprimiert. Googlebot bricht den Abruf ab und gibt nur den bis dahin geladenen Teil zur Indexierung weiter. Referenzierte CSS- und JavaScript-Dateien zählen einzeln | [6] |
| Lazy-Loading | Inhalt lädt, sobald er im Viewport sichtbar wird, und die Bild- oder Video-URLs stehen im gerenderten HTML im src |
Nur ein Teil der Bilder oder Videos erscheint im gerenderten HTML | Inhalt lädt erst nach Scrollen oder Klicken. Google interagiert nicht mit der Seite | [7] |
| Abhängigkeit von gespeichertem Zustand | Der Inhalt kommt ohne Cookies und ohne Local oder Session Storage aus | Einzelne Bausteine hängen an gespeichertem Zustand | Der Hauptinhalt hängt an Cookies oder Storage. Der WRS behält keinen Zustand und leert beides bei jedem Seitenaufruf | [2] |
Tools und Datenquellen
Diese Tools zeigen dir, was Google nach dem Rendering sieht.
| Tool | Bericht oder Kennzahl | Wofür |
|---|---|---|
| URL-Prüfung (Search Console) und Rich Results Test | Geladene Ressourcen, JavaScript-Konsolenausgaben und Exceptions, gerendertes DOM | Prüfen, wie Google eine URL crawlt und rendert[2] |
| Crawling-Statistik (Search Console) | Googlebot- und WRS-Aktivität auf der Seite | Aktivität und Rückmeldungen überwachen[2] |
| Client-seitige Analytics | Aktivität von Googlebot und WRS, möglicherweise unvollständig | Für Googlebot-Aktivität nur eingeschränkt aussagekräftig[2] |
| Screaming Frog SEO Spider | JavaScript-Rendering per headless Chromium, gespeichertes Raw und Rendered HTML, Chrome Console Log | Ursprüngliches und gerendertes HTML vieler URLs vergleichen (Herstellerangabe)[8] |
Optimierung
Die wichtigsten Hebel
- Soft-404 in Single-Page-Apps beheben (Quick Win). Leite Fehlerzustände per JavaScript auf eine URL um, die serverseitig mit 404 antwortet, oder setze per JavaScript ein
noindexim Robots-Meta-Tag der Fehlerseite.[1] [2] Welche Seiten betroffen sind, zeigt der Prüfpunkt „Statuscodes von Fehlerseiten“ im Selbstaudit. - Content Fingerprinting einführen (Quick Win). Hänge einen Fingerabdruck des Dateiinhalts an den Dateinamen, etwa
main.2bb85551.js. Der WRS kann Caching-Header ignorieren und dadurch veraltetes JavaScript oder CSS nutzen, ein neuer Dateiname bei jeder Änderung verhindert das.[1] [2] - JavaScript-Fehler protokollieren (Quick Win). Erfasse Fehler, die Nutzer und Googlebot auf der Seite auslösen, zum Beispiel über den globalen
error-Handler. Parse-Fehler lassen sich so nicht protokollieren.[2] - Navigation auf echte Links umstellen (Quick Win). Ersetze Klick-Handler auf Nicht-Link-Elementen und Fragment-Routen durch
<a href>-Links und History-API-Routing. Die Kriterien stehen im Selbastudit, kontrolliere das Ergebnis danach in der URL-Prüfung. - Infinite Scroll indexierbar machen (Langfristig). Gib jedem Abschnitt eine eigene, dauerhafte URL mit absoluter Seitenzahl, etwa
?page=12, und vermeide relative Angaben wie?date=yesterday. Verlinke die Abschnitte nacheinander und aktualisiere per History API die angezeigte URL, sobald ein neuer Abschnitt zum wichtigsten sichtbaren Element wird.[7] - Rendering-Architektur anpassen (Langfristig). Liefere den Kerninhalt im initialen HTML aus: Server-Side Rendering oder Prerendering macht die Seite für Nutzer und Crawler schneller.[1] Google empfiehlt Server-Side Rendering, Static Rendering (HTML je URL zur Build-Zeit) oder Hydration. Dynamic Rendering war ein Workaround, der zusätzliche Komplexität und Ressourcen erfordert.[4] Das Chrome-Team rät zu SSR oder Static Rendering statt zu einem vollen Rehydration-Ansatz, Static Rendering braucht allerdings vorab HTML für jede URL.[3]
Fallstricke und Grenzen
Typische Fehler
- Canonical per JavaScript abweichend vom HTML setzen. Setze das Canonical bevorzugt im HTML. Setzt du es per JavaScript, muss es dem Wert im ursprünglichen HTML entsprechen, und es darf nur ein Canonical-Tag auf der Seite stehen. Widersprüchliche oder mehrfache Tags können zu unerwarteten Ergebnissen führen.[1]
- Web Components ungeprüft einsetzen. Google flacht bei Web Components Shadow DOM und Light DOM ab. Nutzt eine Komponente den
<slot>-Mechanismus nicht für Light-DOM-Inhalt, ziehe ihre Dokumentation heran oder wähle eine andere Komponente, und prüfe das Ergebnis in der URL-Prüfung.[2] - Eine JavaScript-Paywall, die den Volltext nur versteckt. Manche Lösungen liefern den vollen Inhalt in der Serverantwort und verbergen ihn per JavaScript, bis der Abo-Status bestätigt ist. Das ist keine verlässliche Zugriffsbeschränkung, der volle Inhalt sollte erst nach bestätigtem Status ausgeliefert werden.[2]
Wann stößt JavaScript-Rendering an Grenzen?
- Googlebot lehnt Berechtigungsanfragen wie den Kamerazugriff ab. Biete Inhalte daher auch ohne Freigabe an.[2]
- Nicht jede Browser-API steht zur Verfügung, ein Beispiel ist WebGL. Feature Detection (die Prüfung, ob eine API vorhanden ist) und ein Fallback sind nötig.[2]
- Googlebot ruft Inhalte per HTTP ab. WebSockets und WebRTC werden nicht unterstützt, biete deshalb einen HTTP-Fallback an.[2]
Zusammenspiel mit anderen Faktoren
- Strukturierte Daten: JSON-LD lässt sich per JavaScript erzeugen und in die Seite einfügen, teste die Umsetzung.[1]
- Interne Verlinkung: Jede Seite, die dir wichtig ist, braucht einen Link von mindestens einer anderen Seite.[5]
- Crawlbarkeit und Indexierbarkeit greifen vor dem Rendering, wie die Ausgangslage-Tabelle zeigt.
Fazit
Sieht Google Inhalt oder Links erst nach dem Ausführen von JavaScript, entscheidet das Rendering darüber, was ankommt. Starte mit der URL-Prüfung, arbeite den Selbstaudit ab und wähle die Hebel passend zu deiner Ausgangslage. Alle Faktoren findest du unter Alle Rankingfaktoren im Überblick, ein verwandter Beitrag ist die Interne Verlinkung.
Quellen
- Google: Understand the JavaScript SEO basics (Stand: 04.03.2026). https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics. Abgerufen am 19.09.2026.
- Google: Fix Search-related JavaScript problems (Stand: 18.12.2025). https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript. Abgerufen am 19.09.2026.
- web.dev (Google): Rendering on the Web (Stand: 05.01.2026). https://web.dev/articles/rendering-on-the-web. Abgerufen am 19.09.2026.
- Google: Dynamic rendering as a workaround (Stand: 10.12.2025). https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering. Abgerufen am 19.09.2026.
- Google: Link best practices for Google (Stand: 10.12.2025). https://developers.google.com/search/docs/crawling-indexing/links-crawlable. Abgerufen am 19.09.2026.
- Google: Googlebot (Stand: 03.02.2026). https://developers.google.com/search/docs/crawling-indexing/googlebot. Abgerufen am 19.09.2026.
- Google: Fix lazy-loaded content (Stand: 10.12.2025). https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading. Abgerufen am 19.09.2026.
- Screaming Frog: SEO Spider Configuration (Stand: 22.05.2026). Herstellerangabe, Sekundärquelle. https://www.screamingfrog.co.uk/seo-spider/user-guide/configuration/. Abgerufen am 19.09.2026.