Trainings-Crawler und agentische Browser in GA4: Welcher Maschinenverkehr in den Berichten auftaucht

Automatisierter Traffic lässt sich nicht sauber in unsichtbare Crawler und sichtbare KI-Browser aufteilen. Ob ein Maschinenbesuch in GA4 erscheint, hängt vom Messweg ab: Welche Funktionen führt der Client aus, welche Ereignisse werden gesendet und wie erfolgt die Verarbeitung? Ein Seitenaufruf am Server, ein erfasstes Ereignis und eine Sitzung im Bericht sind unterschiedliche Beobachtungen.

Ein Trainings-Crawler sammelt Inhalte für einen bestimmten Zweck. Ein agentischer Browser erledigt Aufgaben automatisch, beispielsweise Seiten öffnen, Links verfolgen oder Formulare ausfüllen. Diese Beschreibungen belegen für sich genommen weder JavaScript-Unterstützung noch Identität oder Sichtbarkeit in Analytics. Ausgangspunkt sind das beobachtete Verhalten eines konkreten Dienstes und die tatsächliche Tracking-Konfiguration.

Redaktionell geprüft am 24. Oktober 2026.

JavaScript trennt Menschen und Crawler nicht zuverlässig

Ein Programm, das nur HTML herunterlädt, führt keinen Google-Tag im Browser aus. Dadurch allein entsteht kein Ereignis dieses Browser-Tags. Die weitergehende Behauptung, Suchmaschinen-Crawler führten niemals JavaScript aus, ist jedoch falsch: Google dokumentiert für Googlebot eine Rendering-Phase. Auch Rendering garantiert nicht, dass jede Ressource oder Analytics-Anfrage ausgeführt wird. Google: Grundlagen der JavaScript-Suchmaschinenoptimierung · Google: Grenzen der JavaScript-Darstellung

Daneben existiert ein eigener Messweg: Ein Server kann Ereignisse über das Measurement Protocol senden, das Google als Ergänzung zum Tagging beschreibt. Ein Ereignis beweist deshalb keinen menschlichen Browserbesuch. Umgekehrt wird eine Anfrage an die Website nicht automatisch zum Analytics-Ereignis. Google: Measurement Protocol

Ein funktionierender Browser garantiert keine Sitzung im Bericht

Ein automatisierter Browser kann denselben Seitencode wie ein gewöhnlicher Browser ausführen. Ob dabei der Tag geladen wird und ein Ereignis gesendet wird, muss trotzdem beobachtet werden. Eine blockierte Anfrage, eine nicht ausgelöste Tag-Bedingung oder ein abgebrochener Besuch können diesen Messweg unterbrechen. Ein vorhandenes Browserfenster bestätigt keine erfolgreiche Erfassung.

Zusätzlich schließt Google bekannten Bot- und Spider-Traffic automatisch aus. Als Grundlagen nennt Google eigene Untersuchungen und die IAB-Liste, nicht lediglich den angezeigten Browsernamen. Der Ausschluss lässt sich nicht deaktivieren; die entfernte Menge wird nicht ausgewiesen. Daraus folgt keine Zusage, dass jede Automation erkannt wird. Google Analytics: Ausschluss bekannter Bots

Drei Beobachtungsebenen beantworten verschiedene Fragen

Diese Trennung erklärt auch mögliche Unterschiede zwischen Protokollen. Ein CDN kann antworten, ohne den Ursprungsserver zu kontaktieren. Protokollierung und Caching bestimmen, auf welcher Ebene ein Eintrag entsteht. Für Vergleiche müssen Zeitzonen, Zeiträume und Einheiten übereinstimmen: HTTP-Anfragen sind nicht mit Sitzungen gleichzusetzen.

robots.txt formuliert Regeln, ist aber keine Zugriffssperre

RFC 9309 unterscheidet Crawler-Regeln ausdrücklich von einer Zugriffsberechtigung. Eine Regel wirkt auf einen Client mit entsprechender Umsetzung. Dessen JavaScript-Fähigkeiten entscheiden nicht darüber. Google dokumentiert selbst unterschiedliche Behandlung für gewöhnliche Crawler und nutzerinitiierte Abrufe. Das Verhalten eines Dienstes lässt sich nicht auf alle KI-Agenten übertragen. RFC 9309: Regeln für Crawler · Google: Crawler und Abrufprogramme prüfen

