JavaScript-SEO: JS-Seiten indexieren lassen

Indexierung erfolgt in zwei Wellen

Googlebot ruft zunächst Ihr rohes HTML ab und kann jeden Inhalt, der bereits in dieser ersten Antwort vorhanden ist, fast sofort indexieren. Alles, was erst nach der Ausführung von JavaScript erscheint, wird für einen zweiten Durchlauf — das Rendering — eingereiht, der separate Ressourcen nutzt und dem ersten Crawling um Sekunden bis, auf einer crawl-eingeschränkten Website, deutlich länger hinterherhinken kann. Wenn Ihre Inhalte oder internen Links erst nach diesem zweiten Durchlauf existieren, verlassen Sie sich auf einen langsameren, weniger sicheren Weg, überhaupt indexiert zu werden.

Was die Indexierung tatsächlich zerstört

• Hauptinhalt oder interne Links, die erst nach einem Client-Abruf gerendert werden, ohne aussagekräftigen Inhalt im ursprünglichen HTML.
• Inhalte, die hinter einer Nutzeraktion verborgen sind — ein Klick, ein Scrollen, ein Hover —, die Googlebot keinen Grund hat auszuführen.
• In robots.txt blockierte JS- oder CSS-Dateien, die die Seite zum korrekten Rendern benötigt; siehe Robots.txt vs. Noindex dafür, wie sich eine Blockade als Bumerang erweisen kann.
• Clientseitiges Routing, das den tatsächlichen HTTP-Status nie ändert — eine defekte Route kann leer rendern oder eine Nicht-gefunden-Meldung anzeigen, während sie weiterhin 200 zurückgibt, was als Soft 404 erscheint.
• Hydrations- oder Rendering-Fehler, die nur in einer Headless-Browser-Umgebung auftreten und bei normalen manuellen Tests unbemerkt bleiben.

So prüfen Sie, was Google tatsächlich sieht

Die URL-Prüfung in Search Console verfügt über eine Ansicht „Getestete Seite“, die das gerenderte HTML und einen Screenshot nach dem Durchlauf von Googles Renderer zeigt — nicht nur die rohe Antwort. Vergleichen Sie das mit Ihrem Quell-HTML: Fehlen wichtige Inhalte oder Links in der rohen Antwort, sind aber nach dem Rendering vorhanden, hängen Sie vollständig von der Render-Warteschlange ab statt vom schnellen ersten Crawling.

Was tatsächlich hilft

• Rendern Sie die für SEO relevanten Inhalte und Navigationslinks serverseitig (oder generieren Sie sie statisch), statt sie nach dem Laden clientseitig abzurufen.
• Verwenden Sie echte <a href>-Elemente für interne Links, keine Klick-Handler auf Nicht-Anker-Elementen — Googlebot folgt hrefs, nicht beliebigen JavaScript-Event-Bindungen.
• Blockieren Sie nicht die JS/CSS-Bundles, von denen die Seite zum Rendern abhängt — Google muss sie abrufen können, um die Seite überhaupt zu rendern.
• Sobald eine Seite behoben ist, warten Sie nicht einfach auf den nächsten Render-Durchlauf — beantragen Sie die Neuindexierung direkt oder pushen Sie die URL über IndexNow, damit die korrigierte Version nach Ihrem eigenen Zeitplan erfasst wird statt nach der Warteschlange des Renderers.

Hinweise zu einzelnen Frameworks

• Clientseitige React-Apps: Eine reine Single-Page-App liefert eine fast leere HTML-Hülle aus. Für Seiten, die ranken sollen, verwenden Sie ein Framework mit Server-Rendering oder statischer Generierung.
• Next.js und Nuxt: Server-Rendering und statische Generierung legen den Inhalt standardmäßig ins initiale HTML. Achten Sie auf wichtige Inhalte, die nur in clientseitigen Effects geladen werden.
• Angular und Vue: Nutzen Sie das serverseitige Rendering von Angular bzw. Nuxt für Vue, damit Seiten mit ihrem Inhalt bereits im HTML ausgeliefert werden.
• Infinite Scroll: Kombinieren Sie ihn mit paginierten URLs, die eigenständig laden, damit Crawler auch Elemente jenseits des ersten Bildschirms erreichen.

Ein kurzer Test, den Sie heute durchführen können

Öffnen Sie die Seite, wählen Sie „Seitenquelltext anzeigen“ (nicht „Untersuchen“) und suchen Sie nach einem Satz aus Ihrem Hauptinhalt sowie einigen internen Link-URLs. Fehlen sie im Quelltext, sind sie von JavaScript abhängig. Führen Sie anschließend eine kostenlose Indexierbarkeitsprüfung durch, um zu bestätigen, dass die Seite 200 zurückgibt, nicht auf noindex gesetzt ist und das richtige Canonical hat.