AI Crawler im Logfile 2026: 181.474 Zugriffe ausgewertet – 93 % der KI-Bots waren gefälscht

AI Crawler im Logfile zu finden ist einfach: Ein grep nach GPTBot, ClaudeBot oder PerplexityBot liefert innerhalb von Sekunden eine Zahl. Genau dieses Vorgehen empfehlen praktisch alle Anleitungen, die man zu dem Thema findet – teile die Trefferzahl durch die Gesamtzeilen, und du hast deinen „KI-Bot-Anteil”. Wir haben es gemacht. Und dann haben wir die Zahl überprüft.

Das Ergebnis hat den ganzen Artikel gedreht: Von 54.252 Zugriffen, die sich als KI- oder Suchmaschinen-Crawler ausgaben, waren nur 3.909 echt. Die übrigen 50.343 (92,8 %) kamen von Servern, die keinem der Betreiber gehören, deren Namen sie im User-Agent trugen. Der mit Abstand aktivste „KI-Crawler” auf unserer Seite – 36.146 Zugriffe, mehr als jeder echte Bot – war zu 100 % eine Fälschung, die ausschließlich nach Passwörtern und Zugangsdaten suchte.

Dieser Artikel ist kein Überblicksartikel über AI Crawler. Er ist die Auswertung von 181.474 echten Zugriffen auf getmind.io über 33 Tage, jeder einzelne davon gegen die offiziell veröffentlichten IP-Bereiche der Betreiber geprüft. Alle Zahlen stammen aus unseren eigenen Logs, alle Verifikationslisten direkt von den Herstellern.

Die Kurzfassung

Methodik: Caddy-Access-Logs im JSON-Format, vollständig ab Aktivierung des Loggings am 06.08.2026. Verifikation per Abgleich der Client-IP gegen die offiziellen Prefix-Listen der Betreiber (Abruf am 07.09.2026): claude.com/crawling/bots.json, openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json, perplexity.ai/perplexitybot.json, perplexity.ai/perplexity-user.json sowie Googles googlebot.json und special-crawlers.json.

Warum wir das überhaupt gemessen haben

Am 6. August 2026 ist uns beim Schreiben eines anderen Artikels aufgefallen, dass getmind.io überhaupt kein Zugriffsprotokoll hatte. Im Caddy-Block fehlte die log-Direktive. Ausgerechnet der Artikel, in dem wir Lesern empfehlen, ihre Server-Logs nach KI-Crawlern zu durchsuchen, entstand auf einem Server, der genau das nicht konnte.

Wir haben das damals nachgerüstet und offen in den Artikel geschrieben, dass wir keine Crawler-Zahlen vorlegen können, weil die Messung erst an diesem Tag begann. Eine Historie hätte man erfinden müssen.

Das ist jetzt 33 Tage her. Die Messung existiert. Dies ist die Auswertung.

Der Umweg ist erwähnenswert, weil er das Grundproblem zeigt: Eine fehlende Messung meldet sich nie von selbst. Es gibt keinen Fehler, keine leere Ansicht, keinen roten Status – nur eine Frage, die niemand stellt. Ein Jahr lang hätten wir behaupten können, wir wüssten, wer unsere Seite liest.

Schritt 1: Der naive Ansatz – und was er liefert

Der Standardweg aus jeder Anleitung sieht so aus:

grep -Eic 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Google-Extended|CCBot|Bytespider|Amazonbot' access.log

Auf unseren Daten ergibt dieser Ansatz 43.951 KI-Crawler-Zugriffe gegenüber 21.914 klassischen Suchmaschinen- und SEO-Bots. Eine hübsche Schlagzeile: „KI-Bots lesen unsere Seite doppelt so oft wie Google.”

Aufgeschlüsselt sah die Rangliste so aus:

