SPA-SEO im Jahr 2026: Ein HTML-First-Praxisleitfaden für Next.js, Nuxt, SvelteKit und Astro

TL;DR: Single-Page-Applications können ranken – vorausgesetzt, URLs, Statuscodes, Metadaten und der Hauptinhalt sind bereits in der ersten HTML-Antwort vorhanden. Google rendert JavaScript oft verspätet, die meisten KI-Crawler rendern es gar nicht. Wähle pro Route ein Rendering-Modell, liefere zuerst das Dokument, dann den App-State und lass JavaScript anschließend hydrieren. Unten findest du einen Field Guide 2026 für Teams, die mit Next.js, Nuxt, SvelteKit oder Astro arbeiten.

Hör auf zu fragen, ob Google „JavaScript unterstützt“

Die Einstiegsfrage für SPA-SEO lautet längst nicht mehr „kann Googlebot JavaScript rendern?“. Ja, kann es. Martin Splitt sagt das seit Jahren. Trotzdem debuggen viele ihre SPA, indem sie view-source: anschauen, als wäre das die Seite, die Google indexiert.

„Viele Leute schauen immer noch auf View Source. Das ist nicht das, was wir zum Indexieren verwenden. Wir nutzen das gerenderte HTML.“

Martin Splitt, Developer Advocate bei Google

Damit stirbt eine schlechte Gewohnheit. Wer nur den Initial-Source einer React-, Vue-, Angular-, SvelteKit-, Nuxt-, Remix- oder Next.js-App prüft, sieht nicht, was Google letztlich verarbeitet. Entscheidend ist der gerenderte DOM.

Für 2026 lautet die Frage nicht mehr, ob Google rendern kann, sondern ob das Dokument schnell genug ankommt, um für Googlebot, Social-Parser und die zunehmend dominierenden KI-Crawler nützlich zu sein.

Die KI-Crawler-Lücke verändert die Rechnung

Jahrelang hielt ich das für ein reines Google-Problem (lag damit jahrelang falsch). Dann tauchten KI-Crawler mit anderem Verhalten auf.

„Die Ergebnisse zeigen konsistent, dass keiner der großen KI-Crawler aktuell JavaScript rendert.“

Vercel Engineering

GPTBot, ClaudeBot, PerplexityBot, der Gemini-Fetch – sie alle holen nur Roh-HTML. Befindet sich dein wichtigster Inhalt erst hinter der Hydration, sehen diese Crawler nur eine leere App-Shell statt Preistabelle, Produkttext, FAQ oder Vergleichstabelle. Starte unseren AI Crawler Inspector gegen ein paar SPA-Seiten und du siehst, was sie sehen.

Klassifiziere Routen, bevor du das Rendering-Problem klassifizierst

Die meisten Teams überspringen diesen Schritt und fragen, ob die ganze SPA SSR braucht. Das kostet unnötige Entwicklerzeit.

Eine echte SPA mischt zwei Dinge: crawlbare Seiten und private App-States. Preis-Seiten, Blogposts, Dokus, Templates, Integrationen, Vergleichs- und Produkt-Landing-Pages sind Seiten. Dashboards, Onboarding-Flows, Modals, Filter, Account-Screens und gespeicherte Reports sind States.

Starte mit der Klassifikation. Bitte die Entwickler nicht, „SEO für die App zu fixen“. Lass sie markieren, welche Routen Suchtraffic verdienen, und wähle erst dann Rendering, Indexierung, Canonicals und Statuscodes pro Route.

Routen-Typ	Soll ranken?	Rendering-Wahl	Index-Regel
Blogpost	Ja	SSG oder SSR	Index, self-canonical
Produkt-Landing-Page	Ja	SSG oder SSR	Index, self-canonical
Interne Suchergebnisse	Meist nein	CSR oder SSR	Oft noindex
Dashboard-Route	Nein	CSR reicht	Hinter Auth oder noindex
Facettierte Filter-URL	Manchmal	SSR nur, wenn kuratiert	Canonical oder noindex

Eine SPA mit 40 öffentlichen URLs und 4 000 Dashboard-States hat nicht 4 040 SEO-Seiten, sondern 40 Seiten plus Produkt-Interface. Öffentliche Routen brauchen feste URLs, Self-Canonicals, servergelieferte Metadaten, crawlbare Links, nützliches First-Byte-HTML und korrekte Statuscodes. Dashboard-Routen brauchen schnelle Interaktion, Auth und State-Management. Beide Gruppen in ein einziges Rendering-Modell zu pressen, verschlechtert meist beide.

Wähle das Rendering-Modell pro Route, nicht pro App

