JavaScript-SEO: So wird eine JS-App indexiert

TL;DR: Google kann JavaScript indizieren, aber Client-Rendering bringt eine zusätzliche, verzögerte Phase zwischen Crawling und Indexierung. Platziere primäre Inhalte, routenspezifische Metadaten und crawlbare Links in servergerendertem oder statischem HTML. Verifiziere anschließend mit dem URL-Inspektionstool in der Google Search Console, was im gerenderten DOM ankommt, welche Ressourcen geladen wurden und ob JavaScript-Fehler vorliegen – statt dich darauf zu verlassen, was dein Browser anzeigt.

Wenn deine React-, Vue-, Angular- oder angeblich servergerenderte App in Google fehlt, hör auf zu fragen, ob Googlebot „JavaScript unterstützt“. Das tut er. Die relevante Frage ist, ob Google die benötigten Ressourcen abrufen, die Anwendung ausführen, ihre Links entdecken und ein indexierbares DOM erzeugen kann, bevor irgendwo etwas fehlschlägt.

Der Pipeline-Test, den deine JavaScript-App überstehen muss

Google Search Central beschreibt die Verarbeitung von JavaScript in drei klar getrennten Phasen:

„Google verarbeitet JavaScript-Web-Apps in drei Hauptphasen: 1. Crawling 2. Rendering 3. Indexing“

Zuerst fordert Googlebot die URL an und analysiert die Antwort. Wenn diese Antwort nahezu nur eine leere App-Shell ist, hat Google noch nicht dein Produkt- und Artikel-„Copy“, den Artikelbody, Überschriften, clientgenerierte Metadaten oder Routen-Links. Es hat eine URL, etwas HTML-Grundgerüst und Referenzen auf Ressourcen.

Google stellt anschließend berechtigte Seiten für das Rendering in eine Warteschlange. In der Doku heißt es dazu: „Die Seite kann in dieser Warteschlange für ein paar Sekunden bleiben, aber es kann länger dauern.“ Das ist das korrekte Modell. Vermeide die alte Behauptung, dass JavaScript immer eine Verzögerung von Tagen oder Wochen bei der Indexierung erzeugt; Google sagt das nicht. Es gibt zwar eine verzögerte Warteschlange, aber deine Seite muss trotzdem erfolgreich rendern, sobald sie vorne ankommt.

Diese Warteschlange ist die Phase, die Entwickler gedanklich gern ausblenden. In einem lokalen Browser wirkt die Anwendung vollständig, während die abgerufene Antwort möglicherweise kaum mehr als ein Root-Element und Bundle-Referenzen enthält (view-source hilft hier – auch wenn es nur die halbe Diagnose ist).

Beim Rendering führt Google die Seite in einem Headless Browser aus. Google bestätigt, dass „Google Search JavaScript mit einer Evergreen-Version von Chromium ausführt“. Moderne Framework-Syntax ist damit sehr wahrscheinlich nicht das Problem. Besserer Verdacht: blockierte Ressourcen, fehlgeschlagene API-Requests, Laufzeit-Ausnahmen, Inhalte, die von einer Interaktion abhängen, sowie schlechtes Link-Markup.

Nach dem Rendering kann Google das resultierende DOM untersuchen und URLs extrahieren, die durch JavaScript hinzugefügt wurden. Diese URLs gehen zurück in die Crawl-Warteschlange. Die Indexierung erfolgt später. Unsere Guides zu was Crawling im SEO bedeutet und wie Googles Indexierung funktioniert beschreiben die Grenzen zwischen diesen Phasen.

Eine clientgerenderte Kategorieseite kann für Google also als URL bekannt sein, während Produkte, Beschreibungen und ausgehende Links unbekannt bleiben. Discovery ist nicht Indexierung. Eine indexierte URL ist auch kein Beleg dafür, dass Google die vollständige Seite gesehen hat.

CSR funktioniert – ist aber ein fragiler Standard für Seiten, die ranken müssen

Addy Osmani und Jason Miller definieren Client-side Rendering auf web.dev als das Rendern einer Anwendung im Browser, bei dem JavaScript das DOM verändert. Server-side Rendering sendet vom Server erzeugtes HTML. Statisches Rendering erstellt dieses HTML zur Build-Zeit. Hydration ergänzt Anwendungsstatus und Event Handler zu HTML, das bereits existiert.

