Bot-Traffic verfälscht eure Analytics – wie ihr ihn herausrechnet

Ein relevanter Anteil der Zugriffe auf eine Website kommt nicht von Menschen, sondern von Maschinen: Suchmaschinen-Crawler, LLM-Bots wie GPTBot, ClaudeBot und PerplexityBot, dazu Scraper und Scanner. In der Webanalyse blähen diese Zugriffe eure Besucherzahlen auf und verzerren Kennzahlen wie Sitzungsdauer und Absprungrate. Wer den Bot-Anteil sauber trennt, statt ihn zu blocken, gewinnt belastbare Zahlen – und entscheidet bewusst, welche Maschinen er zulässt und welche nicht.

Derselbe Bot-Zugriff, drei gegensätzliche Deutungen

Derselbe Bot-Zugriff erscheint je nach Blickwinkel völlig anders. Genau diese Mehrdeutigkeit ist der Grund, warum Bot-Traffic so oft unbemerkt eure Auswertung verfälscht.

• Marketing sieht im Analytics-Tool einen Anstieg der Zugriffe und freut sich über vermeintliches Wachstum – obwohl kein einziger potenzieller Kunde dahintersteckt.
• Die Logfiles entlarven denselben Zugriff als Maschine: identischer User-Agent, auffällige Frequenz, kein Laden von Bildern oder Skripten.
• Die Härtung entscheidet, was zu tun ist – den nützlichen Crawler zulassen, den schädlichen Scanner aussperren.

Drei Disziplinen, ein Datensatz. Erst wenn diese Sichten zusammenspielen, wird aus Rohverkehr eine ehrliche Kennzahl.

Woran ihr einen Bot erkennt

Maschinen verhalten sich anders als Menschen, und dieses Verhalten hinterlässt Spuren. Einzelne Signale sind nie ein Beweis, aber in Kombination ergeben sie ein klares Bild:

• User-Agent: Viele seriöse Bots kennzeichnen sich offen, etwa Googlebot, GPTBot oder ClaudeBot. Verlassen solltet ihr euch darauf nicht – ein User-Agent lässt sich beliebig fälschen.
• Zugriffsfrequenz: Dutzende Seitenaufrufe pro Sekunde oder ein streng systematisches Abklappern aller Unterseiten ist menschlich nicht plausibel.
• IP-Muster: Zugriffe aus Rechenzentrums-IP-Bereichen oder von Adressen, die seriöse Anbieter offiziell dokumentieren, lassen sich zuordnen.
• Fehlende JS-Ausführung: Viele Bots laden nur das HTML und ignorieren JavaScript, Bilder und Stylesheets. Wer kein Skript ausführt, taucht in JS-basierten Trackingtools oft gar nicht erst auf.

Warum reine JS-Tracker die Wahrheit nur halb zeigen

Klassische Analytics-Tools – egal ob Matomo oder Google Analytics in der JavaScript-Variante – zählen einen Besuch erst, wenn ein eingebettetes Skript im Browser ausgeführt wird. Das filtert viele simple Bots automatisch heraus, weil sie kein JavaScript laden. Das klingt praktisch, führt aber zu zwei Problemen:

• Es entsteht ein falsches Sicherheitsgefühl: Was im Dashboard nicht auftaucht, scheint nicht zu existieren – obwohl die Maschine sehr wohl auf eurem Server war.
• Anspruchsvolle Bots führen inzwischen JavaScript aus und rutschen damit als vermeintlich echte Besucher durch. Gerade Scraper, die Inhalte vollständig erfassen wollen, rendern Seiten wie ein echter Browser.

Das Resultat: Ihr seht einen Teil der Bots gar nicht und zählt einen anderen Teil fälschlich als Menschen.

Die Logfiles sind die vollständigere Quelle