Rendering-Strategie ist Architektur, kein Plugin-Schalter. Wählst du das falsche Modell, wird jedes spätere Ticket ein Workaround.

CSR: ok fürs Dashboard, riskant für Landing-Pages

Client-Side-Rendering passt perfekt für authentifizierte Software-Screens. Muss sich der Nutzer einloggen, sollen Crawler die Route ohnehin nicht indexieren. Gefährlich wird CSR, wenn dieselbe App-Shell Preis-Seiten, Dokus, Artikel oder Produkt-Seiten bedient, deren Inhalt erst nach JavaScript-Ausführung und API-Calls erscheint.

SSG: langweilig, schnell und meist die beste Wahl

Static-Site-Generation baut Seiten vorab als HTML. Für Blogs, Dokus, Changelogs, Glossare, Templates und die meisten Marketing-Inhalte ist SSG unschlagbar: schnell, cachbar, günstig, crawlerfreundlich. Astro 5 treibt das mit Islands-Architektur und Zero-JS-by-default am weitesten.

SSR: sinnvoll, wenn öffentlicher Inhalt oft wechselt

Server-Side-Rendering passt, wenn öffentlicher Content pro Anfrage, Region, Inventar, Berechtigung oder Aktualität variiert. Lee Robinson beschreibt das Next.js-Modell so:

„Next.js prerendert die Seite bei jeder Anfrage als HTML auf dem Server.“

Lee Robinson, VP Developer Experience bei Vercel

SSR liefert Crawlern HTML ohne Client-Bundle-Wartezeit und spiegelt trotzdem frische Daten.

ISR und PPR: das praktikable Mittel für große Sites

Incremental-Static-Regeneration aktualisiert statische Seiten nach dem Veröffentlichen. Für programmatisches SEO, Dokus und große Template-Bibliotheken verhindert ISR Rebuild-Schmerzen ohne komplettes CSR. Next.js 15 hat Partial Prerendering (PPR) stabil gemacht: statische Shell, dynamische Löcher per Stream – näher an realen Produkt-Seiten.

Dynamic Rendering: das Auslauf-Workaround

Dynamic Rendering liefert eine Version an Crawler, eine an User. Es kann eine Legacy-SPA retten, wenn die Migration nicht fertig ist, aber niemals Basis einer neuen Strategie sein.

„Ich sehe das eher als temporären Workaround – temporär kann auch ein paar Jahre heißen – aber eben zeitlich begrenzt.“

John Mueller, Search Advocate bei Google

Nutz Dynamic Rendering als Brücke. Ersetze sie durch server- oder statik-gerenderte Public-Routen.

Framework-Details, die 2026 zählen

Das richtige Rendering-Modell ist auch Framework-abhängig. Defaults haben sich in den letzten zwölf Monaten verschoben – relevant für SPA-SEO.

• Next.js 15. React 19 stabil, Turbopack dev stabil, fetch- und GET-Route-Handler standardmäßig nicht mehr gecacht. Die früheren Defaults verdeckten Stale-Content-Bugs; jetzt musst du Caching pro Route explizit setzen. Partial Prerendering ist das SEO-Highlight – statische Shell, gestreamte Deltas. Mehr Details im Next.js-, React- und Nuxt-SEO-Guide.
• Nuxt 4. Applikationscode liegt jetzt standardmäßig in app/. Separate TypeScript-Projekte für App, Server, Shared und Builder reduzieren Type-Bleed, der früher Server-Secrets in Client-Bundles leakte. Nuxt 4.4 (März 2026) bringt vue-router v5 und typisierte Layout-Props – kleine Gewinne für saubere Route-Metadaten.
• SvelteKit 2 mit Svelte 5 Runes. Seiten werden per Default server-gerendert; Prerendering ist pro Route opt-in. Das Modell lautet eher „jede Route SSR, außer ich sage statisch“ – Umkehr der SPA-Falle. Bundles bleiben so klein, dass Hydration selten blockiert.
• Astro 5 (und 6). Zero-JavaScript-Default, Islands-Architektur, Multi-Framework-Support. Nach der Cloudflare-Übernahme (Jan 2026) wurde Edge-Deployment noch schlanker. Astro ist die einfache Wahl für Content-starke SPAs, die nur auf einzelnen Seiten React- oder Vue-Komponenten brauchen.

Das Framework ist weniger entscheidend als die Disziplin pro Route. Alle vier können eine crawlbare SPA ausliefern – oder eine unsichtbare, wenn du öffentliche Inhalte hinter Hydration versteckst.

Crawl-Fallen, die Indexing immer noch brechen

Die harten SPA-SEO-Fails sind langweilig: Auslieferungs-Bugs, keine mysteriösen Penalties.

