Warum die meisten AI-Crawler deine JavaScript-Inhalte nicht lesen können.
Deine Produktseite sieht im Browser vollständig aus. Aber GPTBot, ClaudeBot und PerplexityBot, also die Crawler-Programme, die für ChatGPT, Claude und Perplexity Websites einlesen, öffnen nie einen Browser. Sie lesen das rohe HTML, das dein Server sendet, und alles, was JavaScript darauf aufbaut, existiert für sie schlicht nicht. So siehst du deine Seite so, wie AI sie sieht, in etwa zwei Minuten.
Es gibt zwei Versionen deiner Website. AI sieht nur eine.
Wenn ein Mensch deine Produktseite öffnet, passiert vieles, das er nie bemerkt. Der Browser lädt das HTML, lädt dann JavaScript-Dateien, führt sie aus, holt Produktdaten aus deinem Shopsystem und baut die fertige Seite Stück für Stück zusammen: Der Preis erscheint, Bewertungen laden, das FAQ-Akkordeon klappt auf. Das polierte Ergebnis ist Version eins, die gerenderte Seite. Rendern ist schlicht das Fachwort für diese Zusammenbau-Arbeit.
Version zwei ist das, was vor all dem existierte: die rohe HTML-Antwort, genau so, wie dein Server sie gesendet hat. Bei vielen modernen Shops ist diese rohe Antwort fast leer. Das gilt besonders für sogenannte Single-Page-Apps mit React oder Vue, also Seiten, bei denen der Browser die komplette Seite erst per JavaScript aufbaut. Die rohe Antwort sieht dann ungefähr so aus:
Seitenquelltext einer client-seitig gerenderten Produktseite
<body>
<div id="root"></div>
<script src="/assets/main.8f3a2c.js"></script>
</body>Kein Produktname. Kein Preis. Keine Beschreibung, keine Bewertungen, kein FAQ. All das kommt erst später, wenn JavaScript in einem Browser läuft. Und hier liegt der entscheidende Punkt: Die meisten AI-Crawler führen dieses JavaScript nie aus. Sie fordern die Seite an, lesen die rohe Antwort und ziehen weiter. Wenn dein Produkt nur in Version eins existiert, dann existiert dein Produkt für ChatGPT, Claude und Perplexity nicht.
Welche Crawler JavaScript rendern und welche nicht
JavaScript im Crawl-Maßstab auszuführen ist teuer. Es bedeutet, für jede Seite des Webs so etwas wie einen vollständigen Browser laufen zu lassen, also spart sich das fast jeder AI-Crawler. Auf Basis der veröffentlichten Dokumentation der Crawler und des beobachteten Verhaltens zum Zeitpunkt dieses Artikels:
Crawler | Versorgt | Führt JavaScript aus? |
|---|---|---|
GPTBot / OAI-SearchBot | ChatGPT, OpenAI-Suche | Nein. Liest die rohe HTML-Antwort. |
ClaudeBot | Claude | Nein. Liest die rohe HTML-Antwort. |
PerplexityBot | Perplexity | Nein. Liest die rohe HTML-Antwort. |
Googlebot | Google-Suche, AI Overviews | Teilweise. Rendering passiert verzögert in einem zweiten Durchlauf. |
Bingbot | Bing, Copilot | Eingeschränkt. Verlass dich nicht darauf. |
Das Muster ist deutlich: Das eine Ökosystem mit ausgereiftem JavaScript-Rendering ist die klassische Google-Suche, und selbst dort ist Rendering verzögert und nicht für jede Seite garantiert. Die Crawler hinter den am schnellsten wachsenden AI-Assistenten lesen rohes HTML, Punkt. Wer dir sagt „Google rendert JavaScript, also ist alles gut", beantwortet eine Frage von 2019, nicht die Frage, ob ein AI-Shopping-Agent deinen Katalog sehen kann.
Was typischerweise verloren geht
Der Schaden ist selten alles oder nichts. Auch bei Shops, die die Grundseite server-seitig rendern, werden bestimmte besonders wertvolle Bausteine oft nachträglich per JavaScript eingefügt und sind in der rohen Antwort unsichtbar:
Preise und Verfügbarkeit, die nach dem Laden live aus dem Shopsystem nachgeladen werden.
Produktvarianten, bei denen Größen, Farben und ihre Preise erst existieren, nachdem ein Skript gelaufen ist.
Bewertungen und Sterne, die ein externes Review-Widget nachlädt.
FAQ-Akkordeons, deren Fragen und Antworten im JavaScript-Bundle leben, nicht im HTML.
Lieferzeiten, Versandkosten und Bestand pro Standort, die auf Abruf geholt werden.
Schau dir die Liste noch einmal an: Das ist fast genau die Information, die ein AI-Assistent braucht, um ein Produkt zu empfehlen oder zu kaufen. Die Marketing-Headline überlebt meistens. Die Fakten oft nicht.
Teste es selbst: drei Wege, ganz ohne Entwickler
Terminal · eine Seite abrufen wie GPTBot
curl -A "GPTBot" https://www.example-shop.de/products/pour-over-set | grep "49,90"Kommt diese Suche leer zurück, während der Preis in deinem Browser klar sichtbar ist, hast du das gesamte Problem gerade in einer Zeile reproduziert.
Was wirklich hilft
Es gibt drei ehrliche Wege, und welcher passt, hängt davon ab, wie viel du an deinem Stack ändern kannst:
Server-Side-Rendering (SSR). Die sauberste Lösung. Die Zusammenbau-Arbeit wandert auf deinen Server: Er liefert das fertige HTML, JavaScript ergänzt nur noch Interaktivität. Moderne Frameworks (Next.js, Nuxt, Astro und andere) unterstützen das gut. Der Haken: Bei einem bestehenden Shop ist das ein echtes Entwicklungsprojekt, kein Schalter, den man umlegt.
Pre-Rendering. Seiten werden beim Build oder durch einen Pre-Render-Dienst zu statischem HTML gerendert, und Crawler bekommen die fertige Version. Funktioniert gut für Kataloge, die sich nicht im Minutentakt ändern. Schwieriger wird es bei Live-Beständen und häufigen Preisänderungen, weil der Snapshot der Realität hinterherhinken kann.
Die Fakten server-seitig als strukturierte Daten ausliefern. Statt den Storefront umzubauen, veröffentlichst du die maschinenrelevanten Fakten (Produkte, Preise, Verfügbarkeit, Antworten) als sauberes server-gerendertes HTML mit strukturierten Daten, also Fakten in einem Format, das Maschinen direkt lesen können. Der Schema-Export von Klariton geht diesen Weg: eine crawlbare Subdomain, generiert aus deinen Shop-Daten, angebunden mit einer Zeile in der robots.txt (der kleinen Textdatei, die Crawlern sagt, wo sie hindürfen), oder ausgeliefert über deine eigene Server-API in rund zehn Zeilen Code. Dein Shop bleibt exakt, wie er ist. Crawler bekommen eine Version, die sie lesen können.
Übrigens gilt dieselbe Logik über Shops hinaus: Wenn du Dienstleistungen verkaufst, ist die Lesbarkeits-Lücke meist noch größer. Warum Dienstleister und B2B-Unternehmen strukturierte Daten noch dringender brauchen als Shops, liest du im eigenen Artikel dazu.
Eine Warnung auf der ehrlichen Seite der Rechnung: Baue deine Strategie nicht auf den Engines auf, die rendern. Googles Rendering existiert, aber es ist verzögert, ressourcenbegrenzt und deckt genau ein Ökosystem ab. Die Entwicklung bei Agentic Reach geht in Richtung von mehr Agenten mit schnellen, günstigen, reinen HTML-Anfragen, nicht weniger: Laut Visa nutzen 47% der US-Shopper bereits AI-Tools für mindestens eine Shopping-Aufgabe, und Visa erwartet bis zum Weihnachtsgeschäft 2026 Millionen Verbraucher, die per AI-Agent kaufen. Server-seitig ausgelieferter Inhalt ist die Basis, die für alle funktioniert.
Häufige Fragen
Stell deine Frage zu Klariton.
Gegroundet in Klaritons eigenem Wissen, belegt statt erfunden.
Wie sichtbar ist deine Marke für AI?
Der kostenlose AI-Visibility-Check zeigt dir in unter einer Minute, wie AI-Assistenten deinen Shop heute sehen.