Eine Seite, die im Browser vollständig aussieht, kann bei Google halb leer ankommen. Das liegt selten an böser Absicht der Suchmaschine. Meist arbeitet Googles Rendering anders als der Browser eines Besuchers: ohne Klicks, ohne gespeicherte Daten, mit Größengrenzen und mit einer Pause zwischen Abruf und Ausführung. Wer diese Unterschiede kennt, findet die Ursache schneller. Dieser Ratgeber beschreibt, was beim Rendering durch Google passiert und woran es scheitert.
Welche Rendering-Strategie Sie für eine neue Website wählen sollten, beantwortet der Ratgeber Client Side oder Server Side Rendering. Die Übergangslösung mit getrennter Auslieferung für Bots behandelt Dynamisches Rendering.
Drei Schritte mit einer Pause dazwischen
Google verarbeitet JavaScript-Seiten in drei Phasen: Crawling, Rendering und Indexierung [1]. Beim Crawling ruft Googlebot das HTML ab, so wie es der Server ausliefert. Danach wartet die Seite auf das Rendering. Google schreibt dazu: "Die Seite verbleibt möglicherweise nur einige Sekunden in dieser Warteschlange, es kann jedoch auch länger dauern." [1] Im Rendering führt Google die Seite in einem Browser aus, und das Ergebnis, das gerenderte HTML, geht in die Indexierung.
Für das Rendering nutzt Google laut seinem Leitfaden zur Funktionsweise der Suche eine aktuelle Version von Chrome und führt den gefundenen JavaScript-Code aus [2]. Das gilt seit Mai 2019. Damals stellte Google den "evergreen Googlebot" vor, der die jeweils neueste Chromium-Engine nutzt; zum Zeitpunkt der Ankündigung war das Version 74, und Google sagte zu, die Engine regelmäßig zu aktualisieren [3].
Wann Google gar nicht rendert
Zwei Fälle führen dazu, dass das Rendering ausbleiben kann. Liefert der Server einen anderen Statuscode als 200, wird das Rendern laut Google möglicherweise übersprungen [1]. Und steht im ursprünglichen HTML ein noindex, werden Rendering und JavaScript-Ausführung möglicherweise ebenfalls übersprungen [1]. Eine Single-Page-App, die im HTML noindex setzt und es per Skript wieder entfernt, bleibt deshalb unter Umständen draußen. Umgekehrt funktioniert es: Fehlerseiten in Single-Page-Apps lassen sich per JavaScript mit noindex versehen [1].
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Was der Rendering-Browser nicht kann
Der Browser, mit dem Google rendert, verhält sich in einigen Punkten bewusst anders als der Browser Ihrer Besucher. Google nennt in seiner Anleitung zur Fehlersuche bei JavaScript unter anderem diese Eigenschaften [4]:
- Anfragen nach Berechtigungen lehnt Googlebot in der Regel ab. Inhalte, die erst nach Freigabe von Standort, Kamera oder Benachrichtigungen erscheinen, sieht Google nicht.
- Der Zustand bleibt nicht über Seitenaufrufe hinweg erhalten. Local Storage, Session Storage und HTTP-Cookies werden beim Seitenaufbau gelöscht. Ein Cookie-Banner, das nach der ersten Zustimmung verschwindet, erscheint für Google also bei jedem Abruf neu.
- Nicht jede Schnittstelle wird unterstützt. Google nennt WebGL als Beispiel und rät zu Funktionserkennung mit einem Ersatzweg.
- Fragment-Adressen mit # sind kein verlässlicher Weg, verschiedene Inhalte zu laden. Google empfiehlt die History API.
Hinzu kommt, dass Googles Crawler nicht auf Schaltflächen klicken und im Allgemeinen keine JavaScript-Funktionen auslösen, die eine Nutzeraktion voraussetzen [6]. Inhalte hinter "Mehr laden", Reitern, die erst beim Klick Daten holen, oder Akkordeons mit nachgeladenem Text fehlen dann im gerenderten HTML. Links findet Google nur über a-Elemente mit href [1]. Mehr dazu unter JavaScript-Links und Navigation.
Größengrenzen und Ressourcen
Googlebot liest von jeder Datei nur einen Teil. Die Dokumentation sagt: "Beim Crawling für die Google Suche crawlt der Googlebot die ersten 2 MB eines unterstützten Dateityps und die ersten 64 MB einer PDF-Datei." [5] Ist die Grenze erreicht, bricht Googlebot den Abruf ab und gibt nur den bereits geladenen Teil an die Indexierung weiter. Jede Ressource, die im HTML eingebunden ist, also CSS und JavaScript, wird einzeln abgerufen und unterliegt derselben Grenze. Gemessen wird an den unkomprimierten Daten [5].
Für das Rendering heißt das: Ein einzelnes JavaScript-Bündel, das unkomprimiert größer als 2 MB ist, kommt bei Google nicht vollständig an. Auch sehr große HTML-Seiten, etwa mit eingebetteten Daten für die Hydration, können an die Grenze stoßen. Teilen Sie große Bündel auf und laden Sie Code für Bereiche, die beim ersten Aufbau nicht gebraucht werden, getrennt.
Gesperrte Ressourcen sind die zweite Hürde. Google schreibt: "In der Google Suche wird JavaScript aus blockierten Dateien oder auf blockierten Seiten nicht gerendert." [1] Eine robots.txt-Sperre für ein Skriptverzeichnis wirkt sich deshalb unmittelbar auf den Inhalt im Index aus. Siehe auch robots.txt Fehler vermeiden.
Zwischenspeicher und veraltete Dateien
Google speichert abgerufene Ressourcen zwischen, hält sich dabei aber nicht unbedingt an Ihre Angaben. "Der WRS ignoriert Caching-Header möglicherweise." [1] WRS steht für Web Rendering Service, Googles Rendering-Dienst. Die Folge: Google rendert eine Seite unter Umständen mit einer älteren Fassung Ihrer Skriptdatei. Abhilfe schafft ein Fingerabdruck im Dateinamen, etwa app.3f9c2a.js, der sich bei jeder Änderung ändert. So lädt Google nach einer Änderung zwangsläufig die neue Datei [1].
Title, Description und Canonical nach dem Rendern
Viele Frameworks setzen Title und Meta-Description erst im Browser. Das ist für Google grundsätzlich in Ordnung: Beides lässt sich laut Google mit JavaScript festlegen oder ändern [1]. Beim Canonical ist Google vorsichtiger. Die kanonische URL legen Sie am besten im HTML fest. Wird sie per JavaScript gesetzt, soll sie denselben Wert haben wie im ursprünglichen HTML [1]. Widersprechen sich beide Fassungen, weil das Skript beim Seitenwechsel einen anderen Wert einträgt, sendet die Seite zwei Signale. Prüfen Sie deshalb im URL-Prüftool neben dem sichtbaren Text auch den head des gerenderten HTML. Weitere Grundlagen stehen unter JavaScript SEO Grundlagen.
Web Components und Shadow DOM
Google rendert auch Web Components. Für die Indexierung gilt dabei eine Regel: Google kann nur Inhalte sehen, die im gerenderten HTML sichtbar sind [1]. Inhalte im Shadow DOM, die nach dem Rendern nicht im Ergebnis auftauchen, fehlen also. Ob Ihre Komponenten ihren Text sichtbar machen, zeigt der Blick in das gerenderte HTML.
So sehen Sie, was Google rendert
Das wichtigste Werkzeug ist das URL-Prüftool der Search Console, mit dem Live-Test einer Adresse. Es zeigt die geladenen Ressourcen, die Ausgabe und Ausnahmen der JavaScript-Konsole und das gerenderte DOM [4]. Gehen Sie dabei so vor:
- Live-Test starten und das gerenderte HTML öffnen.
- Darin nach einem Satz aus dem Hauptinhalt, dem Title, dem Canonical und einem wichtigen internen Link suchen.
- In der Liste der Ressourcen nach nicht geladenen Dateien sehen, vor allem nach solchen, die durch robots.txt blockiert sind.
- Die Konsolenmeldungen auf Fehler prüfen. Ein Fehler in einem frühen Skript kann alles danach verhindern.
Für Fehler, die nur bei Google auftreten, schlägt Google vor, JavaScript-Fehler über einen globalen onerror-Handler zu protokollieren. Manche Fehlerarten, etwa Fehler beim Parsen, lassen sich so allerdings nicht erfassen [4]. Wir empfehlen, den Test für je eine Seite jeder Vorlage zu machen, also Startseite, Kategorie, Produkt, Beitrag und Kontakt.
Zeigt das URL-Prüftool weniger, als Ihre Besucher sehen, und Sie finden die Ursache nicht? Bringen Sie die Frage in die gratis Sprechstunde mit. Hängen Rankings an der Frage, prüft SEO NW die Vorlagen im Rahmen der Leistung OnPage-Optimierung. Den Begriff erklärt das Glossar unter JavaScript-Rendering.
- Organisation Grundlagen von JavaScript-SEO. Google Search Central. Stand 04.03.2026. abgerufen am 31.10.2026
- Organisation Umfassender Leitfaden zur Funktionsweise der Google Suche. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
- Organisation The new evergreen Googlebot. Google Search Central Blog. Stand 07.05.2019. abgerufen am 31.10.2026
- Organisation JavaScript-Probleme im Zusammenhang mit der Google Suche beheben. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
- Organisation Googlebot. Google Search Central. Stand 06.02.2026. abgerufen am 31.10.2026
- Organisation Best Practices für die Paginierung bei Google. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
Häufige Fragen
Rendert Google jede Seite mit JavaScript?
Google stellt abgerufene Seiten in eine Warteschlange für das Rendering. Bei einem anderen Statuscode als 200 oder einem noindex im ursprünglichen HTML kann das Rendering übersprungen werden.
Welchen Browser nutzt Google zum Rendern?
Laut Google eine aktuelle Version von Chrome. Seit Mai 2019 nutzt Googlebot die jeweils neueste Chromium-Engine und aktualisiert sie regelmäßig.
Sieht Google Inhalte, die erst nach einem Klick erscheinen?
In der Regel nicht. Googles Crawler klicken nicht auf Schaltflächen und lösen im Allgemeinen keine JavaScript-Funktionen aus, die eine Nutzeraktion voraussetzen.
Gibt es eine Größengrenze für JavaScript-Dateien?
Ja. Googlebot ruft von jeder Datei die ersten 2 MB ab, gemessen an den unkomprimierten Daten. Das gilt für HTML, CSS und JavaScript jeweils einzeln.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.
