Das Grundproblem
Bei einer klassischen Website liefert der Server fertiges HTML aus. Suchmaschinen lesen den Inhalt direkt aus dieser Antwort. Bei vielen JavaScript-Anwendungen liefert der Server dagegen eine fast leere HTML-Hülle und ein großes Skript. Erst wenn der Browser das Skript ausführt, entstehen Texte, Bilder und Links.
Für Google bedeutet das: Um den Inhalt zu sehen, muss die Seite gerendert werden. Google kann das – der Web Rendering Service nutzt eine aktuelle Version von Chromium. Aber das Rendering ist aufwendig, kann zeitverzögert stattfinden und scheitert gelegentlich an Fehlern, Zeitlimits oder blockierten Ressourcen. Andere Suchmaschinen und viele KI-Crawler rendern JavaScript deutlich eingeschränkter oder gar nicht.
Wie Google JavaScript verarbeitet
- Crawling: Der Googlebot ruft die URL ab und erhält das ursprüngliche HTML.
- Erste Verarbeitung: Links und Inhalte im ursprünglichen HTML werden sofort erfasst.
- Rendering-Warteschlange: Die Seite wird für das Rendering vorgemerkt.
- Rendering: Der Web Rendering Service lädt die Seite mit allen Ressourcen, führt JavaScript aus und erzeugt das gerenderte HTML.
- Zweite Verarbeitung: Inhalte und Links aus dem gerenderten HTML werden erfasst und für die Indexierung verwendet.
Google hat erklärt, dass die Verzögerung zwischen Crawling und Rendering heute meist kurz ist. In der Praxis sehe ich aber immer wieder Fälle, in denen Inhalte, die nur per JavaScript erzeugt werden, verzögert oder unvollständig indexiert werden – besonders bei großen Websites.
Die Rendering-Strategien im Vergleich
| Strategie | Funktionsweise | SEO-Eignung | Typische Frameworks |
|---|---|---|---|
| Client-Side Rendering (CSR) | Browser erzeugt die Inhalte aus JavaScript | riskant, abhängig vom Rendering der Suchmaschine | React (klassisch), Vue, Angular ohne SSR |
| Server-Side Rendering (SSR) | Server erzeugt für jede Anfrage fertiges HTML, JavaScript übernimmt danach | sehr gut | Next.js, Nuxt, Angular Universal, SvelteKit |
| Static Site Generation (SSG) | HTML wird beim Build vorab erzeugt | sehr gut, ideal für Inhalte, die sich selten ändern | Next.js, Nuxt, Astro, Gatsby, Hugo |
| Incremental Static Regeneration (ISR) | statische Seiten werden bei Bedarf neu erzeugt | sehr gut für große Websites | Next.js, Nuxt |
| Dynamic Rendering | Bots bekommen vorgerenderte Seiten, Nutzer die JavaScript-Version | Übergangslösung, von Google nicht mehr empfohlen | Prerender-Dienste |
| Hybride Ansätze, Islands | nur interaktive Bereiche nutzen JavaScript | sehr gut | Astro, Qwik |
Für Websites, die über Suchmaschinen gefunden werden sollen, empfehle ich SSR oder SSG. Client-Side Rendering ist für eingeloggte Anwendungsbereiche, Dashboards oder Werkzeuge in Ordnung, die ohnehin nicht indexiert werden sollen.
Die typischen Probleme
Links, die keine Links sind
Google folgt nur Links, die als <a href="..."> umgesetzt sind. Elemente, die per onclick oder Router-Funktionen navigieren, ohne ein href zu besitzen, erkennt Google nicht als Link.
<!-- Wird von Google erkannt -->
<a href="/leistungen/dachsanierung">Dachsanierung</a>
<!-- Wird nicht als Link erkannt -->
<span onclick="navigate('/leistungen/dachsanierung')">Dachsanierung</span>
<a onclick="goTo('dach')">Dachsanierung</a>
Fragment-URLs
URLs mit Hash wie /#/leistungen werden von Google nicht als eigene Seiten behandelt. Alles nach dem # ignoriert Google für die Indexierung. Moderne Router nutzen deshalb die History API mit echten Pfaden.
Inhalte nach Nutzeraktionen
Google klickt keine Buttons, scrollt nicht wie ein Mensch und füllt keine Formulare aus. Inhalte, die erst nach einem Klick auf „Mehr laden“ oder beim Scrollen erscheinen, bleiben unter Umständen unsichtbar. Unendliches Scrollen sollte deshalb mit paginierten URLs kombiniert werden, die sich direkt aufrufen lassen.
Metadaten per JavaScript
Titel, Meta Description, Canonical-Tags und Robots-Anweisungen, die erst per JavaScript gesetzt oder verändert werden, sind fehleranfällig. Besonders heikel: Steht im ursprünglichen HTML noindex und entfernt JavaScript es später, verarbeitet Google die Seite unter Umständen gar nicht erst weiter.
Fehlerseiten ohne Statuscode
Single-Page-Apps liefern für jede Route den Statuscode 200, weil der Server nur die Hülle ausliefert. Eine nicht existierende Seite zeigt dann eine Fehlermeldung mit Code 200 – ein klassischer Soft 404. Die Lösung sind echte 404-Antworten vom Server oder eine noindex-Anweisung für Fehlerrouten.
Blockierte Ressourcen
Wenn JavaScript-Dateien oder API-Endpunkte per robots.txt gesperrt sind, kann Google die Seite nicht vollständig rendern.
Zeitüberschreitungen und Fehler
Skripte, die lange laden, auf langsame APIs warten oder mit Fehlern abbrechen, führen dazu, dass Google einen unvollständigen Zustand indexiert.
Performance
Große JavaScript-Bündel verlängern die Ladezeit und verschlechtern die Reaktionsfähigkeit, messbar an den Core Web Vitals LCP und INP.
So prüfen Sie Ihre JavaScript-Website
| Methode | Was sie zeigt |
|---|---|
| Quelltext im Browser (Strg+U) | ursprüngliches HTML ohne JavaScript |
| Elemente-Ansicht der Entwicklertools | gerendertes DOM nach JavaScript |
| URL-Prüfung in der Search Console | gerendertes HTML und Screenshot aus Sicht von Google |
| Rich Results Test | ebenfalls gerendertes HTML, ohne Search-Console-Zugang nutzbar |
| Crawler mit JavaScript-Rendering | Vergleich von Rohdaten und gerenderten Daten für viele Seiten |
| Browser mit deaktiviertem JavaScript | was Crawler ohne Rendering sehen |
| Suche nach Textausschnitten mit site: | ob bestimmte Inhalte indexiert sind |
Ein einfacher Test: Öffnen Sie den Quelltext einer wichtigen Seite und suchen Sie nach einem Satz aus dem Hauptinhalt. Ist er dort nicht zu finden, hängt die Indexierung vollständig vom Rendering ab.
Ein Softwareanbieter hatte seine Marketing-Website als React-Anwendung mit Client-Side Rendering umgesetzt. Die Search Console meldete die Seiten als indexiert, aber für Fachbegriffe aus den Produktbeschreibungen rankte die Website kaum. Die URL-Prüfung zeigte, dass Google zwar die Hauptüberschriften sah, die per API nachgeladenen Detailtexte aber häufig fehlten, weil die API gelegentlich langsam antwortete. Nach der Umstellung auf Next.js mit statischer Generierung erschienen die Inhalte im ursprünglichen HTML, und die Rankings für die Fachbegriffe stiegen innerhalb von zwei Monaten deutlich.
Best Practices
- Inhalte, die ranken sollen, per SSR oder SSG im ursprünglichen HTML ausliefern
- Links als
<a href>mit echten, sprechenden URLs umsetzen - History API statt Hash-Routing verwenden
- Titel, Description, Canonical und Robots serverseitig setzen
- Für nicht existierende Routen einen echten 404 zurückgeben
- JavaScript- und CSS-Ressourcen nicht per robots.txt blockieren
- Lazy Loading so umsetzen, dass Inhalte ohne Scrollen im DOM sind oder über eigene URLs erreichbar
- Bundles aufteilen und nur benötigtes JavaScript laden
- Strukturierte Daten im ursprünglichen HTML ausgeben
- Regelmäßig mit der URL-Prüfung testen
KI-Crawler und JavaScript
Ein oft übersehener Aspekt: Viele Crawler von KI-Anbietern führen kein oder nur eingeschränkt JavaScript aus. Inhalte, die nur clientseitig entstehen, sind für diese Systeme unsichtbar. Wer in ChatGPT, Perplexity oder Claude als Quelle genannt werden möchte, sollte seine wichtigsten Inhalte deshalb serverseitig bereitstellen. Mehr dazu im Beitrag KI-Crawler.
Fragen und Antworten
Kann Google JavaScript lesen?
Ja, Google rendert JavaScript mit einer aktuellen Chromium-Version. Das Rendering kann aber verzögert, unvollständig oder fehlerhaft sein. Inhalte im ursprünglichen HTML sind deshalb sicherer.
Ist React schlecht für SEO?
Nein. React mit serverseitigem Rendering oder statischer Generierung, etwa über Next.js, ist sehr gut für SEO geeignet. Probleme entstehen vor allem bei reinem Client-Side Rendering.
Brauche ich Dynamic Rendering?
Google empfiehlt Dynamic Rendering nicht mehr als langfristige Lösung. Wer neu baut, sollte auf SSR oder SSG setzen. Bestehende Lösungen mit Dynamic Rendering funktionieren weiterhin, sollten aber mittelfristig ersetzt werden.