SPA-SEO ist ein Auslieferungsproblem, kein Rendering-Problem

TL;DR: Bei SPA-SEO geht es längst nicht mehr ums Rendering, sondern um die Auslieferung: URLs, Statuscodes, Metadaten und der Hauptinhalt müssen existieren, bevor JavaScript ins Spiel kommt – denn Google rendert oft verspätet und viele KI-Crawler rendern überhaupt nicht.

SPA-SEO dreht sich nicht mehr darum, ob Google „JavaScript unterstützt“

Die meisten Ratschläge zu SPA-SEO beginnen noch immer mit der falschen Frage: Kann Google JavaScript rendern?

Ja, Google kann JavaScript rendern. Martin Splitt sagt das seit Jahren – und trotzdem debuggen viele SPAs, indem sie auf view-source: starren, als sei das die Version, die Google indexiert.

„Viele Leute schauen sich immer noch den Quelltext an. Das ist nicht das, was wir zum Indexieren verwenden. Wir nutzen das gerenderte HTML.“

Martin Splitt, Developer Advocate bei Google

Dieses Zitat ist wichtig, weil es eine schlechte Gewohnheit beendet. Wer nur den initialen Quelltext einer React-, Vue-, Angular-, SvelteKit-, Nuxt-, Remix- oder Next.js-App prüft, verpasst womöglich, was Google am Ende sieht. Der gerenderte DOM zählt.

Doch das bedeutet nicht, dass Client-Side Rendering für jede öffentliche Route sicher ist. Rendering kostet Zeit. Rendering kann scheitern. Rendering kann später stattfinden als das Crawling. Andere Bots rendern womöglich nie. Die eigentliche Frage für spa seo lautet daher, ob der Crawler rechtzeitig ein sinnvolles Dokument erhält.

View Source ist der falsche Debugging-Reflex

View Source zeigt die erste HTML-Antwort. Bei einer klassischen CSR-App besteht diese Antwort oft aus einer leeren Hülle, einem Root-Element, einem Skript-Bundle und einem Stoßgebet. Google könnte die Seite später rendern, die Route ausführen, APIs aufrufen und den echten Inhalt finden. Könnte.

Dieses „könnte“ sorgt für merkwürdige Rankings. Die Seite wirkt im Browser perfekt und ist trotzdem brüchig für die Suche – der Browser ist geduldig, Crawler arbeiten jedoch mit Queues, Budgets, Timeouts und Fehlermodi.

Gerenderter DOM zählt, aber HTML zum First Byte gewinnt

seojuice.io ist bewusst aufgeteilt – öffentliche Seiten liefern statisches HTML, das eingeloggte Dashboard verhält sich wie eine App. Zwei Rendering-Strategien unter einer Domain, weil die Routen unterschiedliche Aufgaben haben.

Blog, Tools und Landingpages müssen gefunden, gecrawlt, verstanden, geteilt und zitiert werden. Das Dashboard muss nicht für „Page Health Scoring UI“ ranken und wird es nie. JavaScript darf die öffentliche Seite nach dem Laden verbessern, aber schon die erste Antwort sollte wie eine Seite aussehen.

KI-Crawler haben das Risikoprofil verändert

Jahrelang hielt ich das für ein reines Google-Problem (ich lag jahrelang falsch). Dann verschärften KI-Crawler die alte Abkürzung.

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

Vercel Engineering

Sieht GPTBot, ClaudeBot, PerplexityBot oder ein anderer Crawler nur eine App-Shell, fehlt dein Inhalt auf dieser Oberfläche schlicht. Google-Rendering hilft Google (und nur Google) – es rettet nicht jeden Crawler, Vorschaubot, Monitoring-Dienst, Social-Parser oder KI-Ingestion-Prozess.

Entscheide, welche SPA-Routen Seiten sind und welche App-States

Diesen Schritt überspringen die meisten Teams. Sie fragen, ob die komplette SPA SSR braucht. Dieses Framing verschwendet Engineering-Zeit.