Das SEO-Problem mit CSR ist strukturell, nicht ideologisch. Dein wichtigster Content fehlt in der initialen Antwort und hängt davon ab, dass später noch ein anderes System mehr Arbeit erledigt. Das kann einwandfrei funktionieren. Trotzdem würde ich nicht jede öffentliche Route davon abhängig machen, wenn HTML eine ganze Fehlerklasse eliminiert.

„Allgemein gesagt ermutigen wir Entwickler, serverseitiges Rendering oder statisches Rendering statt eines vollständigen Rehydration-Ansatzes zu betrachten.“

Das ist die Empfehlung von Osmani und Miller – keine Anweisung, jede Anwendung in eine statische Site zu verwandeln. Ein privates Analytics-Dashboard hat andere Anforderungen als eine öffentliche Marketplace-Kategorie. Render das, was für Rankings gebraucht wird, auf dem Server oder zur Build-Zeit – und ergänze Client-Interaktivität dort, wo sie ihren Preis wert ist.

Frameworks bieten mehrere Wege zu dieser Architektur. Unser Guide zu SEO für Next.js, React und Nuxt deckt die framework-spezifischen Entscheidungen ab. Aber ein SSR-fähiges Framework garantiert nicht automatisch servergerenderten Output. Ich bin davon ausgegangen – bis ich feststellen musste, dass die nützlichen Daten erst nach dem Mount geladen wurden (das Framework-Logo hat mich nicht gerettet).

Dynamic Rendering nicht reaktivieren

Dynamic Rendering liefert Bots eine vorgerenderte Seite, während Nutzer die JavaScript-Anwendung erhalten. Google hatte es einst als Workaround dokumentiert, aber die aktuelle Empfehlung ist explizit:

„Dynamic Rendering war ein Workaround und keine langfristige Lösung für Probleme mit durch JavaScript generierten Inhalten in Suchmaschinen.“

Googles Dokumentation zu Dynamic Rendering empfiehlt stattdessen serverseitiges Rendering, statisches Rendering oder Hydration. Genau dort würde ich Engineering-Zeit investieren. Bot-Detection, separate Caches und zwei mögliche Darstellungen jeder Seite schaffen mehr Gelegenheiten, dass Content und Metadaten auseinanderdriften.

Wenn Dynamic Rendering bereits eine Legacy-Seite „hochhält“, baue es nicht einfach ohne Migrationsplan aus. Aber verwechsel keinen tolerierten Workaround mit einer tragfähigen neuen Architektur.

Die JavaScript-SEO-Fails, die ich zuerst prüfen würde

1. Primärer Content existiert erst nach der JavaScript-Ausführung

Abrufen der URL ohne JavaScript auszuführen. Wenn die Antwort eine App-Root, eine Lade-Meldung und ansonsten kaum etwas enthält, hängt jedes relevante Element von Googles Rendering-Phase ab. Verschiebe den Haupttext der Seite, Überschriften, Produktdatensätze, Artikelbody und die essenzielle Navigation in den SSR- oder SSG-Output.

Du musst JavaScript nicht entfernen. Du brauchst eine sinnvolle HTML-Basis. Behält Filter, Rechner, Account-Status und interaktive Controls im Client, wo es passend ist. Der schärfere Test lautet: Wenn das Hauptbundle fehlschlägt, erklärt die Antwort dann immer noch, was diese URL enthält?

Teste repräsentative Templates, nicht nur eine „praktische“ URL. Eine Startseite kann statisch sein, während Kategorieseiten erst nach dem Mount komplett nachladen. Produktseiten können SSR nutzen, während gefilterte Routen das generische Shell zurückgeben. Eine erfolgreich durchgeführte Prüfung auf einer Seite beweist weniger, als die meisten Teams glauben möchten.

Ich behebe das, bevor ich Metadaten poliere. Ein servergerenderter Titel kann keinen leeren Artikelbody ausgleichen. Umgekehrt ist ein vollständiger Artikel trotzdem im Trouble, wenn Google einen permanenten Ladezustand bekommt. Erst Architektur.

2. Deine „Links“ sind eigentlich Event Handler

Das ist eines der häufigsten Probleme, die wir bei Sites sehen, die mit SEOJuice verbunden sind. Eine Karte oder ein Menüpunkt ruft eine Router-Methode auf, aber im Markup gibt es keinen echten Anchor oder ein Ziel. Es verhält sich wie Navigation für eine Person. Es ist kein crawlbarer Link.

„Google kann Ihre Links nur entdecken, wenn sie <a>-HTML-Elemente mit einem href-Attribut sind.“

