JavaScript SEO: Rendering, Indexierung & KI-Suche

JavaScript SEO ist die Lücke zwischen dem, was dein Framework rendert, und dem, was ein Crawler tatsächlich sieht. Manchmal ist die Lücke null — eine serverseitig gerenderte Next.js-Seite shippt vollständiges HTML, jedes Wort von Googlebot indexiert, jedes Wort von ChatGPT gelesen. Manchmal ist die Lücke alles — eine clientseitige React-SPA shippt ein leeres <div id="root"> und vier Megabyte JavaScript, und der KI-Crawler, der gerade vorbeigeschaut hat, hat nichts extrahiert. 2026 ist der Preis für ein falsches Setup höher denn je, weil es jetzt zwei verschiedene Crawler-Klassen mit komplett unterschiedlichem Render-Verhalten gibt. Ich habe Lumina's JS vs No-JS Tool auf die 12 Top-Guides für javascript seo auf Google EN und DE losgelassen, und das Muster ist trostlos: null shippen FAQPage-Schema, vier lehren Dynamic Rendering weiterhin als aktuellen Render-Modus ohne Hinweis auf Googles Position (Googles eigene Doku nennt es “eine Notlösung und keine Langzeit-Lösung”), und Onelys “Ultimate Guide” — aktuell Rang 7 auf Google US — hat seinen dateModified seit März 2020 nicht angefasst.

Dieser Leitfaden ist die vollständige Evergreen-Referenz. Was JavaScript SEO ist, wie Googles dreiphasige Render-Pipeline tatsächlich funktioniert, die vier Render-Modi und welcher 2026 zu wählen ist, die sieben Probleme, die in Production die meisten Fehler verursachen, die neuen und weitgehend ungeschriebenen Regeln für KI-Crawler-Sichtbarkeit, Framework-für-Framework-Patterns für Next.js / Nuxt / SvelteKit / Astro / Remix, wie man es testet und warum Dynamic Rendering von der Shortlist runter sollte. Kein Filler. Code, wo es zählt. Wenn du deine eigene Seite parallel testen willst, öffne Lumina's JS vs No-JS Tool in einem zweiten Tab.

Was JavaScript SEO wirklich ist

Bei JavaScript SEO geht es darum sicherzustellen, dass Suchmaschinen und KI-Crawler den Inhalt lesen können, den JavaScript zu einer Seite hinzufügt. Jede moderne Website hat zwei HTML-Versionen: das rohe HTML, das der Server ausliefert, und das gerenderte HTML, nachdem jedes Skript gelaufen ist. JavaScript SEO heißt: die Differenz zwischen den beiden im Griff zu haben — denn nicht jeder Crawler überbrückt sie.

Du kannst beide selbst sehen. Das rohe HTML steht im Browser unter view-source:. Das gerenderte HTML lebt im Elements-Panel der DevTools. Die Disziplin von JavaScript SEO besteht darin, beide nahe genug aneinander zu halten, dass jeder Crawler — Googlebot, GPTBot, ClaudeBot — dasselbe sieht wie ein menschlicher Nutzer.

Bei einer statischen HTML-Seite ohne JavaScript ist die Differenz null. Beide HTML-Versionen sind identisch, jeder Crawler liest denselben Inhalt. Bei einer Seite, die mit React, Vue oder Angular gebaut und als clientseitige SPA ausgeliefert wird, ist die Differenz dagegen alles: Das rohe HTML ist eine fast leere Hülle, der sichtbare Inhalt erscheint erst, sobald das JavaScript-Bundle im Browser läuft. Die meisten realen Websites liegen irgendwo dazwischen — ein serverseitig gerendertes Framework, das den Hauptinhalt als statisches HTML ausliefert und JavaScript nur für Interaktivität nutzt.

