JavaScript SEO: Rendering, Indexierung & KI-Suche

Bei JavaScript SEO geht es um die Lücke zwischen dem, was dein Framework rendert, und dem, was ein Crawler tatsächlich bekommt. Manchmal ist die Lücke null: Eine serverseitig gerenderte Next.js-Seite liefert fertiges HTML, und jeder Crawler liest dieselben Wörter. Manchmal fehlt alles: Eine clientseitige React-App liefert ein leeres <div id="root"> plus Bundle, und ein Crawler ohne JavaScript bekommt nichts. Dieser zweite Fall kostet 2026 mehr als früher, weil die Crawler hinter ChatGPT, Claude und Perplexity gar kein JavaScript ausführen.

Wenn du deine eigene Seite parallel prüfen willst, öffne Luminas JS-vs-No-JS-Tool in einem zweiten Tab.

Was JavaScript SEO eigentlich ist

Jede Seite hat zwei HTML-Versionen: das rohe HTML, das der Server ausliefert, und das DOM, nachdem alle Skripte gelaufen sind. JavaScript SEO heißt, die wichtigen Inhalte in der ersten Version unterzubringen oder zumindest sicherzustellen, dass jeder relevante Crawler bis zur zweiten kommt.

Beides kannst du selbst ansehen. view-source: im Browser zeigt das rohe HTML, der Elements-Tab der DevTools das gerenderte DOM. Auf einer statischen Seite sind beide praktisch gleich. Bei einer clientseitigen SPA mit React, Vue oder Angular ist das rohe HTML eine fast leere Hülle, und der Inhalt existiert erst, wenn das Bundle gelaufen ist. Die meisten echten Seiten liegen irgendwo dazwischen.

Warum das jetzt wichtig ist: Crawler zerfallen in zwei Gruppen. Googlebot rendert JavaScript mit einem Headless Chromium. Die Crawler von OpenAI, Anthropic und Perplexity tun das nicht (die Zahlen stehen weiter unten). Eine CSR-Seite, die bei Google gut rankt, kann für ChatGPT trotzdem so gut wie unsichtbar sein.

Wie Google JavaScript rendert: Crawlen, Rendern, Indexieren

Googles Dokumentation beschreibt drei Phasen: Crawling, Rendering, Indexierung. Jede Seite mit Statuscode 200 landet in der Rendering-Warteschlange, außer ein robots-Meta-Tag oder -Header verbietet die Indexierung. Die meisten JavaScript-SEO-Probleme entstehen zwischen diesen Phasen.

Phase 1: Crawling. Googlebot ruft die URL ab und liest die rohe Antwort: Statuscode, Header und das HTML, das existiert, bevor irgendein Skript läuft. Links in diesem rohen HTML können sofort zum Crawlen vorgemerkt werden.

Phase 2: Rendering. Ein Headless Chromium führt die Seite aus und baut das DOM. Laut Google kann eine Seite „ein paar Sekunden“ in der Warteschlange bleiben, es kann aber auch länger dauern. Eine garantierte Zeit gibt es nicht.

Phase 3: Indexierung. Google indexiert das gerenderte HTML: Title, Überschriften, Links, strukturierte Daten, Fließtext. Was JavaScript hinzugefügt hat, kann jetzt ranken.

Das alte Modell der „zwei Indexierungswellen“ stammt von der Google I/O 2018. Dort beschrieben John Mueller und Tom Greenaway einen ersten Durchgang auf dem rohen HTML und einen späteren nach dem Rendern, unter Umständen Tage später. Ein Jahr darauf, auf dem Chrome Dev Summit 2019, sagte Martin Splitt, der Median zwischen Crawlen und Rendern liege inzwischen bei etwa fünf Sekunden. „Tage oder Wochen“ stimmt als Regel also nicht mehr. Rendern bleibt aber ein eigener Schritt, der sich verzögern und schiefgehen kann. Wenn Inhalt, Links oder Canonical einer Seite erst nach dem Rendern existieren, hängst du davon ab, dass dieser Schritt klappt.

