Viele Websites laufen heute ganz oder teilweise über JavaScript: Shops mit Filtern, Buchungsstrecken, Webanwendungen mit React oder Vue, aber auch klassische Firmenwebsites, deren Baukasten Menüs und Inhalte per Skript nachlädt. Google kommt mit JavaScript zurecht, allerdings nach eigenen Regeln. Wer sie kennt, vermeidet die meisten Probleme, bevor sie in der Search Console auftauchen.
Die Kurzfassung steht im Glossar unter JavaScript-SEO. Diese Seite geht die Regeln aus Googles Dokumentation der Reihe nach durch und ordnet sie für die Praxis ein.
Crawling, Rendering, Indexierung
"Die Verarbeitung von JavaScript-Webanwendungen durch Google durchläuft drei Hauptphasen" [1]: Crawling, Rendering und Indexierung. Beim Crawling ruft der Googlebot eine Adresse ab und liest das ausgelieferte HTML. Danach wartet die Seite auf das Rendering. "Alle Seiten mit dem HTTP-Statuscode 200 werden an die Rendering-Warteschlange gesendet" [1], sofern kein noindex dagegen spricht. Zur Dauer schreibt Google: "Die Seite verbleibt möglicherweise nur einige Sekunden in dieser Warteschlange, es kann jedoch auch länger dauern." [1]
Gerendert wird mit einem aktuellen Browser: "JavaScript wird in der Google Suche mit einer Evergreen-Version von Chromium ausgeführt" [1]. Erst das gerenderte HTML wertet Google für die Indexierung aus, und erst dort findet es Links, die ein Skript eingefügt hat [1]. Was das für die Wahl zwischen Rendering im Browser und auf dem Server bedeutet, erklärt der Ratgeber Client-Side oder Server-Side Rendering.
Was schon im ersten HTML stimmen muss
Einige Angaben wirken, bevor überhaupt gerendert wird. Die wichtigste ist noindex. Google warnt: "Wenn Google auf das noindex-Tag stößt, werden das Rendering und die JavaScript-Ausführung möglicherweise übersprungen." [1] Ein Skript, das noindex später entfernt, kommt dann nicht mehr zum Zug. Steht noindex im ausgelieferten HTML, bleibt die Seite draußen.
Beim Canonical ist Google ebenso deutlich: "Die kanonische URL lässt sich am besten mit HTML festlegen." [1] Ein per JavaScript gesetzter Canonical wird zwar beim Rendering erkannt, Google rät aber davon ab, und er darf nicht von dem im HTML abweichen [1]. Title und Meta-Beschreibung dürfen per JavaScript gesetzt oder geändert werden [1]. Sicherer ist trotzdem, wenn sie schon im ersten Abruf stimmen, denn nicht jeder Dienst, der Ihre Seite abruft, führt Skripte aus.
Ein Sonderfall ist das sogenannte App-Shell-Modell, bei dem das ausgelieferte HTML nur ein Gerüst enthält und der eigentliche Inhalt erst per JavaScript kommt [1]. Google kann solche Seiten verarbeiten. Für Nutzer und Crawler bleibt serverseitiges Rendering oder Pre-Rendering nach Googles Worten "trotzdem eine sehr gute Option" [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.
Statuscodes und Soft-404-Fehler
Klassische Websites antworten auf eine fehlende Seite mit dem Statuscode 404. Single-Page-Anwendungen liefern dagegen oft für jede Adresse dieselbe Hülle mit Status 200 aus und zeigen die Fehlermeldung erst per Skript. Für Google sieht das wie eine normale Seite mit wenig Inhalt aus, ein Soft-404-Fehler. Google nennt zwei Auswege: per JavaScript auf eine Adresse weiterleiten, die der Server mit 404 beantwortet, oder der Fehlerseite per JavaScript ein noindex mitgeben [1]. Was der Bericht dazu in der Search Console zeigt, beschreibt die FAQ-Seite Soft 404 in der Search Console.
Links und Adressen
Google findet Unterseiten über Links, und dafür braucht es ein bestimmtes Format. Allgemein kann Google einen Link nur crawlen, wenn es sich um ein a-Element mit einem href-Attribut handelt [3]. Links, die ein Skript einfügt, sind in Ordnung, solange sie dieses Markup nutzen [3]. Für Single-Page-Anwendungen mit clientseitigem Routing empfiehlt Google die History API [1]. Adressen mit Fragment, also mit Rautezeichen wie "#/produkte", kann der Googlebot nicht zuverlässig auflösen [1]. Beispiele für gute und schlechte Links stehen im Ratgeber JavaScript-Links und Navigation.
Was der Googlebot anders macht als ein Besucher
Der Googlebot rendert wie ein Browser, verhält sich aber nicht wie ein Mensch. Googles Seite zur Fehlersuche nennt mehrere Unterschiede [2]. "Der Googlebot lehnt in der Regel Anfragen nach Nutzerberechtigungen ab." [2] Inhalte, die erst nach Freigabe von Standort oder Kamera erscheinen, sieht Google also nicht. "Bei der Darstellung von Inhalten ist keine Datenpersistenz gewährleistet." [2] Lokaler Speicher und Cookies werden zwischen den Abrufen gelöscht, Inhalte dürfen davon nicht abhängen. WebSockets und WebRTC werden nicht unterstützt, Inhalte brauchen deshalb einen Weg über normale HTTP-Verbindungen [2].
Auch beim Funktionsumfang gibt es Grenzen. Nicht jede Browser-Schnittstelle wird beim Rendering unterstützt. Google nennt für diesen Fall Differential Serving und Polyfills, weist aber darauf hin, dass sich nicht jede fehlende Funktion nachrüsten lässt [1]. Die Seite zur Fehlersuche rät deshalb, für alle kritischen Schnittstellen eine Funktionserkennung einzubauen und einen Ersatzweg vorzusehen, wenn eine Funktion fehlt [2]. Ein Skript, das an einer fehlenden Funktion abbricht, liefert dem Googlebot sonst eine halbe Seite.
Dazu kommt das Zwischenspeichern. Laut Google speichert der Googlebot aggressiv zwischen und ignoriert dabei womöglich Caching-Header [1]. Nach einem Update kann Google so eine alte Skriptdatei mit neuem HTML kombinieren. Abhilfe schaffen Dateinamen mit Inhalts-Fingerabdruck wie main.2bb85551.js, die sich bei jeder Änderung ändern [1]. Die meisten aktuellen Build-Werkzeuge erzeugen solche Namen von sich aus.
Strukturierte Daten, Bilder und Webkomponenten
Strukturierte Daten im Format JSON-LD dürfen per JavaScript erzeugt und eingefügt werden. Google empfiehlt, das Ergebnis mit dem Test für Rich-Suchergebnisse zu prüfen [1]. Webkomponenten unterstützt Google ebenfalls. Gerendert wird aber nur, was am Ende im gerenderten HTML sichtbar ist, und für Inhalte im Light DOM verweist Google auf das slot-Element [1]. Für nachgeladene Bilder gibt es eigene Hinweise zum Lazy Loading, auf die Googles Grundlagenseite verweist [1].
In dieser Reihenfolge prüfen
Beginnen Sie mit dem Quelltext einer wichtigen Seite, nicht mit dem Elementfenster der Entwicklerwerkzeuge. Steht der Haupttext darin, ebenso Title, Canonical und Links? Dann ist die Seite auch ohne Rendering lesbar. Im zweiten Schritt öffnen Sie die Adresse im URL-Prüftool der Search Console oder im Test für Rich-Suchergebnisse und vergleichen das gerenderte HTML mit dem, was Sie im Browser sehen [2]. Fehlen dort Inhalte, sieht Google sie auch nicht.
Drittens empfiehlt Google, JavaScript-Fehler zu erfassen und zu prüfen, auch solche, die beim Abruf durch den Googlebot entstehen [2]. Ein Skript, das im Browser des Entwicklers läuft und beim Googlebot an einer fehlenden Berechtigung scheitert, fällt sonst nicht auf. Nach unserer Erfahrung finden sich die meisten Probleme in diesen drei Schritten, lange bevor eine tiefere Analyse nötig wird. Wie Google rendert und wo die Grenzen liegen, vertieft der Ratgeber Rendering durch Google.
Ihre JavaScript-Website wird schlechter indexiert, als sie sollte, und Sie wissen nicht, wo Sie anfangen sollen? Stellen Sie die Frage in der gratis Sprechstunde. Die Ursachensuche und Behebung übernimmt SEO NW bei der Leistung Indexierungsprobleme beheben.
- Organisation Grundlagen von JavaScript-SEO. Google Search Central. Stand 04.03.2026. abgerufen am 31.10.2026
- Organisation Für die Suche relevante JavaScript-Probleme beheben. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
- Organisation SEO-Link-Best-Practices für Google. Google Search Central. Stand 31.12.2025. abgerufen am 31.10.2026
Häufige Fragen
Kann Google JavaScript-Seiten indexieren?
Ja. Google rendert Seiten mit einer aktuellen Chromium-Version und indexiert das gerenderte HTML. Das geschieht in einem eigenen Schritt nach dem Crawling, der einige Sekunden oder länger dauern kann.
Darf noindex per JavaScript gesetzt oder entfernt werden?
Setzen ja, etwa für Fehlerseiten in einer Single-Page-Anwendung. Entfernen nein: Steht noindex im ausgelieferten HTML, überspringt Google das Rendering möglicherweise, und das Skript kommt nicht mehr zum Zug.
Warum sieht Google Inhalte nicht, die bei mir im Browser erscheinen?
Häufige Gründe sind Inhalte, die eine Berechtigung, gespeicherte Daten oder eine WebSocket-Verbindung voraussetzen, Skriptfehler beim Abruf durch den Googlebot oder Adressen mit Rautezeichen. Das URL-Prüftool zeigt, was Google gerendert hat.
Brauche ich serverseitiges Rendering?
Nicht zwingend, Google kann clientseitig gerenderte Seiten verarbeiten. Google nennt serverseitiges Rendering oder Pre-Rendering aber eine sehr gute Option, weil die Seite schneller wird und nicht alle Crawler JavaScript ausführen.
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.