Falle 1: die Universal-Shell. Jede URL liefert denselben 200, dieselbe leere Root, dasselbe Bundle. Der Router entscheidet später, ob /pricing, /docs/api oder /totally-fake-url existiert. Das überfordert Crawler und führt zu Falle 2: Soft 404.

„Anstatt 404 zurückzugeben, antwortet die Seite mit 200 … und zeigt je nach JavaScript-Ausführung etwas an.“

Martin Splitt, Developer Advocate bei Google

Ungültige Routen müssen echte 404 oder 410 liefern. Eine schicke Client-Side-„Page not found“ mit 200 verschwendet Crawl-Budget und verwirrt Signale.

Falle 3: Navigation, die Crawler nicht folgen können. Buttons, Click-Handler und Router-Events sind prima für Nutzer, aber interne Discovery braucht Anker mit echtem href. Liegt deine wichtigste Seite nur hinter einem JS-Handler, ist Crawlability schwächer als gedacht.

Metadaten sind ein weiterer Klassiker. Viele SPAs aktualisieren Title, Description, Canonical, Robots, Open Graph und Schema erst nach Route-Wechsel. Im Browser sieht das gut aus, für Crawler scheitert es. Route-Metadaten müssen in der HTML-Antwort stehen.

Canonicals brauchen Extra-Aufmerksamkeit. Ich sah hydratisierte Apps, die ein korrektes Canonical mit einer Staging-Domain, der Root-URL oder der vorherigen Route überschrieben. Der Bug bleibt leise, bis Dubletten eskalieren oder falsche Seiten ranken.

Infinite Scroll versteckt Content hinter Client-State. Haben Seite 2, 3 und älter keine crawlbaren URLs, entdeckt die Suche sie nie. Nutze paginierte Fallback-URLs für wichtige Archive und Kategorien.

API-geladener Hauptinhalt ist fragil. Wenn H1, Fließtext, Produktdetails, Reviews oder interne Links erst nach Hydration per API kommen, hast du mehr Fehlerquellen: Bot-Traffic trifft Rate-Limits, APIs blocken unbekannte Agents, Timeouts lassen den Render-DOM dünn.

Was AI Overviews aus einer SPA wirklich zitieren

2026 ist das der Knackpunkt. Googles AI Overviews fassen Antworten über den organischen Treffern zusammen und zitieren die Quellen. Diese Zitate sind das neue Funnel-Top und folgen einer klaren HTML-Logik.

Das System greift auf statische Signale zu: sichtbarer Text, Überschriften, Listen, Tabellen, semantisches HTML in der ersten Antwort. Hydration wartet es nicht ab. Steht dein zitierfähiger Absatz erst nach useEffect, sieht ihn kein Overview.

Drei Dinge zählen für SPA-Seiten, die zitiert werden wollen:

1. HTML-erste Antwort-Absätze. Die ersten 300–400 Wörter jeder indexierbaren Route sollten die Hauptfrage ohne JavaScript beantworten. Die meisten AIO-Zitate stammen von dort.
2. Semantische Struktur für Listen und Tabellen. <ul>, <ol> und <table> werden direkt extrahiert. Div-Pseudotabellen nicht.
3. Stabile URLs, die der Bot neu abrufen kann. AI Overviews prüfen Quellen erneut. Hash-Routen, Query-Only-Pages und Dynamic-Rendering-Forks machen das wacklig.

Dasselbe gilt für Perplexity-Zitate, ChatGPT-Browsing-Antworten und Claudes Web-Reads. Ihre Crawler holen Roh-HTML; fehlt die Antwort dort, fehlt das Zitat. Optimieren für AI Overview-Zitate erklärt mehr, unsere AIO-Impact-Analyse zeigt den Traffic-Schwund.

Liefere jede indexierbare Route zuerst als Dokument aus

Die Regel: Verdient eine Route Suchtraffic, muss die erste Antwort wie eine Seite aussehen.

Jede öffentliche URL liefert also nützliches HTML mit allen Kernsignalen:

• Korrektes <title>
• Meta-Description
• Self-referenzielles Canonical
• Eine klare H1
• Hauptinhalt
• Crawlbare interne Links
• Strukturierte Daten, falls sinnvoll
• Passender Statuscode
• Open Graph und Twitter-Tags, falls Sharing wichtig ist

JavaScript kann danach Komponenten hydrieren, personalisieren, Events tracken, die UX anreichern – darf aber nicht nötig sein, damit der Crawler das Thema versteht.

