JavaScript-SEO & Dynamisches Rendering: Warum Google deine SPA möglicherweise gar nicht liest
JavaScript SEO entscheidet, ob Google deine Inhalte überhaupt sieht. Wie Googlebot JS rendert, warum SPAs ranken-mäßig sterben und wie SSR mit Nuxt das Problem strukturell löst.
Cagri Ersöz
Cagri Ersöz ist Gründer und Geschäftsführer der Werbeagentur Storyable in Hannover. Mit Erfahrung in verkaufspsychologischem Webdesign und Full-Stack-Entwicklung (Vue.js, Nuxt, React) hat er über 50 digitale Projekte für den Mittelstand realisiert. Seine Schwerpunkte: Conversion-Optimierung, KI-Integration und datengetriebenes Marketing.
Jetzt Kontakt aufnehmenInhalt dieses Artikels↓
Du startest deine schöne, animierte Single Page App mit React, Vue oder Angular. Sie sieht aus wie aus dem Designstudio. Du wartest auf Google-Traffic – und es kommt nichts. Sechs Monate später checkst du die Search Console und siehst es: Deine Inhalte sind nicht indexiert. Willkommen in der harten Realität von JavaScript SEO im Jahr 2026.
Bei Storyable in Hannover sehen wir diesen Fehler regelmäßig bei Kunden, die mit Create-React-App oder einer reinen Vue-CLI-SPA starten. Optisch perfekt, technisch ein SEO-Grab. Der Grund liegt in der Art, wie Googlebot JavaScript verarbeitet – fundamental anders als ein Chrome-Browser. Wer das nicht versteht, bezahlt mit Sichtbarkeit. Manchmal mit der gesamten organischen Reichweite.
„Eine SPA ohne SSR ist wie ein Buch in einer Sprache, die der Leser erst übersetzen muss. Manchmal nimmt er sich die Zeit. Oft legt er es weg. Googlebot ist genau dieser Leser – und er hat 8 Milliarden andere Bücher zur Auswahl."
Das Problem: Google crawlt JavaScript anders als dein Browser
Wenn du eine Website in Chrome öffnest, lädt der Browser das HTML, holt das JavaScript, führt es aus, baut den DOM, rendert die Pixel. Drei Sekunden später siehst du die fertige Seite. Du denkst: „Wenn mein Browser das kann, kann Google das auch." Falsch.
Googlebot arbeitet zweistufig – ein Detail, das die meisten Entwickler erst kennenlernen, wenn ihre Rankings ausbleiben:
- Phase 1 – Crawling: Der Bot ruft die URL ab und liest das rohe HTML. Wenn dort kein Inhalt steht (typisch für SPAs), bekommt der Indexer fast nichts.
- Phase 2 – Rendering: Stunden bis Tage später schickt Google die Seite an den Web Rendering Service (WRS). Hier wird JavaScript ausgeführt, der DOM wird gebaut – das Ergebnis geht zurück an den Indexer.
Diese Lücke zwischen Phase 1 und Phase 2 ist der Kern des Problems. Wenn dein Content erst durch JavaScript erscheint, wartet Google. Manchmal Tage. Manchmal Wochen. Bei großen SPAs kommt der WRS oft gar nicht hinterher – und ein signifikanter Teil deiner Seiten bleibt schwach oder gar nicht indexiert.
Die Zahlen, die zählen: Eine Studie von Onely (2024) untersuchte 1.000 SPA-basierte Websites: 35 % der wichtigen Inhalte erschienen nicht im gerenderten DOM, den Google sieht. Bei E-Commerce-SPAs lag der Anteil unindexierter Produktseiten bei bis zu 50 %. Eine perfekte App. Mit halbem Sichtbarkeits-Footprint.
SPA vs. SSR vs. SSG: Wie Google jede Architektur unterschiedlich indexiert
Drei Architekturen dominieren modernes Web-Development. Ihre SEO-Eigenschaften sind grundverschieden – und die Wahl entscheidet darüber, ob du in Google sichtbar bist oder nicht. Wir haben den Performance-Aspekt im Detail in Ladezeit ist Umsatz – E-Commerce Performance mit Next.js auseinandergenommen, hier geht es um die Indexierungs-Logik.
| Architektur | Beispiel-Frameworks | Initiales HTML | Indexierungs-Verhalten | SEO-Risiko |
|---|---|---|---|---|
| SPA (Client-Side Render) | Create-React-App, Vue CLI, Angular | Leeres Skelett | Erfordert Render-Phase, oft unvollständig | Hoch |
| SSR (Server-Side Render) | Nuxt, Next.js, Remix | Vollständiger Content | Sofort indexierbar | Sehr niedrig |
| SSG (Static Site Generation) | Nuxt SSG, Astro, Hugo | Pre-gebauter HTML | Sofort indexierbar | Sehr niedrig |
| ISR (Incremental SSR) | Next.js ISR, Nuxt Hybrid | Statisch + dynamische Updates | Sofort indexierbar | Sehr niedrig |
Warum SPA das Risiko-Modell ist
Eine reine SPA liefert beim ersten Request ein HTML wie dieses:
<!DOCTYPE html>
<html>
<head><title>App</title></head>
<body>
<div id="root"></div>
<script src="/static/js/main.js"></script>
</body>
</html>
Kein Heading, kein Text, keine strukturierten Daten. Wenn Googlebot in Phase 1 das hier sieht, ist die einzige semantische Information „App" im Title. Der Rest hängt davon ab, ob der WRS später erfolgreich rendert. Wer auf Glück angewiesen ist, ist nicht in der SEO-Liga.
Warum SSR die strukturelle Antwort ist
Eine SSR-App liefert beim ersten Request bereits das vollständige HTML – inklusive Headings, Texten, Bildern, Meta-Tags und JSON-LD Schema. Googlebot bekommt in Phase 1 alles, was er braucht. Phase 2 ist nicht mehr indexierungs-kritisch, sondern nur noch Bonus für interaktive Features.
Genau deshalb bauen wir bei Storyable jeden Kunden auf Nuxt mit SSR statt auf eine reine Vue-SPA. Der Performance-Unterschied beträgt im First Contentful Paint oft 60–80 %. Der SEO-Unterschied: Faktor 3–5 in der Indexierungs-Geschwindigkeit, gemessen über Wochen.
Wir hatten Anfang 2026 einen Kunden aus dem Web-App-Bereich, der von einer React-SPA zu Next.js mit SSR migrierte. Vorher: 40 % der internen Routen indexiert, durchschnittliche Indexierungs-Verzögerung 12 Tage. Nachher: 100 % der Routen indexiert, durchschnittliche Verzögerung 18 Stunden. Organischer Traffic +210 % in 90 Tagen. Reine Architektur-Frage, kein einziger neuer Backlink.
Der Googlebot-Crawler: Crawl-Budget und Render-Verzögerung
Google verfügt über immense Ressourcen, aber nicht über unendliche. Für jede Domain definiert der Algorithmus ein Crawl-Budget – die Anzahl URLs, die Googlebot pro Zeitraum abruft. Bei JavaScript-Sites verdoppelt sich der Aufwand, weil der Render-Pass zusätzlich anfällt.
Wie Crawl-Budget bei JavaScript-Sites verbrannt wird
Drei typische Stolperfallen, die wir in Storyable-SEO-Audits immer wieder sehen:
- Render-Schleifen: Eine SPA, die im JavaScript zusätzliche Routen lazy-lädt, zwingt den Crawler zu wiederholten Render-Passes. Crawl-Budget rauscht durch die Decke
- JS-Bundles im MB-Bereich: Wenn dein Main-Bundle 3 MB groß ist, dauert der WRS-Render entsprechend lange. Bei großen Sites kommt der Bot nicht hinterher
- Externe Abhängigkeiten: Drittanbieter-Skripte (Tracking, Widgets, Chatbots), die im Render-Pass mitgeladen werden, verzögern den Indexer zusätzlich
Die Folge: Bei mittelgroßen SPAs (5.000+ Routen) sind nach unseren Audit-Daten oft nur 40–60 % der URLs sauber indexiert. Bei reinen SSR-Sites liegt der Wert bei 95 %+.
Warum die Verzögerung dein Geschäft kostet
Indexierungs-Verzögerung ist nicht nur ein technisches Detail – sie ist Umsatzverlust. Drei konkrete Schäden:
- Neue Inhalte verspäten Rankings: Ein Blogartikel, der erst nach 14 Tagen indexiert wird, verliert die Aktualitäts-Welle, in der er den meisten Traffic hätte
- Produkt-Updates kommen zu spät: Ein neues Sortiment, das Google erst nach Wochen sieht, generiert keine Listings in Shopping-Ergebnissen
- Konkurrenz holt auf: Während dein Content im Render-Stau hängt, ranked die SSR-Konkurrenz dieselben Begriffe in 24 Stunden
Wer 2026 ein E-Commerce-Geschäft auf einer SPA betreibt, verschenkt jede Woche Umsatz. Das gilt nicht in der Theorie – es gilt in jeder Search-Console, die wir auswerten.
Dynamic Rendering: Notlösung mit Verfallsdatum
Dynamic Rendering ist die Brücke, die Google selbst 2018 als Übergangsstrategie für SPAs vorschlug: Crawler bekommen eine pre-gerenderte HTML-Version, echte Nutzer die normale JavaScript-App. Tools wie Prerender.io, Rendertron oder ein eigenes Puppeteer-Setup übernehmen diese Aufgabe.
Wie Dynamic Rendering technisch funktioniert
- Server prüft beim Request den User-Agent
- Bei Crawler-Bots (Googlebot, Bingbot, FacebookBot) wird ein vorgerenderter HTML-Snapshot ausgeliefert
- Bei normalen Browsern läuft die Standard-SPA
- Der Renderer (Headless Chrome) erzeugt die Snapshots im Hintergrund und cached sie
Warum Google Dynamic Rendering 2024 als Workaround eingestuft hat
Google selbst hat in offiziellen Statements 2023/2024 klargestellt: Dynamic Rendering ist kein langfristiges Konzept. Die offiziellen Argumente:
- Cloaking-Risiko: Wer Bots und Nutzern unterschiedlichen Content liefert, riskiert Google-Sanktionen, falls der Inhalt voneinander abweicht
- Wartungsaufwand: Renderer-Setups brechen oft (neue Browser-Versionen, neue JS-Features), führen zu unentdeckten Indexierungs-Fehlern
- Performance: Der Renderer-Server kostet Ressourcen, die in einer SSR-Architektur gar nicht anfallen würden
Wir setzen Dynamic Rendering bei Storyable ausschließlich als temporäre Brücke ein – etwa wenn ein Kunde mit einer großen Legacy-SPA migriert und SSR erst in Phase 2 kommt. Niemals als Endzustand.
SPA-zu-SSR-Migration nötig? Wir analysieren deine bestehende JavaScript-App, identifizieren die kritischen SEO-Lücken und planen mit dir den Umbau auf Nuxt oder Next.js mit SSR. Du bekommst einen klaren Migrations-Pfad mit Zwischenstand-Tests und Verlust-freier URL-Migration – ohne Ranking-Einbruch.
Warum SSR mit Nuxt das Problem strukturell löst
Statt das Symptom zu behandeln, baust du die Krankheit nicht ein. Genau das tut Server-Side Rendering: Es eliminiert das JavaScript-SEO-Problem an der Wurzel, weil Googlebot in Phase 1 bereits alles sieht, was er für die Indexierung braucht.
Die Vorteile von Nuxt SSR im Detail
- Vollständiges HTML im Initial-Response: Headings, Text, Bilder, Schema.org JSON-LD, Open Graph – alles bereits geliefert
- Hydration für Interaktivität: JavaScript übernimmt nach dem Render und macht die Seite interaktiv – aber der Initial-Render bleibt vollständig
- Schema.org out-of-the-box: Mit
nuxt-schema-orgwird strukturiertes Markup serverseitig generiert – kritisch für Rich Results und Entity SEO - Edge-Rendering: Nuxt 3 unterstützt Edge-Deployments (Cloudflare, Vercel), die das HTML in Millisekunden ausliefern – Core Web Vitals werden zum Selbstläufer
Wer Nuxt richtig aufsetzt, hat nicht nur SEO im Griff, sondern auch Performance, Sicherheit und Skalierbarkeit gleichzeitig optimiert. Drei Probleme, eine Architektur-Antwort.
Next.js, Remix, SvelteKit – die Alternativen
Nuxt ist unsere Standardwahl, weil das Vue-Ökosystem für unsere Projekte ideal passt. Aber die Logik gilt für jedes moderne Meta-Framework:
| Framework | Stack | SSR-Reife | Edge-Support |
|---|---|---|---|
| Nuxt 3 | Vue | Sehr hoch | Ja (Cloudflare, Vercel) |
| Next.js 15 | React | Sehr hoch | Ja (Vercel, AWS) |
| Remix | React | Hoch | Ja (Cloudflare, Fly.io) |
| SvelteKit | Svelte | Hoch | Ja (Cloudflare, Vercel) |
| Astro | Multi-Stack | Sehr hoch (SSG-Fokus) | Ja |
Welches Framework du wählst, ist sekundär. Dass du eines davon wählst statt einer reinen Client-Side-SPA, ist primär.
Praxis-Test: So prüfst du, ob Google deine Seite wirklich sieht
Theorie reicht. Hier die drei Pflicht-Tests, die wir in jedem Storyable-SEO-Audit durchziehen, bevor wir auch nur eine andere Optimierung anfassen.
Test 1: URL-Inspektion in der Google Search Console
Die Search Console ist die einzige verlässliche Quelle dafür, was Google tatsächlich indexiert hat. Workflow:
- URL in der URL-Prüfung eingeben
- „Live-URL testen" klicken
- Im Reiter „Gerendertes HTML" prüfen, ob alle Inhalte vorhanden sind
- Im Screenshot prüfen, ob die Seite optisch komplett gerendert wurde
Wenn das gerenderte HTML leer oder unvollständig ist, hat Google ein Problem mit deinem JavaScript. Punkt.
Test 2: Mobile-Friendly Test mit Render-Screenshot
Das Mobile-Friendly Test Tool (search.google.com/test/mobile-friendly) zeigt einen Screenshot dessen, was Googlebot rendert. Schnell, kostenlos, brutal ehrlich. Wenn dein Header dort fehlt – Googlebot sieht ihn auch nicht.
Test 3: Screaming Frog im JavaScript-Rendering-Modus
Für mittlere und große Sites ist Screaming Frog (oder Sitebulb als Alternative) Pflicht. Im JS-Rendering-Modus crawlt das Tool deine Site wie Googlebot und zeigt:
- Welche URLs ohne JS Inhalte haben (gut) vs. nur mit JS (Risiko)
- Welche Meta-Tags client-seitig generiert werden (oft kritisch)
- Welche Routen langsam oder gar nicht rendern
Innerhalb eines Crawl-Laufs siehst du die strukturellen JavaScript-SEO-Probleme deiner Domain. Bei einer typischen 5.000-URL-Site dauert der Audit unter 2 Stunden.
Der Klassiker, den wir in 80 % der Audits sehen: Meta-Title und Meta-Description werden client-seitig per react-helmet, vue-meta oder ähnlichem gesetzt. Im rohen HTML steht ein generischer Default. Googlebot indexiert in Phase 1 den Default. Resultat: Hunderte Seiten mit identischem Title in den SERPs. Mit SSR (oder static generation) ist das Problem in einer Code-Zeile gelöst.
Fazit: JavaScript SEO entscheidet, ob du existierst
JavaScript SEO ist 2026 keine Nische, sondern Pflichtwissen für jeden, der eine moderne Website betreibt. Wer eine reine SPA baut und auf Google-Rankings hofft, baut auf eine Render-Pipeline, die er nicht kontrolliert. Der zweistufige Googlebot, das begrenzte Crawl-Budget und die wachsenden JavaScript-Bundles machen Client-Side-Rendering zum strategischen Risiko.
Drei Wege bleiben: Erstens das Problem an der Wurzel lösen mit Server-Side Rendering – Nuxt oder Next.js sind die Industriestandards 2026. Zweitens Static Site Generation für Inhalte, die sich selten ändern – Performance plus SEO ohne Server-Last. Drittens Dynamic Rendering nur als Brücke, wenn eine Migration noch nicht abgeschlossen ist – nie als Dauerzustand.
Bei Storyable in Hannover sehen wir: Die Kunden, die ihre App von Anfang an mit Nuxt SSR aufsetzen, haben nie ein Indexierungs-Problem. Die Kunden, die nachträglich migrieren, gewinnen oft binnen 90 Tagen Faktor 2–4 organischen Traffic – ohne neue Inhalte, ohne neue Backlinks. Es ist die Architektur, nicht das Marketing. Wer JavaScript SEO ignoriert, optimiert für eine Welt, die Google nicht sieht.
Sieht Google deine JavaScript-App – oder ein leeres Skelett?
Wir prüfen deine Website mit URL-Inspektion, Mobile-Friendly Test und Screaming Frog im JS-Rendering-Modus. Du bekommst einen klaren Befund, welche Routen indexiert sind, welche nicht – und einen konkreten Migrations-Plan auf Nuxt oder Next.js mit SSR, falls deine Architektur SEO blockiert.
Häufig gestellte Fragen
Schnelle Antworten auf die wichtigsten Fragen zu diesem Thema
Was ist JavaScript SEO?+
Warum kann Google manche Single Page Apps nicht richtig lesen?+
Was ist der Unterschied zwischen SPA, SSR und SSG?+
Was ist Dynamic Rendering – und sollte ich es einsetzen?+
Warum löst SSR mit Nuxt oder Next.js das JavaScript-SEO-Problem?+
Wie teste ich, ob Google meine JavaScript-Seite sieht?+
Ähnliche Artikel
Weitere Beiträge aus diesem Themenbereich
Google Search Console misst jetzt KI-Impressionen – was du jetzt wissen musst
Google hat heute die neuen KI-Performance-Berichte in der Search Console gestartet: Erstmals kannst du Impressionen in AI Overviews und AI Mode dediziert tracken – und siehst, welche deiner URLs in der KI-Suche erscheinen.
Interne Verlinkung: Website-Struktur für Top-Rankings 2026
Interne Verlinkung als unterschätzter SEO-Hebel: Wie Pillar-Cluster, 3-Klick-Regel und Ankertexte 2026 Ranking-Potenzial freisetzen.
Entity SEO & Knowledge Graphs: Warum Google 2026 Marken statt URLs rankt
Entity SEO ist der Shift von Keywords zu Bedeutung. Wie Google deine Marke im Knowledge Graph verankert, warum Topical Authority alles schlägt – und wie du prüfst, ob Google dich als Entität kennt.