JavaScript SEO richtig umsetzen
Rendering, crawlbare Navigation und Indexierung moderner Websites verlässlich planen und testen
Rendering, crawlbare Navigation und Indexierung moderner Websites verlässlich planen und testen
JavaScript SEO stellt sicher, dass Suchmaschinen die wichtigen Inhalte, Links und Seitensignale einer JavaScript-basierten Website zuverlässig abrufen, rendern und indexieren können. Betroffen sind nicht nur Single-Page-Applications. Auch Shops, Buchungsseiten und klassische CMS-Websites laden Navigation, Produktdaten, Filter oder Textabschnitte häufig erst nachträglich über JavaScript.
Google kann JavaScript mit einem aktuellen Chromium-System ausführen. Daraus folgt jedoch nicht, dass jede technisch im Browser sichtbare Ansicht automatisch und sofort für die Suche verfügbar ist. Der Crawler muss zunächst die URL und ihre Ressourcen abrufen, anschließend kann die Seite in einer getrennten Phase gerendert werden. Fehlerhafte API-Aufrufe, blockierte Skripte, nicht crawlbare Navigation oder eine leere HTML-Ausgabe können diesen Ablauf unterbrechen.
Das Ziel ist deshalb nicht, JavaScript grundsätzlich zu vermeiden. Entscheidend ist eine Architektur, in der zentrale Inhalte und Navigationswege auch bei verzögerter oder fehlgeschlagener Skriptausführung belastbar bleiben.
Google beschreibt die Verarbeitung JavaScript-basierter Seiten in drei Phasen: Crawling, Rendering und Indexierung. Beim ersten Abruf prüft Googlebot die robots.txt, liest die HTTP-Antwort und kann bereits Links aus dem ursprünglichen HTML übernehmen. Seiten mit Status 200 gelangen grundsätzlich in die Rendering-Warteschlange, sofern keine Indexierungssperre entgegensteht. Nach der Ausführung des JavaScripts wird das gerenderte HTML erneut ausgewertet.
Zwischen Abruf und Rendering kann Zeit liegen. Eine Website, deren Hauptinhalt ausschließlich nach einem clientseitigen API-Aufruf erscheint, schafft daher zusätzliche Fehlerquellen. Serverseitig ausgeliefertes HTML kann dagegen schon beim ersten Abruf gelesen werden und ist außerdem für Browser, Assistenztechnik und andere Crawler robuster.
Die passende Rendering-Strategie hängt von Inhalt, Aktualität, Personalisierung und technischer Plattform ab. Viele Projekte kombinieren mehrere Verfahren: redaktionelle Seiten werden statisch erzeugt, Produktseiten serverseitig gerendert und interaktive Funktionen anschließend im Browser aktiviert.
| Verfahren | Erste HTML-Antwort | SEO-Eignung | Typisches Risiko |
|---|---|---|---|
| Client-Side Rendering (CSR) | App-Shell, Inhalt folgt per JavaScript | Möglich, wenn Rendering vollständig funktioniert | Leere oder unvollständige Ausgabe bei Skript- und API-Fehlern |
| Server-Side Rendering (SSR) | Inhaltliches HTML pro Anfrage | Sehr gut für dynamische, öffentliche Seiten | Serverlast, Cache- und Hydration-Fehler |
| Static Site Generation (SSG) | Vorab erzeugtes vollständiges HTML | Sehr gut für stabile Inhalte | Veraltete Seiten bei fehlendem Rebuild |
| Hydration | SSR- oder SSG-HTML wird interaktiv | Gut bei konsistenter Ausgabe | Server- und Client-Zustand unterscheiden sich |
| Dynamic Rendering | Unterschiedliche Ausgabe für Bots und Nutzer | Nur als Übergangslösung | Hohe Komplexität und abweichende Inhalte |
Google empfiehlt Dynamic Rendering nicht mehr als dauerhafte Lösung. Wenn eine bestehende Anwendung Probleme verursacht, sind serverseitiges Rendering, statische Erzeugung oder Hydration in der Regel die wartbareren Zielbilder. Unabhängig vom Verfahren müssen Nutzer und Suchmaschinen inhaltlich dieselbe Seite erhalten.
Google kann Links am zuverlässigsten als HTML-Element <a> mit einem auflösbaren href-Attribut erkennen. Ein Klick-Handler auf einem div, ein Button ohne Zieladresse oder eine URL nur in einem Datenattribut ersetzt keinen crawlbaren Link.
<!-- crawlbar und auch ohne JavaScript nutzbar -->
<a href="/produkte/laufschuhe/">Laufschuhe</a>
<!-- keine verlässliche interne Verlinkung -->
<button onclick="openCategory('laufschuhe')">Laufschuhe</button>Clientseitiges Routing darf den normalen Link ergänzen: JavaScript kann den Klick abfangen, die Ansicht aktualisieren und mit der History API die URL setzen. Die Zieladresse muss trotzdem direkt aufrufbar sein und serverseitig eine passende Antwort liefern. Hash-Fragmente wie /shop/#/produkt-123 sollten nicht verwendet werden, um eigenständige indexierbare Inhalte zu adressieren.
href-Ziele.Jede indexierbare URL braucht einen eindeutigen Seitentitel, eine passende Meta Description und einen konsistenten Canonical. Diese Angaben sollten bevorzugt bereits im ursprünglichen HTML-Head stehen. Google kann mit JavaScript gesetzte Metadaten verarbeiten, doch serverseitige Angaben reduzieren Wartezeit und Konflikte.
<title>Laufschuhe für Damen | Beispiel-Shop</title>
<meta name="description" content="Leichte Damen-Laufschuhe vergleichen.">
<link rel="canonical" href="https://www.example.de/laufschuhe/damen/">Ein besonders riskanter Ausgangszustand ist noindex im initialen HTML, das JavaScript später entfernen soll. Google kann die Seite wegen der Sperre bereits vor dem Rendering verwerfen. Soll eine URL indexiert werden, darf sie deshalb nicht zunächst als noindex ausgeliefert werden. Ebenso problematisch sind doppelte Canonicals oder Metadaten, die während der Hydration auf andere Werte wechseln.
Strukturierte Daten sollten denselben sichtbaren Hauptinhalt beschreiben und nach dem Rendering vollständig vorhanden sein. Für wichtige Seitentypen ist eine serverseitige JSON-LD-Ausgabe meist einfacher zu prüfen und gegen Template-Änderungen abzusichern.
Der sichtbare Text „Produkt nicht gefunden“ macht aus einer erfolgreichen HTTP-Antwort noch keine Fehlerseite. Liefert eine SPA für existierende und nicht existierende Routen immer Status 200, können Soft-404-Signale, unnötiges Rendering und unklare Indexierungszustände entstehen. Der Server sollte den Zustand bereits in der HTTP-Antwort ausdrücken.
| Status | Bedeutung | Typischer SEO-Einsatz |
|---|---|---|
| 200 | Inhalt erfolgreich geliefert | Existierende, nutzbare und grundsätzlich indexierbare Seite |
| 301 oder 308 | Dauerhaft verschoben | Alte URL hat ein fachlich passendes neues Ziel |
| 302 oder 307 | Vorübergehend anderes Ziel | Zeitlich begrenzte Umleitung |
| 404 | Ressource nicht gefunden | URL existiert nicht oder ihr Zustand ist unbekannt |
| 410 | Ressource dauerhaft entfernt | Entfernung ist sicher bekannt und es gibt keinen Ersatz |
| 500 oder 503 | Serverfehler oder vorübergehend nicht verfügbar | Technischer Fehler; nicht als leere Seite mit 200 tarnen |
Wenn ein altes Produkt einen passenden Nachfolger besitzt, ist eine serverseitige permanente Weiterleitung sinnvoll. Ohne Ersatz liefert die URL 404 oder bei sicher dauerhafter Entfernung 410. JavaScript-Weiterleitungen sind nur eine nachrangige Lösung, wenn der Serverstatus technisch nicht steuerbar ist.
Google kann nur rendern, was Googlebot abrufen darf und was innerhalb der Rendering-Umgebung erfolgreich antwortet. Werden benötigte JavaScript- oder CSS-Dateien in der robots.txt gesperrt, fehlen möglicherweise Inhalte, Navigation oder Layoutinformationen. Auch API-Endpunkte müssen ohne Nutzeraktion erreichbar sein, dürfen keine abgelaufenen Tokens voraussetzen und sollten Fehler kontrolliert behandeln.
Lazy Loading kann die anfängliche Datenmenge reduzieren, darf wichtige Inhalte aber nicht dauerhaft hinter Scroll-, Klick- oder Wischaktionen verstecken. Inhalte sollten geladen werden, sobald sie in den sichtbaren Bereich gelangen. Bei Bildern ist natives Lazy Loading eine robuste Grundlage:
<img src="/bilder/laufschuh-123.webp"
loading="lazy"
width="800" height="600"
alt="Blauer Laufschuh Modell 123">Infinite Scroll benötigt zusätzlich eine crawlbare Seitenfolge. Jeder Ausschnitt erhält eine dauerhafte URL, zum Beispiel ?page=2, und ist über einen normalen Link erreichbar. Die sichtbare Endlosansicht kann diese URLs per JavaScript nachladen, die Suchmaschine darf aber nicht auf Scroll-Ereignisse angewiesen sein.
<a href="/kategorie/laufschuhe/?page=2">Nächste Seite</a>Jede paginierte Seite sollte einen eigenen selbstreferenzierenden Canonical besitzen. Alle Folgeseiten auf Seite 1 zu kanonisieren oder nur die erste URL in der Navigation erreichbar zu machen, kann die Entdeckung tiefer liegender Produkte erschweren.
JavaScript SEO und Performance sind nicht identisch, beeinflussen sich aber gegenseitig. Große Bundles belegen Hauptthread und Netzwerk, verspätete Hydration verzögert Interaktion und nachträglich eingefügte Elemente können Layoutverschiebungen verursachen. Technische Entscheidungen sollten deshalb sowohl Indexierbarkeit als auch reale Nutzungsdaten berücksichtigen.
Ein Test im eigenen Browser reicht nicht aus: Dort können Cookies, Cache, Login und bereits geladene App-Daten Fehler verdecken. Für wichtige Templates werden ursprüngliches HTML, gerenderter DOM, Netzwerkantworten und Google-Sicht gemeinsam geprüft.
curl kontrollieren.curl -I https://www.example.de/produkte/laufschuh-123/
curl -L -s https://www.example.de/produkte/laufschuh-123/Nach Releases werden dieselben Muster automatisiert überwacht. Besonders aussagekräftig sind Abweichungen bei Statuscodes, leerer Hauptinhalt, fehlende interne Links, geänderte Canonicals und ein unerwarteter Anstieg von JavaScript- oder API-Fehlern.
<a href>-Links erreichbar?Passende Artikel: Robots.txt richtig einsetzen, Canonical Tag richtig einsetzen und Google Search Console richtig nutzen. Die technische Prüfung konkreter Rendering- und Indexierungsprobleme ist Bestandteil unserer SEO-Seitenanalyse.