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:
<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
Öffne eine Produktseite im Browser, Rechtsklick, dann „Seitenquelltext anzeigen". Das zeigt die rohe Server-Antwort, nicht die gerenderte Seite. Suche jetzt (Strg+F / Cmd+F) nach deiner Produktbeschreibung und deinem Preis. Findest du sie dort nicht, finden die meisten AI-Crawler sie auch nicht.
Der curl-Befehl unten lädt eine Seite genau so, wie ein Crawler es tut: eine Anfrage, kein JavaScript. Leite das Ergebnis in eine Suche nach deinem Preis oder Produktnamen und sieh, was ein Bot tatsächlich bekommt.
Der kostenlose AI-Visibility-Check liest deine Seiten so, wie AI-Crawler es tun, und zeigt dir, was maschinenlesbar ist und was fehlt, über mehrere Seiten hinweg und ganz ohne Setup.
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
Führt wirklich kein AI-Crawler JavaScript aus?
Google ist die nennenswerte Ausnahme: Der Google-Crawler kann JavaScript für die Suche rendern, und AI-Features auf Basis des Google-Index profitieren indirekt davon. GPTBot, ClaudeBot, PerplexityBot und die meisten anderen AI-Crawler holen die rohe HTML-Antwort und hören dort auf. Da du nicht steuern kannst, welcher Crawler vorbeikommt, ist Inhalt in der Server-Antwort die einzige verlässliche Basis.
Mein Shop läuft auf Shopify oder WooCommerce. Betrifft mich das?
Klassische Themes rendern auf beiden Plattformen den Großteil der Produktinhalte server-seitig, der Kern der Seite ist also meist sichtbar. Die Probleme beginnen bei Inhalten aus Apps und Widgets: Bewertungs-Sektionen, FAQ-Akkordeons, Größentabellen, Bundle-Angebote und ähnliche Elemente werden oft erst nach dem Laden per JavaScript eingefügt. Teste die Seiten, die zählen, mit dem Seitenquelltext, statt es anzunehmen.
Ist ein React- oder Headless-Storefront schlecht für AI-Sichtbarkeit?
Nicht per se. Die Frage ist, wo die Seite zusammengebaut wird. Ein Headless-Storefront, also ein Shop, dessen Oberfläche als eigene App auf dem Shopsystem aufsetzt, ist bestens lesbar, solange er Server-Side-Rendering oder Pre-Rendering nutzt, denn dann liefert der Server vollständiges HTML. Eine rein client-seitige App baut dagegen alles erst im Browser des Besuchers auf und liefert eine fast leere HTML-Hülle. Diese Hülle ist alles, was die meisten AI-Crawler je sehen werden.
Was ist die schnellste Lösung, wenn ich meinen Shop-Stack nicht ändern kann?
Liefere die Fakten server-seitig aus, ohne den Storefront anzufassen. Ein praktischer Weg ist eine crawlbare Subdomain, die deine Produkte und Antworten als sauberes HTML mit strukturierten Daten spiegelt, automatisch generiert aus deinen Shop-Daten. Der Schema-Export von Klariton funktioniert genau so: eine Zeile in der robots.txt genügt, um Crawler dorthin zu leiten, oder rund zehn Zeilen, wenn du lieber über deine eigene Server-API auslieferst.
Der kostenlose Klariton-Check liest deine Seiten wie GPTBot: kein JavaScript, keine Gnade. Du bekommst einen konkreten Report, was heute maschinenlesbar ist und was unsichtbar bleibt, bevor ein AI-Assistent das für dich entscheidet.