JavaScript-SEO und Rendering für KI-Crawler 2026

Ein Jahrzehnt lang lautete die JavaScript-SEO-Frage schlicht: "Kann der Googlebot meine Seite rendern?" 2026 hat sie eine zweite Hälfte, die genauso zählt: "Können es die KI-Crawler?" Und bei den meisten lautet die Antwort: nein. So funktioniert Rendering heute wirklich und das solltest du tun.

Die Rendering-Lücke zwischen Google und KI-Crawlern

Der Googlebot rendert JavaScript. Er holt dein HTML, stellt die Seite in eine Warteschlange, startet eine moderne Chromium-Instanz und indexiert das resultierende DOM. Dieser zweistufige Prozess läuft seit Jahren zuverlässig, also kann eine gut gebaute Client-App in der klassischen Google-Suche ranken.

Bei den KI-Crawlern sieht es anders aus. Die Bots hinter ChatGPT, Perplexity, Claude und Googles eigenen KI-Systemen holen meist rohes HTML und führen kein JavaScript aus. Sie sind auf Tempo und Skalierung über Milliarden URLs ausgelegt, und für jede einen vollen Browser laufen zu lassen ist teuer. Also lesen sie, was der Server schickt, und ziehen weiter.

Das erzeugt eine Rendering-Lücke. Eine Seite, die der Googlebot geduldig rendert, kann für einen LLM-Crawler völlig leer aussehen. Wenn dein Inhalt, deine Überschriften und Links erst nach dem Ausführen von JavaScript existieren, kannst du bei Google ranken und in KI-Antworten unsichtbar sein — genau dort, wo Sichtbarkeit 2026 am schnellsten wächst.

Zwei Crawler-Familien, die du auseinanderhalten solltest:

• Trainings-/Indexierungs-Crawler (z. B. GPTBot, ClaudeBot), die Inhalte für Modelle und Retrieval sammeln.
• Live-Retrieval-Fetcher, die eine Seite in Echtzeit für eine konkrete Anfrage abrufen. Sie sind die ungeduldigsten von allen und warten fast nie auf das Rendering.

SSR vs. CSR: Wähle den sicheren Standard

Die Architekturentscheidung bestimmt, ob dein Inhalt diese Lücke überlebt.

• Client-Side-Rendering (CSR). Der Server schickt eine nahezu leere HTML-Hülle plus ein JavaScript-Bundle; der Browser baut die Seite. Toll für app-artige Interaktivität, gefährlich für die Crawlbarkeit. Bots ohne Rendering sehen die leere Hülle.
• Server-Side-Rendering (SSR). Der Server liefert bei jedem Request voll ausgebautes HTML, danach hydratisiert JavaScript es für Interaktivität. Jeder Crawler bekommt den Inhalt sofort.
• Static Site Generation (SSG). Seiten werden zur Build-Zeit zu HTML vorgerendert. Die schnellste und crawlerfreundlichste Option für Inhalte, die sich nicht pro Request ändern.

Meine Standardempfehlung ist unmissverständlich: Liefere deinen Hauptinhalt im initialen HTML, per SSR oder SSG. Reines CSR bleibt echt interaktiven, eingeloggten oder nicht indexierbaren Bereichen vorbehalten. Wenn dein Wert der Inhalt ist und du ihn in KI-Antworten willst, muss er in dem HTML stehen, das der Server schickt.

Hydration-Fallen, die dich leise ausbremsen

Selbst Teams, die auf SSR setzen, stolpern über Hydration — den Schritt, in dem Client-JavaScript das Server-HTML "übernimmt". Achte darauf:

• Inhalt, der erst nach der Hydration erscheint. Wenn Tabs, Akkordeons oder "Mehr lesen"-Bereiche ihren echten Text per JavaScript einspeisen, verpassen ihn Crawler ohne Rendering. Packe den vollen Text ins Server-HTML und steuere die Sichtbarkeit per CSS.
• Hydration-Mismatches. Wenn Server- und Client-HTML voneinander abweichen, verwerfen manche Frameworks das Server-Markup und rendern clientseitig neu — und erschaffen kurz wieder ein CSR-Problem. Halte Server- und Client-Ausgabe identisch.
• Streaming- und Partial-Hydration-Sonderfälle. Moderne Frameworks streamen HTML in Teilen. Sorge dafür, dass der relevante Inhalt im initialen Dokument ausgeliefert wird, nicht in einer spät eintreffenden Async-Boundary.
• Nur clientseitiges Routing. Passiert die interne Navigation komplett in JavaScript ohne echte <a href>, können Crawler ihr nicht folgen. Rendere immer echte Anchor-Tags mit realen URLs.

Mach Inhalte für beide crawlbar

Eine praktische Checkliste, die ich auf jede JavaScript-lastige Seite anwende:

1. Lege den Kerninhalt serverseitig ab. Haupttext, H1–H3, Produktdetails und interne Links gehören ins rohe HTML.
2. Nutze echte Links. <a href="/echte-url">, nicht <div onclick>. So entdecken sowohl Google als auch LLM-Crawler deine Seite.
3. Rendere Metadaten serverseitig. Title, Meta-Description, Canonical und strukturierte Daten (JSON-LD) sollten ohne JavaScript vorhanden sein.
4. Blockiere keine Ressourcen in der robots.txt. Wenn du auf das Rendering des Googlebots setzt, braucht er dein CSS und JS. Sie zu blockieren zerstört das Rendering.
5. Füge strukturierte Daten hinzu. Schema.org-Markup hilft jedem Parser, und sauberes, gut ausgezeichnetes HTML ist das, was LLMs am zuverlässigsten extrahieren.
6. Behalte den Crawler-Zugriff im Blick. Entscheide bewusst, ob du KI-Crawler zulässt. Sie in der robots.txt zu blockieren ist ein Sichtbarkeits-Trade-off, kein neutraler Standard.

So testest du, was Crawler wirklich sehen

Vertrau nicht länger der gerenderten Ansicht in den DevTools. Sie zeigt das DOM nach JavaScript — das, was der Googlebot sieht, aber nicht die rohen Fetcher. Stattdessen:

• Sieh dir den Quelltext an. Nutze curl -A "Mozilla/5.0" https://deineseite.de/seite oder Seitenquelltext anzeigen im Browser (nicht Untersuchen). Prüfe, ob dein Haupttext, deine Überschriften und Links in diesem HTML stehen.
• Vergleiche mit dem gerenderten DOM. Die Differenz zwischen Quelltext und gerendertem DOM ist genau das, was JavaScript-abhängige Crawler verpassen.
• Nutze das URL-Prüftool in der Search Console, um das gerenderte HTML des Googlebots zu sehen, und deaktiviere JavaScript im Browser, um einen Bot ohne Rendering zu simulieren.
• Prüfe deine Server-Logs auf User-Agents von KI-Crawlern, um zu erfahren, wer dich tatsächlich abruft und wie oft.

Die Lücke zwischen Quelltext und gerendertem DOM ist dein KI-Sichtbarkeitsrisiko in einer einzigen Messung. Lebt dein Inhalt nur im gerenderten DOM, hast du Arbeit vor dir.

Das Fazit

2026 ist Rendering keine reine Google-Angelegenheit mehr. Der Googlebot führt dein JavaScript aus, aber die KI-Crawler, die entscheiden, ob du in ChatGPT- und Perplexity-Antworten auftauchst, tun es meist nicht. Liefere deinen echten Inhalt als serverseitig gerendertes HTML, nutze echte Links und serverseitige Metadaten und teste mit dem Quelltext statt mit den DevTools. Tu das, und du bist für jedes System lesbar, das zählt — nicht nur für das eine, das zufällig einen Browser startet.