Der Grund, warum das 2026 zählt, ist, dass Crawler in zwei Klassen mit sehr unterschiedlichem Verhalten zerfallen. Googlebot nutzt ein Headless Chromium und rendert JavaScript zuverlässig (mit Einschränkungen, dazu unten). Die neue Generation der KI-Crawler — GPTBot von OpenAI, ClaudeBot von Anthropic, PerplexityBot, Googles eigener Google-Extended für Gemini-Training — holen rohes HTML und gehen weiter. Sie führen kein JavaScript aus. Sie warten nicht auf Hydration. Sie versuchen es nicht erneut. Die CSR-Seite, die bei Google gut rankt, kann für ChatGPT unsichtbar sein.

Wie Google JavaScript rendert: die Zwei-Wellen-Realität

Google handhabt JavaScript in drei sequenziellen Phasen: Crawling, Rendering, Indexierung. Seiten mit Status 200 landen nach dem initialen Crawl in einer Render-Queue, in der ein Headless Chromium das JavaScript ausführt und das gerenderte HTML zurück in die Indexierung schickt. Die meisten JavaScript-SEO-Probleme leben in der Lücke zwischen diesen Phasen, weil Rendering weder sofort noch garantiert ist.

Phase 1 — Crawling. Googlebot holt die URL und liest die rohe HTML-Antwort. Status-Code, Response-Header, alles im Head, alles im Body, das existiert, bevor irgendein Skript läuft. Das ist die Version, die auch KI-Crawler sehen.

Phase 2 — Rendering. Seiten, die einen 200-Status zurückgegeben haben (und nicht durch Robots-Meta-Tags blockiert sind), landen in einer Render-Queue. Wenn Googles Ressourcen es zulassen, führt ein Headless Chromium die Seite aus, läuft das JavaScript, baut das gerenderte DOM. Googles Doku sagt, die Queue kann “wenige Sekunden” dauern, “kann aber länger dauern”. Es gibt kein SLA. Rendering konkurriert mit Crawl-Budget, mit anderen Render-Jobs, mit Googles eigener Infrastruktur-Last.

Phase 3 — Indexierung. Sobald das Rendering fertig ist, nimmt Google das gerenderte HTML und lässt seine Indexierungs-Pipeline darauf laufen. Title, Meta-Description, Headings, Links, Strukturierte Daten, Inhalt. Alles, was JavaScript hinzugefügt hat, wird für das Ranking verfügbar.

Das, was jeder SEO-Autor seit Jahren wiederholt — “Googles zweite Indexierungswelle kann Tage oder Wochen dauern” — war 2018 wahr, als Martin Splitt das System erstmals öffentlich beschrieb. Heute ist es nuancierter. Bei den meisten Seiten passiert Rendering Sekunden nach dem initialen Crawl. Bei sehr großen Sites mit schwerem JavaScript oder bei Sites, denen Google nicht viel Render-Budget gibt, kann sich die Queue ziehen. Das Risiko ist gesunken; es ist nicht null. Seiten, die komplett von JavaScript abhängen, werden langsamer indexiert als Seiten, die vollständiges HTML ausliefern, und die Indexierung neu hinzugefügter oder geänderter Inhalte hinkt hinterher. Wenn du auf einer CSR-Site einen heißen Beitrag veröffentlichst, könnte er zehn Minuten später ranken oder erst morgen.

SSR, CSR, Static, Hybrid: wähle einen

Moderne Frameworks unterstützen fünf unterschiedliche Render-Modi: server-side (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR), client-side (CSR) und Hybrid. Die Wahl, die du hier triffst, ist die größte Entscheidung für JavaScript SEO. Vier der fünf sind sicher für öffentliche Seiten; einer ist eine Falle, die KI-Sichtbarkeit komplett bricht.

Server-Side Rendering (SSR)

Der Server führt das Framework aus, generiert das vollständige HTML für die angeforderte URL und sendet dieses HTML an den Client. Der Browser zeigt die gerenderte Seite sofort, danach hydriert ein JavaScript-Bundle sie für Interaktivität. Crawler, die rohes HTML lesen, sehen die komplette Seite. Next.js mit getServerSideProps oder dem App-Router-Default, Nuxt 3 mit Universal Mode, Remix, SvelteKit mit serverseitigen Load-Funktionen, Angular Universal — alle SSR. Das ist die sicherste Wahl für SEO. Kosten: du zahlst Compute pro Request.

