GA4 Bot Traffic Spike: Stop Bots Without Hurting SEO

Condensed cross-post of the original KeyboardTester.click case study: GA4 Bot Traffic Spike: Stop Bots Without Hurting SEO.

GA4 suddenly showed 319 active users in the last 30 minutes, while the country table separately displayed Singapore: 301.

That did not mean 319 people were simultaneously connected, and the separately refreshed country row could not be combined with that total. GA4 Realtime is a rolling 30-minute view, and its tiles can refresh on different schedules. The screenshot was an alert—not a firewall verdict.

We investigated the incident across three layers:

1. behavior inside GA4;
2. request patterns at Cloudflare’s edge;
3. traffic that actually reached the hosting origin.

Together, the evidence supported distributed abusive browser automation or scraping-like traffic using rotating IPs. It did not identify an operator or motive, and it did not prove a DDoS campaign, hacking, data theft, or an AI-crawler operation.

What made the traffic suspicious

The analyzed Singapore aggregate in GA4 had:

• zero engaged sessions;
• close to one page per session;
• mostly direct or blank attribution;
• a concentrated desktop-browser profile;
• a broad sweep across unrelated landing pages.

Those signals were suspicious, but GA4 alone was not enough. A legitimate burst, a tagging error, Measurement Protocol spam, a VPN exit, and automated browsers can all create confusing analytics.

Cloudflare supplied the next layer. One hour contained a sharp three-minute cluster totaling 5,675 requests. The wider sample included explicit headless-browser traffic and repeated stock-browser signatures requesting public pages, CSS, JavaScript, PWA files, and broad image inventories.

The origin log then confirmed that some of this activity was consuming hosting resources. In one nine-minute window, it recorded 3,869 requests from 1,101 IP addresses. Rotating addresses made IP-by-IP blocking a poor long-term control.

An impact sample at the edge recorded 10,038 requests and 166,891,967 response bytes in 35 minutes. A separate origin window recorded 2,126 requests and 63,296,919 response-body bytes in roughly 32 minutes.

The windows and units matter. These numbers should not be combined into one invented total, but they do establish that the incident involved real requests and transfer—not merely an odd chart inside GA4.

Was it Googlebot, an AI crawler, or an attack?

Recognized Google, Bing, OpenAI, Meta, and advertising-verification crawlers appeared separately in small volumes. They were not the population driving the visible burst.

A browser-looking user agent is not proof of a person. Likewise, a crawler name in a user agent is not proof that the request really came from that crawler. Known-good crawlers should be verified and explicitly protected.

We also inspected the requested paths. The sample did not show a burst of login attempts, admin probing, exposed-file requests, brute force, or exploit paths. The suspicious origin requests we inspected used GET or HEAD against public content, with no POST burst.

The accurate conclusion was therefore:

Distributed browser automation or scraping-like traffic was reaching public pages through rotating IPs. No evidence of compromise was found, but the operator and motive remained unknown.

That wording matters. “No evidence found” is not the same as proving that no hostile activity existed anywhere.

Does this traffic hurt bandwidth, SEO, or ads?

It can consume bandwidth. Cached responses may stay at the edge, but cache misses, dynamic pages, and some assets still reach the host. Our origin logs confirmed both requests and response bytes during the incident.

The analytics spike itself does not create an automatic Google ranking penalty. The indirect SEO risk grows if automation causes real latency, resource throttling, or 5xx responses that affect visitors and search crawling. An over-broad firewall rule can create the opposite problem by blocking verified crawlers.

Automated page loads also distort acquisition and content reports. For an ad-supported site, bot activity can contribute to invalid-traffic risk. That is a reason to monitor unusual ad metrics and policy notices—not a reason to assume every automated page view produced an invalid click.

Why we did not block Singapore

Country attribution is not identity. Legitimate visitors, VPN users, proxy networks, cloud infrastructure, and automated clients can all appear under the same country.

A country-wide block would have rejected real users and still allowed determined automation to move to another exit region. We therefore classified behavior rather than nationality.

