If you run a small or mid-sized website, there is a decent chance your Google Analytics numbers have been wrong for months. Not wrong by a rounding error — wrong in the way that shows up as a mystery traffic spike from Singapore, a "Direct" channel that doubled overnight, an engagement rate that fell off a cliff, or a conversion rate that looks terrible because half the "visitors" in the denominator were never people. Site owners have been reporting exactly this pattern on Google's own support forum, usually with the same frustrated addendum: the standard GA4 filters didn't stop it.

They're right, and it's worth understanding why before you spend an afternoon building segments. GA4's bot filtering was designed for bots that announce themselves. The bots polluting your reports in 2026 don't.

TL;DR

• Any bot that appears in GA4 executed JavaScript. The analytics tag is JS, so simple scrapers (curl, Python scripts) never show up in your reports at all — even though they may be the bulk of your bot traffic in server logs. GA4 shows you the sophisticated slice and hides the dumb majority.
• GA4's automatic bot exclusion is based on known-bot lists — Google's research plus the IAB International Spiders and Bots List. It cannot be disabled, configured, or extended, and a headless Chrome instance presenting a normal Chrome user agent sails straight past it.
• The tell-tale pattern: a spike in Direct or Unassigned traffic, concentrated in one or two cities you don't sell to, sessions with one pageview and near-zero engagement time.
• GA-side filters only change your reports. The bots still hit your server, still burn bandwidth, and still skew anything measured outside GA.
• Blocking at the origin fixes both. If the request is refused before your page renders, the analytics tag never loads — the bot disappears from GA4 and from your server load in the same stroke.
• Don't blanket-block datacenter IPs to get there. In our production data, 30.3% of IPs carried a datacenter flag while only 2.2% scored as genuinely risky. Use monitor mode first.

How a bot ends up in your Analytics at all

This is the part most guides skip, and it changes how you read every number that follows.

GA4 records a session when the gtag JavaScript on your page executes and sends events to Google. A bot written with curl or Python's requests library downloads your HTML and leaves. No JavaScript runs, no event fires, no session exists. That bot is invisible to GA4 — forever — no matter how many million requests it makes. If you've read our bot detection guide, you know roughly half of web traffic is automated; almost none of that simple-scraper volume appears in Analytics.

So the bots you *can* see in GA4 are, by definition, running a real browser engine — usually headless Chrome driven by Puppeteer or Playwright. They load your page fully, execute your scripts, fire your analytics events, and get counted as visitors. These are the more expensive, more capable bots: scrapers that need JS-rendered content, ad-fraud bots that need to look like humans, and SEO tools crawling with full rendering.

There is one more route in that never touches your website at all: spam sent straight to your analytics property. Your measurement ID (the G-XXXXXXX string) is public — it's in your page source. GA4 closed the worst of the Universal Analytics-era abuse by requiring an API secret for server-side Measurement Protocol hits, but the browser endpoint your own tag uses needs no secret, so anyone can still embed your ID on their page or fire events at it from a script, and those hits land in your property without a single request to your server. It's rarer than it used to be, but it matters for one practical reason: no amount of blocking on your website can stop hits that never visited your website. We'll come back to how to spot the difference.

Why the built-in filter misses almost everything that matters

GA4 automatically excludes "known bots and spiders" — traffic identified by Google's own research combined with the International Spiders and Bots List maintained by the IAB. Google's documentation is plain about the boundaries: you cannot disable the exclusion, and you cannot see how much was excluded — and there is no mechanism to add your own entries. That's the entire built-in defence.

Think about what such a list can contain: bots that identify themselves by user agent, plus infrastructure that has been fingerprinted. A headless Chrome instance configured to present the current stable Chrome user agent — the default posture for any scraping framework written this decade — matches nothing on that list. From GA4's side of the tag it is indistinguishable from a person, because it *is* a real Chrome engine loading your real page.

The traffic waves that flooded GA4 properties through 2025 and 2026 — the ones showing up as Direct sessions from Singapore, Ashburn, Boardman — are exactly this shape. Real browsers, clean user agents, running from cloud servers. The advice that circulates in the support threads is to filter these sessions out of *reports* after the fact, and that advice is honest about the platform's limits: the analytics tool can only ever hide these sessions from your charts. It has no mechanism to make them stop.

Reading the fingerprints in your own reports

Before fixing anything, confirm what you're looking at. Open an Exploration in GA4 (Explore → Free form) and slice by these dimensions. Bot waves are usually blatant once you look.

Geography that doesn't match your business. The single loudest signal. A UK plumbing site suddenly getting 40% of its sessions from Singapore is not experiencing organic growth. Cloud regions leave geographic signatures: Ashburn, Virginia and Boardman, Oregon host major AWS regions; Council Bluffs, Iowa is a Google data center; Falkenstein and Nuremberg are Hetzner's data center parks. These cities appear in analytics far more often as datacenters than as customers.

Channel: Direct or Unassigned. "Direct" is not really a source — it's GA4's bucket for sessions it can't attribute. A bot launched from a script has no referrer, so it lands there. If your Direct channel jumped while every other channel stayed flat, be suspicious.

Engagement time near zero, one page per session. Most headless jobs load one URL, capture what they need, and exit. Hundreds of sessions with identical behaviour — same landing page, zero engagement, no second event — is machine traffic.

