Das Muster ist so verbreitet, dass es vorhersagbar ist. Ein Team veröffentlicht eine schöne neue Single-Page-Anwendung. Im Browser funktioniert alles. Sechs Wochen später ist der organische Traffic um 60 % eingebrochen, Seiten fehlen im Index, und niemand kann etwas Kaputtes benennen.
Die Ursache ist fast immer das Rendering. Google kann JavaScript ausführen, woraus die verbreitete Annahme entstand, JavaScript-SEO sei gelöst. Ist es nicht. Google rendert verzögert, innerhalb von Ressourcengrenzen, ohne Nutzerinteraktion und ohne Geduld für langsame Skripte. Und 2026 gibt es ein zweites Publikum: Die meisten KI-Crawler führen überhaupt kein JavaScript aus.
Möchten Sie SEO-Probleme auf jeder Website finden?
Testen Sie WebSEO Auditor kostenlos — führen Sie Ihr erstes Audit in Sekunden durch.
Kostenlos testenWie Google JavaScript tatsächlich verarbeitet
- Crawl. Der Googlebot holt das rohe HTML — genau das, was curl liefert, bevor ein Skript läuft.
- Render-Warteschlange. Braucht die Seite JavaScript, wandert sie in eine Queue. Das dauert Minuten, bei niedrig priorisierten Websites deutlich länger.
- Rendern und Indexieren. Ein Headless-Chromium führt die Skripte aus; das entstehende DOM wird indexiert.
- Alles, was nicht im rohen HTML steht, wird spät indexiert — wenn überhaupt.
- Der Renderer scrollt, klickt und akzeptiert keine Cookies. Inhalte hinter Interaktion bleiben unsichtbar.
- Rendering hat ein Budget. Langsame oder fehlerhafte Skripte werden abgebrochen — das unvollständige DOM wird indexiert.
Die verlässliche Faustregel: Google indexiert Ihr rohes HTML sofort und Ihr gerendertes DOM irgendwann. Alles Kritische gehört in das erste.
Die fünf Fehlerbilder
1. Inhalte, die Interaktion erfordern
Tabs, Akkordeons, "Mehr laden"-Buttons, Infinite Scroll und Inhalte hinter Cookie-Wänden. Akkordeons sind nur dann unkritisch, wenn der Inhalt im DOM liegt und lediglich per CSS ausgeblendet wird.
2. Client-Routing ohne echte URLs
Navigation über onclick erzeugt keine crawlbaren Links. Jedes interne Ziel braucht einen echten Anker mit href auf eine serverseitig auflösbare URL.
3. Blockierte JavaScript-Ressourcen
Blockiert die robots.txt Ihre Skript- oder CSS-Bundles, kann der Renderer die Seite nicht bauen. Assets zu sperren, um Crawl-Budget zu sparen, ist eine Scheinersparnis.
4. Soft 404 in Single-Page-Anwendungen
Ein fehlendes Produkt zeigt "nicht gefunden" auf einer Seite mit Status 200. Jeder clientseitige 404-Zustand muss mit einem echten 404 vom Server einhergehen.
5. Späte Meta-Tags und strukturierte Daten
Nachträglich per JavaScript eingefügte Titel, Canonicals und JSON-LD sind unzuverlässig. Sämtliche Head-Metadaten gehören in die erste HTML-Antwort.
Rendering-Strategien im Vergleich
| Strategie | Was der Crawler im rohen HTML erhält | SEO-Eignung |
|---|---|---|
| Client-seitiges Rendering (CSR) | Ein leeres div | Schlecht — für indexierbare Inhalte vermeiden |
| Server-seitiges Rendering (SSR) | Vollständiges HTML pro Anfrage | Ausgezeichnet |
| Statische Generierung (SSG) | Vorgebautes vollständiges HTML | Ausgezeichnet — die schnellste Option |
| Inkrementelle statische Regeneration | Vollständiges HTML, periodisch neu gebaut | Ausgezeichnet für große Kataloge |
| Islands / partielle Hydration | Vollständiges HTML plus kleine JS-Inseln | Ausgezeichnet |
| Dynamic Rendering | Abweichendes HTML für Bots | Überholter Notbehelf |
Rendering in einer Viertelstunde auditieren
- Seitenquelltext anzeigen, nicht Element untersuchen. Suchen Sie einen markanten Satz Ihres Hauptinhalts.
- Seite per curl abrufen — die Rohantwort ist die Wahrheit für nicht rendernde Crawler.
- JavaScript in den DevTools deaktivieren und neu laden.
- Live-Test der URL-Prüfung in der Search Console ausführen.
- Wortzahlen vergleichen zwischen rohem HTML und gerendertem DOM.
- Anker mit href zählen im rohen HTML.
- Head-Metadaten verifizieren im rohen HTML.
- Eine 404-Route testen und den echten Statuscode prüfen.
Das Problem mit KI-Crawlern
Die Crawler hinter KI-Assistenten sind meist einfache HTTP-Fetcher ohne Browser. Eine clientseitig gerenderte Website kann daher von Google passabel indexiert und für die KI-Suche praktisch unsichtbar sein. Wenn KI-Sichtbarkeit zählt, ist serverseitiges Rendering keine Performance-Vorliebe mehr, sondern Zugangsvoraussetzung. Mehr dazu in KI und die Auswertung von Audit-Ergebnissen.
Framework-Hinweise
- React und Next.js: Serverkomponenten rendern serverseitig, aber Client-Komponenten mit eigenem Datenabruf holen das Problem zurück. Pro Route auditieren.
- Vue und Nuxt: Universal-Modus ja, SPA-Modus nein — prüfen, was der Produktionsbuild tatsächlich nutzt.
- Angular: ohne Angular Universal ist die Rohantwort faktisch leer.
- Astro und Islands: statisches HTML als Standard — die sicherste Wahl für Content-Websites.
- Headless-Commerce: die häufigste Quelle gravierender Probleme.
Rendering kostet auch Performance
Große Bundles verzögern LCP, weil der Hauptinhalt erst nach der Skriptausführung erscheinen kann, und Hydration im Main Thread treibt INP auf Mobilgeräten. Weniger JavaScript behebt beides gleichzeitig — siehe die technische SEO-Checkliste.
Die 12-Punkte-Checkliste
- Hauptinhalt erscheint im Quelltext, nicht nur im gerenderten DOM.
- Titel, Canonical, Meta-Robots und hreflang stehen im ersten HTML.
- JSON-LD wird serverseitig gerendert.
- Interne Navigation nutzt Anker mit echten href-Attributen.
- Kein indexierbarer Inhalt hinter Klick, Scroll oder Cookie-Wand.
- JavaScript und CSS sind nicht per robots.txt blockiert.
- Fehlende Seiten liefern echten 404- oder 410-Status.
- Paginierung nutzt crawlbare Links.
- Gerendertes Ergebnis ist für Bots und Nutzer identisch.
- Die URL-Prüfung zeigt den erwarteten gerenderten Inhalt.
- Rohes HTML genügt nicht rendernden KI-Crawlern.
- Bundle-Größe wird überwacht.
Symptom, Ursache, Lösung
Die meisten JavaScript-SEO-Untersuchungen enden bei einer von sechs Diagnosen. Diese Tabelle verkürzt den Weg von der Beobachtung zur Reparatur.
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| Seiten indexiert, aber fast leer | Rendering-Timeout oder Skriptfehler | Hauptinhalt serverseitig rendern, Bundle verkleinern |
| Neue Seiten erscheinen erst nach Wochen | Verzögerung in der Render-Queue | Inhalt ins erste HTML legen, per Sitemap einreichen |
| Tiefe Seiten werden nie entdeckt | Navigation über Klick-Handler | Echte Anker mit href verwenden |
| Falscher Titel in den Suchergebnissen | Titel wird clientseitig überschrieben | Titel serverseitig rendern |
| Rich Results verschwunden | JSON-LD wird nachträglich injiziert | Strukturierte Daten im HTML ausliefern |
| Leere Seiten für gelöschte Produkte indexiert | Soft 404 mit Status 200 | Echten 404 oder 410 zurückgeben |
Rendering dauerhaft überwachen
Rendering-Regressionen sind im Code-Review unsichtbar. Ein Refactoring, das den Datenabruf vom Server in den Client verschiebt, sieht in jedem Browser korrekt aus und leert still das rohe HTML. Fangen Sie das in der Pipeline ab, nicht sechs Wochen später in der Search Console.
- Rohes HTML in der CI prüfen. Die gebaute Seite ohne Skriptausführung abrufen und sicherstellen, dass Titel, H1, Canonical und ein bekannter Inhaltsstring vorhanden sind. Wenige Zeilen Code fangen die Mehrheit der Regressionen.
- HTML-Antwortgröße je Template verfolgen. Ein plötzlicher Sturz von 60 kB auf 4 kB ist eine unangekündigte Rendering-Änderung.
- Bundle-Größe überwachen mit einem Budget, das den Build scheitern lässt.
- Abdeckungsbericht beobachten — Wachstum bei "Gecrawlt, zurzeit nicht indexiert" ist oft das erste äußere Symptom.
- Nach jedem Framework-Upgrade erneut prüfen. Rendering-Standards ändern sich zwischen Hauptversionen häufiger, als Release Notes vermuten lassen.
Cookie-Banner, Consent und Geo-Redirects
Drei Interaktionsmuster blockieren Crawler so wirksam wie jeder Rendering-Bug — und alle drei werden meist außerhalb der SEO-Diskussion umgesetzt.
Consent-Layer, die Inhalte verbergen, bis eine Wahl getroffen wurde, führen dazu, dass der Crawler nur das Banner sieht. Inhalte gehören unabhängig vom Consent-Status ins DOM; Einwilligung regelt Tracking und Personalisierung, nicht die Existenz des Artikeltexts.
Clientseitige Geo-Weiterleitungen schicken Besucher anhand von IP oder Browsersprache auf lokalisierte Versionen. Der Googlebot crawlt überwiegend aus wenigen Regionen — aggressive Weiterleitungen führen dazu, dass ganze Sprachversionen nie gecrawlt werden. Nutzen Sie hreflang plus Hinweisbanner.
Altersabfragen und Login-Wände verstecken alles hinter einer Interaktion, die der Renderer nicht ausführt. Soll der Inhalt ranken, muss ein relevanter Teil ohne Anmeldung sichtbar sein.
Wenn die Architektur kurzfristig nicht änderbar ist
- Nur die öffentlichen Seiten prerendern. Marketingseiten, Artikel und Produktseiten lassen sich statisch erzeugen, auch wenn der eingeloggte Bereich clientseitig bleibt.
- Head-Metadaten auf den Server verlagern. Titel, Description, Canonical und JSON-LD sind kleine Änderungen mit überproportionaler Wirkung.
- Den ersten Viewport serverseitig rendern und den Rest hydrieren. Das allein bringt den Hauptinhalt ins rohe HTML und verbessert zugleich LCP.
Ist keines davon kurzfristig möglich: Risiko dokumentieren und messen. Führen Sie eine Zahl darüber, wie viel Prozent Ihrer wichtigsten Seiten im rohen HTML leer sind. Diese Zahl lässt sich vorlegen, wenn die Architekturentscheidung das nächste Mal ansteht.
Was Sie laufend messen sollten
Drei Kennzahlen genügen, um das Rendering im Griff zu behalten: der Anteil wichtiger Seiten, deren Hauptinhalt im rohen HTML steht, die mediane Zeit von Veröffentlichung bis Indexierung, und die Zahl der Seiten unter "Gecrawlt, zurzeit nicht indexiert". Bewegt sich eine davon in die falsche Richtung, liegt es fast immer am Rendering oder an der Inhaltsqualität — und welche von beiden, verrät die erste Zahl.
Einwände aus dem Entwicklungsteam — und die Antworten
"Google führt JavaScript doch aus." Ja, aber in einer Warteschlange und mit Ressourcengrenzen. Die Frage ist nicht ob, sondern wann und wie verlässlich — und was jene Crawler tun, die gar keine Skripte ausführen.
"Serverseitiges Rendering verkompliziert die Architektur." Stimmt. Deshalb wird nach Seitentyp abgegrenzt: öffentliche Seiten auf dem Server, Anwendungsansichten im Client. Die gesamte App muss nicht umgebaut werden.
"Wir haben schon einen Prerender-Dienst für Bots." Das ist eine überholte und fragile Lösung: Sie muss gepflegt werden, kann unbemerkt ausfallen und liefert Bots und Nutzern unterschiedliches HTML. Bauen Sie nichts Neues darauf.
"Das schaffen wir in diesem Sprint nicht." Die schlankste Variante verlagert Head-Metadaten und den Hauptinhalt des ersten Viewports auf den Server. Das sind meist wenige Tage Arbeit und deckt den größten Teil des Risikos ab.
Am wirksamsten führt man dieses Gespräch, indem man zeigt statt behauptet: curl auf die wichtigste Seite absetzen und gemeinsam ansehen, was in der Antwort steht. Ein leeres div beendet die Diskussion schneller als jedes Argument.
Vor der Framework-Entscheidung
Wie viel JavaScript-SEO-Arbeit anfällt, entscheidet sich vor der ersten Codezeile. Stellen Sie bei der Technologiewahl drei Fragen: Werden öffentliche Seiten ohne Zusatzkonfiguration als vollständiges HTML ausgeliefert? Lassen sich Metadaten und strukturierte Daten je Route serverseitig setzen? Und gibt es einen dokumentierten Weg, echte Statuscodes für fehlende Seiten zurückzugeben?
Frameworks, die alle drei mit Ja beantworten, kosten keinen zusätzlichen SEO-Aufwand. Frameworks, die für jeden Punkt eine Erweiterung brauchen, kosten ihn in jedem Quartal aufs Neue.
Prüfen Sie Ihre Website in zwei Minuten
Öffnen Sie Ihre wichtigste Seite, zeigen Sie den Quelltext an und suchen Sie den ersten Satz Ihres Hauptinhalts. Fehlt er, sieht jeder nicht rendernde Crawler eine leere Seite.
Starten Sie ein kostenloses Audit mit WebSEO Auditor und sehen Sie, wie Ihre Seiten für Crawler aussehen, bevor JavaScript ausgeführt wird.