Die gute Nachricht: Sie sind dem AI-Bot-Ansturm nicht schutzlos ausgeliefert. Es gibt mittlerweile eine Reihe von Methoden und Funktionen, um Bot-Traffic entweder gar nicht erst in Ihre Analytics-Daten gelangen zu lassen oder ihn zumindest nachträglich auszusortieren.
Im Folgenden geben wir einen Überblick – von Bordmitteln in gängigen Analytics-Tools bis hin zu neuen, innovativen Ansätzen – und gehen auf die Vor- und Nachteile ein. Außerdem diskutieren wir, ob es manchmal sinnvoller ist, Ihre echten Nutzer*innen zu isolieren, statt jeden Bot krampfhaft auszuschließen.
Die Serie im Überblick
Vorige Artikel:
Einführung: AI-Traffic entschlüsselt: eine Serie für Analytics-Profis
- Teil 1: AI-Bots vs. AI-SEO: die zwei Gesichter des AI-Traffics
- Teil 2: AI-Traffic und Datenqualität: Wie KI-Bots Ihre Daten verzerren
Nächste Artikel:
Die einfachste Stufe der Verteidigung: Nutzen Sie die eingebaute Bot-Filtering-Funktion Ihres Analytics-Werkzeugs.
Google Analytics etwa bietet schon lange die Option „Bekannte Bots und Spider ausschließen“. In Google Analytics 4 (GA4) ist diese Filterung mittlerweile standardmäßig aktiv.
GA4 basiert auf einer regelmäßig aktualisierten IAB-Bot-Liste und entfernt Traffic von bekannten Crawlern und Spidern automatisch aus Ihren Reports. Das heißt, Hits von Bots, die sich eindeutig durch ihren User-Agent zu erkennen geben, tauchen gar nicht erst in den GA4-Daten auf.
In Universal Analytics (GA3) musste man das noch manuell in den View-Einstellungen ankreuzen; in GA4 passiert das „by default“. Allerdings gilt: Wirklich alle Bots erwischt GA4 damit nicht, vor allem neuartige oder solche, die nicht auf der Standardliste stehen, können durchrutschen. Daher ist oft ergänzend ein eigenes Filtering nötig.
Auch Adobe Analytics verfügt über Bot-Filterfunktionen. Adobe nutzt ebenfalls die IAB/ABC-International-Spiders-&-Bots-Liste, die bekannte Bots anhand ihres User-Agents identifiziert.
In den Adobe-Admin-Einstellungen (Report Suite Settings) gibt es den Bereich Bot Rules: Hier können Sie die Standard-Botfilterung aktivieren, sodass bekannte Bots automatisch aus den Reports ausgeschlossen werden.
Adobe bietet darüber hinaus individuelle Bot-Regeln an (dazu gleich mehr), aber schon die Grundfunktion spart viel Arbeit.
Wichtig zu wissen: Hits, die als Bot erkannt und gefiltert werden, erscheinen in Adobe nur noch in speziellen Bot-Berichten, nicht in den normalen Traffic-Zahlen. Adobe behandelt Bot-Daten also getrennt, damit sie Ihre normalen Analysen nicht verfälschen.
Piano Analytics (ehemals AT Internet) setzt ebenfalls auf automatisierte Filterung. Laut Piano-Doku wird die Analytics-Datenerfassung standardmäßig um alle Treffer bereinigt, die auf einer von einer Organisation gepflegten Roboterliste stehen – das dürfte ebenfalls die IAB-Liste sein.
Piano filtert Bots anhand von IP-Adressen und User-Agent-Mustern aus, sodass diese gar nicht erst in die Datenauswertung gelangen. Allerdings weisen sie darauf hin, dass neu auftauchende Bots eventuell nicht sofort erkannt werden. Sollte Ihnen in Piano also ein ungewöhnlicher Traffic-Anstieg auffallen, der auf einen Bot hindeutet, greift zunächst der automatische Filter möglicherweise noch nicht. Hier hilft dann der nächste Schritt: eigene Ausschlussregeln.
Diese Out-of-the-Box-Lösungen sind Ihre erste Verteidigungslinie. Sie erfordern kaum Aufwand – in GA4 ist es automatisch aktiv, in Adobe/Piano sollten Sie prüfen, ob die Option aktiviert ist. Und sie entfernen einen Großteil der „bekannten Übeltäter“ aus Ihren Berichten.
Allerdings: Verlassen Sie sich nicht blind darauf. Die dynamische Bot-Landschaft, insbesondere KI-Crawler, die teils unter wechselnden Namen oder Tarnungen kommen, sorgt dafür, dass immer etwas durchschlüpfen kann. Daher ergänzen viele Unternehmen diese Basisfilter durch Custom Filtering und Segmentierung.
Für eine feinere Kontrolle lohnt es sich, eigene Filterregeln aufzusetzen, zugeschnitten auf die KI-Bots, die Ihre Seite heimsuchen. Das Herzstück hierbei ist meist der User-Agent-String: Jeder Bot sendet bei der Anfrage an Ihren Server einen User-Agent-Header, der oft, aber nicht immer, seinen Namen oder Zweck verrät, zum Beispiel bei GPTBot:
Mozilla/5.0 (compatible; GPTBot/1.0; +http://openai.com/gptbot)
Sie können diese Kennung nutzen, um Traffic auszufiltern oder separat zu markieren.
In Google Analytics 4 können Sie beispielsweise mit RegEx-Filtern arbeiten.
Ein Tipp aus der Praxis: Nutzen Sie in GA4 das Feld „Benutzerkennung“ oder „Browser“ in einem Vergleichs- oder Ausschlussfilter. Ein vorgeschlagener Regex, um verdächtige Bots abzudecken, lautet:
^(?i).*(ai|openai|chatgpt|gpt|copilot|gemini|bard|google\.bard|perplexity|crawler|bot).*$
Dieser Ausdruck würde jeden User-Agent- oder Traffic-Quellnamen matchen, der Begriffe wie „bot“, „crawler“, „AI“, „OpenAI“, „ChatGPT“ oder „Bard“ enthält.
Sie könnten damit einen Datenfilter in GA4 anlegen, der alle Hits mit solchen Mustern ausschließt, bevor sie in die Berichte einfließen.
Alternativ lässt sich ein solcher Regex auch in Explorationen oder Segmenten verwenden, um die Bot-Sessions herauszufiltern und getrennt zu betrachten. Beachten Sie: Ein zu generelles Muster kann auch legitime Dinge ausschließen. Zum Beispiel könnte „…ai…“ auch mal im User-Agent eines menschlichen Browsers stehen.
Testen Sie Filter ausführlich und fortlaufend, um weder zu wenige noch zu viele Seitenaufrufe aus den Daten auszuschließen. Das Filtern über den User-Agent funktioniert aber auch nur solange, wie sich die Bots höflich darüber anmelden. Theoretisch können sie beim Seitenaufruf auch jeden anderen String angeben.
In Adobe Analytics haben Sie in den Bot Rules ebenfalls freie Hand, eigene Bedingungen hinzuzufügen. Sie können in den Einstellungen z. B. eine Regel erstellen:
User Agent enthält „GPTBot“ oder enthält „/bot“.
Adobe erlaubt Kombi-Bedingungen mit ODER-Verknüpfung. Sie können sogar IP-Adressbereiche eingeben, wenn Sie feststellen, dass bestimmte Cloud-Rechenzentren, etwa AWS oder Azure, massenhaft Bot-Traffic schicken. Allerdings wechseln Bots ihre IPs häufig, daher ist User-Agent-basierte Filterung meist effektiver.
Wichtig: Adobe bietet auch die Option, eine CSV-Liste von Bot-Regeln hochzuladen – praktisch, wenn Sie z. B. eine kuratierte Liste aller bekannten KI-Crawler-Strings pflegen und regelmäßig aktualisieren möchten. Die Bot-Filterung greift dann konsistent auf alle Hits zu.
Piano Analytics ermöglicht es, im Modul Data Management eigene Traffic-Exclusions zu konfigurieren.
Laut Piano-Doku können Sie dort Kriterien festlegen wie Stadt, Organisation (ISP) oder eben User-Agent, um Traffic auszuschließen. Wenn Sie z. B. bemerken, dass 90 % der verdächtigen Zugriffe aus einem bestimmten ISP kommen, etwa „Google Cloud“, könnten Sie diesen vorübergehend als Ganzes ausschließen. Auch hier gilt aber: zu breite Filter können echte Nutzer*innen erwischen, da Google Cloud z. B. auch legitime Nutzer-Proxy-Verbindungen hostet. Daher besser eng fassen: etwa User-Agent enthält „GPTBot“ oder „python-requests“, falls manche Bots sich nicht mal als Browser ausgeben.
Sollte das Data Management nicht ausreichen, bietet Piano auch an, den Support zu kontaktieren, um in Absprache z. B. bestimmte IP-Ranges auf die Blacklist zu setzen. Diese manuelle Komponente ist etwas umständlicher als bei GA oder Adobe, wo man es selbst in der UI erledigen kann.
Eine weitere Best Practice ist es, Segmente für Bot-Traffic anzulegen, statt alles radikal zu löschen. Warum? So können Sie Trends im Bot-Aufkommen beobachten, ohne dass es Ihre Hauptmetriken beeinträchtigt.
Sie könnten z. B. ein Segment „AI Bots“ definieren, mit Kriterien wie oben genannten User-Agent-Matches oder z. B. Land = „nicht gesetzt“, falls Bots keine Geodaten auflösen, und daneben ein Segment „menschliche Nutzer*innen“, etwa: Browser beinhaltet „Chrome|Firefox|Safari|Edge“.
In Ihren Analysen rechnen Sie dann entweder nur das menschliche Segment aus – oder zeigen beide getrennt, um zu sehen, ob Bots gerade einen Peak haben. Diese Transparenz hilft, intern Bewusstsein zu schaffen, etwa „Letzte Woche kamen 30 % unseres Traffics von KI-Crawlern“, und um die Effektivität von Gegenmaßnahmen zu prüfen.
Mit Custom Filters und Segmenten können Sie den Großteil des AI-Traffics identifizieren und ausblenden. Es erfordert etwas initiale Arbeit – die relevanten Muster sammeln, Regex testen –, zahlt sich aber aus.
Kombinieren Sie ruhig mehrere Ansätze: technische Merkmale (User-Agent, Headless-Browser-Indikatoren), Verhaltensmerkmale (z. B. mehr als 50 Seiten pro Session in weniger als einer Minute, was Menschen nie tun würden) und Herkunft (Cloud-Provider-IP). Letztere lassen sich z. B. durch Logfile-Analyse ermitteln.
Achten Sie auch darauf, Ihre Filter regelmäßig zu überprüfen. Die KI-Bot-Welt entwickelt sich weiter – neue Bots tauchen auf, alte ändern ihren Fingerprint.
Ein Beispiel: Im August 2024 gaben über die Hälfte der großen Nachrichten-Websites an, OpenAIs GPTBot in ihrer robots.txt zu blockieren, während Google-Extended von ca. 43 % blockiert wurde. Die Bots, die blockiert werden, könnten versuchen, unter einem generischeren Agent zu crawlen. Es ist also ein Katz-und-Maus-Spiel.
Jetzt Bot-Filterung einrichten lassen:
Eine zusätzliche Schicht, um KI-Traffic zu managen, ist die Analyse der Server-Logfiles. Anders als clientseitige Analytics, die auf JavaScript und Pixel zählen, erfasst der Webserver jede Anfrage sehr detailliert, auch die von Bots. Ein Blick in Ihre Access-Logs kann hilfreich sein, um verdächtiges Verhalten zu enttarnen, zum Beispiel:
/sitemap.xml oder massenhaft paginierte Seiten stehen, ist das ein Indiz.Durch Log-Analyse hat z. B. das Team von SourceHut bemerkt, dass KI-Crawler ihren Dienst an die Belastungsgrenze brachten – man sah es an den IP-Ranges, vielen aus Google/Azure, und der Frequenz. Sie zogen daraus die Konsequenz und blockierten ganze Cloud-Provider-Netze.
Auch das Open-Source-Dokumentationsportal Read the Docs meldete, dass nach dem Blockieren bekannter KI-Crawler der Traffic um 75 % zurückging, von 800 GB auf 200 GB pro Tag, und monatlich ca. 1.500 US-Dollar an Bandbreite eingespart wurden. Diese Zahlen zeigen, wie massiv der Impact sein kann – und solche Erkenntnisse gewinnt man meist erst durch serverseitiges Monitoring.
Als Analytics-Verantwortliche*r können Sie mit Ihrem DevOps-/Hosting-Team zusammenarbeiten: Richten Sie ggf. Logfile-Dashboards ein, z. B. via Kibana oder Splunk, die verdächtigen Traffic visualisieren. Oder nutzen Sie kleine Skripte, die regelmäßig die Top-User-Agents und -IPs auswerten. Diese Daten können Sie dann nutzen, um die oben erwähnten Filter gezielt zu aktualisieren.
Zudem: Sollten Ihre Bot-Filter auf der Analytics-Ebene nicht ausreichen, können Sie serverseitig auch in Erwägung ziehen, aggressiven Crawlern via robots.txt, Rate Limiting oder Firewalls Einhalt zu gebieten.
Angesichts der wachsenden Vielfalt und Hartnäckigkeit von Bots stellt sich strategisch die Frage: Ist es auf Dauer effizienter, die echten Nutzer*innen zu identifizieren und sich auf diese zu konzentrieren, anstatt jeder neuen Bot-Art hinterherzujagen? Anders formuliert: Könnte man nicht alle Interaktionen standardmäßig als Bot behandeln und nur die als menschlich werten, die bestimmte Kriterien erfüllen?
In Bereichen wie Ad-Fraud-Erkennung oder Security gibt es ähnliche Ansätze, Stichwort Challenge-Response, bei denen Nutzer*innen beispielsweise JavaScript ausführen oder ein CAPTCHA lösen müssen, um den Test zu bestehen.
Für Web Analytics im engeren Sinne ist das trickreich, aber ein paar Überlegungen dazu:
Browser-Fähigkeiten: Ein echter Nutzer surft i. d. R. mit einem Standard-Browser, der Cookies zulässt, JavaScript ausführt und CSS rendert. Man könnte also alle Sessions, die gar keine JS-Events erzeugen, als verdächtig einstufen.
Wenn Sie Custom Events nutzen (Scrolltiefe, Button-Klicks etc.), haben menschliche Besucher*innen hier fast immer Einträge; KI-Crawler hingegen nicht. Segmentieren Sie z. B. „Session enthält mindestens ein Interaktions-Event“ vs. „nicht“ – die Ersteren sind mit hoher Wahrscheinlichkeit menschlich.
Nutzungsfluss: Menschen zeigen relativ unregelmäßiges Verhalten: mal Verweildauern von einigen Sekunden, mal Minuten; oft erfolgt eine Navigation von einer Einstiegsseite tiefer ins Menü, aber selten wird jede Seite der Website stumpf sequenziell besucht.
Bots dagegen haben oft entweder extrem gleichförmige Muster (alle paar Sekunden ein Request, stundenlang) oder übermenschlich schnelle Aktionen (100 Seiten in 5 Sekunden). Mit etwas Data Science ließen sich solche Muster automatisch clustern. Für die Praxis: Man kann definieren, dass z. B. Sessions mit mehr als X Pageviews pro Minute, mit exakt gleichen Zeitabständen zwischen den Hits oder mit ungewöhnlich hoher Tiefe eher Bots sind. Alles andere zählt man als „menschenähnlich“.
Quellen & Technik: Ein großer Teil echter Besucher*innen kommt über bekannte Traffic-Quellen wie Suchmaschinen, Direktzugriffe oder Social-Media-Referrals.
Viele Bots haben dagegen keinen Referrer oder kommen von obskuren Quellen. Ebenso surfen echte Nutzer*innen von üblichen Gerätetypen und Browser-Versionen. Wenn Sie z. B. sehen, dass „Browser = Firefox 48 on Windows XP“ plötzlich 5.000 Sessions generiert hat, obwohl diese Version uralt ist, ist das mit hoher Wahrscheinlichkeit kein echter User. Solche Kombinationen lassen sich ausschließen.
Verifikation durch Aktionen: In einigen Fällen könnte man wichtige Metriken an Aktionen knüpfen, die Bots nicht durchführen, z. B. die Conversion-Rate lieber auf Basis abgeschickter Formulare berechnen als auf Basis der Sessions insgesamt. Ein Bot füllt meist kein echtes Formular aus. Menschen schon. So hätte man einen Indikator, der weniger anfällig ist.
Dieser whitelist-artige Ansatz hat allerdings einen Pferdefuß: Er ändert die Sicht auf Ihre Daten fundamental, und man läuft Gefahr, echte Nutzer*innen, die nur kurz da waren, fälschlich auszuschließen. Außerdem werden Bots immer „menschlicher“ – es gibt bereits einige, die z. B. den Chrome-Headless-Browser nutzen und damit Cookies/JS etc. ausführen können, oft erkennbar an „HeadlessChrome“ im Agent. Solche Bots würden Ihre „Mensch-Filter“ passieren.
Dennoch kann es ein ergänzender Weg sein, positive Indikatoren zu nutzen. Zum Beispiel könnten Sie in Ihren Reports einen KPI definieren wie „verifizierte User-Visits“, der nur Sessions zählt, die einen JS-basierten Heartbeat oder eine Interaktion hatten. Damit hätten Sie eine Kennzahl, die garantiert bot-bereinigt ist – und die Veränderungen der echten Nutzer*innen zeigt, selbst wenn der rohe Traffic mal schwankt.
Einige Unternehmen gehen einen pragmatischen Weg: Sie trennen Bot-Traffic von vornherein, indem sie parallele Tracking-Properties nutzen. Beispielsweise lässt man alle Hits mit bestimmten Bot-Kennungen in Property B laufen, alle anderen in Property A, der Haupt-Analytics. In GA4 ginge das über serverseitiges Tagging oder entsprechende Filterlogik.
So haben Sie eine Art Sandbox, in der Sie Bot-Aktivitäten beobachten können; vielleicht interessieren Sie bestimmte Crawling-Patterns ja doch, während Ihre Hauptdaten sauber bleiben.
Ganz wichtig: Kommunizieren Sie intern, was Sie filtern. Nichts ist schlimmer, als wenn in einem Management-Meeting die Frage kommt „Warum sind unsere Besucherzahlen gesunken?“ und niemand bedenkt, dass es am herausgefilterten Bot-Traffic lag. Erklären Sie Stakeholdern, dass Brutto-Visits und bereinigte Visits zu unterscheiden sind und dass ein Rückgang in den bereinigten Zahlen eigentlich eine Datenqualitätsverbesserung ist.
Zum Abschluss noch ein Blick darauf, wie man KI-Traffic kategorisieren sollte, wenn man ihn schon in den Daten hat. Denn nicht jeder Bot ist gleich – und eine Segmentierung kann helfen, gezielter auf Probleme zu reagieren. Hier ein paar sinnvolle Unterscheidungsmerkmale:
Es gibt grob zwei Kategorien: Training-Bots, die alles für KI-Modelle crawlen, und Search-/Assist-Bots, die nur punktuell kommen, um eine Antwort für Nutzer*innen zu holen.
Training-Bots wie GPTBot, ClaudeBot oder Common Crawl haben tendenziell hohe Frequenz, breite Abdeckung und kommen immer wieder.
Assistenz-Bots wie ChatGPT-User, Bings Chat-Agent oder Bard erscheinen beim Abrufen sporadisch und zielgerichtet, oft mit einem Referrer oder einem speziellen Query-Parameter. Wenn Sie diese Gruppen separat segmentieren, sehen Sie z. B., ob Ihr Content häufig in ChatGPT-Abfragen landet – das könnte sogar als positives Signal gewertet werden.
Sie könnten Segmente nach den großen Playern bilden: OpenAI-Bots, Anthropic-Bots, Google-Bots (inkl. Googlebot & Google-Extended) und andere, etwa Meta oder Perplexity. So lässt sich intern reporten, wer Ihren Content am meisten „nutzt“. Vielleicht stellen Sie fest, dass 70 % aller Bot-Hits von OpenAI kommen – dann wissen Sie, mit wem Sie ggf. verhandeln müssten, falls Pay-per-Crawl relevant wird.
Man kann Bot-Sessions auch nach Intensität segmentieren: Heavy Hitters, Bots mit mehr als 1.000 Anfragen pro Tag, vs. Light Bots mit sporadischen Hits. Die Heavy Hitters sind Ihre Haupt-„Schädlinge“ für Daten und Serverlast.
Sie könnten auch tracken, ob Bots sich an Ihre robots.txt gehalten haben, etwa indem Sie einen Eintrag /trap-page mit Disallow anlegen. Wird diese Seite trotzdem gecrawlt, ignoriert der Bot die Robots-Regeln. Solche Bots verdienen besondere Aufmerksamkeit im Sinne von: blocken.
Manche Bots bringen indirekt Traffic, etwa Bing Chat, wenn es in der Antwort Ihre Seite erwähnt und ein User klickt. Andere nehmen nur, wie GPTBot. Ein Bot mit Referrer bing.com könnte bedeuten, dass Bing in Reaktion auf eine Nutzeranfrage Ihre Seite kurz gecrawlt hat – eine potenziell wertvolle Sache, da ein Nutzer dahinter stand.
Die technische Umsetzung der Segmentierung erfolgt wieder via Filter- bzw. Segment-Bedingungen. In GA4 könnten Sie z. B. einen benutzerdefinierten Parameter bot_type mitschicken, wenn Sie es serverseitig erkennen können, oder nachträglich mit Regex auf den User-Agent klassifizieren. In Adobe könnten Sie eine eVar reservieren, in die Sie via Processing Rule den Bot-Typ mappen. In Piano ebenso über ein berechnetes Feld.
Der Nutzen solcher Segmente: Feinjustierung Ihrer Abwehr und Analyse. Vielleicht entscheiden Sie, nur Training-Bots komplett zu sperren, Search-Bots aber weiter zuzulassen, weil Sie den Traffic von z. B. Bing Chat nutzen möchten. Ihre Analytics könnte dann zeigen, ob diese Maßnahme greift.
Schauen wir uns nun noch einmal konkret an, wie Sie in den drei verbreiteten Analytics-Plattformen Bot-Traffic ausschließen oder segmentieren können.
navigator.userAgent ausliest und als Custom Dimension an GA4 sendet. Besser ist es, per JS nur ein Flag wie istBot = true/false zu senden, um die Datenmenge gering zu halten.traffic_type setzen, wenn der User-Agent ein Bot ist – schon filtert GA4 ihn auf Property-Ebene aus. Solche Hacks bedürfen etwas technischer Bastelei, funktionieren aber.Bei allen Tools ist es ratsam, Änderungen zunächst in einer Test- oder Staging-Umgebung auszuprobieren. Gerade Filter, die Traffic komplett verwerfen, sollten sorgfältig geprüft werden – nichts ist ärgerlicher als versehentlich echte Besucher*innen weggefiltert zu haben.
Sie brauchen konkrete Maßnahmen, wie Sie KI-Bot-Traffic in GA4, Adobe oder Piano filtern können? Wir unterstützen Sie hands-on bei der Umsetzung – von der technischen Konfiguration bis zur strategischen Interpretation der Segmentierungen.
Zum nächsten Artikel
Teil 4: Pay-per-Crawl & Co.: Wie Unternehmen KI-Crawlern begegnen