Auch die Site-Architektur zählt. Eine öffentliche Route ohne crawlbare Links bleibt schwach – selbst wenn sie server-gerendert ist. Ein perfektes Dokument, das fünf Klicks tief hinter Client-Navigation steckt, performt nicht wie eines in einem klaren internen Link-System.

Teste SPA-SEO mit gerendertem HTML, nicht mit Hoffnung

Testest du nur die Browser-Experience, prüfst du den Happy Path. SPA-SEO braucht härtere Tests.

1. Rufe die URL ohne JavaScript ab und prüfe, ob der Inhalt verständlich bleibt.
2. Inspektiere die URL in der Google Search Console und sieh dir das gerenderte HTML an.
3. Vergleiche initiales HTML mit dem gerenderten DOM in den Chrome DevTools.
4. Teste Statuscodes direkt: curl -I https://example.com/missing-route
5. Crawle die Site einmal mit JS-fähigem und einmal mit JS-freiem Crawler.
6. Bestätige, dass Title, Canonical, Robots, Schema und interne Links vor Hydration existieren.
7. Checke Server-Logs auf Bot-Hits, blockierte APIs, Timeouts, unerwartete Redirects.
8. Validiere strukturierte Daten nach dem Rendern mit Googles Rich-Results-Test.

Der unangenehme H1-Test: Braucht Googlebot fünf Schritte und zwei API-Calls für die H1, ist die Seite fragil – selbst wenn sie irgendwann indexiert wird. Dasselbe gilt für GPTBot, ClaudeBot und PerplexityBot: Steht die H1 nicht im Roh-HTML, taucht die Route nicht als KI-Zitat auf.

SPA-SEO-Checkliste 2026

Nutz sie pro Route. Ein Site-weiter „Pass“ kaschiert zu viele Fehler.

• Rendering: Öffentliche Seiten via SSG, SSR, ISR oder PPR. Private Screens bleiben CSR.
• Routing: Jede indexierbare URL hat eine eigene Route, eigenen Inhalt, self-canonical.
• Statuscodes: Fehlende Seiten liefern 404 oder 410, nie 200.
• Links: Interne Navigation nutzt crawlbare <a href="">.
• Metadaten: Title, Description, Canonical, Robots, Open Graph, Schema pro Route im HTML.
• Content: Haupttext, H1, Produktinfos und Kernlinks existieren ohne Client-Daten.
• Performance: Bundle-Größe, Hydration-Kosten, Third-Party-Scripts, Route-Level-Codesplitting im Griff.
• Index-Kontrolle: Dashboards, private Routen, Low-Value-Filter, dünne Such-Seiten blocken oder noindex.
• Testing: Initiales HTML, gerenderter DOM und indexierter Content auf wichtigen Templates vergleichen.
• KI-Sichtbarkeit: Zitierbare Absätze, Listen, Tabellen im Roh-HTML, damit AI Overviews & Co. sie greifen.

Search, AI-Antworten, Link-Previews und Discovery-Systeme hängen von Zugänglichkeit ab. Rankings kommen danach.

Die einfachste SPA-SEO-Architektur, die ich heute ausliefern würde

Würde ich 2026 eine moderne SPA mit Such-Fokus bauen, renderte ich nicht das ganze Produkt serverseitig. Ich würde splitten.

Siten-Bereich	Empfohlener Ansatz
Marketing-Site	Static Generation
Blog & Doku	Static Generation oder ISR
Produkt-Pages	SSR, ISR oder Next.js PPR
Programmatic-SEO-Pages	Static Generation mit starkem Pruning
Dashboard	CSR hinter Auth
Such- & Filter-Pages	Noindex, außer manuell kuratiert
Ungültige Routen	Echte 404 oder 410
Shared Layout	Server-gerenderte Metadaten & Navigation

Marketing-Seiten und Artikel: HTML-first. Produkt-Flächen, die Frische brauchen: SSR, ISR oder PPR. Das Dashboard bleibt app-artig – Ranking wäre sinnlos. Programmatic-SEO-Pages brauchen Disziplin. Static Generation macht tausende Seiten leicht – auch tausende, die niemand indexieren sollte. Generiere nur Seiten mit echter Nachfrage, nützlichem Content und internen Links. Prune den Rest, bevor Google entscheiden muss.

Die gewinnende SPA ist nicht die, die beweist, dass Crawler JavaScript ausführen können. Es ist die, die Crawler nicht zu unnötiger Arbeit zwingt.

FAQ

Kann eine Single-Page-Application 2026 bei Google ranken?

Ja. Eine SPA kann ranken, wenn indexierbare Routen crawlbaren Inhalt, korrekte Metadaten, interne Links und gültige Statuscodes bereits in der ersten HTML-Antwort liefern. Google kann JavaScript rendern, aber sich darauf zu verlassen macht die Site fragiler und unsichtbar für KI-Crawler, die gar nicht rendern.