Static Site Generation (SSG)

Das Framework rendert jede Seite zur Build-Zeit vor und produziert statische HTML-Dateien, die vom CDN ausgeliefert werden. Kein Per-Request-Compute, keine Render-Verzögerung, kein Risiko von Server-Ausfällen auf indexierungs-kritischen Seiten. Astro per Default, Next.js mit getStaticProps, Gatsby, Hugo, 11ty, Lumina selbst. Das ist die schnellste Option für SEO und die billigste zum Hosten. Kosten: jede Inhalts-Änderung braucht einen Rebuild und Deploy. Nicht praktikabel für Sites mit Millionen dynamischer URLs.

Incremental Static Regeneration (ISR)

SSG mit Cache-Revalidierungs-Policy. Jede URL wird beim ersten Request statisch generiert, dann aus dem Cache ausgeliefert, dann im Hintergrund regeneriert, wenn ein Revalidierungs-Timer abläuft. Kombiniert SSGs Performance mit der Fähigkeit, sehr große URL-Räume zu handhaben. Next.js, Nuxt 3 und Astro unterstützen es. Exzellentes SEO-Verhalten — Crawler bekommen immer Cache-HTML, treffen nie einen langsamen First-Render-Pfad.

Client-Side Rendering (CSR)

Der Server gibt eine fast leere HTML-Hülle mit einem Script-Tag zurück. Der Browser lädt das JavaScript-Bundle, führt es aus, baut das DOM, holt Daten von APIs, rendert den Inhalt. Das macht plain Create React App, Vite + React ohne SSR-Schicht und die meisten älteren Vue- oder Angular-SPAs. Vermeide es für jede öffentliche Seite, die ranken soll. Googlebot kann es rendern, aber mit Verzögerung und Risiko; KI-Crawler können es überhaupt nicht rendern.

Hybrid (Modus-Wahl pro Route)

Das Framework entscheidet pro Route, welchen Modus zu verwenden. Öffentliche Marketing-Seiten und Blog-Posts bekommen SSG oder SSR; das authentifizierte Dashboard bekommt CSR. Next.js App Router behandelt das als Default-Modell. Astros “Islands”-Architektur geht weiter — der Großteil der Seite ist statisch, mit kleinen JavaScript-hydrierten Regionen dort, wo sie gebraucht werden. Hybrid ist das, was fast jede moderne Site fahren sollte.

Die 7 häufigsten JavaScript-SEO-Probleme

Jede Site, die ich in den letzten zwei Jahren auditiert habe und die Ranking-Probleme durch JavaScript hatte, fiel in eines von sieben wiederkehrenden Mustern. Sechs sind in einem Nachmittag fixbar — durch eine Markup- oder Routing-Anpassung. Eines erfordert Re-Architektur der Render-Pipeline. Keines davon ist subtil, sobald du weißt, wonach du im rohen HTML suchen musst.

1. Kritischer Inhalt erst nach Hydration gerendert. Der Server gibt eine leere Hülle zurück. Title und Meta-Tags existieren (gut), aber H1, Body-Text und Hauptnavigation erscheinen erst, wenn React hydriert. In View Source: nichts. Im gerenderten DOM: alles. Googlebot wird das wahrscheinlich irgendwann rendern; KI-Crawler sehen nichts. Der Fix: Route auf SSR oder SSG umstellen. Wenn die ganze Stack-Migration nicht machbar ist, das Critical-Path-HTML serverseitig hand-rendern und JavaScript für Interaktivität übernehmen lassen.

2. Interne Links als <div onclick> statt <a href> gerendert. Ein erstaunlich häufiges Muster in React-Apps. Das Element sieht aus wie ein Link, verhält sich für Menschen wie ein Link, aber ein Crawler ohne JavaScript sieht ein Div ohne Ziel. Selbst Googlebots Renderer kann diese verpassen, weil sie kein synthetisches Navigations-Event feuern, an das der Crawler hookt. Verwende echte <a>-Tags mit echten href-Attributen für jede interne Navigation. React Routers <Link> rendert per Default ein <a>; benutze es.