SSR, CSR, Static, Hybrid: Welcher Modus passt

Frameworks bieten fünf Rendering-Modi: serverseitiges Rendering (SSR), statische Generierung (SSG), inkrementelle statische Regenerierung (ISR), clientseitiges Rendering (CSR) und hybride Setups, die pro Route wählen. Diese Entscheidung zählt für JavaScript SEO mehr als jede spätere Feinarbeit. Vier der fünf Modi bringen deine Inhalte ins rohe HTML, CSR nicht.

Server-Side Rendering (SSR)

Der Server führt das Framework bei jeder Anfrage aus und liefert fertiges HTML. Der Browser zeigt es sofort an, danach macht JavaScript die Seite interaktiv (Hydration). Crawler, die rohes HTML lesen, bekommen die ganze Seite. Next.js, Nuxt, SvelteKit, React Router v7 (früher Remix) und Angular mit @angular/ssr unterstützen das. Der Preis: Rechenzeit bei jeder Anfrage.

Static Site Generation (SSG)

Alle Seiten werden beim Build zu HTML gerendert und über ein CDN ausgeliefert. Kein Rechenaufwand pro Anfrage, nichts, was zur Laufzeit ausfallen kann. Astro standardmäßig, Next.js mit statischen Parametern, Gatsby, Hugo, 11ty und reine HTML-Seiten wie Lumina arbeiten so. Der Haken: Jede Inhaltsänderung braucht einen neuen Build, und bei Millionen URLs wird das mühsam.

Incremental Static Regeneration (ISR)

Statische Seiten mit Ablauf-Timer. Eine Seite wird erzeugt, gecacht und nach Ablauf im Hintergrund neu generiert. Next.js kann das nativ, Nuxt über routeRules bei Hostern, die es unterstützen. Astro hat kein eingebautes ISR, ähnliches Verhalten gibt es nur über einen Host-Adapter wie den von Vercel. Für Crawler verhält es sich wie SSG: Sie bekommen gecachtes HTML.

Client-Side Rendering (CSR)

Der Server liefert eine fast leere Hülle und ein Script-Tag. Der Browser lädt das Bundle, holt Daten und baut die Seite. So arbeiten Vite + React ohne SSR-Schicht, Create React App und viele ältere Vue- oder Angular-SPAs. Für Seiten, die ranken oder zitiert werden sollen, ist das die falsche Wahl. Googlebot kann sie rendern, mit dem Umweg und seinen Risiken. Crawler ohne JavaScript bekommen die leere Hülle.

Hybrid (Modus pro Route)

Marketingseiten und Artikel bekommen SSG oder SSR, das eingeloggte Dashboard CSR. Next.js, Nuxt und SvelteKit erlauben diese Wahl pro Route. Astros Islands-Modell geht noch weiter: Die Seite ist statisches HTML, nur die interaktiven Komponenten bringen JavaScript mit. Für die meisten Seiten ist Hybrid die richtige Antwort.

Die 7 häufigsten JavaScript-SEO-Probleme

Die meisten lassen sich im Markup oder Routing beheben. Eines braucht einen anderen Rendering-Modus.

1. Wichtiger Inhalt erst nach der Hydration. Title und Meta-Tags stehen im rohen HTML, aber H1, Fließtext und Navigation tauchen erst auf, wenn die App gelaufen ist. Googlebot kommt vermutlich hin, GPTBot und ClaudeBot nicht. Die Lösung ist SSR oder SSG für diese Route. Wenn eine komplette Umstellung noch nicht drin ist, rendere zumindest den wichtigen Inhalt auf dem Server und überlass JavaScript nur die Interaktivität.

