Googlebot crawlt deine Website in zwei Phasen. JavaScript-schwere Seiten verbrauchen mehr Crawl-Budget, können Indexierungsverzögerungen verursachen und wichtige Inhalte unsichtbar machen. Hier erfährst du, wie das Two-Wave-Rendering funktioniert und wie du deine Website JS-SEO-optimiert aufstellst.
Das Crawl-Budget beschreibt die Menge an Seiten, die Googlebot in einem bestimmten Zeitraum von deiner Website crawlt und verarbeitet. Es setzt sich aus zwei Faktoren zusammen:
Für die meisten kleinen und mittleren Websites (unter 1.000 Seiten) ist das Crawl-Budget kein praktisches Problem. Relevant wird es bei:
Wenn du das Crawl-Budget tiefer verstehen möchtest, empfehlen wir auch unseren Artikel zum Crawl-Budget optimieren.
Googlebot verarbeitet JavaScript-Websites nicht auf einmal. Das Rendering läuft in zwei zeitlich getrennten Wellen ab:
Googlebot lädt die rohe HTML-Antwort des Servers. Alles was direkt im HTML-Code steht, wird sofort indexiert. Externe JavaScript-Dateien werden in dieser Phase noch nicht ausgeführt. Das passiert innerhalb von Stunden nach dem Crawl.
Zu einem späteren Zeitpunkt – von einigen Stunden bis zu mehreren Tagen – kommt Googlebot zurück und führt JavaScript aus. Dieser zweite Besuch ist ressourcenintensiv und hat eine niedrigere Priorität. Erst jetzt werden Inhalte sichtbar, die von JavaScript in den DOM eingefügt werden.
Die praktische Konsequenz: Wenn kritische Inhalte (Titel, Preise, Produktbeschreibungen, Kategorie-Links) erst nach JavaScript-Rendering sichtbar sind, kann es Tage dauern, bis Google sie indexiert. Das verlangsamt neue Seiten und kann Rankings verzögern.
Das Rendering von JavaScript ist für Google rechenintensiver als das einfache Parsen von HTML. Google beschreibt selbst, dass JavaScript-Rendering Ressourcen verbraucht, die begrenzt sind. Bei sehr JavaScript-lastigen Websites kann es passieren, dass Googlebot weniger Seiten pro Tag crawlt als bei einer einfachen HTML-Website gleicher Größe.
Das ist besonders problematisch für:
Wie wir im Artikel zu JavaScript async und defer beschrieben haben, blockieren Scripts ohne diese Attribute das HTML-Parsing. Für Googlebot bedeutet das: Länger brauchen um eine Seite zu verarbeiten, was zu einem niedrigeren effektiven Crawl-Budget führt.
Stell dir vor, du kannst normalerweise 1.000 Seiten pro Tag crawlen. Wenn jede Seite 2 Sekunden länger braucht weil Scripts das Rendering blockieren, reduziert das de facto dein Crawl-Budget. Mehr Ressourcen pro Seite = weniger Seiten insgesamt.
Viele moderne Websites laden neue Inhalte per "Infinite Scroll" oder "Load More"-Buttons nach. Das Problem: Googlebot scrollt nicht. Was nicht im initialen HTML (oder nach einem ersten JavaScript-Render) sichtbar ist, wird möglicherweise nicht gecrawlt.
Die Lösung: Implementiere Paginierung mit echten URLs (/kategorie?seite=2) statt reinem Infinite Scroll. Dann kann Googlebot jede Seite einzeln crawlen.
<!-- ⛔ PROBLEMATISCH: Navigation mit JavaScript-Event statt echten Links -->
<button onclick="navigateTo('/produkte/')">Produkte</button>
<!-- ✅ GUT: Echter Hyperlink -->
<a href="/produkte/">Produkte</a>Wenn die Navigation deiner Website ausschließlich per JavaScript-Events funktioniert (onclick statt echter <a href>-Links), kann Googlebot die Seiten möglicherweise nicht crawlen. Googlebot kann zwar JavaScript ausführen, aber er erkennt Link-Strukturen primär über <a href>-Tags.
// ⛔ PROBLEMATISCH: Wichtiger Inhalt nur wenn JS-Variable gesetzt
if (window.userLoggedIn) {
document.getElementById('product-description').innerHTML = 'Produktbeschreibung...';
}
// Googlebot ist nicht eingeloggt → Beschreibung bleibt leerWenn wichtige Inhalte nur unter bestimmten JavaScript-Bedingungen gerendert werden (Login-Status, Cookie-Wert, localStorage), sieht Googlebot diese Inhalte nicht. Das gilt für Produktbeschreibungen, Preise, Bewertungen – alles was hinter einem JavaScript-Gatter steckt.
// ⛔ PROBLEMATISCH: Canonical erst nach Seitenload setzen
document.addEventListener('DOMContentLoaded', function() {
const canonical = document.createElement('link');
canonical.rel = 'canonical';
canonical.href = 'https://beispiel.de/richtige-url/';
document.head.appendChild(canonical);
});Canonical-Tags und Meta-Tags (robots, noindex) sollten immer im statischen HTML stehen. Wenn sie per JavaScript gesetzt werden, können sie im ersten Crawl-Wave fehlen, was zu falscher Indexierung oder doppeltem Content in der zweiten Welle führt.
Wenn JavaScript-Fehler das weitere Script-Rendering stoppen, kann Googlebot weniger Inhalte sehen als ein normaler Nutzer. Wichtige Inhalte die von einem Script abhängen, das mit einem Fehler abbricht, bleiben unsichtbar.
Überprüfe regelmäßig die JavaScript-Konsole deiner Seite in den Chrome DevTools. Jeder unbehandelte Fehler ist ein potenzielles Indexierungsproblem.
Du hast mehrere Möglichkeiten, das JavaScript-Rendering aus Googlebots Perspektive zu testen:
Im "URL prüfen"-Tool der Search Console kannst du eine URL eingeben und dann auf "Gerenderte Seite" klicken. Du siehst den gerenderten Screenshot und den DOM nach JavaScript-Rendering – genau so wie Googlebot die Seite sieht.
Das Live-Test-Feature in der Search Console zeigt dir sowohl den HTML-Quellcode (Wave 1) als auch den gerenderten DOM (Wave 2). Vergleiche beide: Alles was nur im gerenderten DOM steht, muss die JS-Rendering-Queue durchlaufen.
Deaktiviere JavaScript im Browser (Chrome DevTools → drei Punkte → More tools → Rendering → uncheck "Enable JavaScript") und lade deine Seite neu. Was du jetzt siehst, ist ungefähr das, was Googlebot in Wave 1 sieht. Fehlen kritische Inhalte? Das ist ein Problem.
Mit dem JavaScript SEO Checker auf Shift07 kannst du direkt sehen, welche Inhalte auf deiner Seite von JavaScript abhängen und potenziell Indexierungsprobleme verursachen.
Bei SSR rendert der Server das fertige HTML – inklusive aller JavaScript-generierten Inhalte – und sendet es an den Browser. Googlebot sieht sofort alle Inhalte, ohne auf JavaScript-Rendering zu warten. Das ist die beste Lösung für SEO-kritische Inhalte.
getServerSideProps oder getStaticPropsBei SSG werden alle Seiten beim Build-Prozess als statische HTML-Dateien erzeugt. Für Blogs, Dokumentationen und ähnliche Websites mit selten wechselnden Inhalten ist das ideal – maximale Crawl-Effizienz, kein JavaScript-Rendering nötig.
Als Zwischenlösung können SPAs Dynamic Rendering einsetzen: Für normale Nutzer wird die SPA ausgeliefert, für Googlebot (erkannt am User-Agent) eine vorgerenderte HTML-Version. Tools wie Rendertron oder Prerender.io können das übernehmen. Mehr dazu in unserem Artikel zu Dynamic Rendering für JavaScript SEO.
Der klassische Ansatz: Erstelle eine vollständig funktionsfähige HTML-Version deiner Seite als Basis. JavaScript verbessert nur das Nutzererlebnis obendrauf. So hat Googlebot immer Zugriff auf alle kritischen Inhalte im HTML, während Nutzer die verbesserte JavaScript-Version erleben.
<a href>-Links (nicht nur JavaScript-Events)async oder defer geladen (kein render-blocking)JavaScript und SEO schließen sich nicht aus – aber JavaScript-schwere Websites müssen mehr Sorgfalt auf die Crawlability und das Rendering ihrer Inhalte verwenden. Das Two-Wave-Rendering von Googlebot bedeutet: Inhalte, die erst nach JavaScript-Ausführung erscheinen, werden später und seltener indexiert als HTML-Inhalte.
Die wichtigsten Maßnahmen:
<a href> ermöglicht Googlebot die Entdeckung aller URLs.async und defer reduzieren den Crawl-Aufwand pro Seite.In Kombination mit einem optimierten Crawl-Budget und dem Entfernen von render-blockenden Ressourcen legst du die technische Grundlage für eine gut indexierte, schnelle Website.