Jeder Zugriff auf euren Server – ob Mensch oder Maschine, ob mit oder ohne JavaScript – landet im Server-Logfile. Damit ist das Logfile die einzige Quelle, die wirklich jeden Request sieht, und genau deshalb die belastbare Basis für die Bot-Trennung. Vollständig heisst allerdings nicht selbsterklärend: Ob hinter einem Zugriff ein Mensch oder eine Maschine stand, steht nicht im Log – das ergibt erst die Mustererkennung.

Wer Bots ehrlich von Menschen trennen will, schaut nicht ins Analytics-Dashboard, sondern ins Server-Logfile – dort steht jeder Zugriff, ungefiltert.

Im Logfile lassen sich User-Agent, IP, Zeitstempel und angefragte Ressource zusammenführen und Muster sichtbar machen, die ein JS-Tracker prinzipbedingt nicht kennt. So bekommt ihr eine Grössenordnung dafür, wie hoch der Maschinenanteil tatsächlich ist – und könnt eure Analytics-Zahlen entsprechend einordnen.

Bots trennen statt pauschal blocken

Bot-Traffic ist nicht per se schädlich. Suchmaschinen-Crawler sind die Voraussetzung dafür, dass ihr überhaupt gefunden werdet. Und LLM-Crawler werden für die Auffindbarkeit in KI-gestützten Such- und Antwortsystemen zunehmend relevant – wer sie aussperrt, kann einen wachsenden Auffindbarkeitskanal einschränken (Generative Engine Optimization). Die Aufgabe lautet darum nicht «blocken», sondern «sauber unterscheiden»:

• Bekannte Bots filtern oder segmentieren: Beide gängigen Tools bieten Bot-Filter. In Matomo lassen sich bekannte Bots ausschliessen, Google Analytics filtert bekannte Bots und Spider automatisch anhand einer Branchenliste – die aussortierten Zugriffe sind danach allerdings nicht mehr einsehbar. Ein aktivierter Bot-Filter verbessert die Datenqualität, ersetzt aber keine Analyse des Rohverkehrs. Wichtig ist, dass ihr wisst, was gefiltert wird.
• Legitime Crawler bewusst zulassen: Suchmaschinen- und ausgewählte LLM-Bots gehören durchgelassen – sie sind Teil eurer Auffindbarkeit, nicht ihr Gegner.
• Nur Schädliches blocken: Scraper, die Inhalte abgreifen, oder Scanner, die nach Schwachstellen suchen, gehören auf Server-Ebene ausgesperrt. Das ist Aufgabe der Härtung, nicht des Analytics-Tools.

So bleiben eure Kennzahlen sauber, ohne dass ihr eure Sichtbarkeit beschädigt.

Welche Maschinentypen ihr unterscheiden müsst

«Bot» ist eine Sammelbezeichnung für Programme mit gegensätzlichen Absichten. Die Entscheidung – zulassen, filtern oder sperren – fällt nicht für «Bots», sondern pro Typ:

Typ	Typische Kennung	Was er will	Nutzen für euch	Sinnvoller Umgang
Suchmaschinen-Crawler	Googlebot, bingbot	eure Seiten indexieren	Voraussetzung dafür, gefunden zu werden	zulassen, aus der Analyse filtern
LLM-Bot	GPTBot, ClaudeBot, PerplexityBot	Inhalte für KI-Antworten erfassen	Sichtbarkeit in KI-Antworten	bewusst entscheiden, segmentiert auswerten
Monitoring / Uptime-Dienst	eigener oder generischer User-Agent, immer gleiche IP, fester Takt	Erreichbarkeit prüfen	betrieblich nötig	ausschliessen – sonst zählt euer eigener Wächter als Besucher
Scraper	oft getarnt als Browser	Inhalte, Preise, Adressen abgreifen	keiner	auf Server-Ebene sperren
Schwachstellen-Scanner	Aufrufe auf /wp-login.php, /.env, /admin	Lücken finden	keiner	auf Server-Ebene sperren, Muster beobachten
Vorschau-Bot aus Chat und Social	Abruf beim Teilen eines Links	Vorschaubild erzeugen	neutral	ausschliessen – ein geteilter Link ist kein Besuch