3. Lazy-loaded Inhalt durch Intersection Observers gegated. Der Renderer scrollt nicht. Inhalt, der nur lädt, wenn der Nutzer in den Sichtbereich scrollt, lädt nie für den Headless-Renderer. Image-Lazy-Loading via loading="lazy" ist okay — Googlebot handhabt das. Custom-JavaScript, das IntersectionObserver nutzt, um Text, Kommentar-Threads oder Produkt-Varianten zu laden, ist nicht okay. Verschiebe diesen Inhalt in das initiale Render oder in eine click-getriggerte Expansion.

4. noscript-Fallbacks, die lügen. Das Muster: echter Inhalt im JavaScript, eine reduzierte “Bitte JavaScript aktivieren”-Nachricht in <noscript>. Crawler sehen das Noscript und den JavaScript-gerenderten Inhalt. Die beiden divergieren über die Zeit. Entweder shippe vollen Inhalt im Noscript-Fallback (das macht den SPA-Zweck zunichte) oder entferne den Noscript-Block ganz und nutze stattdessen SSR. Die Halb-Lösung ist die schlechteste Option.

5. Hash-Fragment-Routing. Single-Page-Apps, die #/page-URLs statt PushState-Routing verwenden. Das Fragment wird nie an den Server gesendet, also kann der Server keinen unterschiedlichen Inhalt pro Route rendern, und Crawler indexieren es nicht als separate Seite. Migriere zu History-API-Routing mit serverseitigem Fallback, der das richtige HTML pro Pfad zurückgibt.

6. Redirects in JavaScript implementiert. Die Seite gibt einen 200-Status mit einem window.location = '/new-url' in einem Script-Tag zurück. Browser folgen dem Redirect; Crawler vielleicht nicht. Selbst Googlebot bevorzugt HTTP 301/302 Redirects, weil sie das Canonical-Signal sauber erhalten. KI-Crawler folgen JavaScript-Redirects definitiv nicht. Nutze serverseitige Redirects, wo immer möglich.

7. Schwere Hydration, die Interaktivität über Googles Render-Budget hinaus verzögert. Die Seite rendert irgendwann sauber, aber das JavaScript-Bundle ist so groß, dass die Hydration 8 oder 10 Sekunden dauert. Googlebots Renderer könnte die Seite in einem Teilzustand erfassen und nur das indexieren, was vor Ende seines Budgets gerendert war. Der Fix ist derselbe wie bei Core Web Vitals: Code-Splitting, Lazy-Loading von nicht-kritischem JavaScript, weniger ausliefern. Lumina's Core Web Vitals Leitfaden deckt die praktischen Patterns für Bundle-Größe ab.

JavaScript SEO und KI-Crawler: das 2026er Frontier

KI-Crawler führen JavaScript nicht aus. GPTBot, ClaudeBot, PerplexityBot und Google-Extended holen alle rohes HTML und gehen weiter — kein Headless Browser, keine Render-Queue, kein Retry. Das ist die neue Einschränkung, über die im SERP für JavaScript SEO niemand schreibt, und sie hat die Kalkulation von Client-Side Rendering stärker verändert als irgendein Google-Update der letzten fünf Jahre.

Die neue Crawler-Generation — OpenAIs GPTBot, Anthropics ClaudeBot, PerplexityBot, Googles Google-Extended (für Gemini-Training, separat vom Googlebot, der für die Suche genutzt wird) — führen kein JavaScript aus. Sie schicken einen GET-Request, lesen die rohe HTML-Antwort, extrahieren, was sie finden, und gehen weiter. Kein Headless Browser. Keine Render-Queue. Kein Retry. Wenn dein Inhalt in einem JavaScript-Bundle steckt, das clientseitig hydriert, sieht jede KI-Suchmaschine eine leere Hülle.