2. Navigation ohne echte Links. Ein <div onClick> oder <span>, das per JavaScript navigiert, sieht für Menschen wie ein Link aus. Googles Dokumentation ist da eindeutig: Google findet Links nur, wenn sie <a>-Elemente mit href-Attribut sind. Das gilt auch für Googlebot nach dem Rendern, nicht nur für Crawler ohne JavaScript. <Link> in React Router und Next.js erzeugt ein echtes <a href>, also nimm das.

3. Inhalte, die erst nach Scrollen oder Klicken laden. Natives loading="lazy" für Bilder und iframes ist in Ordnung, IntersectionObserver auch, den Google für Lazy Loading ausdrücklich empfiehlt. Kaputt ist Inhalt, der nur bei einem Scroll-Event, einem „Mehr laden“-Klick oder einem Tab-Klick ohne Fallback nachlädt. Lade ihn, sobald er im Viewport ist, oder pack ihn gleich ins HTML.

4. noscript-Fallbacks ohne Inhalt. Ein „Bitte aktiviere JavaScript“ im <noscript> hilft keinem Crawler. Ein Crawler ohne Rendering bekommt diese Meldung statt deines Inhalts. Rendere den Inhalt lieber auf dem Server und betrachte den noscript-Block als SEO-irrelevant.

5. Routing über Hash-Fragmente. SPAs, die über #/produkte routen. Laut Googles JavaScript-SEO-Grundlagen kann Googlebot solche URLs nicht zuverlässig auflösen. Nutze die History API mit echten Pfaden und sorg dafür, dass der Server für jeden Pfad das passende HTML liefert.

6. Weiterleitungen per JavaScript. Eine 200-Antwort mit window.location = '/neue-url' im Skript. Google kann dem folgen, sobald die Seite gerendert ist, aber das ist ein langsamerer, schwächerer Weg als ein serverseitiger 301 oder 302. Crawler ohne Rendering sehen die Weiterleitung nie. Leite serverseitig weiter, wo immer es geht.

7. Schwere Bundles und wackelige Datenabrufe. Große Bundles, lange Ketten von API-Aufrufen und Skripte, die in einer Headless-Umgebung scheitern, erhöhen die Chance, dass beim Rendern eine unvollständige Seite herauskommt. Die Gegenmittel überschneiden sich mit der Arbeit an den Core Web Vitals: Code aufteilen, Unnötiges verzögern, weniger ausliefern. Der Core-Web-Vitals-Leitfaden zeigt die praktische Seite.

JavaScript SEO und KI-Crawler

Die meistgenutzten KI-Crawler führen kein JavaScript aus. Sie rufen die URL ab, lesen das rohe HTML und ziehen weiter. Für sie existiert CSR-Inhalt nicht.

Die besten öffentlichen Zahlen stammen aus Vercels Auswertung des eigenen Netzwerks vom 17. Dezember 2024. Im Monat davor stellte GPTBot 569 Millionen Anfragen, der Crawler von Claude 370 Millionen. Ein Teil dieser Anfragen lud sogar JavaScript-Dateien (11,5 % bei ChatGPT, 23,8 % bei Claude), aber keiner der Crawler von OpenAI, Anthropic, Meta, ByteDance oder Perplexity führte sie aus. Die zwei Ausnahmen laut Vercel: Gemini nutzt die Infrastruktur von Googlebot und rendert JavaScript, und auch Applebot rendert mit einem browserbasierten Crawler.

Daraus folgen zwei Dinge. Erstens bauen Googles KI-Funktionen (AI Overviews, AI Mode, Gemini) auf Googles gerendertem Index auf. Eine CSR-Seite, die Google indexiert, kann dort also trotzdem auftauchen. Google-Extended ändert daran nichts, denn es ist ein robots.txt-Token, kein Crawler (die ganze Bot-Liste steht im KI-Crawler-Guide). Zweitens hängen ChatGPT, Claude und Perplexity davon ab, was ihre Crawler im rohen HTML finden. Stehen Produktbeschreibungen, Preise oder FAQ-Antworten erst nach der Hydration auf der Seite, haben diese Engines nichts zum Zitieren.

