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 werden sie verarbeitet? 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 über einen Browser. 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 28. September 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: JavaScript SEO basics · Google: JavaScript rendering limitations

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 er den Tag lädt und ein Ereignis sendet, 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: Known bot-traffic exclusion

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, der sie anwendet. Seine 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: Robots Exclusion Protocol · Google: Verify crawlers and fetchers

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. Sie 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.

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: Enhanced measurement events

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 weder unmittelbar die Denkzeit noch beweisen sie Automation. Erfassung und gebündelte Übermittlung müssen berücksichtigt werden. Google: BigQuery Export schema

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: HTTP Message Signatures

Zum Prüfstand vom 28. September 2026 liegt für Web Bot Auth der Arbeitsgruppenentwurf draft-ietf-webbotauth-httpsig-protocol-00 vom 1. September 2026 vor. Die frühere Behauptung, es gebe noch kein angenommenes Arbeitsgruppendokument, ist veraltet. Ein Internet-Draft der Arbeitsgruppe ist weiterhin kein fertiger RFC; zudem beteiligen sich nicht alle automatisierten Clients. IETF: HTTP Message Signatures for automated 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. Kleine Gruppen bleiben sichtbar; der CSV-Export unterstützt die anschließende Untersuchung.

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.