JavaScript-SEO 2026: Wie React- und Next.js-Seiten sicher ranken

Wer eine Single-Page-Application mit der Standardeinstellung seines Frameworks live nimmt und danach über schlechte Sichtbarkeit klagt, hat kein SEO-Problem, sondern eine Architektur-Entscheidung übersprungen. Vor einigen Jahren war JavaScript-SEO ein echtes Risiko: Eine klassische SPA lieferte anfangs nur ein leeres HTML-Gerüst, und Suchmaschinen mussten erst mühsam JavaScript ausführen, um überhaupt Inhalte zu sehen. Technisch ist dieses Problem heute lösbar - aber nur, wenn die Rendering-Architektur bewusst gewählt wird.

Warum das alte Problem nicht von selbst gelöst ist

Eine klassische Single-Page-Application rendert ihre Inhalte im Browser: Der erste Request liefert nur ein minimales HTML-Grundgerüst plus ein JavaScript-Bundle, und erst nachdem dieses Bundle geladen und ausgeführt wurde, entstehen Überschriften, Text und Links. Für einen menschlichen Besucher mit modernem Browser ist das kaum spürbar. Für einen Crawler, der Ressourcen sparen muss oder JavaScript gar nicht ausführt, bedeutet es: Er sieht zunächst nichts oder nur einen Bruchteil des tatsächlichen Inhalts.

Die Konsequenzen reichen weiter, als viele erwarten: schlechtere Rankings, weil der Crawler den eigentlichen Inhalt gar nicht bewerten kann, deutlich längere Zeiten bis zur ersten Indexierung, und vollständige Sichtbarkeitslücken bei KI-Systemen, die JavaScript grundsätzlich nicht ausführen. Wer eine bestehende Seite migriert oder neu aufsetzt, trifft die Rendering-Entscheidung deshalb am besten vor dem ersten Zeilencode, nicht als nachträgliche Reparatur, wenn die Rankings bereits einbrechen.

Wie Google und KI-Crawler JavaScript heute verarbeiten

Google verarbeitet JavaScript inzwischen in zwei Schritten. Zuerst wird das rohe HTML erfasst und indexiert, danach folgt eine zweite Rendering-Welle, in der JavaScript ausgeführt und zusätzlicher Inhalt nachgetragen wird. Diese zweite Welle kann Tage dauern und läuft nicht für jede Seite gleich zuverlässig. Bei vielen KI-Crawlern - etwa den Systemen, die Inhalte für ChatGPT, Claude oder Perplexity live nachladen - ist die Lage strenger: Ein großer Teil liest ausschließlich das initial ausgelieferte HTML und führt gar kein JavaScript aus. Inhalte, die erst clientseitig entstehen, bleiben für diese Systeme schlicht unsichtbar.

Ein einfacher Test zeigt, wie Ihre eigene Seite dasteht:

curl -s https://ihre-domain.de | grep -i "<title"

Erscheint der tatsächliche Seitentitel im Ergebnis, liefert der Server bereits vollständiges HTML aus. Erscheint stattdessen nur ein Platzhalter oder gar nichts, hängt der Inhalt vollständig von clientseitigem JavaScript ab - ein Risiko, das sich mit der richtigen Rendering-Strategie beheben lässt.

Die drei tragfähigen Rendering-Strategien

Static Site Generation (SSG) erzeugt das HTML für jede URL einmal beim Build und liefert es danach als statische Datei über ein CDN aus. Crawler bekommen sofort vollständiges HTML, ohne dass ein Server pro Anfrage etwas berechnen muss. Diese Strategie eignet sich besonders für Marketing-Seiten, Blogartikel und Dokumentation, deren Inhalt sich nicht bei jedem Aufruf ändert.

Server-Side Rendering (SSR) generiert das HTML dagegen bei jedem Request frisch auf dem Server. Das bedeutet mehr Serverlast als bei SSG, ist aber notwendig für Inhalte, die sich pro Nutzer oder sehr häufig ändern, etwa personalisierte Ergebnisseiten oder Preise, die live berechnet werden.

Incremental Static Regeneration (ISR) verbindet beides: Seiten werden wie bei SSG statisch ausgeliefert, aber nach einem definierten Zeitraum oder Ereignis automatisch im Hintergrund neu generiert. Das kombiniert die Performance von SSG mit einer Aktualität, die näher an SSR liegt, und passt gut zu Blogs oder Produktkatalogen mit moderater Änderungsfrequenz.

Keine der drei Strategien ist grundsätzlich die „bessere“ - sie beantworten unterschiedliche Fragen. Die entscheidende Frage lautet nicht, welches Framework im Einsatz ist, sondern wie oft sich der Inhalt einer bestimmten Seite ändert und ob er für jeden Besucher gleich aussieht. Eine Seite, die für alle Besucher identisch ist und sich selten ändert, gehört zu SSG. Eine Seite, die sich pro Nutzer unterscheidet, gehört zu SSR. Alles dazwischen ist ein Kandidat für ISR.

Welche Strategie zu welcher Seite passt

Unsere eigene Website ist bewusst nach der ersten Zeile dieser Tabelle gebaut: eine Next.js-Anwendung auf Vercel, deren Seiten beim Build statisch vorgerendert werden. Da sich Inhalte wie Leistungsbeschreibungen und Blogartikel nicht minütlich ändern, entsteht jedes HTML einmal beim Build, inklusive strukturierter Daten und lokalisierter Pfade für Deutsch und Englisch. Zur Laufzeit bleibt nur eine schlanke Middleware für die Sprachweiche übrig, die am ausgelieferten HTML nichts ändert. Für ein Dashboard mit nutzerspezifischen, häufig wechselnden Daten wäre dagegen SSR oder ISR die passendere Wahl - die Entscheidung hängt am Inhalt, nicht am Framework.

Konkrete Maßnahmen für die nächsten 90 Tage

• Tag 1-30: Mit einem einfachen HTTP-Request ohne JavaScript prüfen, welche Seiten bereits vollständiges HTML ausliefern
• Tag 31-60: Für Seiten ohne SSR/SSG eine passende Rendering-Strategie festlegen und die Umstellung planen
• Tag 61-90: Umstellung technisch umsetzen, erneut per curl-Test verifizieren und die Indexierung in der Search Console beobachten

Fazit

JavaScript-SEO ist 2026 kein ungelöstes Problem mehr, sondern eine Architekturentscheidung, die am Anfang eines Projekts getroffen werden sollte. Static Site Generation, Server-Side Rendering und Incremental Static Regeneration liefern jeweils vollständiges HTML, das sowohl klassische Suchmaschinen als auch KI-Crawler zuverlässig lesen können - reines clientseitiges Rendering ohne diese Absicherung bleibt dagegen ein vermeidbares Risiko. Wie sich diese technische Basis auf Ladezeit und Core Web Vitals auswirkt, beschreiben wir im Artikel Core Web Vitals 2026. Wie KI-Systeme Inhalte darüber hinaus bewerten, zeigen wir im Artikel ChatGPT-Sichtbarkeit 2026. Was ein technisches SEO-Audit kostet, sehen Sie im Artikel zu SEO-Kosten. Für eine unverbindliche Einschätzung Ihrer aktuellen Architektur nehmen Sie gerne Kontakt mit uns auf.