Odd technology splits. Sort by browser version and screen resolution. A sudden cohort on an outdated Chrome build, or a resolution like 800×600 that no phone or laptop has shipped with in years, is a scripted browser using library defaults.

The cross-check that settles it: your server logs. If a suspicious cohort in GA4 has no matching requests in your access logs, it never visited you — that's measurement-ID spam, and the fix is GA-side only (filter the sessions in reporting; there is nothing to block). If the requests *are* in your logs, note the IP addresses. Run a few through an IP intelligence lookup and you'll typically find they resolve to hosting providers — which is what makes them blockable.

What GA-side fixes actually do (and don't)

The standard advice — and it's not wrong, just incomplete — is some combination of:

• Filter internal traffic by defining your own IP addresses under Admin → Data streams → Configure tag settings. Useful for excluding your office; useless against bots, because you'd need to enumerate the world's cloud IPs in a tool built to hold a handful of addresses.
• Segments and filters in Explorations to exclude the suspicious country, city, or channel from your analysis. This works, and for pure measurement-ID spam it's the only tool you have.
• List unwanted referrals for referral spam specifically.

All of this shares one property: it edits your reports. The bots keep arriving. Your server keeps rendering pages for them, your hosting bill keeps counting their bandwidth, your WooCommerce store keeps creating sessions for them, and any measurement that happens outside GA4 — server-side conversion tracking, ad platform pixels, your host's own visitor stats — stays polluted. You've cleaned the mirror, not the room.

There's also a maintenance cost nobody mentions: bot waves move. Filter Singapore this month and the next wave arrives via a German provider. Report-side filtering is a chore you now own indefinitely.

Blocking at the origin: remove it from the data and the server at once

The property that makes origin-side blocking attractive for analytics is almost a side effect: if a request is refused before your page renders, your analytics tag is never served, so the session never exists. No filter, no segment, no cleanup. The bot doesn't appear in GA4 for the same reason a visitor who never came doesn't appear.

The signal that makes this workable is the one GA4 can't see: where the IP address actually lives. A headless browser can fake its user agent, screen size, and timezone, but it runs on rented cloud infrastructure, and the IP ranges of hosting providers are knowable. That session "from Singapore" is a machine in a Singapore datacenter, and the IP says so even when everything else about the browser looks human.

On WordPress, Predax Security does this at the earliest point in the request: each visitor's IP is checked against live datacenter, VPN, proxy and Tor data, and a visitor that trips your rules gets a 403 block page before WordPress renders anything — which means before the GA4 tag, your theme, or your plugins load. One request cost to the bot, near-zero cost to you, nothing recorded in Analytics.

Two things keep this from becoming the blunt instrument it could be:

Verified crawlers are exempt by identity, not by user agent. Blocking datacenter IPs naively would block Googlebot, which also lives in a datacenter. Predax verifies real crawlers against the IP ranges their operators publish (and forward-confirmed reverse DNS), so genuine Googlebot and Bingbot pass while a fake "Googlebot" from a rented server — which the check exposes precisely because its IP isn't in Google's published ranges — gets treated like any other datacenter visitor. One honest caveat: crawlers that publish no IP ranges at all (Bytespider is the notable one) can't be verified this way and fall through to your normal rules.

Monitor mode first. The plugin ships in monitor mode: it logs what it *would* have blocked without blocking anything. Run that for a week against the suspicious cohort in your GA4 reports. If the flagged IPs line up with the junk sessions, turn on enforcement for that category. If they don't, you've lost nothing. We wrote up what over-blocking actually costs using our own production numbers — across 93,414 IPs scored by our API, 30.3% carried a datacenter flag while only 2.2% scored as genuinely risky, so "block everything from a datacenter" punishes corporate VPN users, monitoring tools, and accessibility services to solve a much smaller problem. Look before you enforce.

If you're behind Cloudflare, its bot tooling can also refuse traffic before it reaches you, and the two approaches stack fine — edge rules catch what they catch, and origin-side checks judge whatever gets through with fresher per-IP data. Neither replaces the other; they just fail differently.

A realistic cleanup sequence

1. Diagnose in GA4. Exploration by city + channel + engagement time. Identify the cohort: which cities, which landing pages, what date it started.
2. Cross-check server logs for the same window. No matching requests → measurement-ID spam → filter in GA and stop there. Matching requests → note the IPs.
3. Check a sample of those IPs. The free lookup on our homepage will tell you whether they're hosting-provider space. If ten out of ten resolve to cloud providers, you have your answer.
4. Turn on monitoring at the origin (Predax Security in monitor mode, or your stack's equivalent) and let it run at least a few days. Compare its flagged list against the GA4 cohort.
5. Enforce narrowly. Block the categories that match your junk traffic — usually datacenter and proxy — with verified crawlers exempt. Resist the urge to block whole countries; the bots are in a datacenter *in* that country, and country blocking takes out real residents with them.
6. Annotate the date in GA4. Your traffic will drop when enforcement starts, because fake traffic is leaving the dataset. Future-you, comparing year over year, will want to know why.

That last point deserves a plain warning: cleaning bot traffic out of your analytics makes your numbers *worse* on paper. Sessions fall. If you report traffic to a client or a boss, tell them before the chart dips, not after.