An dieser Tabelle stimmt eine Sache nicht, und sie ist der Grund für alles Weitere: Claude-SearchBot hatte in 16 Tagen mehr Zugriffe als alle anderen Bots in 33 Tagen zusammen. Für eine Seite mit gut 110 Artikeln ergibt das keinen Sinn. Ein Crawler, der Inhalte indexiert, ist irgendwann fertig.

Statt die Zahl zu veröffentlichen, haben wir sie aufgemacht.

Schritt 2: Die Frage, die alles kippte – was hat der Bot angefordert?

Statuscodes von Claude-SearchBot: {'404': 36146}

Alle 36.146 Zugriffe waren 404. Kein einziger Treffer. Die angeforderten Pfade:

Das ist kein Crawler. Das ist ein Scanner, der systematisch nach Zugangsdaten sucht – AWS-Schlüssel, Git-Zugänge, Deployment-Secrets, Firebase-Credentials – und dabei den Namen eines seriösen KI-Anbieters trägt, weil dieser Name in vielen Konfigurationen von Ratenbegrenzung und Bot-Abwehr ausgenommen ist.

Der zweite Hinweis steckte im User-Agent selbst. Die 36.130 Zugriffe kamen mit dieser Zeichenkette:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; Claude-SearchBot/1.0; +mailto:support@anthropic.com

Daneben fanden sich 68 Zugriffe mit dieser:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Claude-SearchBot/1.0; +claudebot@anthropic.com)

Der Unterschied ist ein einziges Zeichen: Bei der ersten Variante steht nach Gecko ein Semikolon nach der schließenden Klammer statt innerhalb – die Klammer wird nie geschlossen. Dazu eine mailto:-Adresse, die Anthropic in seinen Bots nicht verwendet. Wer den User-Agent gefälscht hat, hat ihn aus dem Gedächtnis nachgebaut.

Aber ein schief geschriebener User-Agent ist ein Indiz, kein Beweis. Ein Angreifer kann ihn morgen korrigieren. Beweisen lässt sich die Sache nur über die Herkunft.

Schritt 3: Der eigentliche Test – die offiziellen IP-Listen

Alle großen Betreiber veröffentlichen inzwischen die IP-Bereiche, aus denen ihre Crawler laufen. Das ist der einzige belastbare Nachweis, denn der User-Agent ist ein Feld, das der Absender frei ausfüllt – eine Behauptung, kein Ausweis.

Die Fundstelle für Anthropic zu finden war der erste Test in Ehrlichkeit. Meine geratenen Adressen (anthropic.com/claudebot.json, anthropic.com/claude-searchbot.json) lieferten alle HTTP 404. Ein 404 auf eine geratene URL beweist gar nichts – er sagt nur, dass die Vermutung falsch war. Erst der Weg über die offizielle Hilfeseite führte zum echten Link:

Anthropic schreibt in seiner Dokumentation ausdrücklich dazu:

„If a crawler has a source IP address on this list, it indicates that the crawler is coming from Anthropic.”

Jede Client-IP aus unseren Logs wurde gegen diese Listen geprüft. Das Ergebnis:

Verifikation per Prefix-Abgleich (ipaddress-Modul, IPv4 und IPv6). Für Googlebot wurden googlebot.json und special-crawlers.json zusammen als gültige Menge behandelt.

Drei Dinge fallen auf:

GPTBot hat unsere Seite in 33 Tagen kein einziges Mal besucht. Alle 273 Zugriffe unter diesem Namen kamen von fremden Servern. Dasselbe gilt für Google-Extended und Perplexity-User. Wer nur grep benutzt, hätte für alle drei eine Aktivität berichtet, die es nicht gab.

Der Verkehr in beide Richtungen ist falsch. Nicht nur wird Aktivität erfunden – die echte Aktivität geht in der Fälschung unter. Echter ClaudeBot: 978 Zugriffe. Im Rohzählwert versteckt zwischen 36.499 Zeilen, die seinen Namen tragen.