Der Punkt dieser Tabelle: Die ersten beiden Zeilen dürft ihr nicht sperren, die letzten beiden dürft ihr nicht zählen – und die mittleren beiden verfälschen eure Zahlen am unauffälligsten, weil sie regelmässig und unspektakulär kommen.

Wie ihr euren eigenen Bot-Anteil bestimmt

Den Maschinenanteil zu beziffern, verlangt kein neues Werkzeug – nur das Access-Log und eine feste Reihenfolge. Ihr arbeitet euch vom Rohverkehr in mehreren Abzügen zum menschlichen Rest vor.

1. Rohzugriffe für einen festen Zeitraum zählen. Nur Aufrufe von HTML-Dokumenten, nicht von Bildern, Stylesheets, Schriften oder Skripten. Statuscode 200 und 304 zählen, Weiterleitungen und Fehler nicht. Nehmt mindestens eine volle Woche – Crawler haben Tages- und Wochenrhythmen, ein einzelner Tag täuscht.
2. Selbstdeklarierte Bots per User-Agent abziehen. Das ist der grosse, einfache Block: Suchmaschinen- und LLM-Bots kennzeichnen sich in der Regel offen. Notiert den Anteil pro Bot getrennt, statt ihn in einer Summe zu ertränken – die Verteilung ist die eigentliche Information.
3. Die Selbstdeklaration verifizieren. Ein User-Agent ist eine Behauptung, kein Ausweis. Die grossen Anbieter dokumentieren ihre IP-Bereiche und lassen sich per Reverse-DNS mit anschliessendem Vorwärts-Abgleich bestätigen. Was sich als Googlebot ausgibt, aber aus einem beliebigen Rechenzentrum kommt, ist kein Googlebot – und gehört in die Kategorie «getarnt».
4. Den Rest über das Verhalten prüfen. Für die verbleibenden Zugriffe zählen die Muster: keine Assets nachgeladen, kein Referrer, gleichmässige Zeitabstände, systematisches Durchgehen der Sitemap, Aufrufe auf Pfade, die es bei euch gar nicht gibt. Jedes Signal für sich beweist nichts, drei zusammen genügen.
5. Gegen das Tracking stellen. Vergleicht die bot-bereinigten Log-Seitenaufrufe mit den Seitenaufrufen aus eurem Analytics-Tool – dieselbe Kennzahl, derselbe Zeitraum. Liegt das Tracking darunter, seht ihr euren Consent-Gap. Liegt es darüber, zählt euer Tracking Maschinen als Menschen: ein Bot, der JavaScript ausführt.

Zwei Fallstricke, an denen diese Rechnung in der Praxis scheitert:

• Ein vorgelagerter Cache. Liefert ein CDN oder ein Page-Cache die Seite direkt aus, erreicht der Bot-Zugriff euren Server nie und fehlt im Origin-Log. Ihr unterschätzt den Maschinenanteil dann systematisch – und zwar genau bei den Bots, die am fleissigsten dieselben Seiten holen. Wer ein CDN einsetzt, muss dessen Logs heranziehen.
• Die eigenen Zugriffe. Uptime-Monitoring, das Backup-Skript, der Preview-Abruf, wenn jemand einen Link in einen Chat stellt, und die Redaktion, die ihre eigene Seite kontrolliert: Das sind auf einer kleinen KMU-Website keine Randgrössen. Wer sie nicht vor der Bot-Rechnung ausschliesst, erklärt sein eigenes Rauschen zum Trend – und wundert sich, warum der «Verkehr» an Werktagen zwischen 8 und 17 Uhr am höchsten ist.

Und eine ehrliche Grenze: Einen getarnten Scraper, der einen echten Browser fernsteuert, Assets nachlädt und sich Zeit lässt, unterscheidet ihr im Log nicht sicher von einem Menschen. Ihr erkennt ihn erst, wenn er skaliert – an der Menge, nicht am einzelnen Zugriff.