Ich betreibe einen kleinen Home-Assistant-/Self-Hosting-Blog. An einem normalen Tag schauen ein paar Dutzend Menschen vorbei. Als ich endlich meine nginx-Logs nach AI-Crawlern durchsucht habe, stoppte mich die Zahl: in neun Tagen haben AI-Bots die Seite 18.209 Mal getroffen. Bei einem Blog dieser Größe lesen mich inzwischen mehr Maschinen als Menschen.
Hier die komplette Aufschlüsselung, was mich überrascht hat, und ein paar Punkte, die die meisten „soll ich AI-Bots blockieren?“ -Diskussionen falsch verstehen.
Die nackten Zahlen (9 Tage, ein kleiner Blog)
Von 348.667 Requests insgesamt kamen 18.209 (5,2 %) von AI-/LLM-User-Agents:
Bot Requests Was es ist
-------------------------------------------------------------
ChatGPT-User 6.687 OpenAI - Live-Abruf im Auftrag eines Nutzers
Bytespider 3.369 ByteDance / TikTok Crawler
meta-externalagent 3.274 Meta AI
Amazonbot 1.923 Amazon
OAI-SearchBot 1.211 OpenAI Search-Index
ClaudeBot 850 Anthropic - Training / Index-Crawler
PerplexityBot 319 Perplexity
DuckAssistBot 225 DuckDuckGo AI
GPTBot 172 OpenAI Training-Crawler
CCBot 86 Common Crawl (speist viele Modelle)
YouBot 68 You.comÜberraschung #1: Der größte „AI-Bot“ ist gar kein Crawler
Die mit Abstand größte Quelle - ChatGPT-User, 6.687 Requests - crawlt nicht, um ein Modell zu trainieren. Es ist ein Live-Abruf: Jemand stellt ChatGPT eine Frage, ChatGPT hält meine Seite für relevant und holt sie in Echtzeit, um zu antworten. Genauso bei Perplexity-User und den anderen Assistenz-Abrufern.
Das dreht die „soll ich blockieren?“-Rechnung um. ChatGPT-User scrapt dich nicht - es ist ein echter Mensch, über seinen Assistenten, der deine Seite gerade jetzt liest. Blockierst du es, stoppst du kein Training; du verschwindest nur aus den Antworten und verlierst den Besuch. (Die andere Seite sehe ich in meinen Analytics: echte Sessions von claude.ai und gemini.google.com.)
Das Mental-Modell „AI-Bot = Scraper zum Blockieren“ ist also für einen großen Teil des Traffics falsch. Es gibt Training-Crawler (GPTBot, ClaudeBot, CCBot) und es gibt Live-Answer-Engine-Abrufer (ChatGPT-User, Perplexity-User, DuckAssistBot). Sie gleich zu behandeln ist der Fehler.
Überraschung #2: robots.txt-Verhalten ist völlig uneinheitlich
Ich habe geprüft, wer überhaupt /robots.txt abruft:
ClaudeBot 233 gewissenhaft - prüft ständig
PerplexityBot 56 schaut rein
Bytespider 77 ruft sie ab (ob es sich dran hält, ist sein Ruf)
GPTBot 0 in diesem Fenster kein einziges Mal (geringes Volumen)
ChatGPT-User 0 nie - und das ist korrekt (nutzer-initiiert, wie ein Browser)Das Praktische daran: Ein pauschales Disallow befolgen die braven Training-Crawler, die Nutzer-Abrufer ignorieren es - weil robots.txt nie für sie gedacht war. Wenn dein Ziel „kein Training füttern, aber in Antworten auftauchen“ ist, macht der Standard schon ungefähr das Richtige - aber nur für die Bots, die sich daran halten.
Die Lücke, die niemand erwähnt: Diese Crawler führen kein JavaScript aus
Das ist die, die mich wirklich etwas gekostet hat - und der Grund, warum ich am Ende ein kleines Tool dafür gebaut habe.
Fast jeder AI-Crawler holt dein rohes Server-HTML und führt kein JavaScript aus. Wenn dein Framework also JSON-LD-Structured-Data client-seitig einfügt, oder dein Streaming-SSR Meta-Tags in den Body statt in den initialen Head schreibt, sind diese Signale für den Crawler unsichtbar - obwohl Google sie rendert und jede SEO-Browser-Extension sagt, alles sei in Ordnung.
Ich habe auf meiner eigenen Seite genau sechs Seiten gefunden, die das tun - weil ich einen Crawler gebaut habe, der bewusst die JS-lose Ansicht parst und gegen das hydratisierte DOM diffed. Googlebot rendert; GPTBot und ClaudeBot meist nicht. Wenn dir wichtig ist, in AI-Antworten korrekt repräsentiert zu sein, müssen deine Structured Data und Metadaten im Server-HTML stehen - nicht erst nach der Hydration aufgemalt werden.
Was ich konkret damit machen würde
Blockiere nicht reflexartig „AI-Bots“. Trenne Training-Crawler (GPTBot, ClaudeBot, CCBot - robots.txt wirkt) von Live-Answer-Abrufern (ChatGPT-User, Perplexity-User - die zu blockieren kostet echte Referrals).
Verifiziere per ASN / Reverse-DNS, nicht per User-Agent. Der UA-String ist trivial fälschbar; ein „GPTBot“ von einer beliebigen Consumer-IP ist kein GPTBot.
Pack Structured Data + Metadaten ins server-gerenderte HTML. Wenn es erst nach JS erscheint, sehen die AI-Crawler es nie.
Behalte Bytespider im Auge, falls Last ein Thema ist - es ist der aggressivste der echten Crawler.
Für einen Blog mit ein paar Dutzend menschlichen Lesern am Tag sind AI-Crawler inzwischen das größte Nicht-Such-Publikum, das auf den Server trifft. Sie gehen nicht weg - es lohnt sich also zu wissen, welche dich lesen, und sicherzustellen, dass sie auch sehen, was du veröffentlichst.
Den JS-losen-Ansicht-Crawler, den ich benutzt habe, gibt es Open Source (seo-geo-audit) - er flaggt genau diese Lücke, plus die üblichen SEO-Checks, in reinem Node ohne kostenpflichtige Abhängigkeiten.
