JavaScript-SEO: was Google von einer JavaScript-Seite wirklich zu sehen bekommt
Google kann JavaScript ausführen, aber nicht sofort und nicht immer vollständig. Was im ersten HTML steht, ist sicher. Alles andere hängt am Rendern — und dort gehen Links, Texte und Statuscodes verloren, wenn die Seite nicht dafür gebaut ist.
JavaScript ist für Suchmaschinen kein Hindernis mehr — aber auch nicht gleichwertig zu fertigem HTML. Google kann Seiten rendern, also JavaScript ausführen und das Ergebnis lesen. Die Frage ist, was dabei verloren geht und wie man die Seite so baut, dass das Wichtigste gar nicht vom Rendern abhängt.
Drei Schritte statt einem
Google beschreibt die Verarbeitung von JavaScript-Seiten in drei Phasen: Crawlen, Rendern und Indexieren. Beim Crawlen wird das HTML abgerufen und nach Links durchsucht. Das Rendern — das Ausführen von JavaScript in einem Browser — kann danach in eine Warteschlange kommen. Erst das gerenderte Ergebnis wird indexiert.
Für die Praxis folgt daraus eine einfache Regel: Was schon im ersten HTML steht, ist sicher. Title, Description, Canonical, Überschriften, Text und Links werden beim ersten Abruf gesehen. Alles, was erst JavaScript erzeugt, hängt davon ab, dass das Rendern stattfindet und gelingt.
Was dabei verloren geht
| Element | Problem, wenn nur JavaScript es erzeugt |
|---|---|
| Text und Produktdaten | fehlen, wenn eine API beim Rendern nicht antwortet oder zu langsam ist |
| Links | werden nicht verfolgt, wenn sie kein a-Element mit href sind |
| Title und Canonical | können sich zwischen erstem und gerendertem HTML widersprechen |
| Statuscode | eine „nicht gefunden“-Ansicht mit Status 200 ist ein Soft-404 |
| Strukturierte Daten | fehlen im ersten Abruf, wenn sie erst im Browser entstehen |
Besonders tückisch sind Links. Ein Menü, das über onClick navigiert, funktioniert für Besucher einwandfrei. Für eine Suchmaschine gibt es dort keinen Link, dem sie folgen kann.
Zwei Fehler, die uns selbst passiert sind
Unsere Website ist eine React-Anwendung. Jede Seite wird beim Build vorgerendert, das erste HTML enthält also den vollständigen Inhalt. Trotzdem sind uns zwei typische Fehler unterlaufen.
Leer nach dem Laden. Eine neue Seite war auf dem Server korrekt, wurde im Browser aber beim Hydrieren leer — dem Moment, in dem React das vorgerenderte HTML übernimmt. Die Ursache: Daten, die die Seite für die Übergabe an den Browser mitgab, enthielten Bestandteile, die sich nicht übertragen lassen. Im ersten HTML stand alles; im Browser wäre die Seite für Besucher leer geworden. Wir haben das vor der Veröffentlichung im Browser bemerkt — eine Prüfung nur des HTML hätte es nie gefunden.
Inhalt nur im Bundle. Ein Fragenblock auf einer unserer Leistungsseiten stand nur im JavaScript, nicht im vorgerenderten HTML. Bei einem Vergleich der ausgelieferten Seiten fiel er deshalb nicht auf — weder als Änderung noch als Inhalt. Für eine Suchmaschine war er nur nach dem Rendern vorhanden.
Beide Fälle zeigen dieselbe Lehre: Man muss beide Sichten prüfen — das erste HTML und die gerenderte Seite im Browser.
Welche Rendering-Strategie wofür passt
| Strategie | Erstes HTML | geeignet für |
|---|---|---|
| Nur im Browser rendern | leere Hülle | Bereiche hinter einer Anmeldung |
| Vorrendern beim Build | vollständig | Inhalte, die sich mit dem Release ändern: Leistungen, Ratgeber |
| Serverseitiges Rendern | vollständig | Seiten mit häufig wechselnden Daten: Kategorien, Preise, Bestände |
| Dynamisches Rendern nur für Bots | vollständig für Bots | laut Google eine Übergangslösung, keine langfristige |
Für Onlineshops mit Headless-Frontend ist serverseitiges Rendern meist der richtige Weg, weil Preise und Bestände nicht bis zum nächsten Build warten können. Wie viel eine Storefront über die API überhaupt bekommt, haben wir in zwanzig Storefront-Funktionen gegen die Store-API geprüft.
So prüfen Sie eine Seite
- Ohne JavaScript abrufen.
curl -s https://ihre-domain.de/seitezeigt das erste HTML. Stehen Überschrift, Text, Links und Canonical darin? - URL-Prüfung in der Search Console. Unter „Gecrawlte Seite“ sehen Sie das HTML, das Google gerendert hat, und mögliche Ladefehler.
- Im Browser mit Konsole. Neue Vorlagen einmal laden und die Konsole auf Fehler prüfen.
- Unbekannte Adresse aufrufen. Eine erfundene URL muss mit Status 404 antworten, nicht mit 200.
- robots.txt gegenlesen. Skripte und Styles, die zum Darstellen nötig sind, dürfen nicht gesperrt sein.
Wie technische SEO-Punkte in einem Shop priorisiert werden, steht im Ratgeber Technisches SEO im Onlineshop.
JavaScript ist kein SEO-Problem, solange das Wichtige nicht davon abhängt. Gehört es ins erste HTML, ist es beim ersten Abruf da — egal, wann gerendert wird.
Häufige Fragen
- Kann Google JavaScript ausführen?
- Ja. Google rendert Seiten mit einem aktuellen Chromium. Das Rendern kann aber zeitversetzt zum Abruf erfolgen, und was dabei scheitert — etwa ein blockiertes Skript oder ein Fehler beim Laden von Daten —, fehlt im Index.
- Brauche ich serverseitiges Rendern?
- Nicht zwingend. Entscheidend ist, dass das erste HTML den Inhalt enthält. Das erreicht man mit serverseitigem Rendern oder mit Vorrendern beim Build. Für Seiten, deren Inhalt sich selten ändert, ist Vorrendern oft die einfachere Lösung.
- Was ist ein Soft-404 bei JavaScript-Seiten?
- Eine Seite, die „nicht gefunden“ anzeigt, aber mit Status 200 antwortet. Bei Single-Page-Anwendungen passiert das, wenn der Server jede Adresse mit derselben Hülle beantwortet. Der Server sollte für unbekannte Adressen 404 senden.
- Darf ich JavaScript-Dateien in der robots.txt sperren?
- Nein, wenn die Seite sie zum Darstellen braucht. Ohne die Dateien kann Google die Seite nicht rendern und sieht nur die leere Hülle.
- Gilt das auch für Shops mit Headless-Frontend?
- Ja, besonders dort. Ein Headless-Frontend holt Produkte und Kategorien über eine API. Wenn diese Daten erst im Browser geladen werden, steht im ersten HTML nichts davon.