Eine echte SPA mischt fast immer zwei Dinge: crawlbare Seiten und private App-States. Pricing-Seiten, Blogposts, Dokus, Templates, Integrationen, Vergleichsseiten und Produkt-Landingpages sind Seiten. Dashboards, Onboarding-Schritte, Modals, Filter, Account-Screens und gespeicherte Reports sind App-States.

Der Fix startet mit Klassifikation. Bitte nicht die Engineers, „SEO für die App zu reparieren“. Lass sie markieren, welche Routen Suchtraffic verdienen, und wähle dann pro Route Rendering, Indexing, Canonicals und Statuscodes.

So erkläre ich es in einem Technical-SEO-Audit. Eine SPA mit 40 öffentlichen URLs und 4 000 Dashboard-States hat keine 4 040 SEO-Seiten. Sie hat 40 Seiten und eine Produkt-UI.

Diese Unterscheidung ändert den Fahrplan. Öffentliche Routen brauchen stabile URLs, Self-Canonicals, servergelieferte Metadaten, crawlbare Links, sinnvolles First-Byte-HTML und korrekte Statuscodes. Dashboard-Routen brauchen schnelle Interaktion, Auth, State-Management und Privatsphäre. Beides in ein einziges Rendering-Modell zu zwingen, verschlechtert meist beide.

Bei mindnow war dies der häufigste SPA-Fehler in Kundenprojekten. Das Team wollte eine elegante Frontend-Architektur. Die Suche wollte langweilige Dokumente. Der Kompromiss war nicht, die App aufzugeben, sondern aufzuhören, jeder Route denselben Zweck zuzuschreiben.

Wähle das richtige Rendering-Modell, bevor du SEO-Tickets schreibst

Rendering-Strategie ist eine Architekturentscheidung, kein SEO-Plugin-Häkchen – wählst du das falsche Modell, wird jedes spätere Ticket ein Workaround.

CSR: okay fürs Dashboard, riskant für Landingpages

Client-Side Rendering ist für authentifizierte Software-Screens völlig in Ordnung. Muss sich ein Nutzer einloggen, sollten Crawler die Route ohnehin nicht indexieren. Gefährlich wird CSR, wenn dieselbe App-Shell Pricing-Seiten, Dokus, Artikel und Produktseiten bedient, deren Inhalt erst nach JavaScript-Ausführung und API-Antworten erscheint.

SSG: langweilig, schnell und meist die beste Wahl

Static Site Generation baut Seiten vorab als HTML (meist beim Build oder Deploy). Für Blogs, Dokus, Changelogs, Glossar-Seiten, Templates und die meisten Marketing-Inhalte ist SSG unschlagbar: schnell, cachebar, günstig und crawlerfreundlich.

SSR: sinnvoll, wenn sich öffentlicher Inhalt oft ändert

Server-Side Rendering passt besser, wenn öffentlicher Content sich je Anfrage, Geografie, Inventar, Berechtigung oder Aktualität ändert. Lee Robinson brachte das Next.js-Modell auf den Punkt:

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

Lee Robinson, VP Developer Experience bei Vercel

SSR liefert Crawlern HTML, ohne auf das Client-Bundle zu warten, und zeigt dennoch frische Daten.

ISR: das praktische Mittelmaß für große Sites

Incremental Static Regeneration (statische Seiten, die nach Veröffentlichung erneuert werden) ist oft der beste Mittelweg für große Content-Bibliotheken. Du bekommst statisches HTML für die meisten Anfragen und Regeneration bei Änderungen. Für programmatic SEO, Dokus und große Template-Bibliotheken verhindert ISR schmerzhafte Rebuilds, ohne auf volles CSR zurückzufallen.

Dynamic Rendering: die Übergangslösung mit Verfallsdatum

Dynamic Rendering liefert Crawlern eine Version und Nutzern eine andere. Es kann eine Legacy-SPA retten, wenn eine Migration noch nicht bereit ist – aber ich würde keine neue Suchstrategie darauf aufbauen.