Die Traffic-Zahlen machen das konkret. Vercels Netzwerkdaten, Anfang 2025 veröffentlicht, zeigten GPTBot mit 569 Millionen Requests pro Monat über die Plattform und ClaudeBot mit 370 Millionen. Beide Bots lesen statisches HTML bei jedem dieser Requests. Eine Site, die von Client-Side-Rendering abhängt, gibt diesen Crawlern nichts — keine Produkt-Beschreibungen, keine FAQ-Antworten, keine Vergleichstabellen, keine Review-Zitate. Die Seite erscheint im Request-Log des Crawlers; der Inhalt erscheint nicht in der Trainings- oder Retrieval-Pipeline des Modells.

Das zählt, weil das KI-Such-Interface jetzt einen relevanten Anteil daran hat, wie Menschen Informationen finden. ChatGPT Search, Claude mit Web-Zugriff, Perplexity, Geminis grounded Antworten, Google AI Overviews — alle ziehen aus dem offenen Web in Echtzeit, und alle ziehen aus der rohen HTML-Version deiner Site. Der Blue-Link-Traffic von einem Google-Ranking existiert weiter und zählt weiter. Der KI-Citation-Traffic ist neu, wächst schnell und hängt komplett davon ab, ob dein Inhalt im rohen HTML steht.

Der Fix-Pfad ist derselbe, den Google seit Jahren empfiehlt: Server-Side Rendering oder Static Rendering. Der Unterschied ist, dass sich die Cost-Benefit-Analyse verschoben hat. CSR war immer ein Google-Indexierungs-Risiko; 2026 ist es zusätzlich ein KI-Sichtbarkeits-Aussterbe-Event. Die gleiche architektonische Änderung schützt beides.

Framework-Cheat-Sheet: Next.js, Nuxt, SvelteKit, Astro, Remix

Jedes moderne JavaScript-Framework unterstützt einen Render-Modus, der für SEO sicher ist. Die Defaults variieren, die API-Namen variieren, die Ergonomie variiert. Was folgt, ist eine kurze Referenz: in welchem Modus jedes Framework standardmäßig läuft, welche Konfigurations-Switches für SEO zählen, und der größte Fehler, den du in jedem einzelnen vermeiden solltest.

Next.js

App Router (Next 13+) defaulted auf Server-Components und Server-Side Rendering. Eine Seite ist serverseitig gerendert, außer du markierst sie explizit als Client-only mit der 'use client'-Direktive. Für statische Generierung exportierst du eine generateStaticParams-Funktion. Für ISR setzt du export const revalidate = 60 (Sekunden). Der Pages Router funktioniert weiter und nutzt getStaticProps / getServerSideProps / getStaticPaths. Beide Router shippen vollständiges HTML an Crawler, wenn korrekt konfiguriert. Der Fehler, den es zu vermeiden gilt: die ganze App als 'use client' markieren und Next versehentlich in ein CSR-Framework verwandeln. Audite, welche Komponenten tatsächlich Client-Interaktivität brauchen.

Nuxt 3

Universal Mode (der Default) ist SSR. nuxt build produziert einen Node-Server, der Seiten on-demand rendert. nuxt generate rendert alle Routen für statisches Deployment vor. Hybrid-Rendering via routeRules-Config in nuxt.config.ts erlaubt dir, SSR, SSG, ISR und SPA-Mode pro Route zu mischen. Der Fehler, den es zu vermeiden gilt: global auf spa-Mode wechseln, weil clientseitige Auth-Flows einfacher waren — das macht die ganze Site CSR.

SvelteKit

Server-Side Rendering per Default. +page.server.ts läuft serverseitig, +page.ts läuft in beiden Kontexten. Statische Generierung via @sveltejs/adapter-static-Adapter. SvelteKits Server-First-Design macht es schwer, versehentlich eine CSR-only Seite auszuliefern, was teilweise erklärt, warum es bei SEO-Benchmarks über seinem Gewicht punktet.

Astro

Null JavaScript per Default. Jede .astro-Datei rendert zu statischem HTML vor. Interaktivität ist Opt-in via dem „Islands“-Modell — drop eine React-, Vue-, Svelte- oder Solid-Komponente mit einer client:load- oder client:visible-Direktive ein, und nur diese Insel shippt JavaScript. Der stärkste Framework-Default, den ich für Content-Sites mit SEO als Hauptanforderung gesehen habe. Lumina selbst ist plain HTML, nicht Astro, aber Astro ist das Framework, das ich am häufigsten empfehle, wenn ein Team auf einer Marketing- oder Content-Site frisch startet.