Wie verbreitet ist das? Als ich im April 2026 50 große Medienseiten aus Deutschland, Österreich und der Schweiz getestet habe, zeigten sieben davon 25 % oder mehr ihres Textes erst, nachdem JavaScript gelaufen war. Die Details stehen in der JS-vs-No-JS-Studie.

Die Lösung ist die, die Google seit Jahren empfiehlt: serverseitiges oder statisches Rendering. CSR war für die Google-Indexierung schon immer ein zusätzliches Risiko. Für ChatGPT, Claude und Perplexity ist es eine Wand, und dieselbe Umstellung löst beides.

Framework-Spickzettel: Next.js, Nuxt, SvelteKit, Astro, React Router

Jedes große Framework hat einen Rendering-Modus, der für SEO funktioniert. Standards und API-Namen unterscheiden sich.

Next.js

Der App Router (ab Next 13) nutzt standardmäßig React Server Components, Seiten werden auf dem Server gerendert, entweder beim Build oder pro Anfrage. generateStaticParams rendert dynamische Routen vorab, export const revalidate = 60 schaltet ISR ein. Ein verbreitetes Missverständnis: 'use client' macht eine Seite nicht clientseitig gerendert. Client Components werden trotzdem auf dem Server zu HTML vorgerendert, die Direktive markiert nur, wo JavaScript für Interaktivität mitgeliefert wird. Der eigentliche Fehler ist, Inhalte im Browser per useEffect zu laden. Dann enthält das vorgerenderte HTML nur einen Ladekreis. Hol Inhalte auf dem Server.

Nuxt

Universal Rendering (SSR) ist Standard. nuxt generate rendert alle Routen vorab für statisches Hosting, und mit routeRules in der nuxt.config.ts mischst du SSR, Prerendering, ISR und reines Client-Rendering pro Route. Vermeiden solltest du ssr: false global, nur weil ein Login-Flow so einfacher war. Damit wird die ganze Seite zur CSR-App.

SvelteKit

Standardmäßig serverseitiges Rendering. +page.server.ts läuft nur auf dem Server, +page.ts auf beiden Seiten. Mit export const prerender = true oder @sveltejs/adapter-static bekommst du statische Ausgabe. Vermeiden solltest du export const ssr = false auf öffentlichen Routen.

Astro

Seiten werden standardmäßig zu statischem HTML gerendert und bringen kein JavaScript mit, solange du keins hinzufügst. Interaktive Komponenten sind Islands zum Einschalten: Eine React-, Vue-, Svelte- oder Solid-Komponente mit client:load oder client:visible liefert JavaScript aus, der Rest bleibt HTML. Rendering pro Anfrage braucht einen Server-Adapter. Für Content-Seiten, bei denen SEO an erster Stelle steht, würde ich einem Team, das neu anfängt, Astro empfehlen.

React Router v7 (früher Remix)

Remix ist mit Version 7 in React Router aufgegangen. Im Framework-Modus bekommst du Server-Rendering, Loader, die auf dem Server laufen, und Formulare, die ohne JavaScript funktionieren, also das Modell, das Remix hatte. Routen lassen sich auch beim Build vorrendern. Vermeiden solltest du den SPA-Modus für öffentliche Seiten.

JavaScript SEO testen

1. Roh gegen gerendert. Strg+U (Cmd+Option+U am Mac) zeigt das rohe HTML, der Elements-Tab das gerenderte DOM. Fehlen im rohen HTML deine H1, dein Fließtext oder deine Navigationslinks, bekommen KI-Crawler sie nicht, und Google ist aufs Rendern angewiesen. Luminas JS-vs-No-JS-Tool übernimmt den Vergleich: Wortzahl vor und nach JavaScript plus Listen der Überschriften, Links und Bilder, die erst nach dem Rendern auftauchen.