„Ich sehe das eher als temporären Workaround – wobei temporär ein paar Jahre bedeuten kann – aber eben als zeitlich begrenzte Lösung.“

John Mueller, Search Advocate bei Google

Genau so sollte man es sehen. Nutze Dynamic Rendering als Brücke, ersetze sie dann durch servergerenderte oder statische öffentliche Routen.

Behebe die SPA-Crawl-Fallen, die das Indexing noch sabotieren

Die harten SPA-SEO-Fehler sind meist langweilig. Keine mysteriösen Ranking-Penalties, sondern Auslieferungs-Bugs.

Falle eins ist die universelle Shell. Jede URL liefert dieselbe 200-Antwort, denselben leeren Root-Node und dasselbe Bundle. Der Router entscheidet später, ob /pricing, /docs/api oder /totally-fake-url existiert. Das zwingt Crawler zu viel Arbeit und erzeugt Falle zwei: Soft-404.

„Statt mit 404 zu antworten, liefert sie einfach 200 … und zeigt immer eine Seite basierend auf der JavaScript-Ausführung.“

Martin Splitt, Developer Advocate bei Google

Ungültige Routen sollten echte 404- oder 410-Codes liefern. Ein schickes Client-Side-„Page not found“-Component mit 200 bleibt ein schlechtes Signal (die „Soft-404“-Falle, die Crawl-Budgets frisst).

Falle drei ist Navigation, der Crawler nicht folgen können. Buttons, Click-Handler, Custom-Components und Router-Events sind für Nutzer okay, doch interne Discovery braucht crawlbare <a>-Tags mit echten hrefs. Sind deine wichtigsten Seiten erst nach einem JavaScript-Click erreichbar, ist Crawlability schwächer als gedacht.

Metadaten sind ein weiterer Klassiker. Viele SPAs aktualisieren Titel, Descriptions, Canonicals, Robots-Tags, Open-Graph-Tags und Schema erst nach Routenwechsel. Im Browser-Tab wirkt das – für Crawler, Social-Parser und KI-Bots kann es scheitern. Routen-spezifische Metadaten gehören ins zurückgelieferte HTML jeder indexierbaren URL.

Canonicals verdienen eine eigene Warnung. Ich habe hydratisierte Apps gesehen, die einen korrekten Canonical mit einer Staging-Domain, der Root-URL oder der vorherigen Route überschreiben. Solche Bugs sind leise. Niemand merkt etwas, bis Duplikate clustern oder die falsche Seite rankt.

Infinite Scroll ist ebenfalls riskant, wenn es Inhalt hinter Client-State versteckt. Haben Seite 2, 3 und ältere Items keine crawlbaren URLs, entdecken Suchmaschinen sie eventuell nie. Nutze paginierte Fallback-URLs für wichtige Archive und Kategorieseiten.

Per API geladener Hauptinhalt ist auch fragil. Müssen H1, Body-Copy, Produktdetails, Reviews oder interne Links zwei API-Calls nach Hydration abwarten, hast du mehr Fehlerpunkte: Bots treffen Rate-Limits, APIs blocken unbekannte User-Agents, Timeouts lassen den DOM dünn.

Hash-Routing gehört nicht auf indexierbare öffentliche Seiten. Ein URL-Fragment wie /docs#pricing ist für Sprungmarken okay, doch Hash-basiertes App-Routing erschwert Discovery, Canonical-Pflege und Analytics unnötig.

Beobachte schließlich Auth und Bundle-Größe gemeinsam. Öffentliches Content versehentlich hinter Login-Checks? Weg für Crawler. Schwere Bundles? Rendering-Delay und verschwendetes Crawl-Budget. Beides sieht nach „JavaScript-SEO“ aus, die praktische Lösung sind saubere Routen-Grenzen und weniger Client-Work für öffentliche Seiten.

Bau jede indexierbare Route erst als Dokument, dann als App

Die beste SPA-SEO-Regel ist simpel: Verdient die Route Suchtraffic, sollte die erste Antwort wie eine Seite aussehen.

