JavaScript Rendering und AI-Crawler: Die Sichtbarkeits-Kluft

Warum JavaScript Rendering zur Sichtbarkeitsfrage geworden ist

Jahrelang galt JavaScript-Rendering als reines Performance-Thema. Wer client-seitig rendert, riskierte langsamere Ladezeiten, aber kaum verlorene Sichtbarkeit, weil Googlebot JavaScript ausführt. Diese Annahme greift im Zeitalter der KI-Suche zu kurz. Eine neue Klasse von Crawlern liest Webseiten, ohne eine einzige Zeile JavaScript auszuführen: die Crawler hinter ChatGPT, Claude, Perplexity und anderen KI-Systemen.

Die gemeinsame Analyse von Vercel und MERJ über das Crawler-Verhalten im Netzwerk von Vercel hat diese Kluft erstmals breit belegt. Kein grosser KI-Crawler rendert derzeit JavaScript, darunter OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Anthropic (ClaudeBot), ByteDance (Bytespider), Meta und Perplexity (PerplexityBot). Damit verschiebt sich die Logik: Server-Side Rendering ist nicht länger eine Optimierung für schnellere Auslieferung, sondern eine Grundvoraussetzung dafür, dass Inhalte für einen wachsenden Teil des Crawler-Verkehrs überhaupt existieren.

Die Größenordnung dieses Verkehrs ist relevant. Allein GPTBot generierte 569 Millionen Requests und ClaudeBot 370 Millionen Requests im Vercel-Netzwerk innerhalb eines Monats, zusammen rund 20 Prozent des Googlebot-Volumens von 4,5 Milliarden Requests. Wer in ChatGPT oder Perplexity zitiert werden will, muss sicherstellen, dass diese Bots den Inhalt lesen können. Genau das scheitert bei client-seitig gerendertem Content.

Die technische Ursache der Sichtbarkeits-Kluft

Ein Crawler durchläuft prinzipiell zwei Schritte: Er ruft das HTML-Dokument ab (Crawling) und verarbeitet anschliessend dessen Inhalt. Der entscheidende Unterschied liegt darin, ob zwischen diese Schritte ein Rendering-Vorgang geschaltet ist, bei dem ein Browser-Engine das JavaScript ausführt, das DOM aufbaut und nachgeladene Inhalte einfügt.

Googlebot rendert, KI-Crawler nicht: Googlebot, Google Gemini und AppleBot nutzen eine browserbasierte Rendering-Stufe und sehen damit auch Inhalte, die erst per JavaScript entstehen. Die KI-Crawler verzichten darauf. Sie verarbeiten ausschliesslich das rohe HTML, das der Server ausliefert. Interessant ist, dass sie JavaScript durchaus herunterladen: ChatGPT-Crawler fetchen JS-Dateien in 11,50 Prozent ihrer Requests, ClaudeBot in 23,84 Prozent, führen diese Dateien aber nicht aus. Das Laden ohne Ausführen bedeutet: Alles, was erst im Browser zusammengesetzt wird, bleibt unsichtbar.

Was Rendering technisch kostet: Rendering ist ressourcenintensiv. Es erfordert eine Browser-Umgebung pro Seite, Rechenzeit und Arbeitsspeicher. Für einen Crawler, der Milliarden Seiten verarbeitet, ist das ein erheblicher Kostenfaktor. KI-Crawler sind primär auf den Aufbau von Trainings- und Retrieval-Datensätzen ausgelegt und verzichten aus Effizienzgründen auf diese Stufe. Das ist kein vorübergehender Engpass, sondern eine bewusste Architekturentscheidung.

Die praktische Konsequenz: In einem dokumentierten Praxistest konnten ChatGPT, Perplexity und Claude den Inhalt einer client-seitig gerenderten Seite nicht lesen, weil sie auf JavaScript-Rendering angewiesen war. Die betroffenen Seiten erschienen zudem nur in nachrangigen Bereichen wie der "More"-Sektion von ChatGPT statt als primäre Zitatquelle. Sichtbarkeit in der KI-Suche entscheidet sich also bereits an der Frage, ob der Hauptinhalt im server-gelieferten HTML steht.