We also avoided an immediate hard block. The evidence was strong, but the lowest-impact reversible response was a Cloudflare Managed Challenge.

How we scoped the Managed Challenge

The production rule was limited to the suspicious public-page navigation behavior observed during the incident. It excluded:

• Cloudflare-verified bots;
• non-GET traffic;
• APIs and required application endpoints;
• static assets;
• PWA and service-worker paths;
• Cloudflare internal paths.

We are intentionally not publishing the exact expression, browser fingerprints, rule IDs, account details, or origin information. Those details would become an evasion guide and would age faster than the response method.

Managed Challenge can still have negative effects. A legitimate visitor may see a short verification step. Privacy tools or blocked scripts can make verification harder. Poor scoping can break AJAX, APIs, webhooks, service workers, embeds, forms, or crawling.

The safeguards are straightforward:

1. start with the smallest observed pattern;
2. choose a reversible action;
3. exclude verified crawlers and required application paths;
4. test normal users and known-good bots;
5. keep a rollback;
6. monitor false positives before tightening.

What changed after activation

Cloudflare recorded 128 challenged requests. That does not mean 128 unique bots, people, or attackers; one client can generate multiple challenge responses.

Post-rule origin snapshots fell to 8 requests in one minute and 17 in the next. A matching suspicious HTML probe received HTTP 403 with Cloudflare’s challenge marker, while normal probes continued to return HTTP 200.

Regression checks covered:

• normal desktop and mobile navigation;
• a localized Japanese tool;
• the manifest and service worker;
• a public embed with an external referrer;
• Googlebot;
• OAI-SearchBot.

Those controls remained available. That result mattered more than watching one GA4 number fall.

During immediate verification, GA4’s rolling card moved from the original 319 total / Singapore row 301 to a later 241 total / Singapore row 224. A later July 31 context check showed 23 active users. The decline was consistent with mitigation and old activity aging out of the 30-minute window, but it was not proof that one rule caused every change.

A safe playbook for your own GA4 spike

1. Preserve the measurement window

Save a screenshot and record the timezone, minute pattern, countries, source/medium, landing pages, engagement, device, and browser breakdown. Do not call a rolling Realtime count simultaneous connections.

2. Corroborate outside GA4

Compare CDN requests, security events, cache status, response bytes, status codes, and a timestamped origin-log sample. If GA4 spikes but the edge and server see nothing, investigate analytics spam or tagging problems before changing the WAF.

3. Classify behavior, not geography

Separate verified search or AI crawlers, monitoring, ad-verification agents, ordinary browsers, scraping-like navigation, endpoint abuse, and exploit attempts. Each class needs a different response.

4. Start with the smallest reversible control

For suspicious public-page navigation, a narrow Managed Challenge is usually safer than a sitewide hard block. For one hammered endpoint, use an endpoint-specific rate limit or challenge. Exploit, login, or form abuse needs managed WAF rules and application-specific controls.

5. Test both success and failure paths

Check desktop, mobile, important locales, forms, APIs, static files, service workers, embeds, verified crawlers, and a matching suspicious request. Confirm both the edge action and the origin reduction.

6. Monitor and adjust

Watch challenge outcomes, false positives, origin load, 5xx responses, GSC crawl health, GA4 quality, and ad-platform notices. Tighten only when new evidence supports it.

7. Keep analytics cleanup separate

Filtering a report can make charts cleaner, but it does not stop requests or bandwidth consumption. Reporting hygiene and edge mitigation solve different problems.

The main lesson

A sudden GA4 country tile is a signal, not a verdict. Preserve the window, verify what reached the edge and origin, protect known-good traffic, and use the smallest reversible control that addresses the observed behavior.

The complete case study includes the incident screenshots, evidence tables, response matrix, bandwidth discussion, official sources, FAQs, and a Cloudflare WAF walkthrough: read GA4 Bot Traffic Spike: Stop Bots Without Hurting SEO.