Der Anteil ist nicht klein. Wir sind eine Website mit 110 Artikeln und ohne besonderen Bekanntheitsgrad. 92,8 % Fälschungsquote ist kein Ausreißer eines exponierten Ziels, sondern der Normalzustand für jeden Server mit öffentlicher IP.

Schritt 4: Der Fund, der uns selbst überrascht hat – die empfohlene Prüfmethode versagt

Wer nach „Googlebot verifizieren” sucht, findet überall dieselbe Anleitung, und sie stammt von Google selbst:

„Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.”

Anschließend eine Vorwärtsauflösung, um zu prüfen, dass der Name wieder auf dieselbe IP zeigt. Das ist die kanonische Methode, sie steht in Googles offizieller Dokumentation, und sie ist der Standard in unzähligen Blogartikeln und Nginx-Snippets.

Wir haben sie als Kontrolle gegen unsere IP-Prüfung laufen lassen. Bei den echten Googlebot-IPs stimmten beide Verfahren zu 10 von 10 überein (crawl-66-249-65-193.googlebot.com und so weiter). Dann kam die Gegenprobe:

104.155.200.212   212.200.155.104.bc.googleusercontent.com   rDNS bestätigt Google: True
136.109.197.172   172.197.109.136.bc.googleusercontent.com   rDNS bestätigt Google: True

Das sind zwei der IPs, die unsere Prefix-Prüfung als Fälschung markiert hatte. Die rDNS-Methode segnet sie ab – weil googleusercontent.com in der erlaubten Liste steht, und weil jeder eine Maschine in der Google Cloud mieten kann, deren Reverse-DNS auf genau diese Domain endet.

Wir haben das vollständig ausgezählt:

Die aktivste dieser IPs, 34.19.240.51, schickte allein 2.746 Anfragen – und würde von der überall empfohlenen Prüfung als echter Googlebot durchgehen. Alle 11.996 Zugriffe der gefälschten Googlebots waren 404; die meistgesuchten Pfade waren /rclone.conf, /sendgrid.env, /dev/.env und /docker/.env.

🔑 Der Kern des Fundes: Die Anleitung ist nicht veraltet und nicht schlampig abgeschrieben – sie steht so in Googles eigener Doku. Sie ist für einen anderen Zweck korrekt (Google betreibt tatsächlich Dienste unter googleusercontent.com, etwa nutzergesteuerte Abrufe), aber als Bot-Verifikation hat sie ein Loch von der Größe einer öffentlichen Cloud. Eine Prüfung, die eine mietbare Domain als Identitätsnachweis akzeptiert, prüft die Hosting-Rechnung des Absenders, nicht seine Identität.

Wer diese Methode einsetzt, sollte googleusercontent.com streichen und nur googlebot.com und google.com akzeptieren – oder besser gleich gegen die JSON-Prefix-Listen prüfen, die Google im selben Dokument als „automatische Lösung” anbietet.

Schritt 5: Was die echten KI-Crawler tatsächlich gelesen haben

Nach dem Abzug aller Fälschungen bleiben 3.909 verifizierte Zugriffe. Erst hier wird die Auswertung inhaltlich interessant – und sie sieht völlig anders aus als die Rohzahlen.

ClaudeBot: 978 Zugriffe, davon 67 % gar keine Inhalte

659 von 978 Zugriffen gingen an robots.txt und die Sitemap. ClaudeBot holt in 33 Tagen 334-mal unsere Regeldatei ab – etwa zehnmal täglich – und liest dabei kaum Artikel. Das ist ein Crawler, der sehr sorgfältig fragt, ob er darf, und dann wenig tut.

OAI-SearchBot: 45 Zugriffe, davon 45× robots.txt

Der Suchindex-Bot von OpenAI hat unsere Seite in 29 verschiedenen Tagen besucht und ausschließlich robots.txt abgerufen. Nicht einen einzigen Artikel. Nicht die Startseite.

Das war zunächst verdächtig – prüfen wir vielleicht falsch, oder blockieren wir ihn? Unsere robots.txt lautet vollständig:

User-agent: *
Allow: /

Sitemap: https://getmind.io/sitemap-index.xml

Alles erlaubt, für alle. Der Bot fragt also 45-mal nach der Erlaubnis, die ihm 45-mal erteilt wird, und geht dann. Ein Crawler, der nur die Tür prüft und nie eintritt, taucht in jeder grep-Statistik als „aktiv” auf.

PerplexityBot: der einzige, der wirklich liest

Von 771 Zugriffen gingen 678 an echte Inhalte, breit über den Artikelbestand verteilt. Von allen geprüften Bots verhält sich PerplexityBot am ehesten wie ein klassischer Suchmaschinen-Crawler.

ChatGPT-User: der wertvollste Verkehr überhaupt

392 verifizierte Zugriffe, alle mit Status 200, kein einziger 404 – und ausschließlich auf Artikelseiten:

Das ist die Kategorie, die man am wenigsten übersehen sollte. ChatGPT-User ist kein Index-Crawler, sondern der Abruf, der stattfindet, wenn ein Mensch gerade eine Frage gestellt hat und ChatGPT unsere Seite als Antwortquelle heranzieht. Jeder dieser 392 Zugriffe steht für eine reale Nutzeranfrage, in der unser Text zitiert wurde.

Bemerkenswert dabei: Der meistgeholte Artikel ist ausgerechnet der über KI-SEO – und er wurde in beiden Sprachfassungen abgerufen.

Schritt 6: Das größere Bild – 64 % unseres Verkehrs sind Fehlschläge

Wenn man den Blick von den Crawler-Namen löst und den Gesamtverkehr betrachtet, wird das Ausmaß erst deutlich:

Fast zwei Drittel aller Anfragen an unseren Server richten sich an Seiten, die es nicht gibt. Die Suchmuster sind dabei über verschiedene Tarnungen hinweg identisch:

Gezählt wurden Anfragen, deren Pfad eines der Muster .env, .git, credential, .aws, secret, id_rsa, id_ecdsa, .ssh, service-account, config.json, rclone, actuator, .npmrc, token enthält.

Derselbe Angreifer wechselt also lediglich das Namensschild. Mal ist er ein KI-Crawler, mal Googlebot, mal ein Chrome-Browser, mal gibt er sich gar keine Mühe und meldet sich als curl. Das ist der Grund, warum eine Abwehr nach User-Agent-Namen prinzipiell nicht funktionieren kann: Sie filtert das einzige Feld, das der Angreifer kostenlos ändern kann.

Was wir bei der eigenen Messung falsch gemacht haben

Zwei Fehler in unserem eigenen Prüfskript sind bemerkenswert, weil beide plausibel aussahen.

Erstens: Unser erster Auswertungslauf meldete für ChatGPT-User „404-Anteil 90 %, häufigster Pfad /blog/google-ai-seo/”. Das ergab keinen Sinn – die Seite existiert. Der Live-Abruf bestätigte HTTP 200. Die Ursache lag im Skript: Ich berechnete den häufigsten Pfad über alle Zeilen des Bots, während sich die 404-Quote nur auf die gefälschten bezog. Zwei Zahlen aus zwei verschiedenen Grundmengen standen nebeneinander in einer Zeile und lasen sich wie eine Aussage. Ein Bericht, der zwei Kennzahlen nebeneinanderstellt, behauptet stillschweigend, sie beträfen dieselbe Menge.

Zweitens: Der erste Versuch, Anthropics IP-Liste zu holen, lieferte für drei geratene URLs jeweils HTTP 404. Es wäre bequem gewesen, daraus zu schließen, Anthropic veröffentliche keine Liste – die Aussage hätte plausibel geklungen und wäre falsch gewesen. Erst der Umweg über die verlinkte Hilfeseite führte zur echten Adresse. Ein 404 auf eine selbst erfundene URL ist eine Aussage über die Vermutung, nicht über die Welt.