Eine Zugriffsbeschränkung muss der Server oder das CDN tatsächlich durchsetzen. Eine Änderung an robots.txt ist kein GA4-Berichtsfilter und entfernt keine bereits erfassten Ereignisse. Ihr Einfluss auf spätere Kennzahlen hängt davon ab, welche Anfragen entfallen und ob diese überhaupt Ereignisse beigetragen hatten.

Warum Verhaltenshinweise unsicher bleiben

Wiederholte Aktionen, kurze Besuche oder regelmäßige Zeitabstände können eine Untersuchung begründen. Solche Muster können ebenso aus Tests, Überwachung oder der Ereignisübermittlung einer Anwendung entstehen. Es gibt keine allgemeine Regel, die einen geraden Mauspfad in eine bestätigte KI-Sitzung verwandelt. Aussagen über typisches Verhalten benötigen bekannte Vergleichsfälle und eine Untersuchung der Fehlalarme: menschliche Besuche, die fälschlich als automatisierter Traffic eingeordnet werden.

Fehlende Scroll-Ereignisse werden besonders leicht missverstanden. Enhanced Measurement sendet das standardmäßige Scroll-Ereignis, sobald 90 Prozent der vertikalen Seitentiefe sichtbar werden, nicht bei der ersten Bewegung. Menschen können vorher klicken. Die Standardfunktion liefert auch keine fortlaufende Mausspur. Google: Ereignisse der optimierten Analysen

BigQuery bietet Ereignisdetails, aber keine vollständige Browseraufzeichnung. Googles Schema beschreibt event_timestamp als Empfangszeit in Mikrosekunden; gemeinsam gesendete Ereignisse können denselben Wert besitzen. Einfache Zeitdifferenzen messen deshalb nicht unmittelbar die Denkzeit und liefern keinen Beweis für Automation. Erfassung und gebündelte Übermittlung müssen berücksichtigt werden. Google: BigQuery-Exportschema

Kryptografische Identität ist eine andere Art von Beleg

HTTP Message Signatures können erfasste Bestandteile einer Nachricht anhand eines vertrauenswürdigen Schlüssels authentifizieren. Dazu gehören eine geeignete Zuordnung des Schlüssels zur Identität und Schutz vor wiederholter Verwendung einer Nachricht. Eine gültige Signatur bestätigt weder erwünschtes Verhalten noch einen menschlichen Besucher. RFC 9421: Signaturen für HTTP-Nachrichten

Zum Prüfstand vom 24. Oktober 2026 liegt für Web Bot Auth der Arbeitsgruppenentwurf draft-ietf-webbotauth-httpsig-protocol-00 vom 1. September 2026 vor. Ein Internet-Draft der Arbeitsgruppe ist weiterhin kein fertiger RFC; zudem beteiligen sich nicht alle automatisierten Clients. IETF: HTTP-Nachrichtensignaturen für automatisierten Traffic

Praxisablauf mit dem GA4-Traffic-Prüfer

Der GA4-Traffic-Prüfer bietet einen Einstieg über Browser, Betriebssystem, Land und Sitzungsquelle/-medium. Seine Hinweise nennen die jeweils passende Regel und sind keine Bot-Wahrscheinlichkeiten.

Gruppen unter der gewählten Mindestzahl an Sitzungen bleiben im Ergebnis, erhalten aber keine Regelhinweise. Die Bildschirmtabelle zeigt höchstens 500 Zeilen; der CSV-Export enthält alle vom Werkzeug akzeptierten Ergebniszeilen. Der Abruf ist auf 10.000 Zeilen begrenzt; meldet die API mehr Zeilen als geliefert, bricht die Auswertung ab. Ein Ergebnis ohne Hinweise kann deshalb auch aus einer zu hoch gewählten Mindestzahl entstehen.

1. Einen abgeschlossenen Zeitraum wählen und Berichtsmetadaten sowie Änderungen an der Erfassung prüfen.
2. Untersuchungswürdige Gruppen bestimmen und bekannte interne Testzugriffe berücksichtigen.
3. Relevante CDN- oder Serverdaten für denselben Zeitraum vergleichen. Eine Crawler-Identität nach dem dokumentierten Verfahren des Anbieters überprüfen.
4. Das Ergebnis als bestätigte Identität, vermutete Automation oder ungeklärten Traffic dokumentieren. Diese Kategorien dürfen nicht zu einem vermeintlich bestätigten Bot-Anteil verschmelzen.