GPTBot, ClaudeBot und PerplexityBot lesen statisches HTML aus einem Edge-Server – Log-Evidenz-Visualisierung

    GPTBot, ClaudeBot, PerplexityBot: Was AI-Crawler bei Prerendering wirklich sehen

    17. Mai 20264 min Lesezeit
    Till Freitag

    TL;DR: „AI-Crawler executen kein bis kaum JavaScript. Wer seine SPA nicht prerendert, ist für ChatGPT, Claude und Perplexity de facto unsichtbar. Drei Monate Edge-Logs zeigen, wie oft sie kommen – und was sie tatsächlich abholen."

    — Till Freitag

    Warum diese Auswertung

    Wir reden im Cluster oft darüber, dass Prerendering die Brücke zur AI-Suche ist. Aber „LLMs mögen statisches HTML" ist eine Behauptung. Dieser Artikel liefert die Evidenz.

    Wir haben drei Monate Vercel-Edge-Logs unserer eigenen Site (Playwright-SSG) und einer Kundensite (klassische SPA, kein Prerendering) ausgewertet. Gleicher Traffic-Bereich, gleiches Stack-Setup minus Prerendering. Das ist kein Lab-Benchmark – das ist Produktions-Traffic.

    Die drei relevanten User-Agents

    BotUser-Agent (Auszug)BetreiberZweck
    GPTBotMozilla/5.0 (compatible; GPTBot/1.x; +https://openai.com/gptbot)OpenAITraining + ChatGPT Search
    OAI-SearchBotMozilla/5.0 (compatible; OAI-SearchBot/1.x; +https://openai.com/searchbot)OpenAIChatGPT Search live retrieval
    ClaudeBotMozilla/5.0 (compatible; ClaudeBot/1.0; +claudebot@anthropic.com)AnthropicTraining + Claude Citations
    PerplexityBotMozilla/5.0 (compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)PerplexitySearch Index + Answer Engine
    Perplexity-UserPerplexity-User/1.0PerplexityOn-Demand-Fetch bei User-Query

    Wichtig: GPTBot ≠ OAI-SearchBot. GPTBot indexiert breit für Training. OAI-SearchBot holt gezielt URLs, die ChatGPT in einer Antwort zitieren will. Wer in ChatGPT als Quelle auftauchen will, optimiert nicht für GPTBot – sondern für OAI-SearchBot und ähnliche „User-Triggered"-Crawler.

    Was die Logs zeigen: Crawl-Volumen

    Drei Monate, eine Million Edge-Requests, gefiltert nach User-Agent:

    BotRequestsAnteil aller CrawlerTrend
    Googlebot41 %Referenzstabil
    Bingbot12 %stabil
    GPTBot9 %+40 % QoQ
    ClaudeBot7 %+120 % QoQ
    PerplexityBot6 %+60 % QoQ
    OAI-SearchBot4 %neu
    Sonstige (Bytespider, Amazonbot, etc.)21 %gemischt

    Die drei großen AI-Crawler machen zusammen rund ein Viertel des nicht-menschlichen Traffics aus. Tendenz: steil steigend. Wer 2024 noch sagen konnte „das ist Nische", kann das 2026 nicht mehr.

    Was sie tatsächlich abholen

    Hier wird es interessant. Wir haben pro Bot drei Werte gemessen:

    1. HTML-Request (das initiale GET auf die Route)
    2. JS-Bundle-Requests (lädt der Bot überhaupt die App-Bundles?)
    3. Hydration-Indikator (kommt ein Followup-Request, der nur nach Hydration entstehen kann – z. B. ein Lazy-Image, ein API-Call?)

    Auf unserer prerendered Site

    BotHTMLJS-BundleHydration-Followup
    Googlebot100 %78 %31 %
    GPTBot100 %3 %0 %
    OAI-SearchBot100 %0 %0 %
    ClaudeBot100 %0 %0 %
    PerplexityBot100 %1 %0 %

    Auf der nicht-prerendered SPA des Kunden

    BotHTMLJS-BundleHydration-Followup
    Googlebot100 %71 %22 %
    GPTBot100 %2 %0 %
    OAI-SearchBot100 %0 %0 %
    ClaudeBot100 %0 %0 %
    PerplexityBot100 %0 %0 %

    Das ist der Befund in einer Tabelle: AI-Crawler laden Bundles praktisch nicht. Sie führen sie nicht aus. Sie sehen, was im ersten HTML-Response steht – nicht mehr.

    Googlebot rendert in einem signifikanten Teil der Fälle JavaScript (über den Web Rendering Service). Die AI-Crawler tun das schlicht nicht. Auch nicht „manchmal", auch nicht „bei wichtigen Seiten". In drei Monaten Daten: praktisch nie.

    Was das praktisch bedeutet

    Auf der nicht-prerendered Kunden-SPA bekommen GPTBot, ClaudeBot und PerplexityBot dieses HTML:

    <!doctype html>
    <html><head>
      <title>Loading...</title>
    </head><body>
      <div id="root"></div>
      <script type="module" src="/assets/index-abc123.js"></script>
    </body></html>

    Das ist alles. Keine Headline. Kein Text. Kein JSON-LD. Kein OpenGraph mit echtem Title. Für das Trainings-Set und für den Live-Retrieval-Index ist diese Seite ein leeres Dokument mit dem Inhalt „Loading...".

    Auf unserer prerendered Site bekommen sie pro Route:

    • vollständiger <title> und <meta description>
    • alle <h1> bis <h3> mit echtem Text
    • der komplette Artikel-Body im HTML
    • JSON-LD (Article, BreadcrumbList, Organization)
    • OpenGraph mit echtem Title, Description, og:image

    Das ist der ganze Unterschied. Nicht „etwas besser sichtbar". Sondern „existiert" vs. „existiert nicht".

    Warum AI-Crawler kein JavaScript ausführen

    Drei Gründe, die in den Bot-Docs und in Engineering-Posts der Anbieter durchscheinen:

    1. Kosten. Headless-Chromium pro URL ist um Größenordnungen teurer als ein simples fetch. Bei den Crawl-Volumina, über die wir reden (Milliarden URLs/Monat), ist das nicht skalierbar.
    2. Determinismus. LLM-Trainingsdaten sollen reproduzierbar sein. Hydration-Race-Conditions, A/B-Tests, Login-Walls per JS – all das produziert Noise.
    3. Geschwindigkeit. Bei On-Demand-Retrieval (Perplexity-User, OAI-SearchBot) muss die Antwort in Sekunden stehen. Kein Platz für 3 s Hydration.

    Googlebot kann sich Headless-Rendering leisten, weil es seit 15 Jahren ein eigener Infrastruktur-Stack ist. OpenAI, Anthropic und Perplexity bauen das nicht von Grund auf nach. Sie nehmen HTML wie es kommt.

    Was die Logs noch zeigen: Cache-Verhalten

    Ein zweiter Befund, der unser SSR-vs-Pre-Rendering-Argument für Mykeythai stützt:

    AI-Crawler respektieren Cache-Control und ETag deutlich konsequenter als Googlebot. Auf der prerendered Site sehen wir bei GPTBot und ClaudeBot:

    • 70–80 % der Re-Crawls landen auf 304 Not Modified
    • Edge-CDN beantwortet sie aus Region-Cache
    • Origin wird nicht angefasst

    Auf der nicht-prerendered SPA: alle Requests gehen durch (200 mit leerem HTML), weil das HTML praktisch nie einen brauchbaren ETag hat. Mehr Traffic, weniger Inhalt. Schlechtester Trade-off möglich.

    Was du jetzt tun solltest

    Konkret, in dieser Reihenfolge:

    1. Logs filtern. vercel logs --output raw oder direkt aus deinem Edge-Provider. User-Agent-Filter auf GPTBot|ClaudeBot|PerplexityBot|OAI-SearchBot. Wenn die Zahl bei null liegt: du wirst nicht gefunden, weil du nicht prerenderst – oder weil deine robots.txt blockt. Prüf beides.
    2. robots.txt ehrlich machen. Wer in AI-Antworten zitiert werden will, muss diese Bots erlauben. Default-Deny ist eine bewusste Entscheidung, kein Versehen. Unsere Position dazu steht im Linking-Guidelines-Dokument.
    3. Prerendering einschalten. Wenn du auf Lovable bist: Discoverability-Release nutzen. Wenn du eigene Vite-SPAs deployst: Playwright-SSG-Tutorial folgen.
    4. JSON-LD ergänzen. AI-Crawler lieben strukturierte Daten – sie sparen ihnen das Parsen. Wie das automatisiert geht: JSON-LD-Schema für SPAs.
    5. Nach 4 Wochen erneut messen. Crawl-Volumen sollte sich verdoppeln bis vervierfachen. Cache-Hit-Rate Richtung 70 %+.

    Fazit

    Wer 2026 über GEO redet, ohne über Prerendering zu reden, redet über ein Plakat an einer Wand, die kein Licht hat. Die Logs sind eindeutig: AI-Crawler lesen HTML. Sie führen kein JavaScript aus. Und sie kommen häufiger, als die meisten Marketing-Decks behaupten.

    Wenn du wissen willst, ob deine Site für ChatGPT, Claude und Perplexity existiert, schau in deine Edge-Logs. Wenn du das nicht hast, schreib uns. Wir machen den Check kostenlos.

    👉 AI-Discoverability-Audit für deine App →

    TeilenLinkedInWhatsAppE-Mail

    Verwandte Artikel

    Vergleich Static Site Generation vs. Server-Side Rendering – Edge-CDN gegen Server-Rack
    17. Mai 20264 min

    SSR oder Pre-Rendering? Was wir für Mykeythai gegen unseren Standard-Ansatz geprüft haben

    Lovable bringt jetzt SSR per TanStack Start. Wir haben für Mykeythai geprüft, ob wir umstellen – und warum unser Pre-Ren…

    Weiterlesen
    Lovable App mit strukturiertem HTML, sichtbar für Google, ChatGPT und Perplexity
    13. Mai 20266 min

    Lovable SEO/AEO: Jede App ab Tag 1 für Google und ChatGPT sichtbar

    Lovable bringt Server-Side-Rendering, Pre-Rendering für Bestands-Apps, Semrush direkt im Builder-Chat und einen On-Deman…

    Weiterlesen
    Prerendering-Pipeline-Visualisierung: SPA, Playwright, Schema.org und Edge-Deploy
    29. April 20263 min

    Prerendering: Wie aus einer React-SPA eine Google-freundliche Seite wird

    React-SPAs sind für Crawler unsichtbar. Prerendering löst das – ohne Next.js, ohne SSR-Server. So funktioniert unsere Pl…

    Weiterlesen
    serponado.io – von Felix Grote (seobuddha) mit Vibe Coding in 12 Stunden gebaut
    10. Juni 20263 min

    serponado.io – wie Felix Grote in 12 Stunden eine SEO-Contest-Seite gevibe-coded hat

    Felix Grote von der seobuddha GmbH hat in 12 Stunden serponado.io aufgesetzt – eine der kreativsten Seiten im SEO-Contes…

    Weiterlesen
    Cloudflare und Vercel im direkten Vergleich – zwei Edge-Plattformen, zwei Philosophien
    4. Juni 20265 min

    Cloudflare vs. Vercel – Was nutzt man wann?

    Vercel oder Cloudflare? Beide hosten deine moderne Web-App am Edge – aber sie verfolgen grundverschiedene Strategien. Wi…

    Weiterlesen
    ZeroClaw KI-Agent in Rust – minimaler Footprint, maximale Performance
    14. März 20265 min

    ZeroClaw Deep Dive – NullClaws Nachfolger in Rust im Detail

    ZeroClaw ist der Rust-Nachfolger von NullClaw – mit 26.800+ GitHub Stars, Single-Binary-Deployment und 99% kleinerem Foo…

    Weiterlesen
    Minimalistische Illustration eines Entwicklers mit Ponytail und ovaler Brille, der skeptisch Code auf einem Bildschirm betrachtet
    14. Juni 20265 min

    Ponytail: Warum der beste Code der Code ist, den du nie geschrieben hast

    Ein Dev hat Ponytail gebaut – weil seine AI-Agenten 500 Zeilen für ein 5-Zeilen-Problem schrieben. Das Ergebnis: 80-94% …

    Weiterlesen
    Serponado-Tagebuch – Live-Log zum Seobility SEO-Contest 2026 auf till-freitag.comDeep Dive
    9. Juni 20268 min

    Serponado-Tagebuch – täglich live aus dem SEO-Contest 2026

    Tägliches Log aus dem Seobility SEO-Contest 2026: Was wir für das Keyword Serponado tun, was funktioniert, was floppt – …

    Weiterlesen
    Serponado – Fantasie-Keyword des Seobility SEO-Contests 2026
    9. Juni 20265 min

    Serponado – Was ist das? Der SEO-Contest 2026 erklärt

    Serponado ist das Fantasie-Keyword des Seobility & Agenturtipp.de SEO-Contests 2026. Wir dokumentieren live, mit welcher…

    Weiterlesen