Beide Fehler wurden nur gefunden, weil die Ergebnisse gegengeprüft wurden, statt sie zu übernehmen.

Was man daraus praktisch macht

1. Nicht grep, sondern verifizieren

Der Zählbefehl aus den Anleitungen liefert auf unseren Daten eine um den Faktor 14 zu hohe Zahl. Ein belastbares Vorgehen braucht drei Schritte: Namen im User-Agent finden, IP gegen die offizielle Liste prüfen, erst dann zählen.

# 1. Offizielle Listen holen (regelmäßig auffrischen!)
curl -s https://claude.com/crawling/bots.json         -o anthropic.json
curl -s https://openai.com/gptbot.json                -o gptbot.json
curl -s https://developers.google.com/static/search/apis/ipranges/googlebot.json -o googlebot.json

import ipaddress, json

def load(path):
    d = json.load(open(path))
    v4 = [ipaddress.ip_network(p['ipv4Prefix']) for p in d['prefixes'] if 'ipv4Prefix' in p]
    v6 = [ipaddress.ip_network(p['ipv6Prefix']) for p in d['prefixes'] if 'ipv6Prefix' in p]
    return v4, v6

def verified(ip, nets):
    addr = ipaddress.ip_address(ip)
    pool = nets[1] if addr.version == 6 else nets[0]
    return any(addr in net for net in pool)

Wichtig: Die Listen ändern sich. Anthropics Datei trug beim Abruf den Zeitstempel 2026-08-18T23:56:36Z. Eine eingefrorene Kopie markiert nach einiger Zeit echte Bots als Fälschung – ein Prüfer, der veraltet, wird vom Schutz zur Fehlerquelle.

2. Die rDNS-Methode reparieren, wenn man sie nutzt

Falls man beim Reverse-DNS-Verfahren bleiben will: googleusercontent.com aus der Liste der akzeptierten Domains entfernen. Auf unseren Daten wären damit statt 0,6 % der gefälschten Googlebot-Zugriffe 100 % erkannt worden.

3. Zugangsdaten-Pfade ins Nichts laufen lassen

31.478 Anfragen nach .env und Konsorten haben bei uns korrekt 404 geliefert – das ist der Normalfall bei einer statisch generierten Seite, auf der schlicht keine solchen Dateien liegen. Bei einer klassischen Anwendung ist das keine Selbstverständlichkeit. Wer PHP, Node oder Python ausliefert, sollte prüfen, ob Punkt-Dateien überhaupt vom Webserver erreichbar sind.

Bei uns steht in der Caddy-Konfiguration eine passende Regel; wer nginx nutzt, kennt das Äquivalent:

location ~ /\.(?!well-known) { deny all; }

4. robots.txt entscheidet über Sichtbarkeit, nicht über Sicherheit

Die verifizierten Bots halten sich an die Datei – ClaudeBot fragt sie zehnmal täglich ab. Die gefälschten haben sie kein einziges Mal geholt. Das ist die saubere Arbeitsteilung: robots.txt steuert die Höflichen, gegen die Unhöflichen hilft ausschließlich technische Abwehr.

Wichtig ist dabei die Unterscheidung zwischen den Bot-Typen. Anthropic beschreibt sie in seiner Doku selbst:

Wer Training ablehnen, aber zitiert werden möchte, sperrt gezielt die Trainings-Bots (GPTBot, ClaudeBot, Google-Extended) und lässt die Abruf- und Such-Bots (ChatGPT-User, Claude-User, OAI-SearchBot, PerplexityBot) zu. Wir selbst erlauben derzeit alles – bei 392 verifizierten ChatGPT-User-Abrufen wäre eine pauschale Sperre teuer.

5. Erst loggen, dann behaupten

Der banalste Punkt und der, an dem wir selbst gescheitert sind: Ohne Zugriffsprotokoll ist jede Aussage über Crawler geraten. Für Caddy genügt ein Block:

log {
    output file /var/log/caddy/access.log {
        roll_size 50MiB
        roll_keep 5
        roll_keep_for 720h
    }
}

Ein Hinweis aus eigener Erfahrung: caddy validate meldete uns damals „Valid configuration”, der Reload lief trotzdem in einen Timeout – die Logdatei gehörte root, der Dienst läuft als caddy. Die Website lieferte dabei durchgehend HTTP 200, weil die alte Konfiguration weiterlief. validate prüft die Form, nicht die Ausführbarkeit.

Häufige Fragen

Wie erkenne ich AI Crawler im Logfile?

Der erste Schritt ist eine Suche nach den bekannten Namen im User-Agent (GPTBot, ClaudeBot, Claude-SearchBot, PerplexityBot, ChatGPT-User, OAI-SearchBot, CCBot, Bytespider, Amazonbot). Der entscheidende zweite Schritt ist die Prüfung der Client-IP gegen die offiziellen Prefix-Listen der Betreiber. In unserer Auswertung von 181.474 Zugriffen waren 92,8 % aller Treffer aus Schritt eins gefälscht – die reine Namenssuche liefert also eine massiv überhöhte Zahl.

Sind AI Crawler gefährlich für meine Website?

Die verifizierten Crawler sind harmlos: Sie halten sich an robots.txt, holen Seiten in moderatem Tempo und erzeugen bei uns keinerlei Last. Gefährlich sind die Fälschungen, die ihren Namen tragen. Auf unserem Server suchten 31.478 Anfragen gezielt nach .env-Dateien, AWS-Zugangsdaten, SSH-Schlüsseln und Deployment-Secrets – teils unter dem Namen von Claude-SearchBot, teils als Googlebot, teils als normaler Chrome-Browser.

Kann man GPTBot und ClaudeBot per robots.txt blockieren?

Ja, beide Betreiber respektieren robots.txt nach eigenen Angaben, und unsere Messung stützt das: Die verifizierten Bots holen die Datei regelmäßig ab – ClaudeBot allein 334-mal in 33 Tagen. Anthropic unterstützt zusätzlich die nicht standardisierte Crawl-delay-Angabe. Wichtig: Eine Sperre wirkt nur gegen die echten Bots. Die gefälschten haben unsere robots.txt in 33 Tagen kein einziges Mal abgerufen.

Was ist der Unterschied zwischen ClaudeBot, Claude-User und Claude-SearchBot?

ClaudeBot sammelt Inhalte, die potenziell ins Modelltraining einfließen. Claude-User ruft eine Seite ab, wenn ein Mensch Claude gerade eine Frage stellt. Claude-SearchBot indexiert Inhalte für die Websuche. Eine Sperre hat entsprechend unterschiedliche Folgen: Bei ClaudeBot geht es um Trainingsdaten, bei den beiden anderen um die Sichtbarkeit in Antworten und Suchergebnissen.

Warum ist die Reverse-DNS-Prüfung für Googlebot unzuverlässig?

Googles offizielle Anleitung akzeptiert die Domains googlebot.com, google.com und googleusercontent.com. Die dritte Domain gehört zur Google Cloud und ist für jeden zahlenden Kunden erreichbar. In unseren Daten hätten dadurch 37 von 53 gefälschten Googlebot-IPs die Prüfung bestanden – das entspricht 99,4 % des gefälschten Googlebot-Verkehrs. Wer die Methode nutzt, sollte googleusercontent.com streichen oder direkt gegen die JSON-Prefix-Listen prüfen.

Wie viel Traffic verursachen AI Crawler wirklich?

Bei uns deutlich weniger, als die Rohzahlen suggerieren. Von 181.474 Zugriffen in 33 Tagen stammten 3.909 von verifizierten Crawlern aller Anbieter zusammen, davon nur 2.213 auf echte Inhaltsseiten. Das sind rund 67 Seitenabrufe pro Tag durch sämtliche verifizierten KI- und Suchmaschinen-Bots. Die Last entsteht nicht durch die echten Crawler, sondern durch die Scanner, die sich als solche ausgeben.