Das heißt, jede öffentliche URL liefert nützliches HTML mit allen Kernsignalen:

• Korrektes <title>
• Meta-Description
• Self-referenzieller Canonical
• Ein klares H1
• Hauptinhalt
• Crawlbare interne Links
• Strukturierte Daten, wo sinnvoll
• Korrekter Statuscode
• Open-Graph- und Twitter-Tags, falls Sharing wichtig ist

Danach kann JavaScript Komponenten hydratisieren, Elemente personalisieren, Rechner laden, Events tracken, Tabellen filtern und das Erlebnis anreichern. Für den Crawler sollte JS nicht nötig sein, um das Thema der Seite zu verstehen.

Hier treffen Site-Architektur und SPA-SEO aufeinander. Eine öffentliche Route ohne crawlbare Links bleibt schwach, selbst wenn sie servergerendert ist. Ein perfekt gerendertes Dokument, das fünf Klicks tief hinter clientseitiger Navigation vergraben ist, performt schlechter als eine Seite in einer klaren internen Linkstruktur.

Die Document-first-Regel hält Teams ehrlich. Pricing ist ein Dokument. Ein Blogpost ist ein Dokument. Eine Doku-Seite ist ein Dokument. Ein gespeicherter Dashboard-Filter, ein offenes Modal oder ein Onboarding-Schritt ist App-State. App-State wie Suchseiten zu behandeln, bläht den Index auf. Öffentliche Seiten wie App-State zu behandeln, macht sie unsichtbar.

Bei seojuice.io ist diese Trennung Absicht. Öffentliche Routen müssen langweilig genug für Crawler sein. Das Produkt kann nach Login interaktiv bleiben. Beides passt zusammen.

Teste SPA-SEO mit gerendertem HTML, nicht mit Hoffnung

Wer nur das Browser-Erlebnis testet, testet den Happy Path. SPA-SEO braucht hässlichere Tests.

1. URL ohne JavaScript abrufen und prüfen, ob der Inhalt noch Sinn ergibt.
2. URL in der Google Search Console inspizieren und das gerenderte HTML ansehen.
3. Initiales HTML mit gerendertem DOM in Chrome DevTools vergleichen.
4. Statuscodes direkt testen: curl -I https://example.com/missing-route.
5. Site mit einem JS-fähigen und einem Non-JS-Crawler crawlen.
6. Titel, Canonicals, Robots-Tags, Schema und interne Links vor Hydration verifizieren.
7. Server-Logs auf Bot-Hits, blockierte APIs, Timeouts und unerwartete Redirects prüfen.
8. Strukturierte Daten nach dem Rendern mit Googles Rich-Results-Test validieren.

Der unangenehme Test ist der H1-Test. Braucht Googlebot fünf Schritte und zwei API-Calls, um das H1 zu finden, ist die Seite fragil, auch wenn sie am Ende indexiert wird.

Screaming Frog, Sitebulb, Google Search Console, Chrome DevTools, Rich-Results-Test und Server-Logs helfen alle. Welches Tool du nutzt, ist weniger wichtig als der Vergleich: Was existiert bei der ersten Antwort, was erscheint nach dem Rendern, und was hat Google tatsächlich indexiert?

Hier brechen viele JavaScript-SEO-Audits zu früh ab. Sie beweisen, dass Google eine Seite rendern kann. Gut. Jetzt teste ungültige Routen, paginierte Routen, Canonical-Änderungen, Metadaten-Änderungen, API-Fehler, langsame Antworten und Non-Google-Crawler.

SPA-SEO-Best-Practice-Checkliste

Nutze diese Checkliste auf Routen-Ebene. Ein siteweites „Pass“ versteckt zu viele SPA-Fehler.