Remix

Server-Side Rendering mit Progressive Enhancement als Design-Philosophie. Jede Route shippt vollständiges HTML. Forms funktionieren ohne JavaScript per Default. Loaders laufen serverseitig. Remix' mentales Modell ist von allen modernen Frameworks am nächsten am ursprünglichen „Web-Plattform“-Modell, was es zur natürlichen Wahl für SEO-kritische Arbeit macht. Der Haken: es ist weniger populär als Next.js, also ist der Pool an SEO-bewussten Libraries und Tutorials kleiner.

Was du vermeiden solltest

Pures Client-Side React mit Vite, Create React App (Legacy, aber noch in Nutzung), Vue-2-SPAs ohne Nuxt, Angular ohne Universal, jedes Pre-2018-SPA-Setup ohne SSR- oder Static-Pfad. Diese alle shippen leere Hüllen. Sie sind okay für authentifizierte Dashboards. Sie sind nicht okay für jede Seite, die du indexiert oder zitiert haben willst.

Wie du JavaScript SEO testest

Drei Checks decken die meisten JavaScript-SEO-Fehler ab: ein Source-vs-Rendered-Diff im Browser, eine URL-Inspection in der Search Console um zu sehen was Googlebot wirklich gerendert hat, und eine curl-Simulation als GPTBot oder ClaudeBot um zu bestätigen was KI-Crawler tatsächlich sehen. Lass alle drei auf jeder öffentlichen Seite laufen, die wichtig ist, bevor du einen JavaScript-Stack als SEO-ready deklarierst.

1. Source-vs-rendered Diff. Öffne die Seite, drücke Strg-U (Cmd-U auf Mac), um das rohe HTML zu sehen. Dann öffne das Elements-Panel der DevTools, um das gerenderte DOM zu sehen. Die beiden sollten sich für jede Seite, die du indexiert haben willst, stark überlappen. Wenn das rohe HTML deinen H1, deinen Body-Text oder deine interne Navigation vermisst, fällt die Seite durch den Basis-Test für KI-Crawler und ist bei Google im Risiko. Lumina's JS vs No-JS Tool automatisiert das — paste eine URL, bekomme den rohen Word-Count, den gerenderten Word-Count und einen Wort-für-Wort-Diff dessen, was JavaScript hinzugefügt hat.

2. Google Search Console URL Inspection. In der GSC paste die URL in die Inspection-Bar oben, klick „Live-URL testen“, dann „Getestete Seite ansehen“ → „HTML“-Tab. Das ist, was Googlebot tatsächlich gerendert hat, mit den Ressourcen, die Google bereit war, auf deine Seite zu verwenden. Vergleiche mit deiner lokalen DevTools-Sicht. Unterschiede sind Signal: Skripte, die durch robots.txt blockiert sind, Fonts, die nicht geladen haben, Third-Party-SDKs, die getimeoutet sind, lazy-loaded Inhalt, den der Renderer nicht erreicht hat.

3. KI-Crawler-Simulation. Nutze curl -A "GPTBot/1.0" https://deine-seite.de/seite, um als GPTBot abzuholen. Inspiziere die Response. Das ist genau, was OpenAIs Trainings- und Retrieval-Pipeline gesehen hat. Wenn die Response eine leere Hülle ist, ist deine KI-Sichtbarkeit auf dieser Seite null, egal wie Google rankt. Mach dasselbe mit curl -A "ClaudeBot" für Anthropic.

Drei Tools zusätzlich zu den Basics:

• Lumina JS vs No-JS. Kostenlos. Paste eine URL, sieh roh-vs-gerenderte Word-Counts, Framework-Detection, Schema-Sichtbarkeits-Vergleich, KI-Crawler-Readiness-Verdict. Speziell für diese Audit-Klasse gebaut.
• Lumina Crawler Access Checker. Testet deine robots.txt gegen 36 Such- und KI-Crawler inklusive GPTBot, ClaudeBot, PerplexityBot, Google-Extended. Bestätigt, ob der Bot überhaupt holen darf — ein überraschend häufiges Eigentor.
• Google Rich Results Test. Berichtet, ob deine strukturierten Daten korrekt rendern, nachdem JavaScript läuft. Funktioniert auf URLs und auf gepasteten HTML-Snippets. Kostenlos, kein Signup, läuft in Sekunden.

Für Sites mit Hunderten oder Tausenden Templates zählt Batch-Testing. Lumina's Tools unterstützen Bulk-URL-Input beim JS vs No-JS Tool, und der Output exportiert als CSV zum Sortieren nach Render-Gap-Prozent.

Dynamic Rendering: warum es 2026 nicht die Antwort ist

Dynamic Rendering ist die Notlösung, bei der du Crawlern anderes HTML servierst als Nutzern — der Nutzer bekommt die JavaScript-App, der Crawler eine vorgerenderte Version von Prerender.io oder Rendertron. Es funktioniert noch. Google erlaubt es noch. Drei konkrete Gründe, warum es 2026 für eine neue Site nicht deine Wahl sein sollte.

Es funktioniert. Google sagt das. Vier der zwölf Guides im SERP für javascript seo lehren es noch als aktuellen Render-Modus ohne klaren Hinweis auf Googles Position. Es gibt drei Gründe, warum ich es 2026 nicht empfehle, und die Diskrepanz mit dem SERP ist Teil davon.

Google rät explizit ab. Die offizielle Doku beschreibt Dynamic Rendering jetzt als „eine Notlösung und keine Langzeit-Lösung für Probleme mit JavaScript-generiertem Inhalt in Suchmaschinen“. Der empfohlene Pfad ist Server-Side Rendering, Static Rendering oder Hydration. Google hat es nicht formal abgeschafft — Seiten mit Dynamic Rendering werden noch gecrawlt — aber die Schrift an der Wand ist klar für jede neue Site.

Es verdoppelt deine Wartungsfläche. Du shippst zwei Versionen jeder Seite: die JavaScript-SPA für Nutzer und das vorgerenderte HTML für Bots. Inhalts-Änderungen müssen durch beide propagieren. Cache-Invalidierung muss über beide koordinieren. Bugs in einer Version erscheinen nicht in der anderen, bis sie es tun, und die Version, die dein Team zum QA nutzt, ist nicht die Version, die Googlebot liest. Die Anzahl an „Wir haben drei Wochen lang einen Bug an Google ausgespielt, aber nicht an Nutzer“-Stories ist groß.

KI-Crawler sehen, was du User-Agents zeigst. Der User-Agent-Split, auf den sich Dynamic Rendering für Googlebot verlässt, kann für GPTBot, ClaudeBot etc. konfiguriert werden — aber die meisten existierenden Dynamic-Rendering-Setups nehmen die KI-Bots nicht in ihre Crawler-Liste auf. Resultat: KI-Crawler fallen auf den User-Agent-Pfad und sehen die leere SPA-Hülle. Du hast für eine Notlösung gezahlt, die das gestrige Problem löst, nicht das heutige. Die Site auf SSR oder statisch zu migrieren hätte beides auf einmal gelöst.

Wenn du ein Dynamic-Rendering-Setup hast, das heute läuft und funktioniert, reiß es nicht morgen raus. Es ist okay, es laufen zu lassen. Aber wenn dein Team das nächste Mal einen Stack für eine neue Site wählt, greif nicht danach.

FAQ

Wo du anfängst

Fünf Schritte, in dieser Reihenfolge. Weniger als 90 Minuten Arbeit für eine kleine Site, zwei bis drei Stunden für eine mittlere. Beginne damit, die Render-Lücke auf deinen wichtigsten Seiten zu messen, dann migriere öffentliche Routen weg von reinem CSR, fixe die stillen Killer-Bugs, die niemand bemerkt, bestätige dass KI-Crawler dich überhaupt holen können, und validiere vor jedem Deploy.