Rendering-Strategien im Vergleich

Die Wahl der Rendering-Strategie ist die zentrale Stellschraube. Vier Ansätze dominieren, mit klar unterschiedlichen Folgen für KI- und Crawler-Sichtbarkeit.

Client-Side Rendering (CSR): Der Server liefert ein minimales HTML-Grundgerüst, der gesamte Inhalt entsteht erst im Browser durch JavaScript. Für KI-Crawler ist dieser Inhalt nicht vorhanden. Reine CSR-Architekturen sind für die KI-Sichtbarkeit die problematischste Variante.

Server-Side Rendering (SSR): Der Server erzeugt das vollständige HTML pro Anfrage und liefert es fertig aus. Hauptinhalt, Meta-Daten und strukturierte Daten stehen sofort im Quelltext und sind für jeden Crawler lesbar. SSR ist der robusteste Ansatz für maximale Crawler- und KI-Sichtbarkeit.

Static Site Generation (SSG) und Prerendering: Die Seiten werden zum Build-Zeitpunkt vorgerendert und als statisches HTML ausgeliefert. Das kombiniert volle Sichtbarkeit mit sehr schneller Auslieferung. Für Inhalte, die sich selten ändern, etwa Wissensartikel oder Leistungsseiten, ist das oft die ideale Lösung.

Incremental Static Regeneration (ISR): Eine Mischform, die statische Seiten im Hintergrund in definierten Intervallen neu generiert. Sie verbindet die Vorteile von SSG mit der Aktualität dynamischer Inhalte und liefert ebenfalls fertiges HTML aus.

Im Next.js-Kontext bildet der App Router diese Strategien ab. React Server Components rendern standardmäßig auf dem Server, sodass deren Ausgabe direkt im HTML landet. Streaming liefert Inhalte progressiv aus, ohne die Crawler-Lesbarkeit des Hauptinhalts zu gefährden, solange der zentrale Content nicht hinter einer rein clientseitigen Komponente verborgen liegt. Entscheidend bleibt die Faustregel: Was im initialen HTML-Response steht, ist sichtbar. Was erst der Browser zusammensetzt, ist es nicht.

Der Trend zu serverseitigem Rendering lässt sich auch in den Daten ablesen. Beim Vergleich von gerendertem und rohem Wortbestand auf Startseiten zeigt sich ein Median-Unterschied von 13,6 Prozent (Mobile) und 17,5 Prozent (Desktop), wobei der Abstand bei längeren Texten schrumpft, was auf eine relativ größere Verbreitung serverseitiger Technologien bei längeren Inhalten hindeutet. Am 10. Perzentil beträgt die Differenz auf dem Desktop allerdings bis zu 32 Prozent, ein klarer Hinweis darauf, dass ein erheblicher Anteil von Seiten weiterhin Inhalt nachlädt, der KI-Crawlern entgeht.

Best Practices für crawlerfeste Architektur

Hauptinhalt server-seitig ausliefern: Der zentrale Textinhalt, Title und Meta-Description, strukturierte Daten nach Schema.org, die interne Verlinkung, hreflang-Angaben und das Canonical-Tag müssen im initialen HTML-Response stehen. Diese Elemente steuern Indexierung, Sprach- und Regionalzuordnung sowie die Auswertung durch KI-Systeme. Liegen sie nur im gerenderten DOM, sind sie für rohes HTML lesende Crawler verloren.

Strukturierte Daten serverseitig einbetten: JSON-LD sollte direkt im server-gelieferten HTML liegen, nicht per JavaScript injiziert werden. Andernfalls fehlt KI-Crawlern der maschinenlesbare Kontext, der für Entitäten-Erkennung und Zitierfähigkeit wertvoll ist.

Interne Verlinkung als echte HTML-Links: Navigation und interne Links müssen als reguläre Anker-Elemente im Quelltext vorliegen. Per JavaScript erzeugte Links werden von KI-Crawlern nicht verfolgt, und selbst Googlebot benötigt dafür deutlich länger. Crawlbarkeit der Linkstruktur ist die Grundlage dafür, dass Unterseiten überhaupt gefunden werden.