• Rendering: Öffentliche Seiten nutzen SSG, SSR oder ISR. Private Screens dürfen CSR verwenden.
• Routing: Jede indexierbare URL hat eine eigene Route, eigenen Inhalt und ein Self-Canonical.
• Statuscodes: Fehlende Seiten liefern 404 oder 410, nicht 200.
• Links: Interne Navigation nutzt crawlbare <a>-Tags mit echten hrefs.
• Metadaten: Titel, Descriptions, Canonicals, Robots-Tags, Open-Graph-Tags und Schema sind routespezifisch.
• Inhalt: Haupttext, H1, Produktinfos und wichtige Links existieren ohne Client-only-Daten.
• Performance: Bundle-Größe, Hydration-Kosten, Third-Party-Scripts und Route-Level-Code-Splitting sind im Griff.
• Index-Kontrolle: Dashboards, private Routen, schwache Filter und dünne Suchseiten sind blockiert oder noindexiert.
• Testing: Initiales HTML, gerenderter DOM und indexierter Content werden auf wichtigen Templates verglichen.
• KI-Sichtbarkeit: Wichtiger Inhalt steht im HTML, weil viele KI-Crawler kein JavaScript rendern.

„Wird etwas nicht gecrawlt, kann es in keiner Suche auftauchen. Egal auf welcher Oberfläche.“

Jamie Indigo, Technical SEO Consultant bei Not a Robot

Dieser Satz ist die ganze Checkliste in einem Satz. Suche, KI-Antworten, Link-Previews und Discovery-Systeme brauchen zuerst Zugang. Rankings kommen später.

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

Würde ich heute eine moderne SPA mit Suchtraffic bauen, würde ich nicht das ganze Produkt serverrendern. Ich würde es splitten.

Genau so würde ich es auf seojuice.io aufteilen. Marketing-Pages und Artikel müssen HTML-first sein. Produktflächen, die Aktualität brauchen, können SSR oder ISR nutzen. Das Dashboard darf App-like bleiben, weil ein Ranking sinnlos wäre.

Programmatic-SEO-Seiten brauchen besondere Disziplin. Static Generation macht es einfach, tausende Seiten zu erzeugen – auch tausende, die niemand indexieren sollte. Generiere nur Seiten mit echter Suchnachfrage, nützlichem Inhalt und internen Links. Dünne Seiten vorher ausmisten, statt Google entscheiden zu lassen.

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

FAQ

Kann eine Single-Page-Application bei Google ranken?

Ja. Eine SPA kann ranken, wenn indexierbare Routen crawlbaren Inhalt, korrekte Metadaten, interne Links und gültige Statuscodes liefern. Google kann JavaScript rendern, aber sich auf Rendering für alles zu verlassen, macht die Site fragiler.

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

Nein, nicht für jede Route. SSR ist nützlich für öffentliche Seiten mit wechselnden Inhalten. SSG oder ISR ist oft besser für stabilen Content. CSR reicht für private Dashboards, Account-Screens und App-States, die nicht indexiert werden sollen.

Sind Hash-Routen schlecht für SEO?

Hash-Routen sind für indexierbare Seiten eine schlechte Wahl. Für On-Page-Fragmente funktionieren sie, aber öffentliches Content braucht saubere URLs, routespezifische Metadaten und Statuscodes auf Server-Ebene.

Sollten SPA-Suchergebnis-Seiten indexiert werden?

Meist nein. Interne Such- und Facettenseiten erzeugen oft dünne oder doppelte URLs. Kuratierte Filterseiten können indexiert werden, wenn sie eigene Nachfrage, stabilen Inhalt und eine klare Canonical-Strategie haben.

Wie erkenne ich, ob meine SPA ein Soft-404-Problem hat?

Rufe eine Fake-URL auf und prüfe den Statuscode. Liefert /this-page-should-not-exist 200 und nur eine clientseitige Not-Found-Meldung, besteht Soft-404-Risiko.

Brauchst du Hilfe, deine SPA in crawlbare Seiten zu verwandeln?

SEOJuice hilft Teams, crawlbare interne Links über die öffentlichen Seiten hinweg zu stärken, die wirklich Suchtraffic verdienen. Hat deine SPA verwaiste Routen, versteckte Templates oder Seiten, die Google nie erreicht, kann automatisierte interne Verlinkung die Dokumentenebene für Crawler zugänglicher machen.