Eine E-Commerce-Seite verlor 47 % ihrer Sichtbarkeit in der KI-Suche, nachdem ein Deployment verändert hatte, wie Seiten gerendert werden. Dieselben Produktseiten rankten bei Google weiter. Aber ChatGPT, Claude und Perplexity lieferten null Ergebnisse. Der Unterschied war das JavaScript-Rendering.
Das passiert jeder Seite, die auf client-seitiges Rendering setzt. Eine SaaS-Landingpage mit Vue.js taucht in Antworten von ChatGPT nie auf. Eine Nachrichtenseite auf einem JavaScript-Framework ist in Perplexity gar nicht vorhanden. Eine Wissensdatenbank, die Inhalte mit React rendert, bleibt für KI-Crawler unsichtbar. Das sind keine Randfälle. Es ist das Standardverhalten der meisten modernen Web-Frameworks.
Der Unterschied zwischen einer JavaScript-Seite und einer für KI sichtbaren Seite hat nichts mit Komplexität oder Budget zu tun. Es geht darum zu verstehen, was in den ersten Millisekunden passiert, wenn ein Crawler ankommt.
Was KI-Crawler sehen, wenn sie deine Seite abrufen
Der Crawler von Google führt JavaScript aus. Er wartet, bis die Seite gerendert ist, erfasst den endgültigen visuellen Zustand und indexiert ihn. Die meisten KI-Crawler tun das nicht.
Wenn der Crawler von ChatGPT (GPTBot) auf deine Seite kommt, läuft das so ab: 1. Er ruft die HTML-Datei ab 2. Er liest den Text, der im rohen HTML sichtbar ist 3. Er geht zur nächsten Seite weiter
Das JavaScript, das deine Überschrift, deine Produktbeschreibung und deinen Artikeltext rendert, läuft nie. Der Crawler sieht die Verweise auf die JavaScript-Dateien, ignoriert sie aber. Deine Seite wirkt wie eine leere Hülle.
Das liegt daran, dass KI-Crawler auf Tempo und Effizienz ausgelegt sind. JavaScript auszuführen ist langsam. Man muss einen Browser starten, auf Ressourcen warten, Fehler abfangen und Timeouts verwalten. Wenn du täglich Milliarden Seiten crawlst, wird die Ausführung von JavaScript unbezahlbar teuer.
Google steckt Geld in diese Infrastruktur, weil Suchergebnisse davon abhängen, das visuelle Rendering zu verstehen. KI-Suchmaschinen setzen auf das Auslesen von rohem Text. Sie sind darauf optimiert, Fakten und Zitate direkt aus dem HTML zu ziehen, nicht aus dem, was nach der Umwandlung durch JavaScript erscheint.
Welche Rendering-Arten Probleme für KI-Crawler machen
Nicht jedes JavaScript-Framework führt zu gleich viel Sichtbarkeitsverlust. Das Problem liegt gezielt beim client-seitigen Rendering (CSR), bei dem JavaScript im Browser läuft und die Seite aufbaut, nachdem das HTML geladen wurde.
Client-seitiges Rendering (CSR): React, Vue, Angular, Svelte im CSR-Modus. Das HTML kommt leer oder mit Platzhaltern an. JavaScript füllt die Inhalte nach dem Download ein. KI-Crawler warten nicht.
Server-seitiges Rendering (SSR): Next.js, Nuxt, Remix, SvelteKit. Der Server baut die Seite mit den Inhalten schon im HTML auf. Der Browser bekommt komplettes HTML. KI-Crawler sehen sofort alles.
Statische Generierung (SSG): Generatoren für statische Seiten. Die Seiten werden vorab gebaut und als statische HTML-Dateien bereitgestellt. Beim Abruf findet kein Rendering statt. KI-Crawler bekommen den vollen Inhalt sofort.
Single-Page-Anwendungen (SPAs): Die Kategorie mit dem höchsten Risiko. Eine SPA lädt eine einzige HTML-Datei und tauscht mit JavaScript je nach Navigation die Inhalte aus. Für einen Crawler sieht jede Route gleich aus, wenn der Server nicht jede Route gezielt behandelt.
In dem Moment, in dem du CSR als Rendering-Strategie wählst, baust du eine unsichtbare Barriere zwischen deinen Inhalten und jedem KI-Crawler im Internet.
Warum das wichtiger ist, als du vielleicht denkst
Die KI-Suche steht noch am Anfang, aber die Nutzung wächst schnell. Studien zeigen, dass KI-Suchanfragen schneller wachsen als klassische Websuchen. ChatGPT, Perplexity und Claude werden für Fachleute, Studierende und Entscheider zu wichtigen Recherche-Werkzeugen.
Wenn jemand ChatGPT nach „besten Website-Buildern für kleine Unternehmen“ fragt, wählt die KI, welche Marken sie zitiert. Diese Entscheidung hängt davon ab, welche Inhalte sie lesen kann. Wenn deine Seite auf JavaScript setzt, ist sie unsichtbar.
Das ist kein Problem der Zukunft. Eine Analyse von über 500 Mio. GPTBot-Anfragen aus dem Jahr 2025 ergab, dass Seiten mit JavaScript-Abhängigkeit deutlich weniger Zitate bekamen als server-gerenderte Mitbewerber in derselben Branche. Die Lücke wurde bei technischen Inhalten, Produktseiten und Anleitungen größer, also genau bei den Inhalten, die KI-Suchmaschinen bevorzugen.
Für B2B- und E-Commerce-Unternehmen werden KI-Zitate zu einem Hebel für Sichtbarkeit im Wettbewerb. Eine Nennung in einer ChatGPT-Antwort oder in einem Perplexity-Ausschnitt kann denselben Wert an Besuchern bringen wie ein Platz auf der ersten Seite bei Google. Nur kannst du nicht zitiert werden, wenn der Crawler deine Inhalte nicht lesen kann.
Wie du entscheidest, was du tun solltest
Nicht jede Seite muss vom client-seitigen Rendering weg. Die Entscheidung hängt von drei Faktoren ab: deiner Art von Inhalten, deiner Zielgruppe und dem geschäftlichen Wert von KI-Sichtbarkeit in deiner Situation.
Stell dir zuerst diese Fragen:
Sind deine Inhalte zitierwürdig für KI? Nachrichten, Anleitungen, Produktvergleiche, Fachartikel, Expertenrat. Das wird von KI zitiert. Technische Dokumentation, interaktive Tools, Dashboards, die vor allem für eingeloggte Nutzer da sind, eher nicht. Wenn deine Seite überwiegend aus Letzterem besteht, spielt JavaScript-Rendering eine kleinere Rolle.
Sucht deine Zielgruppe in KI-Suchmaschinen? B2B-Fachleute, Produktrechercheure, Studierende, Entwickler. Sie nutzen die KI-Suche intensiv. Wenn deine Zielgruppe sehr speziell ist und ausschließlich bei Google sucht, bringt KI-Sichtbarkeit kurzfristig weniger.
Was kostet es, unsichtbar zu sein? Für eine Nachrichtenseite oder Wissensdatenbank sind null KI-Zitate ein Wettbewerbsnachteil. Für ein Firmen-Intranet oder ein SaaS nur für Mitglieder ist es egal. Bei einem Onlineshop hängt es davon ab, ob deine Kunden Produkte über KI-Shopping-Empfehlungen entdecken.
Wenn du bei „zitierwürdige Inhalte“, „ja, meine Zielgruppe nutzt KI-Suche“ und „verlorene Sichtbarkeit ist ein echter Verlust“ mit Ja geantwortet hast, mach weiter. Wenn die Antworten gemischt sind, setzt du vielleicht andere Prioritäten.
Server-seitiges Rendering: die vollständigste Lösung
SSR löst das JavaScript-Problem umfassend. Der Server baut die komplette Seite mit allen Inhalten, bevor er sie an den Browser schickt. Wenn ein Crawler ankommt, sind die Inhalte schon da.
So funktioniert es: Wenn jemand (oder ein Bot) eine Seite anfragt, führt dein Server deinen Code aus und erzeugt das fertige HTML. Dieses HTML enthält deine Überschrift, deinen Artikeltext und deine Produktdetails. Der Browser bekommt eine komplette Seite und zeigt sie sofort an. JavaScript kann die Interaktivität weiter ergänzen, aber der Inhalt ist bereits zugänglich.
Plattformen, die SSR einfach machen: Next.js (React), Nuxt (Vue), Remix, SvelteKit. Diese Frameworks wurden genau dafür gebaut, SSR unkompliziert zu machen. Du schreibst deine Komponenten einmal, das Framework rendert auf dem Server, und die Seite kommt fertig gebaut an.
Der Haken: SSR braucht Serverressourcen. Dein Server verarbeitet jede Anfrage, baut das HTML und schickt es raus. Das braucht mehr CPU und Arbeitsspeicher als die Auslieferung fertiger statischer Dateien. Langsame oder komplexe Seiten können die Antwortzeit erhöhen, was Leistungswerte wie First Contentful Paint (FCP) und Core Web Vitals beeinflusst.
Für die meisten Seiten ist der Leistungsverlust klein. Bei stark besuchten Seiten mit komplexen Inhalten wird er spürbar. Das lässt sich mit Caching, Edge Computing oder Code-Optimierung lösen, erfordert aber Entscheidungen bei der Architektur.
Pre-Rendering: ein leichterer Ansatz für statische Inhalte
Beim Pre-Rendering werden deine Seiten vorab gebaut und als statische HTML-Dateien bereitgestellt. Wenn ein Crawler kommt, bekommt er sofort eine komplette Seite. Wenn jemand die Seite besucht, bekommt er eine statische Datei, die extrem schnell lädt.
Dienste für Pre-Rendering automatisieren das. Du verweist sie auf deine Seite, sie rufen jede URL in deiner Sitemap auf, rendern jede Seite (und führen dabei das JavaScript aus), erfassen das fertige HTML und liefern diese statischen Versionen an Crawler aus, während Browser weiter die interaktive Version bekommen.
Das funktioniert, wenn: Sich deine Inhalte selten ändern. Blogartikel, Produktseiten, Dokumentation. Inhalte, die sich vielleicht einmal am Tag ändern.
Das scheitert, wenn: Deine Inhalte dynamisch sind. Lagerbestände, nutzerspezifische Daten, Echtzeit-Informationen, personalisierte Inhalte. Wenn deine Seite für jeden Besucher anders aussieht, erfasst Pre-Rendering nicht alle Versionen.
Kosten und Aufwand: Solche Dienste kosten je nach Seitenzahl etwa 99 bis 499 $ pro Monat. Du pflegst zwei Versionen deiner Inhalte: eine für den Browser (JavaScript), eine vorab gerenderte für Crawler. Das verdoppelt den Pflegeaufwand. Wenn du einen neuen Artikel veröffentlichst, musst du die statische Version neu bauen und bereitstellen.
Für Seiten mit stabilen Inhalten ist Pre-Rendering ein pragmatischer Mittelweg zwischen Nichtstun und dem Umstieg auf SSR.
Dynamisches Rendering: eine taktische Option für manche Seiten
Beim dynamischen Rendering wird erkannt, welcher User-Agent die Anfrage stellt. Ist es ein Crawler, liefert der Server gerendertes HTML aus. Ist es ein Browser, liefert er die JavaScript-Version. So bleibt dein bisheriger Tech-Stack bestehen, und Crawler bekommen trotzdem die vollständigen Inhalte.
Die Idee ist in der Theorie elegant. In der Praxis ist sie fragil. Du musst:
Eine Liste von KI-Crawler-User-Agents pflegen und sie ständig aktualisieren, wenn neue Crawler auftauchen. Verpasst du einen, sieht dieser Crawler die leere Seite.
Server-seitiges Rendering gezielt für Crawler aufbauen und für Browser client-seitiges Rendering behalten. Das heißt im Grunde, zwei Versionen deiner Seite zu bauen.
Testen, dass beide Versionen synchron bleiben. Ein Fehler in der Crawler-Version zerstört unbemerkt deine Sichtbarkeit in der KI-Suche.
Dynamisches Rendering funktioniert bei einfachen Inhaltsseiten. Bei komplexen Anwendungen ist es mehr Mühe, als es wert ist. Wenn du für Crawler ohnehin auf dem Server renderst, kannst du auch für alle rendern (das ist SSR).
Wie du erkennst, ob deine Seite dieses Problem gerade hat
Du musst nicht raten. Du kannst es direkt prüfen.
Seitenquelltext ansehen: Klicke mit der rechten Maustaste auf deine Seite, wähle „Seitenquelltext anzeigen“ und suche nach deiner Überschrift. Wenn sie nicht im rohen HTML steht, wird sie per JavaScript gerendert. KI-Crawler sehen sie nicht.
Mit curl abrufen: Führe im Terminal curl https://yoursite.com/your-page aus. Wenn der Inhalt nicht dabei ist, hat JavaScript ihn gerendert.
robots.txt prüfen: Wenn du Crawler daran hinderst, JavaScript auszuführen, sehen sie nur das rohe HTML. Prüfe deine robots.txt oder die Crawl-Einstellungen deiner Seite.
Ein Crawler-Tool nutzen: Ein SEO-Crawler kann deine Seiten so abrufen wie ein Crawler. Wenn Inhalte im Browser erscheinen, aber nicht im Crawler, ist JavaScript die Ursache.
KI-Suchmaschinen direkt abfragen: Suche in ChatGPT, Perplexity oder Claude nach konkreten Formulierungen von deinen Seiten. Wenn deine Inhalte nie erscheinen, hast du ein JavaScript-Sichtbarkeitsproblem.
Optimierung für einzelne KI-Crawler
Nicht alle KI-Crawler verhalten sich gleich. Sie haben unterschiedliche Rendering-Fähigkeiten, unterschiedliche Crawl-Häufigkeiten und unterschiedliche Vorlieben bei Inhalten.
ChatGPT (GPTBot): Führt kein JavaScript aus. Ruft rohes HTML ab. Nutzt für Echtzeit-Inhalte den Index einer Suchmaschine. Häufigkeit: etwa wöchentlich bei etablierten Inhalten.
Claude (über eine Suchmaschine): Führt kein JavaScript aus. Ruft rohes HTML ab. Bevorzugt frische, autoritative Inhalte. Häufigkeit: abhängig von Signalen zur Aktualität der Inhalte.
Perplexity: Führt kein JavaScript aus. Ruft rohes HTML ab. Gewichtet Aktualität stark. Inhalte, die älter als 48 Stunden sind, werden möglicherweise abgewertet. Häufigkeit: hoch bei Trendthemen, niedrig bei statischen Inhalten.
KI-Übersichten von Google: Führen JavaScript aus, weil sie dieselbe Rendering-Infrastruktur wie die Google-Suche nutzen. Optimiere aber so, als täten sie es nicht, dann bist du auch für andere KI-Suchmaschinen sichtbarer.
Die praktische Lehre: Optimiere nicht für einen einzelnen Crawler. Rendere deine wichtigsten Inhalte auf dem Server, und du bist für alle sichtbar.
Wobei WEMASY dir hilft
Der Website-Builder von WEMASY erzeugt standardmäßig server-gerendertes HTML. Jede Seite, die du erstellst, wird mit den Inhalten im HTML gebaut, bevor sie den Browser erreicht. Kein JavaScript-Rendering. Deine Seiten sind für KI-Crawler sofort sichtbar.
Wenn du einen Website-Builder auswählst und KI-Sichtbarkeit für dein Geschäft wichtig ist, sollte server-seitiges Rendering eine Voraussetzung sein, kein nachträglicher Gedanke. Sieh dir an, was in jedem WEMASY-Tarif enthalten ist.
Häufig gestellte Fragen
Kann ich JavaScript für interaktive Funktionen nutzen, ohne KI-Crawler zu blockieren?
Ja. Rendere die Kerninhalte (Überschrift, Artikeltext, Produktdetails) auf dem Server und nutze JavaScript für Ergänzungen (Animationen, Formularprüfung, interaktive Widgets). Das nennt man „Progressive Enhancement“. Der Inhalt steht schon im HTML, und JavaScript setzt den letzten Schliff obendrauf. KI-Crawler sehen die Kerninhalte. Browser bekommen das volle interaktive Erlebnis. Mit dem Website-Builder von WEMASY kannst du das direkt auf deiner Website einrichten.
Macht der Umstieg auf server-seitiges Rendering meine Seite langsamer?
Das kann passieren, wenn dein Server zu schwach ist oder deine Seiten komplex sind. Modernes server-seitiges Rendering mit Caching-Ebenen (etwa Edge-Caching bei modernen Hosting-Plattformen) kann sogar schneller sein als client-seitiges Rendering. Der Unterschied ist bei den meisten Seiten klein. Wenn dir die Leistung wichtig ist, teste vorher in einer Staging-Umgebung.
Muss ich meinen gesamten Tech-Stack ändern?
Wenn du React, Vue oder ein anderes JavaScript-Framework als CSR nutzt, heißt der Umstieg auf Next.js, Nuxt oder ein ähnliches SSR-Framework, dass du deine Komponenten für das Server-Rendering umschreiben musst. Das ist kein schneller Tausch. Wenn deine Seite ganz neu ist, wähle von Anfang an ein SSR-First-Framework. Wenn deine Seite schon länger läuft, sind Pre-Rendering oder dynamisches Rendering kurzfristig vielleicht praktischer.
Was ist, wenn KI-Crawler irgendwann JavaScript ausführen können?
Möglich, aber nicht bald. JavaScript auszuführen ist im großen Maßstab rechenintensiv. Solange der geschäftliche Wert von KI-Zitaten die Kosten der Infrastruktur nicht rechtfertigt, werden Crawler weiter rohes HTML abrufen. Rendere deine Inhalte deshalb jetzt auf dem Server und senke dein Risiko.
Schadet das JavaScript-Rendering-Problem meiner Seite meinen Google-Rankings?
Nein. Der Crawler von Google führt JavaScript aus, deine Google-Rankings sind also nicht betroffen. Das Problem liegt bei KI-Suchmaschinen wie ChatGPT, Claude und Perplexity. Sie führen kein JavaScript aus. Rendere deine Inhalte auf dem Server, wenn du in KI-Suchergebnissen sichtbar sein willst, nicht weil Google es verlangt. Das ist ein anderes Problem als SEO.
Haben Nachrichtenseiten dasselbe JavaScript-Problem?
Ja, und es wird oft übersehen. Eine Nachrichtenseite auf einem JavaScript-Framework, das Inhalte client-seitig rendert, bekommt null KI-Zitate, auch wenn die Inhalte veröffentlicht und indexiert sind. Verlage haben das oft zufällig entdeckt, als Artikel, die in Google News rankten, in ChatGPT oder Perplexity null Erwähnungen bekamen. Prüfe deinen Seitenquelltext. Wenn deine Überschrift nicht darin steht, behebe das.