JavaScript-SEO

Wie verarbeitet Google JavaScript?

Google beschreibt drei Phasen. Beim Crawling ruft der Googlebot eine URL ab und liest das HTML aus der Serverantwort. Seiten mit Status 200 kommen anschließend in eine Warteschlange für das Rendering. Dort führt eine Headless-Version von Chromium in aktueller Version („Evergreen“) das JavaScript aus. Erst das gerenderte HTML fließt in die Indexierung ein.

Daraus folgt eine Lücke zwischen dem ausgelieferten HTML und dem fertigen DOM. Was erst nach Klicks, beim Scrollen oder nach fehlgeschlagenen API-Aufrufen erscheint, fehlt möglicherweise in der Fassung, die Google indexiert.

Für andere Crawler gilt das nicht automatisch. Eine Messung von Vercel (Dezember 2024) ergab, dass die Crawler von OpenAI, Anthropic und Perplexity JavaScript-Dateien zwar teilweise abrufen, aber nicht ausführen. Inhalte, die nur clientseitig entstehen, sehen diese Bots dann nicht. Die KI-Betreiber dokumentieren das Verhalten nicht, es beruht auf Messungen Dritter. Laut Berichten hat sich daran bis Oktober 2026 nichts geändert. Google weist selbst darauf hin, dass nicht alle Bots JavaScript ausführen können.

Wie lange es dauern kann, bis per JavaScript geänderte Inhalte in der Suche ankommen, zeigten Praxistests aus dem Jahr 2017. Auf der Startseite waren die Änderungen nach acht Tagen sichtbar, bei weniger wichtigen Unterseiten nach rund zwei Monaten. Google gibt heute an, dass eine Seite oft nur wenige Sekunden in der Rendering-Warteschlange steht, es aber auch länger dauern kann. Dazu kommt die Zeit bis zum nächsten Crawl.

Rendering-Varianten

Beim Client-Side Rendering (CSR) baut der Browser die Seite aus JavaScript zusammen. Beim Server-Side Rendering (SSR) und bei statischer Generierung liefert der Server fertiges HTML aus. Google nennt Server-Side- oder Pre-Rendering „eine sehr gute Option“, weil die Website damit für Nutzer und Crawler schneller wird. Dynamic Rendering, also eine eigene Fassung nur für Bots, bezeichnet Google als Behelfslösung und nicht als langfristigen Weg.

Beispiel

Ein Onlineshop lädt die Produktliste einer Kategorie per fetch() nach. Im Quelltext steht nur:

<div id="produkte"></div>
<button onclick="ladeMehr()">Mehr laden</button>

Google sieht nach dem Rendering die ersten 24 Produkte. Die übrigen erscheinen erst nach Klick auf den Button und haben keine eigene URL. Eine Paginierung mit echten Links wie <a href="?seite=2"> macht sie crawlbar.

Checkliste

Die Punkte stammen aus Googles Grundlagen zu JavaScript-SEO.

• Wichtige Inhalte, Links und Metadaten stehen im gerenderten HTML, geprüft mit dem URL-Prüftool der Search Console.
• Jede Seite hat einen eindeutigen <title> und eine eigene Meta-Description, auch wenn JavaScript sie setzt.
• Links sind <a>-Elemente mit href-Attribut.
• Single-Page-Anwendungen nutzen für das Routing die History API statt Fragment-URLs.
• Fehlerseiten in Single-Page-Anwendungen leiten per JavaScript auf eine URL mit Status 404 um oder setzen per JavaScript noindex.
• Ein Canonical, das JavaScript setzt, ist identisch mit dem Canonical im ursprünglichen HTML.
• Seiten, die indexiert werden sollen, haben kein noindex im ausgelieferten HTML.
• Die robots.txt sperrt keine JavaScript-Dateien oder Schnittstellen, die das Rendering braucht.
• JavaScript-Dateien tragen einen Fingerprint im Dateinamen, etwa main.2bb85551.js, damit Google keine veralteten Dateien aus dem Cache nutzt.

Häufige Fragen

Wie prüfe ich, was Google von einer JavaScript-Seite sieht? Das URL-Prüftool der Search Console zeigt das gerenderte HTML und blockierte Ressourcen. Ein Vergleich mit dem Quelltext (Rohes HTML) zeigt, welche Inhalte erst per JavaScript entstehen.

Stand: 8. Oktober 2026