GA4 Bot-Traffic-Spitze stoppen – ohne SEO-Schaden
Kurzantwort
Die Anzeige bedeutete nicht, dass 319 Menschen gleichzeitig verbunden waren: GA4 Realtime umfasst ein rollierendes 30-Minuten-Fenster. GA4, Cloudflare und Origin-Logs deuteten gemeinsam auf verteilte missbräuchliche Browser-Automatisierung beziehungsweise scraping-ähnlichen Traffic. Eine eng begrenzte Managed Challenge ließ normale Nutzer, Assets, APIs und verifizierte Crawler durch. Hinweise auf eine Kompromittierung fanden wir nicht.
GA4 zeigte 319 aktive Nutzer in den letzten 30 Minuten; die Ländertabelle nannte in einer separaten Kachel Singapur: 301. Da Realtime-Kacheln nicht zwingend gleichzeitig aktualisieren, haben wir daraus weder einen Anteil berechnet noch gleichzeitige Verbindungen behauptet.
Diese Fallstudie zeigt die gesamte Kette: Menschen und Automatisierung unterscheiden, Google-/Bing-/OpenAI-Crawler trennen, echte Hosting-Übertragung messen, SEO- und AdSense-Risiken bewerten, eine schonende Regel aktivieren und legitime Pfade testen.
Belegt ist verteilte Browser-Automatisierung mit wechselnden IPs. Nicht belegt sind Betreiber, physischer Ursprung, Motiv, DDoS, Hacking, Datendiebstahl oder eine AI-Crawler-Kampagne.
Was „319 aktive Nutzer“ wirklich bedeutete
Realtime zählt Aktivität der vergangenen 30 Minuten und keine offenen Netzwerkverbindungen. Bereits erfasste Events bleiben deshalb nach einer Gegenmaßnahme noch sichtbar, bis sie aus dem Fenster fallen.
Ein Land beweist weder echte Nachfrage noch Missbrauch. Echte Besucher, VPNs, Proxys und automatisierte Browser können derselben Region zugeordnet werden. Singapur war deshalb ein Analysehinweis, keine Identität und kein Grund für eine Ländersperre.
So erkannten wir Automatisierung, ohne GA4 allein zu vertrauen
In der analysierten Singapur-Gruppe sahen wir null engagierte Sitzungen, fast nur eine Seite pro Sitzung, direkte/leere Zuordnung, starke Browser-Konzentration und einen breiten Landingpage-Sweep. Das ist verdächtig, aber allein noch keine Firewall-Grundlage.
Cloudflare zeigte 5.675 Requests in drei gebündelten Minuten sowie Headless- und wiederholte Browser-Signaturen. Das Origin-Log bestätigte reale Host-Last: 3.869 Requests von 1.101 IPs in neun Minuten. Erst die Kette GA4 → Edge → Origin machte die Bewertung belastbar.
Die Beweiskette aus drei Ebenen
| Ebene | Beobachtung | Sichere Aussage |
|---|---|---|
| GA4-Verhalten | Null Engagement, direkte/leere Zuordnung, breiter Page-Sweep | Starkes Automationssignal, allein nicht ausreichend |
| Cloudflare Edge | Gebündelte Minuten, Headless- und wiederholte Browser-Signaturen | Requests erreichten das Edge |
| Origin-Logs | Wechselnde IPs, echte Requests und Response-Bytes | Hosting trug Last und Transfer |
| Bekannte Crawler | Google, Bing, OpenAI und weitere getrennt und klein | Nicht der Treiber der Welle |
| Security-Pfade | Kein Exploit-, Login- oder Admin-Muster im Sample | Keine Hinweise auf Kompromittierung |
Googlebot, AI-Crawler, Scraper oder Angriff?
Erkannte Google-, Bing-, OpenAI-, Meta- und Anzeigenprüf-Crawler tauchten getrennt und in kleinem Umfang auf. Sie verursachten die sichtbare Welle nicht. Ein User-Agent-Name ist zudem leicht fälschbar; gute Crawler müssen verifiziert und ausdrücklich geschützt werden.
Die passende Bezeichnung lautet verteilte missbräuchliche Browser-Automatisierung oder scraping-ähnlicher Traffic. Im untersuchten Sample gab es kein Muster für Login-/Admin-Probing, Brute Force, sensible Dateien oder Exploits. Wir fanden also keine Hinweise auf eine Kompromittierung, kennen Betreiber und Motiv aber nicht.
Was Nichtstun bedeutet: Hosting, Ranking und AdSense
Cloudflare zählte in 35 Minuten 10.038 Requests und 166.891.967 Response-Bytes am Edge. Caching fing einen Teil ab; trotzdem sah das Origin in rund 32 Minuten 2.126 Requests und 63.296.919 Response-Bytes.
Bei gleichbleibender Rate hätten allein die auffälligen Signaturen ungefähr 1,4 GB pro Tag zusätzlich übertragen. Das ist eine Hochrechnung, kein tatsächlicher Tagesverbrauch. Mit unseren Bandbreitenrechner für dauerhaften Transfer verwenden lässt sich eine vergleichbare Rate modellieren; der Rechner erkennt keine Bots.
Ein GA4-Peak erzeugt keine automatische Ranking-Strafe. Indirekt drohen Probleme, wenn echte Latenz/5xx die Erreichbarkeit und das Crawling stören oder eine breite WAF-Regel Googlebot blockiert. Automatisierung verfälscht außerdem Reports und kann für AdSense als ungültiger Traffic relevant sein. Die Welle hätte von selbst enden können, doch wiederkehrende Wellen machen Abwarten zu keiner dauerhaften Abwehr.
Die schonende Lösung: eine eng gefasste Managed Challenge
Wir sperrten Singapur nicht. Die IPs waren verteilt, eine Länderzuordnung ist keine Identität, und echte Nutzer würden getroffen, während Automatisierung ihre Exit-Region wechseln kann.
Statt eines sofortigen Hard Blocks setzten wir eine Managed Challenge nur auf das beobachtete verdächtige Navigationsverhalten. Ausgenommen waren verifizierte Bots, Nicht-GET-Methoden, APIs, statische Assets, PWA-/Service-Worker- und Cloudflare-interne Pfade. Den echten Ausdruck, Fingerprints und IDs veröffentlichen wir nicht.
Eine Challenge ist nicht folgenlos: Echte Nutzer können kurz geprüft werden, Privacy-Tools können stören, und falsches Scoping kann API, AJAX, Webhooks, Embeds, PWA oder Crawler brechen. Deshalb eng starten, Kontrollpfade testen, Fehlalarme beobachten und Rollback behalten. Unser unsere Cloudflare-Workers-Failover-Fallstudie löst dagegen Origin-Ausfälle und ist kein Bot-Filter.
Ergebnis: Challenges am Edge, deutlich weniger Origin-Last
Cloudflare registrierte nach der Aktivierung 128 mit einer Challenge belegte Anfragen. Das sind keine 128 eindeutigen Bots, Personen oder Angreifer; ein Client kann mehrere Challenge-Antworten auslösen.
Die beiden folgenden Origin-Messungen fielen auf 8 Anfragen in einer Minute und 17 in der nächsten. Nach der letzten Eingrenzung erreichte keine neue Anfrage mit dem beobachteten Seitenabruf-Muster den Origin. Normale Desktop- und Mobilseiten, eine japanische Tool-Seite, Manifest, Service Worker, öffentliches Embed, Googlebot und OAI-SearchBot blieben bei HTTP 200; die passende verdächtige HTML-Probe erhielt HTTP 403 mit Challenge-Kennzeichen.
Während der unmittelbaren Kontrolle wechselte die rollierende GA4-Karte von ursprünglich 319 insgesamt und 301 in der Singapur-Zeile auf 241 insgesamt und 224 für Singapur. Eine spätere Kontrolle am 31. Juli zeigte 23 aktive Nutzer. Der Rückgang passt zur Gegenmaßnahme und zum Auslaufen älterer Sitzungen aus dem 30-Minuten-Fenster, beweist aber nicht, dass eine einzige Regel den gesamten Rückgang verursacht hat.
Was nach der Regel erreichbar blieb
| Kontrolle | Ergebnis | Bedeutung |
|---|---|---|
| Normale Desktop-/Mobilseiten | 200 | Normale Besuche blieben erreichbar |
| Japanische lokalisierte Tool-Seite | 200 | Regel war nicht sprach- oder pfadblind |
| Manifest, Service Worker, Embed | 200 | PWA und Einbettung blieben intakt |
| Googlebot und OAI-SearchBot | 200 | Verifizierte Crawler blieben erreichbar |
| Passender verdächtiger HTML-Probe | 403 + Challenge-Kennzeichen | Edge fing das Muster ab |
Sicherer Ablauf bei einem plötzlichen GA4-Peak
1. Screenshot, Zeitzone, Minutenmuster, Quelle, Seiten, Engagement, Geräte und Browser sichern; Realtime als 30-Minuten-Fenster notieren.
2. GA4 mit CDN-Requests, Statuscodes, Bytes, Cache und Origin-Logs abgleichen. Sieht der Server nichts, zuerst Measurement-Spam, Hostname und Tagging prüfen.
3. Verhalten statt Länder klassifizieren: verifizierter Crawler, Monitoring, Browser-Automatisierung, Endpoint-Missbrauch oder Exploit. Mit der kleinsten reversiblen Maßnahme beginnen.
4. Desktop, Mobile, wichtige Sprachen, APIs, Assets, PWA, Embeds, gute Crawler und das verdächtige Muster testen. False Positives, Origin, 5xx, GSC und AdSense beobachten und nur mit neuen Belegen verschärfen.
Wann beobachten, challengen, limitieren oder blockieren?
Nur ein GA4-Anstieg bedeutet untersuchen, nicht sperren. Bei bestätigtem verdächtigem Page-Burst ist eine schmale Challenge sinnvoll; bei einem einzelnen überlasteten Endpoint eher ein pfadspezifisches Rate Limit.
Bei Exploits, Login-/Formularmissbrauch oder echter Ressourcenerschöpfung gehören Managed WAF Rules, Endpoint-Schutz, Rate Limits, gegebenenfalls Turnstile und der Hoster in den Ablauf. Das ist mehr als Analytics-Rauschen.
| Evidenzlage | Sinnvolle erste Aktion | Vermeiden |
|---|---|---|
| Nur GA4-Peak | Analytics prüfen und CDN/Server abgleichen | Ländersperre aus einer Kachel |
| Bestätigte Requests, kaum Wirkung | Beobachten, segmentieren, Baseline sichern | Dauerregel für kurze Anomalie |
| Verdächtiger Seiten-Burst | Schmale Managed Challenge mit Ausnahmen | Siteweiter Hard Block |
| Ein Endpoint wird gehämmert | Pfadspezifisches Rate Limit/Challenge | Unbeteiligte Assets und APIs challengen |
| Exploit, Login, Formularmissbrauch | Managed WAF, Endpoint-Schutz, Limits, Turnstile, Hoster | Als Analytics-Rauschen behandeln |
| Echte 5xx oder Drosselung | Am Edge mindern, Hoster kontaktieren, Crawling prüfen | Nur auf GA4-Rolloff warten |
Cloudflare-Video zu eigenen WAF-Regeln
Das offizielle Video zeigt den Produktablauf für Custom WAF Rules. Nutze die Oberfläche daraus, aber übernimm die evidenzbasierte Eingrenzung und Tests aus diesem Leitfaden statt fremde Ausdrücke zu kopieren.
Primärquellen und Aussagegrenzen
Die Incident-Zahlen stammen aus der KBT-Auswertung von GA4, Cloudflare und Origin-Logs vom 30.–31. Juli. Produkt- und Crawler-Verhalten belegen die offiziellen Google- und Cloudflare-Dokumente.
- Google Analytics: aktive Nutzer in Echtzeit
- Google Analytics: Ausschluss bekannter Bots
- Cloudflare: benutzerdefinierte WAF-Regeln
- Cloudflare: verifizierte Bots zulassen
- Cloudflare Challenges
- Cloudflare-WAF-FAQ: Crawler schützen
- Google Search Central: Googlebot verifizieren
- Google Search Central: Crawling-Kapazität und Serverzustand
- Google AdSense: ungültiger Traffic
Workflow fortsetzen
Häufige Fragen
- Können Bots in GA4 als aktive Nutzer erscheinen?
Ja. GA4 schließt einige bekannte Bots aus, unbekannte automatisierte Browser können aber Tags ausführen. Mit CDN- und Serverdaten bestätigen.
- Kann ich aktive Nutzer direkt in GA4 trennen?
Nein. GA4 zeigt gemessene Aktivität und hält keine Netzwerksitzung, die man beenden kann. Neue passende Requests am CDN/WAF/Origin mindern; alte Events verschwinden erst aus dem 30-Minuten-Fenster.
- Warum zeigte GA4 nach der Gegenmaßnahme weiter Nutzer?
Realtime umfasst die vergangenen 30 Minuten. Vorher erfasste Events bleiben bis zum Ablauf sichtbar; legitime Besucher laufen weiter.
- Verbraucht Bot-Traffic Hosting-Bandbreite?
Ja, wenn Cache Misses, dynamische Seiten oder Assets den Origin erreichen. Unser Log bestätigte echte Requests und Response-Bytes.
- Schadet Bot-Traffic dem SEO-Ranking?
Der Analytics-Peak ist keine automatische Strafe. Indirekt können echte Latenz/5xx oder eine zu breite Regel, die Googlebot sperrt, schaden.
- War das Googlebot, ein AI-Crawler oder ein Hack?
Bekannte Crawler waren getrennt und klein. Die Evidenz sprach für verteilte Browser-Automatisierung; ein Exploit-/Kompromittierungsmuster fanden wir nicht. Betreiber und Motiv sind unbekannt.
- Hört die Welle von selbst auf?
Möglich, wenn eine Crawl-Liste endet, aber nicht garantiert. Wiederkehrende Wellen können andere IPs nutzen; Abwarten ist daher keine dauerhafte Abwehr.
- Kann Managed Challenge negative Folgen haben?
Ja. Echte Nutzer können geprüft werden, Privacy-Tools stören, und falsches Scoping kann API, Embeds, PWA oder Crawler brechen. Eng starten, testen, beobachten und Rollback behalten.
Ein GA4-Peak ist ein Signal, kein Urteil. Sichere das Messfenster, belege Edge- und Origin-Wirkung, schütze verifizierten Traffic und wähle die kleinste reversible Gegenmaßnahme.