Sollte ich AI Crawler blockieren?

Das ist eine Abwägung, keine technische Frage. Trainings-Bots (GPTBot, ClaudeBot, Google-Extended) zu sperren kostet wenig Sichtbarkeit, weil sie nicht für Zitate zuständig sind. Abruf- und Such-Bots (ChatGPT-User, Claude-User, OAI-SearchBot, PerplexityBot) zu sperren macht die Seite in KI-Antworten unsichtbar. Bei uns entfielen 392 verifizierte Zugriffe auf ChatGPT-User – jeder davon steht für eine reale Nutzerfrage, bei der unser Artikel als Quelle herangezogen wurde.

Warum holt OAI-SearchBot nur die robots.txt?

Das haben wir gemessen, aber wir können es nicht erklären. In 29 von 33 Tagen rief der Bot ausschließlich /robots.txt ab – 45 Zugriffe, kein einziger Artikel. An einer Sperre liegt es nicht: Unsere robots.txt erlaubt allen Bots alles. Möglich ist, dass die Datei zentral vorgehalten und der eigentliche Abruf von anderer Infrastruktur erledigt wird. Belegen können wir das nicht – und eine plausible Vermutung ist kein Messergebnis.

Ändern sich die offiziellen IP-Listen?

Ja, regelmäßig. Anthropics Datei trug beim Abruf am 07.09.2026 den Zeitstempel 2026-08-18T23:56:36Z, Googles Listen umfassen zusammen 589 Prefixe. Eine lokal gespeicherte Kopie veraltet und markiert dann echte Crawler als Fälschung. Der Abruf gehört automatisiert – ein Prüfer, der nicht aktualisiert wird, kehrt sein Ergebnis irgendwann ins Gegenteil.

Fazit

Die Ausgangsfrage war einfach: Welche KI-Crawler lesen unsere Artikel? Die einfache Antwort – 43.951 Zugriffe – war um den Faktor 14 zu hoch.

Was übrig bleibt, wenn man die Herkunft prüft, ist ein nüchternes Bild: 3.909 verifizierte Zugriffe in 33 Tagen. ClaudeBot fragt vor allem nach Erlaubnis. OAI-SearchBot fragt nur nach der Erlaubnis. PerplexityBot liest tatsächlich. ChatGPT-User holt sich 392-mal Artikel, weil gerade jemand eine Frage gestellt hat. GPTBot war überhaupt nicht da.

Der eigentliche Befund liegt aber nicht bei den Crawlern, sondern beim Messen selbst. Der User-Agent ist ein Feld, das der Absender ausfüllt – ihn zu zählen heißt, Behauptungen zu addieren. Und die Prüfmethode, die überall gegen dieses Problem empfohlen wird, hat auf unseren Daten 99,4 % der Fälschungen durchgewunken, weil sie eine mietbare Cloud-Domain als Identitätsnachweis akzeptiert.

Beides fällt nie von selbst auf. Ein falsch gezählter Crawler wirft keine Fehlermeldung, und eine Verifikation, die zu viel durchlässt, sieht im Log genauso aus wie eine, die funktioniert – sie meldet sogar häufiger „bestanden”.

Wenn du das auf deinem eigenen Server nachvollziehen willst: Prüfe zuerst, ob du überhaupt ein Zugriffsprotokoll hast. Wir hatten 33 Tage lang keins und hätten es ohne einen Zufall nicht bemerkt.

Weiterlesen: Google KI-SEO beschreibt, wie sich Sichtbarkeit in KI-Antworten überhaupt verändert. IT-Sicherheitslücken ordnet ein, wonach die Scanner in unseren Logs suchen. Und Linux-Server einrichten zeigt die Härtung, die verhindert, dass sie fündig werden.