Schnelle Auslieferung über Edge und CDN: HTTP/3, Edge-Caching und ein CDN verkürzen die Antwortzeiten und senken die Last bei häufigem Crawling. Das ist besonders relevant, weil KI-Crawler ineffizient arbeiten. ChatGPT verbringt 34,82 Prozent seiner Fetches auf 404-Seiten und Claude 34,16 Prozent, gegenüber nur 8,22 Prozent bei Googlebot. Saubere XML-Sitemaps und IndexNow helfen, neue und geänderte URLs gezielt zu signalisieren und die Verschwendung von Crawl-Ressourcen auf tote Pfade zu reduzieren.

Consent-Management von Crawlern entkoppeln: Cookie-Banner und consent-gated Bereiche dürfen den eigentlichen Inhalt nicht vor Crawlern verbergen. Wird der Hauptinhalt erst nach einer Zustimmung per JavaScript geladen, sehen KI-Crawler nur das Banner. Der DSGVO-konforme Weg besteht darin, nicht-personenbezogene Inhalte serverseitig auszuliefern und das Consent-Management auf das zu beschränken, was es betrifft: Tracking und nicht notwendige Cookies. Inhalte hinter eine Zustimmung zu sperren, schadet der Sichtbarkeit, ohne datenschutzrechtlich erforderlich zu sein.

Häufige Fehler

Dynamic Rendering als Lösung missverstehen: Google hat das Ausspielen unterschiedlicher Inhalte an Bots und Nutzer als veraltete Behelfslösung eingestuft. Es erhöht die Komplexität, ist fehleranfällig und ersetzt keine saubere serverseitige Architektur. Wer heute neu baut, sollte direkt auf SSR, SSG oder ISR setzen.

CSR-Frameworks ohne Server-Rendering einsetzen: Eine Single-Page-Application ohne serverseitiges Rendering produziert ein nahezu leeres HTML-Dokument. Für Nutzer funktioniert das, für KI-Crawler ist die Seite inhaltsleer. Der Fehler fällt im Tagesgeschäft oft nicht auf, weil die Seite im Browser einwandfrei aussieht.

Annehmen, dass Googlebot-Sichtbarkeit ausreicht: Selbst wenn Googlebot eine JavaScript-Seite rendert, gilt das nicht für KI-Crawler. Wer ausschliesslich auf das Verhalten von Googlebot optimiert, ignoriert den wachsenden Anteil an Traffic aus ChatGPT, Perplexity und vergleichbaren Systemen.

Crawler pauschal aussperren, ohne die Folgen abzuwägen: Über die robots.txt lassen sich GPTBot, ClaudeBot, PerplexityBot und Google-Extended gezielt erlauben oder sperren. Eine Sperre schützt Inhalte vor der Nutzung in KI-Systemen, schliesst die eigene Marke aber zugleich von der Sichtbarkeit in deren Antworten aus. Diese Abwägung zwischen Kontrolle und Sichtbarkeit sollte bewusst getroffen werden, nicht aus Versehen durch eine zu restriktive Konfiguration.

JavaScript-Last unterschätzen: Grosse Client-Bundles verschlechtern nicht nur die KI-Sichtbarkeit, sondern auch die Performance. Der mediane JavaScript-Payload liegt bei 558 Kilobyte auf Mobile und 613 Kilobyte auf Desktop, wobei rund 44 Prozent (206 Kilobyte) der ausgelieferten Bytes beim Laden ungenutzt bleiben. Dieser ungenutzte Ballast belastet vor allem Largest Contentful Paint und Interaction to Next Paint.

Metriken und Messung

HTML-only gegen gerendertes DOM prüfen: Der schnellste Test besteht darin, das rohe HTML mit dem gerenderten DOM zu vergleichen. Über den Seitenquelltext oder einen einfachen Abruf des HTML lässt sich prüfen, ob der Hauptinhalt bereits ohne JavaScript vorhanden ist. Fehlt der Text im Quelltext, taucht aber im gerenderten Bild auf, liegt ein CSR-Problem vor. Der Google Rich Results Test und der URL-Inspektionsbericht in der Search Console zeigen, was Google gerendert sieht. Ein Crawler wie Screaming Frog kann mit aktiviertem JavaScript-Rendering die Differenz zwischen roher und gerenderter Version systematisch sichtbar machen.

