JavaScript SEO bezeichnet die Gesamtheit der technischen Arbeit, die dafür sorgt, dass Websites, die ihre Inhalte im Browser per JavaScript aufbauen, von Google vollständig gecrawlt, gerendert und indexiert werden können. Eine moderne, mit React, Vue, Angular oder Next.js entwickelte Website bietet Nutzern ein app-artiges, flüssiges Erlebnis; genau dieselbe Architektur legt aber eine unsichtbare Schicht zwischen die Website und die Suchmaschine. Eine Seite, die auf dem Bildschirm des Nutzers vollständig gefüllt erscheint, kann für Google beim ersten Zugriff nur ein leeres HTML-Gerüst sein.
Warum sollte Sie das kümmern? Weil Google beim Ranking auf den Inhalt zugreift, den es tatsächlich sieht. Eine nicht gerenderte Produktbeschreibung, eine spät geladene Kategorieliste oder eine in JavaScript eingebettete Überschrift existiert für Sie, aber nicht für den Index. Das Problem ist zudem tückisch: Weil die Website im Browser einwandfrei funktioniert, geht das Team davon aus, dass alles in Ordnung ist; das Symptom fällt meist erst Monate später auf, wenn der organische Traffic unter den Erwartungen bleibt. 2026 hat sich das Bild noch verschärft: AI Overviews hat sich verbreitet, und KI-gestützte Suchwerkzeuge erzeugen ihre Antworten aus crawlbarem Content, ein erheblicher Teil dieser Bots führt aber gar kein JavaScript aus. Kommt Ihr Inhalt nicht vom Server, sind Sie nicht nur in den klassischen Suchergebnissen, sondern auch in KI-Zusammenfassungen unsichtbar.
Wir haben diesen Beitrag als Leitfaden zur Fehlerbehebung aufgebaut: Zunächst schauen wir uns an, wie Google JavaScript tatsächlich verarbeitet, dann die Risikoprofile der Architekturen CSR, SSR und SSG; anschließend gehen wir vom Symptom zur Diagnose über und behandeln die häufigsten Fehler auf React- und Next.js-Websites samt Lösungen.
Wie Google JavaScript verarbeitet: Crawling, Rendering, Indexierung
Bei einer klassischen HTML-Seite ist der Ablauf einfach: Der Googlebot lädt die Seite herunter, liest den Text, extrahiert Links, indexiert sie. Bei JavaScript-lastigen Seiten kommt ein zusätzlicher Schritt hinzu: das Rendering. Der in der Dokumentation von Google Search Central beschriebene Ablauf besteht aus drei Schritten. Der Googlebot crawlt zunächst die URL und erhält das erste, vom Server zurückgegebene HTML. Fehlt der Inhalt in diesem HTML, wandert die Seite in eine Rendering-Warteschlange; Googles Rendering-Infrastruktur, der Web Rendering Service (WRS), der seit 2019 auf einer aktuellen Chromium-Version läuft, öffnet die Seite wie ein echter Browser, führt das JavaScript aus und übergibt das entstandene DOM an das Indexierungssystem.
Auf dem Papier liest sich das wie: 'Google führt JavaScript ja ohnehin aus, also gibt es kein Problem.' In der Praxis gibt es drei Risiken. Erstens das Timing: Rendering läuft nicht zeitgleich mit dem Crawling ab, sondern wird in eine Warteschlange eingereiht. Google gibt an, dass die meisten Seiten innerhalb von Minuten gerendert werden; das ist aber ein Durchschnittswert, keine Garantie, und in stark ausgelasteten Phasen oder bei großen Websites kann sich die Verzögerung ausdehnen. Zweitens die Kosten: JavaScript auszuführen erfordert ein Vielfaches der Rechenleistung, die das reine Lesen von HTML benötigt. Google stellt keiner Website unbegrenzte Ressourcen zur Verfügung; bei einer Website mit Zehntausenden URLs kann das bedeuten, dass manche Seiten spät gerendert werden oder gar keine Crawling-Priorität erhalten. Drittens die Anfälligkeit: Tritt beim Rendering ein JavaScript-Fehler auf, läuft eine kritische API-Anfrage in ein Timeout, oder wird eine benötigte Ressource blockiert, indexiert Google die unvollständige Version der Seite, ohne Sie separat darüber zu informieren.
Zudem gibt es eine häufig übersehene, aktuelle Tatsache: Obwohl Google rendern kann, begnügt sich der Großteil der antwortgenerierenden KI-Crawler mit dem ersten HTML. Eine Website, die keinen Inhalt vom Server sendet, ist in den Augen dieser Systeme weitgehend leer. In einer Zeit, in der sich das Suchverhalten stark in Richtung KI-Werkzeuge verschiebt, ist das ein Sichtbarkeitsverlust, den man nicht ignorieren kann; die strategische Dimension dieses Themas behandeln wir ausführlich in unserem Beitrag zu SEO in der KI-Suche. Aus diesem Bild ergibt sich das Grundprinzip von selbst: Inhalte, die Sie indexiert sehen möchten, dürfen nicht dem Zufall des JavaScript überlassen bleiben, sie müssen bereits im ersten HTML vorhanden sein.
CSR, SSR, SSG: derselbe Inhalt, drei unterschiedliche Auslieferungsarten
Fast jedem JavaScript-SEO-Problem liegt dieselbe Frage zugrunde: Wo wird das HTML eigentlich erzeugt? Die Antwort ist eine von drei Hauptarchitekturen, und jede hat ein anderes Risikoprofil.
Client-seitiges Rendering (CSR)
Das Standardverhalten reiner React- oder Vue-Anwendungen. Der Server sendet eine nahezu leere HTML-Hülle zusammen mit einem großen JavaScript-Paket; der Inhalt entsteht erst, nachdem Code im Browser ausgeführt wurde, meist nachdem Daten von einer API abgerufen wurden. Für den Nutzer ist das kein Problem, für die Suchmaschine aber das riskanteste Szenario: Im ersten HTML fehlen Überschrift, Text und Link gleichermaßen. Die Indexierung hängt vollständig davon ab, dass der Rendering-Schritt reibungslos abläuft; für Bots, die kein JavaScript ausführen, existiert die Seite faktisch nicht.
Serverseitiges Rendering (SSR)
Das HTML wird bei jeder Anfrage auf dem Server erzeugt; sowohl Browser als auch Bot erhalten eine bereits inhaltlich gefüllte Seite. Das ist das zentrale Versprechen von Frameworks wie Next.js und Nuxt und aus SEO-Sicht der sicherste Ansatz: Der Inhalt liegt im ersten HTML bereit, ohne auf Googles Rendering-Schritt warten zu müssen. Der Preis dafür ist die bei jeder Anfrage anfallende Serverlast und eine sich verlängernde Antwortzeit, wenn die Konfiguration nicht stimmt. Wichtig ist auch zu wissen, dass SSR die Arbeit nicht vollständig erledigt: Die Seite wird im Browser durch einen Prozess namens 'Hydration' interaktiv gemacht, und schwere JavaScript-Pakete drücken in genau dieser Phase die Nutzererlebnis-Metriken nach unten.
Statische Generierung (SSG) und inkrementelle Regenerierung (ISR)
Seiten werden beim Build-Vorgang als HTML erzeugt und über ein CDN ausgeliefert. Für Blogs, Dokumentationen, Unternehmensseiten und selten geänderte Landingpages ist das sowohl die schnellste als auch die sicherste Option; es bleibt nichts mehr zu rendern übrig, die Serverkosten liegen nahe null. Bei großen Websites mit häufig wechselnden Inhalten löst Next.js' ISR-Ansatz (Incremental Static Regeneration) den Konflikt zwischen Aktualität und Geschwindigkeit, indem statische Seiten in festgelegten Abständen im Hintergrund aktualisiert werden.
Die praktische Regel lautet: Jede Seite, auf der Sie organischen Traffic erwarten, Startseite, Kategorie, Produkt, Blog, sollte mit SSR oder SSG ausgeliefert werden. Bei Bereichen, die nicht indexiert werden müssen, wie einem login-geschützten Dashboard, dem Warenkorb oder Kontoseiten, ist CSR völlig legitim. Das Problem liegt nicht in den Architekturen selbst, sondern darin, eine einzige Architektur unterschiedslos überall einzusetzen. Am Rande sei erwähnt, dass Google den über Jahre als Notlösung genannten Ansatz des 'dynamic rendering' (Bots und Nutzern jeweils eine separate Version ausliefern) inzwischen nicht mehr als langfristige Lösung empfiehlt; die aktuelle Empfehlung lautet serverseitiges Rendering oder statische Generierung.
Vom Symptom zur Diagnose: Welches Problem haben Sie?
Fehlerbehebung beginnt damit, das Symptom richtig zu lesen. Nutzen Sie die folgende Liste als Zuordnungstabelle:
- Werden bei einer site:-Suche alle Seiten mit demselben Titel gelistet, werden Ihre Meta-Tags höchstwahrscheinlich nur clientseitig geschrieben.
- Ist die Startseite indexiert, Kategorie- und Detailseiten aber nicht, erzeugen Ihre internen Links möglicherweise kein echtes href; Google kann die Seiten nicht entdecken.
- Häuft sich in der Search Console die Zeile 'Gecrawlt, aber momentan nicht indexiert', wird der Inhalt nach dem Rendering als zu schwach eingestuft, oder die Rendering-Kosten übersteigen den wahrgenommenen Wert der Seite.
- Ist eine Seite indexiert, zeigt das Snippet aber fehlenden oder unpassenden Text, wird ein Teil des Inhalts nicht gerendert.
- Tauchen Ihre Bilder nie in der Google Bildersuche auf, arbeitet Ihr Lazy Loading mit einer Methode, die der Bot nicht durchschauen kann.
- Werden nicht existierende URLs in der Search Console als 'Soft 404' markiert, liefert Ihre Anwendung für jede Adresse den Statuscode 200 zurück.
Jedes dieser Symptome verweist auf einen der folgenden sieben Fehler.
Sieben häufige Fehler auf React- und Next.js-Websites und ihre Lösungen
1. Inhalt entsteht nur clientseitig
Der häufigste und teuerste Fehler. Daten werden in useEffect abgerufen, eine Komponente wird per dynamischem Import mit ssr: false geladen, oder der Inhalt hängt von einem clientseitigen Zustand ab; im Ergebnis fehlt der Haupttext im ersten HTML. Als Beispielszenario: Eine E-Commerce-Website mit 5.000 Produkten ruft Produktbeschreibungen clientseitig über eine API ab. Bei jedem Rendering-Versuch, bei dem die API langsam antwortet oder einen Fehler liefert, sieht Google diese Produktseite als leer; innerhalb weniger Monate kann sich so eine Lücke von mehreren Tausend Seiten zwischen indexierten und tatsächlich vorhandenen Seiten auftun. Die Lösung: Im Next.js App Router werden Komponenten standardmäßig serverseitig gerendert, verlagern Sie den Datenabruf in Server-Komponenten. 'use client' und ssr: false sollten nur für tatsächlich interaktive Teile reserviert werden, die nicht indexiert werden müssen. Einfacher Test: Beim Anzeigen des Seitenquelltexts sollten Sie den Haupttext lesen können.
2. Links, die kein href erzeugen
Der Googlebot folgt ausschließlich Link-Elementen mit einem href-Attribut. Ein an einem div hängendes onClick, das router.push aufruft, ist für den Nutzer ein Link, für den Bot aber eine Sackgasse; Google klickt keine Buttons an und füllt keine Formulare aus. Ebenso erzeugt hash-basiertes Routing (Adressen wie site.com/#/produkte) für Google keine eigene Seite; alles nach dem Rautezeichen wird bei der Indexierung ignoriert. Die Lösung: Die Link-Komponente von Next.js erzeugt von Haus aus ein href, nutzen Sie sie; auch wenn Sie ein spezielles Klickverhalten benötigen, muss stets ein gültiges href vorhanden sein, und Weiterleitungslogik sollte über die History API mit echten URLs funktionieren.
3. Meta-Tags und Canonical werden clientseitig geschrieben
Werden Titel, Beschreibung, Canonical und Robots-Anweisungen nur im Browser über Tools wie react-helmet eingefügt, sieht Google sie erst nach dem Rendering; Bots, die kein JavaScript ausführen, sehen sie überhaupt nicht. Es gibt hier eine noch entscheidendere Feinheit: Laut Googles Dokumentation gelangt eine Seite mit noindex im ersten HTML gar nicht erst in die Rendering-Warteschlange. Der Ansatz 'wir entfernen noindex per JavaScript' funktioniert also nicht; die Seite wird bereits aussortiert, bevor JavaScript überhaupt läuft. Die Lösung: Senden Sie alle Meta-Tags vom Server, in Next.js löst die Metadata API das seitenweise, serverseitig.
4. robots.txt blockiert JavaScript- und CSS-Dateien
Eine Gewohnheit aus einer älteren Website-Generation richtet bei modernen Websites schweren Schaden an: Werden Verzeichnisse wie /assets, /static oder /_next per robots.txt blockiert, kann der WRS die Seite nicht rendern und sieht den Inhalt unvollständig oder defekt. Die Warnung von Google Search Central ist eindeutig: Für das Rendering benötigte Ressourcen müssen crawlbar sein. Eine weitere Feinheit: Der WRS cacht JavaScript-Dateien aggressiv; ein Content-Hash in Dateinamen ist der zuverlässigste Weg, damit Versionsänderungen erkannt werden, moderne Build-Tools erledigen das bereits standardmäßig. Die Lösung: Entfernen Sie JS-/CSS-Blockaden aus der robots.txt und prüfen Sie mit dem URL-Prüftool der Search Console, ob noch blockierte Ressourcen übrig sind.
5. Soft 404: Eine nicht existierende Seite liefert 200
Bei CSR-Anwendungen liefert der Server für jede URL dieselbe App-Hülle mit dem Statuscode 200 zurück; die Meldung 'Produkt nicht gefunden' entsteht clientseitig. Google markiert diese Seiten, die trotz Statuscode 200 Fehlerinhalt zeigen, als Soft 404. Wächst die Zahl, wird Crawling-Budget an Seiten verschwendet, die keinen Wert haben, und das Qualitätsempfinden der gesamten Website leidet. Die Lösung: Lösen Sie Fehlerzustände serverseitig auf. In Next.js liefert ein Aufruf von notFound() einen echten 404-Status; nutzen Sie 410 für dauerhaft entfernte Inhalte und 301 für umgezogene Inhalte.
6. Inhalt, der erst nach Interaktion sichtbar wird
Der Googlebot klickt nicht, scrollt nicht, füllt keine Formulare aus; er rendert die Seite mit einem langen Viewport und sieht, was in diesem Moment im DOM steht. Produkte, die über einen 'Mehr laden'-Button erscheinen, Tab-Inhalte, die erst durch Klick ins DOM gelangen, und über endloses Scrollen nachgeladene Listen sind für den Bot nicht erreichbarer Inhalt. Die Lösung: Unterstützen Sie endloses Scrollen mit paginierten URLs; jeder Abschnitt sollte eine eigene Adresse sowie Vor-/Zurück-Links haben. Tab- und Akkordeon-Inhalte können Sie von Beginn an ins DOM einfügen und per CSS visuell verbergen: Im gerenderten DOM vorhandener Inhalt wird auch dann indexiert, wenn er visuell versteckt ist.
7. Hydration-Last lässt die Core Web Vitals einbrechen
Der Umstieg auf SSR löst das Rendering-Problem, aber nicht das Problem, Megabytes an JavaScript zu senden. Aufgeblähte Pakete verzögern den LCP, lange Aufgaben während der Hydration stören den INP; und die Core Web Vitals sind sowohl Googles Signal für Seitenerlebnis als auch ein direkter Faktor für die Conversion-Rate. Eine grobe Rechnung: Geht man bei einer 4G-Verbindung von etwa 1,5 MB Download pro Sekunde aus, benötigt allein ein 900 KB großes JavaScript-Paket über eine halbe Sekunde nur für die Übertragung; rechnet man Parsing- und Ausführungszeit hinzu, kann die Interaktionsverzögerung auf einem Mittelklasse-Smartphone leicht 1 bis 2 Sekunden erreichen. Die Lösung: Code-Splitting, Entfernen ungenutzter Abhängigkeiten und Belassen nicht interaktionsbedürftiger Komponenten als Server-Komponenten. Mess- und Verbesserungsschritte finden Sie in unserem Core-Web-Vitals-Leitfaden.
Diagnose in fünf Schritten: Betrachten Sie Ihre Website mit Googles Augen
Um herauszufinden, ob diese Fehler auf Ihrer Website vorliegen, brauchen Sie keine teuren Tools; die folgenden fünf Schritte decken den Großteil der Probleme auf:
- Führen Sie eine URL-Prüfung durch: Öffnen Sie das URL-Prüftool in der Search Console und schauen Sie sich mit 'Gecrawlte Seite ansehen' das von Google gerenderte HTML und den Screenshot an. Fehlt der Hauptinhalt dort, ist das Problem bestätigt. Die ausführliche Nutzung des Tools erklären wir in unserem Search-Console-Leitfaden.
- Prüfen Sie das erste HTML: Lassen Sie sich den Quelltext der Seite anzeigen und suchen Sie nach einem Satz aus dem Haupttext. Fehlt er im Quelltext, wird der Inhalt clientseitig erzeugt.
- Schalten Sie JavaScript aus: Deaktivieren Sie JavaScript in den Browsereinstellungen und navigieren Sie durch die Website. Das, was Sie sehen, kommt dem am nächsten, was Bots ohne JavaScript-Ausführung sehen.
- Führen Sie eine site:-Suche durch: Prüfen Sie mit site:ihredomain.de bei Google, ob Titel und Beschreibungen der indexierten Seiten tatsächlich seitenspezifisch sind.
- Lesen Sie den Indexierungsbericht: Prüfen Sie im Seitenindexierungsbericht der Search Console, bei welchen URL-Mustern sich die Gruppen 'Gecrawlt, aber momentan nicht indexiert' und 'Gefunden, aber momentan nicht indexiert' häufen; das Muster verrät Ihnen die genaue Adresse des Fehlers.
Diese Tests zeigen, dass ein Problem existiert; um die Ursache zu finden und zu priorisieren, braucht es ein systematisches Audit. Unsere technische SEO-Checkliste liefert den umfassenden Rahmen, der Rendering-Probleme zusammen mit Crawling-Budget, Website-Architektur und Statuscodes behandelt.
Fazit: Mit Google zu kommunizieren ist eine Übersetzungsaufgabe
Die Beziehung zwischen modernen JavaScript-Frameworks und Suchmaschinen ist keine Unvereinbarkeit, sondern eine Übersetzungsfrage. Google kann JavaScript verarbeiten; aber verzögert, mit Kosten verbunden und unter Bedingungen. Die meisten KI-Crawler verarbeiten es gar nicht. Die Regel ist deshalb eindeutig: Inhalt, Meta-Tags und Links jeder Seite, auf der Sie Traffic erwarten, müssen im ersten HTML vorhanden sein. CSR auf interaktive Bereiche zu beschränken, kritische Seiten mit SSR oder SSG auszuliefern und regelmäßige Rendering-Audits durchzuführen, sind die drei Punkte dieser Vereinbarung.
Die gute Nachricht: Richtig diagnostiziert, lassen sich JavaScript-SEO-Probleme meist mit einer begrenzten Zahl architektonischer Entscheidungen lösen, und die Lösung wirkt sich websiteweit aus. Der schwierige Teil ist, überhaupt zu erkennen, dass auf einer im Browser einwandfrei wirkenden Website ein Problem besteht; dafür muss man wissen, wie man mit Googles Augen schaut.
Bei Welda verbindet unser SEO-Team genau diesen Blick mit einer Entwicklerperspektive: Wir führen Rendering-Audits für React- und Next.js-Projekte durch, begründen mit Daten, welche Seite SSR und welche SSG braucht, und übersetzen die Erkenntnisse in technische Aufgaben, die Ihr Entwicklungsteam direkt umsetzen kann. Diese Arbeit binden wir im Rahmen unserer SEO-Betreuung an einen messbaren Fahrplan. Möchten Sie wissen, wie Ihre Website tatsächlich bei Google ankommt, nehmen Sie Kontakt auf; wir legen den aktuellen Stand mit konkreten Befunden offen.