Diese Formulierung kommt direkt aus Google Search Central. Navigierbare Ziele sollten echte Anchors mit einem href verwenden. Dein Router kann den Klick weiterhin abfangen und clientseitige Navigation ausführen; Progressive Enhancement und SPA-Verhalten sind kompatibel.

Der Schaden verstärkt sich. Wenn eine Liste 100 klickbare Karten als Buttons oder div-Elemente anzeigt, fehlen diese 100 Ziele im Link-Discovery-Mechanismus, den Google dokumentiert (ein Sitemap kann die URLs offenlegen, aber sie repariert nicht die internen-Link-Beziehungen).

Prüfe Menüs, Karten, Pagination, Breadcrumbs, Module mit „related content“, Filter mit stabilen Zielen sowie die Logo-Navigation. Wenn ganze Routengruppen in Google fehlen, auditier Links von bereits bekannten Seiten, bevor du Indexierungsprobleme als Ursache behauptest. Unser SPA-SEO-Best-Practices-Guide geht tiefer in Route Discovery und clientseitige Navigation.

3. robots.txt blockiert JavaScript, CSS oder API-Ressourcen

Google sagt, dass Search kein JavaScript aus blockierten Dateien oder auf blockierten Seiten rendert. Prüfe daher breit angelegte robots.txt-Regeln für Asset-Pfade wie /static/, /_next/, Build-Verzeichnisse und proxied API-Endpunkte, die benötigt werden, um öffentlich sichtbaren Content zu konstruieren.

Untersuche die deployed Asset-URLs, statt der Repository-Konfiguration zu vertrauen. Eine CDN-Regel, ein robots-Datei-File je Environment, eine Authentifizierungsprüfung oder ein veralteter Deployment-Pfad kann dazu führen, dass Produktion sich anders verhält als die lokale Entwicklung (Produktion bleibt dabei erschreckend erfinderisch).

Bestätige außerdem, dass Ressourcen Googlebot sinnvolle Antworten liefern. Ein Bundle, das 403 zurückgibt, ein API-Call, der ohne Session-Cookie fehlschlägt, oder eine abgelaufene Chunk-URL kann den Crawler mit einer leeren Shell zurücklassen – obwohl robots.txt sauber aussieht.

4. Wichtiger Content erfordert Interaktion

Content, der erst nach dem Auswählen eines Tabs, nach dem Klicken auf „Mehr laden“, nach einer scrollabhängigen Anfrage oder nach dem Erteilen einer Berechtigung abgerufen wird, erscheint möglicherweise nicht im DOM, das Google indexiert. Googles Troubleshooting-Doku sagt Entwicklern: „Erwarten Sie, dass Googlebot Anfragen nach Nutzerberechtigungen ablehnt.“

Indexierbarer Content muss ohne Nutzerreise verfügbar sein. Paginierter Content sollte stabile URLs und crawlbare Links haben. Wenn ein Tab eigenständige Informationen enthält, die sich fürs Indexieren lohnen, integriere sie in das initiale HTML oder gib ihnen ein crawlbares Ziel. Ein Crawler sollte nicht erst Product Usage simulieren müssen, um deinen primären Content zu erhalten.

5. Der Router zeigt eine 404, während der Server 200 zurückgibt

Eine SPA kann für eine ungültige Route eine polierte „Not found“-Komponente anzeigen, während der Server 200 OK meldet. Google behandelt das als Soft-404-Muster. Die dokumentierten Fixes: Umleitung auf eine URL, bei der der Server eine echte 404 liefert – oder das robots-meta-tag umstellen bzw. ergänzen auf noindex.

Ich bevorzuge den korrekten Server-Status, sofern der Stack das erlaubt. Statuscodes kommunizieren, was passiert ist, bevor die Anwendung startet. Außerdem lassen sie sich deutlich einfacher überwachen als Router-States.

Prüfe fehlerhafte Produkt-URLs, gelöschte Datensätze, ungültige Pagination, kaputte Locale-Routen und Catch-all-Pfade. Diese Edge Cases erben oft dieselbe App-Shell wie gültige Seiten und erzeugen dann stillschweigend Tausende „erfolgreich aussehende“ Error-URLs.

6. Hydration beschädigt valides serverseitiges HTML

SSR kann vollständiges HTML zurückgeben und trotzdem nach dem Laden scheitern. web.dev weist darauf hin, dass servergerenderte Controls erst reagieren können, wenn clientseitige Skripte ausgeführt wurden und Event Handler angebunden haben. Eine Hydration-Ausnahme kann Nutzer mit toten Controls zurücklassen; ein Mismatch kann Content ersetzen oder entfernen, der in der Antwort existierte.