KI-Bots in den Server-Logs analysieren: Die Server-Log-Analyse zeigt, welche KI-Crawler die Seite tatsächlich abrufen, welche URLs sie ansteuern und wie hoch deren 404-Quote ausfällt. Hohe Fehlerraten deuten auf veraltete Links in Sitemaps oder auf eine ineffiziente Struktur hin. Diese Daten sind der direkteste Beleg dafür, wie KI-Systeme die eigene Domain wahrnehmen.

Indexierungs-Verzögerung berücksichtigen: Selbst bei Google verursacht JavaScript einen messbaren Zeitverlust. In einem Experiment benötigte Googlebot rund neun Mal mehr Zeit, um JavaScript-Seiten zu crawlen als reine HTML-Seiten, konkret 313 Stunden gegenüber 36 Stunden für dieselbe Seitenmenge. Auch einem per JavaScript eingefügten internen Link folgte Googlebot mit 52 Stunden gegenüber 25 Stunden bei einem HTML-Link deutlich langsamer. Diese Verzögerung im Zwei-Wellen-Modell verlängert die Time-to-Index und kostet bei aktuellen Inhalten Reichweite.

Core Web Vitals im Blick behalten: Performance bleibt ein eigenständiges Qualitätssignal. Aktuell bestehen 48 Prozent der mobilen und 56 Prozent der Desktop-Seiten alle drei Core Web Vitals, wobei nur 62 Prozent der mobilen Seiten ein gutes Largest Contentful Paint erreichen gegenüber 74 Prozent auf dem Desktop. Code-Splitting, das Aufschieben nicht kritischen JavaScripts und eine schlanke Hydration-Strategie reduzieren die Client-Last und verbessern LCP und INP zugleich.

GEO-Konsequenz für den DACH- und Österreich-Markt

Für den österreichischen B2B-Markt hat die Sichtbarkeits-Kluft konkrete Bedeutung. Die Reichweite digitaler Kanäle ist hoch: In Österreich gab es im Januar 2025 rund 8,69 Millionen Internetnutzer bei einer Penetration von 95,3 Prozent. Gleichzeitig bleibt die klassische Suche dominant. Google hält in Österreich im Mai 2026 einen Marktanteil von 81,87 Prozent, gefolgt von Bing mit 9,01 Prozent. Da Bing die KI-Antworten in Microsoft Copilot speist und Google AI Overviews ausspielt, fliesst serverseitig gelieferter, sauber strukturierter Inhalt in beide Welten ein: die klassische Suche und die generativen Antwortsysteme.

Wer für Sichtbarkeit in ChatGPT, Perplexity, Gemini und Google AI Overviews optimiert, betreibt damit zugleich solides technisches SEO. Die Anforderungen überschneiden sich: lesbares HTML, eingebettete strukturierte Daten, schnelle Auslieferung und eine crawlbare Linkstruktur. Server-Side Rendering ist der gemeinsame Nenner. Es stellt sicher, dass der Inhalt für den rendernden Googlebot ebenso existiert wie für die nicht rendernden KI-Crawler, die zunehmend mitbestimmen, welche Marken in KI-Antworten auftauchen.

Weiterführendes

JavaScript-Rendering ist damit kein isoliertes Frontend-Thema, sondern ein zentraler Hebel der Auffindbarkeit. Vertiefend lohnt der Blick auf die Next.js-SEO-Architektur mit App Router und Server Components, auf das gezielte AI-Crawler-Management über robots.txt sowie auf IndexNow und XML-Sitemaps als Beschleuniger für effizientes Crawling. Wer diese Bausteine auf eine serverseitig rendernde Grundlage stellt, schliesst die Sichtbarkeits-Kluft, statt sie zu vergrößern.