2. URL-Prüfung in der Search Console. URL eingeben, „Live-URL testen“ klicken, dann „Getestete Seite anzeigen“ und den HTML-Tab öffnen. Das hat Google gerendert, samt Ressourcen, die nicht geladen werden konnten. Vergleich es mit deiner DevTools-Ansicht. Unterschiede deuten auf Skripte, die robots.txt blockiert, auf API-Aufrufe mit Timeout oder auf Inhalte, zu denen der Renderer nie kam.

3. Roher Abruf als Bot. curl -A "GPTBot" https://deine-seite.de/seite zeigt, was dein Server für diesen User-Agent ausliefert. Damit prüfst du gut, ob der Inhalt im rohen HTML steht und ob dein Server Bot-User-Agents anders behandelt. Eine exakte Kopie dessen, was OpenAI bekommt, ist es aber nicht: Firewalls und Bot-Management prüfen oft IP-Bereiche, und ein vorgetäuschter User-Agent von deinem Laptop kann eine andere Antwort bekommen als der echte Crawler.

Drei weitere Tools helfen:

• Lumina JS vs No-JS. Kostenlos. Der Vergleichsmodus rendert eine URL mit und ohne JavaScript und listet auf, was fehlt. Der Modus für die ganze Website liest bis zu 300 URLs aus deiner Sitemap als rohes HTML, markiert Seiten, die wie leere Framework-Hüllen aussehen, und exportiert die Tabelle als CSV.
• Lumina Crawler Access Checker. Prüft deine robots.txt gegen 37 Such- und KI-Crawler, darunter GPTBot, ClaudeBot, PerplexityBot und Google-Extended. Ein Bot, den die robots.txt sperrt, kommt gar nicht erst bis zur JavaScript-Frage.
• Test für Rich-Suchergebnisse von Google. Rendert die Seite und zeigt, welche strukturierten Daten Google nach dem JavaScript findet. Funktioniert mit URLs und eingefügtem Code.

Dynamic Rendering: Warum es keine Lösung ist

Beim Dynamic Rendering bekommen Nutzer die JavaScript-App und Bots eine vorgerenderte HTML-Version, zum Beispiel über Prerender.io. Google verarbeitet solche Seiten weiterhin. Googles Dokumentation nennt das Verfahren aber eine Notlösung und keine langfristige Lösung für Probleme mit JavaScript-generierten Inhalten und empfiehlt stattdessen serverseitiges Rendering, statisches Rendering oder Hydration. Drei Gründe, warum ich heute nicht darauf bauen würde.

Google selbst rät davon ab. Es war eine Brücke aus einer Zeit, in der Googlebot schlechter renderte, und formal abgeschafft hat Google die Unterstützung nicht.

Es verdoppelt die Wartung. Du betreibst zwei Versionen jeder Seite: die App für Nutzer und das vorgerenderte HTML für Bots. Inhaltsänderungen, Caching und Bugfixes müssen in beiden funktionieren, und die Version, die dein Team im Browser testet, ist nicht die, die der Crawler bekommt.

Es hilft nur den Bots auf deiner Liste. Dynamic Rendering schaltet nach User-Agent um. Setups, die vor Jahren gebaut wurden, führen oft Googlebot und Bingbot, aber nicht GPTBot, ClaudeBot oder PerplexityBot. Diese Crawler landen dann bei der leeren Hülle. SSR oder statisches Rendering braucht keine Liste: Jeder Crawler bekommt dasselbe HTML.

Wenn ein Dynamic-Rendering-Setup bei dir heute funktioniert, musst du es nicht morgen abreißen. Prüf, ob die gewünschten KI-Crawler auf der Bot-Liste stehen, und plan den Umstieg auf SSR oder statisches Rendering für den nächsten Relaunch.

FAQ

Wo du anfängst

Fünf Schritte in dieser Reihenfolge.