Ist Server-Side-Rendering für SPA-SEO Pflicht?

Nicht für jede Route. SSR passt zu öffentlichen Seiten mit häufigem Content-Wechsel. Für stabilen Content sind SSG oder ISR oft besser. Next.js 15 bringt mit Partial Prerendering beides in eine Route. CSR ist ok für private Dashboards und States, die nicht indexiert werden sollen.

Sind Hash-Routen schlecht für SEO?

Für indexierbare Seiten ja. Sie funktionieren für On-Page-Fragmente, aber öffentlicher Content braucht saubere URLs, route-spezifische Metadaten und Server-Statuscodes.

Sollen SPA-Suchergebnisseiten indexiert werden?

Meistens nein. Interne Such- und Facetten-Seiten erzeugen oft dünne oder doppelte URLs. Kuratierte Filter-Seiten können indexiert werden, wenn echte Nachfrage, stabiler Content und klare Canonicals vorliegen.

Woran erkenne ich Soft-404-Probleme in meiner SPA?

Ruf eine Fake-URL auf und prüfe den Statuscode. Gibt /this-page-should-not-exist 200 mit einer Client-Side-Not-Found-Meldung zurück, riskierst du Soft 404 und verschwendetes Crawl-Budget.

Zitieren AI Overviews eine JavaScript-gerenderte SPA?

Nur wenn der zitierte Inhalt im Roh-HTML vorhanden ist. Die meisten KI-Crawler führen kein JavaScript aus. Render oder prerender die Absätze, Listen und Tabellen, die du zitiert haben willst.

Brauchst du Hilfe, um deine SPA crawlbar zu machen?

SEOJuice stärkt crawlbare interne Links und HTML-First-Signale auf den öffentlichen Seiten, die Suchtraffic verdienen. Hat deine SPA verwaiste Routen, versteckte Templates oder Seiten, die Google nie erreicht, kann automatisiertes internes Linking die Dokument-Schicht für Crawler und KI-Bots zugänglicher machen.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Kann eine Single-Page-Application 2026 bei Google ranken?", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Eine SPA kann ranken, wenn indexierbare Routen crawlbaren Inhalt, korrekte Metadaten, interne Links und gültige Statuscodes bereits in der ersten HTML-Antwort liefern. Google kann JavaScript rendern, aber sich darauf zu verlassen macht die Site fragiler und unsichtbar für KI-Crawler, die gar nicht rendern." } }, { "@type": "Question", "name": "Ist Server-Side-Rendering für SPA-SEO Pflicht?", "acceptedAnswer": { "@type": "Answer", "text": "Nicht für jede Route. SSR passt zu öffentlichen Seiten mit häufigem Content-Wechsel. Für stabilen Content sind SSG oder ISR oft besser. Next.js 15 bringt mit Partial Prerendering beides in eine Route. CSR ist ok für private Dashboards und States, die nicht indexiert werden sollen." } }, { "@type": "Question", "name": "Sind Hash-Routen schlecht für SEO?", "acceptedAnswer": { "@type": "Answer", "text": "Für indexierbare Seiten ja. Sie funktionieren für On-Page-Fragmente, aber öffentlicher Content braucht saubere URLs, route-spezifische Metadaten und Server-Statuscodes." } }, { "@type": "Question", "name": "Sollen SPA-Suchergebnisseiten indexiert werden?", "acceptedAnswer": { "@type": "Answer", "text": "Meistens nein. Interne Such- und Facetten-Seiten erzeugen oft dünne oder doppelte URLs. Kuratierte Filter-Seiten können indexiert werden, wenn echte Nachfrage, stabiler Content und klare Canonicals vorliegen." } }, { "@type": "Question", "name": "Woran erkenne ich Soft-404-Probleme in meiner SPA?", "acceptedAnswer": { "@type": "Answer", "text": "Ruf eine Fake-URL auf und prüfe den Statuscode. Gibt /this-page-should-not-exist 200 mit einer Client-Side-Not-Found-Meldung zurück, riskierst du Soft 404 und verschwendetes Crawl-Budget." } }, { "@type": "Question", "name": "Zitieren AI Overviews eine JavaScript-gerenderte SPA?", "acceptedAnswer": { "@type": "Answer", "text": "Nur wenn der zitierte Inhalt im Roh-HTML vorhanden ist. Die meisten KI-Crawler führen kein JavaScript aus. Render oder prerender die Absätze, Listen und Tabellen, die du zitiert haben willst." } } ] } </script>