Vergleiche drei Zustände: Raw HTML, das Browser-DOM nach der Hydration und das gerenderte DOM von Google. Wenn die Raw-Antwort korrekt ist, aber das gerenderte DOM Content verliert, hat SSR das Problem nicht vollständig gelöst – es hat nur die Fehlerstelle verschoben.

7. Titles, Canonicals und Beschreibungen kommen zu spät

Google bestätigt, dass JavaScript den Titel und die Meta Description setzen oder ändern kann. Trotzdem gehören routenspezifische Metadaten in der Praxis eher in den Server- oder statischen Response. Wenn das Rendering fehlschlägt, kann Google stattdessen den generischen Application-Titel sehen, nicht die seiten-spezifische Version.

Behandle Canonical-Tags und robots directives mit derselben Disziplin. Änderungen auf Client-Seite können verarbeitet werden – aber kritische Indexierungssignale davon abhängig zu machen, dass beim Ausführen alles klappt, bringt wenig und schafft eine weitere Stelle, an der Routing-Bugs über Templates hinweg auslaufen können.

So siehst du, was Google wirklich gerendert hat

Das URL-Inspektionstool in der Google Search Console ist der entscheidende Check. Dein Browser, ein lokaler Crawler oder Lighthouse können Defekte aufdecken – aber keiner bildet das ab, was Googlebot als Ergebnis protokolliert.

1. Prüfe die exakte kanonische URL. Teste nicht nur die Startseite, wenn die fehlenden Seiten ein anderes Template oder einen anderen Data-Fetching-Pfad nutzen.
2. Öffne „View Crawled Page“. Wenn eine Seite noch nicht indexiert ist, verwende „Test Live URL“ und inspiziere das getestete Ergebnis.
3. Liess das gerenderte HTML. Suche nach einem eindeutigen Satz aus dem primären Content, dem routenspezifischen Titel, der kanonischen URL und Links zu tieferen Seiten.
4. Prüfe den Screenshot. Leere Roots, Ladezustände, Consent-Overlays und fehlende Sektionen machen ein fehlgeschlagenes Rendering oft schnell sichtbar.
5. Überprüfe Konsolenmeldungen und Seitenressourcen. Achte auf Exceptions, blockierte Bundles, fehlgeschlagene API-Calls und Fehler beim Laden von Chunks.
6. Vergleiche das mit der Raw Response. Rufe die URL mit einem HTTP-Client aus der Kommandozeile ab. Der Unterschied zwischen Response-HTML und Googles gerendertem HTML ist die JavaScript-Abhängigkeit, die du bewerten musst.

Googles Leitfaden zur JavaScript-Troubleshooting sagt, dass diese Tools geladene Ressourcen, JavaScript-Console-Ausgaben und Exceptions, das gerenderte DOM sowie weitere Diagnoseinformationen sichtbar machen. Wenn ein wichtiger Absatz oder Link in diesem DOM fehlt, ist Warten auf Rankings keine Teststrategie. Repariere den Rendering-Pfad.

Bei SEOJuice sind wir ein Zwei-Personen-Team: Lida und ich. Direkte Inspektion ist entscheidend, weil wir es uns nicht leisten können, jedes Indexierungsproblem in eine Woche spekulatives Debugging zu verwandeln. Raw HTML, gerendertes HTML, Ressourcen, Console. Vier Checks verengen das Problem schnell.

Den Unterschied haben wir während unserer Migration von seojuice.io zu seojuice.com im Januar 2026 sehr klar gesehen. Die Seiten sahen in einem normalen Browser korrekt aus, und Live-Tests konnten durchgehen – während Googles aufgezeichnete Crawls für einige Routen noch nicht nachgezogen hatten. Ein erfolgreicher Live-Test beweist, dass Google die Seite zur Testzeit rendern kann; er schreibt aber keine historischen Crawls um und garantiert keine Indexierung (ich würde diese Schaltfläche auch nehmen).

Ein praxisnaher Release-Gate für indexierbare JavaScript-Seiten

Behandle JavaScript-SEO nicht als Aufräumaufgabe nach dem Launch. Baue für jede öffentliche Vorlage ein kleines Release-Gate ein:

• Die URL liefert den beabsichtigten Statuscode, ohne sich auf clientseitiges Routing zu verlassen.
• Das Raw HTML enthält die wichtigste Überschrift, den primären Text und routenspezifische Metadaten.
• Navigation verwendet Anchor-Elemente mit href-Attributen.
• JavaScript, CSS und benötigte öffentliche Datenressourcen sind crawlbar.
• Die Seite bleibt nützlich, selbst wenn Hydration fehlschlägt.
• Das gerenderte DOM enthält denselben primären Content und dieselben Indexierungssignale wie die Response.
• Ungültige und gelöschte Routen liefern eine echte Error-Response oder eine bewusste noindex-Anweisung.

Das ist kein Antrag auf pixelidentisches HTML. Interaktiver State darf sich unterscheiden. Die Anforderung ist: Bedeutung der Seite, auffindbare Ziele und Indexierungsanweisungen müssen jede Phase in Googles Pipeline überstehen.

Wo SEOJuice passt – und wo nicht

SEOJuice arbeitet auf einer Live-Site über ein JavaScript-Snippet oder ein CMS-Plugin. Es übernimmt kontinuierlich On-Page-Arbeiten wie interne Links, Meta Titles und Descriptions, Schema-Markup sowie Image-Alt-Text. Der Audit kann auch fehlende Metadaten, dünnen oder fehlenden gerenderten Content, blockierte Ressourcen, nicht crawlbare Link-Muster und Lücken bei der Indexierung aufdecken.

SEOJuice macht aus einer CSR-Anwendung nicht automatisch SSR. Da das Snippet clientseitig läuft, teilt sein Output die oben beschriebene Rendering-Abhängigkeit. Wenn primärer Content im HTML fehlt, behebe zuerst die Rendering-Architektur; Automatisierung sollte darauf aufbauen, dass Google eine Seite zuverlässig verarbeiten kann.

Wenn die Anwendung korrekt rendert und du die verbleibenden On-Page- und Indexierungsfehler identifizieren willst, führe den kostenlosen SEO-Audit aus. Ein kostenloser Plan ist ohne Kreditkarte verfügbar.

Häufig gestellte Fragen

Kann Google JavaScript indexieren?

Ja. Google Search führt JavaScript mit einer Evergreen-Version von Chromium aus. JavaScript-Seiten durchlaufen weiterhin eine verzögerte Rendering-Phase; Content kann also verzögert werden oder komplett fehlen, wenn Ressourcen blockiert sind, die Ausführung fehlschlägt oder wichtige Informationen Interaktion mit Nutzer erfordern.

Warum fehlt meine React-, Vue- oder Angular-App in Google?

Die wahrscheinlichste Ursache ist nicht das Framework selbst. Prüfe, ob essenzieller Content und Links erst nach clientseitiger Ausführung vorhanden sind, ob Bundles oder APIs für Googlebot nicht verfügbar sind und ob Laufzeitfehler das Rendering verhindern. Schau außerdem nach Soft-404s, generischen clientgesteuerten Metadaten und Navigation ohne echte Anchors.

Was ist der Unterschied zwischen SSR, SSG und CSR in Bezug auf SEO?

SSG generiert HTML zur Build-Zeit. SSR generiert HTML auf dem Server für jeden Request. Beide stellen primären Content in der Response bereit. CSR baut die Seite im Browser auf und macht diesen Content damit abhängig von Googles späterer Rendering-Phase. Für öffentliche Seiten, die ranken sollen, ist SSG oder SSR in der Regel der sicherere Standard.

Empfiehlt Google Dynamic Rendering noch?

Nein. Google nennt Dynamic Rendering einen Workaround statt einer langfristigen Lösung. Die aktuelle Guidance richtet sich an Entwickler mit Blick auf serverseitiges Rendering, statisches Rendering oder Hydration. Starte keine neue Implementierung, die separate Ausgabeformate für Bots und Nutzer voraussetzt.

Zählen JavaScript-Buttons und onClick-Navigation als Links?

Nicht als crawlbare Links. Google dokumentiert Link-Discovery über Anchor-Elemente mit href-Attributen. Nutze semantische Anchors für navigierbare Ziele – auch wenn ein clientseitiger Router den Klick abfängt, um einen Full-Page-Reload zu vermeiden.

Wie kann ich sehen, was die Seite Googlebot gerendert hat?

Prüfe die exakte URL in der Google Search Console, öffne die gecrawlte oder live getestete Seite und sieh dir deren gerendertes HTML an – inklusive Screenshot, geladenen Ressourcen und JavaScript-Console-Meldungen. Suche im HTML nach primärem Content und internen Links. Wenn sie dort fehlen, hat Google in diesem Test nicht die vollständige Seite erhalten.