What GA4 does on its own
Every GA4 property drops traffic from user agents on the IAB/ABC International Spiders & Bots List, combined with Google’s own bot research. Three properties of that filter matter more than the filter itself:
- It is on by default. You did not enable it and you cannot disable it. There is no toggle in the admin interface and no parameter that turns it off for a single report.
- It is invisible. No report shows what it removed, no dimension marks a hit as excluded, and no count tells you whether it fired ten times last month or ten million.
- It is a list of names. The mechanism is user-agent matching against declared crawlers, which means it works exactly as well as a bot’s willingness to identify itself.
Taken together, that is a filter you cannot tune, cannot audit, and cannot reason about. It is not useless, but it solves a narrower problem than most people assume it solves.
Why the filter misses the bots that reach your reports
There is a structural mismatch here that explains almost every “bot traffic is ruining my GA4 data” thread. GA4 is a client-side tag: it only ever sees a visitor who loaded your page and executed your JavaScript. The crawlers on the IAB list are, overwhelmingly, the ones that do not do that. Search and AI crawlers mostly fetch raw HTML and never run the tag, so they were never going to appear in your reports whether the filter existed or not.
The automation that does execute your tag is the automation that is running a real browser:
- Uptime and synthetic monitors loading a page every minute, from a datacenter, forever.
- Headless Chrome driven by Playwright, Puppeteer or Selenium — including your own end-to-end test suite pointed at production.
- Performance tooling: Lighthouse runs, page-speed checks, and anything in CI that loads a real page.
- Scrapers and SEO crawlers that render pages rather than parsing HTML, because that is the only way to read a JavaScript-heavy site.
- Agentic browsing: an AI agent driving an ordinary browser session on a user’s behalf, which is indistinguishable from a person at the tag level unless it announces itself.
Some of these announce themselves in the user agent and get caught. Many do not, and the ones on residential or mobile IP addresses running a stock Chrome user agent are not catchable by any free signal at all. The honest summary is that GA4 removes a category of traffic that was mostly not your problem, and leaves the category that is.
How to tell whether it is happening to you
Bot traffic does not distort randomly. It has a signature, and you can look for it in reports you already have:
- A wall of Direct, one-page sessions. Automation rarely carries a referrer and rarely clicks a second link, so it piles up as single-pageview Direct traffic with near-zero engagement time.
- Traffic that is too regular. A monitor checking every 60 seconds produces a flat line where human traffic has a daily rhythm. Look at hourly resolution: humans have a night, bots do not.
- One path, many hits. Uptime checks and health probes concentrate on a single URL, often your home page or a status endpoint.
- Unusual browser versions and screen dimensions. Headless environments cluster on odd viewport sizes and versions that no consumer is running.
- Server load that disagrees with your traffic graph. If your infrastructure is working far harder than your analytics suggests, the gap is traffic your tag never counted or your reports quietly dropped.
What you can actually do inside GA4
1. Exclude internal and developer traffic properly
This is the one filter GA4 genuinely gives you. Define internal traffic by IP range and mark developer traffic with the debug flag, then activate the data filters. It will not touch third-party automation, but your own CI suite and your team’s testing are a real share of the problem and this removes them cleanly.
2. Exclude unwanted referrals
Referrer spam is a different problem from automated browsers — it is usually fabricated hits sent straight to the Measurement Protocol, never a real page load — and the unwanted-referrals list is the intended tool for it. It reclassifies rather than deletes, so the traffic still counts, just not as a referral.
3. Build an engaged-sessions segment in Explore
Instead of removing suspect traffic, define the traffic you trust: sessions with more than one pageview, or with engagement time over a threshold, or reaching a second step. This is a workaround rather than a fix — a determined bot can produce engagement — but it gives you a stable denominator to compare periods against.
4. Filter upstream, before the tag fires
The most effective GA4 bot filtering is not in GA4. A CDN rule or a server-side tag manager sees the request headers and origin network, which is far more than the browser tag ever sees, and can drop or divert automation before it produces a hit. The cost is that you now maintain the rules, and a rule that is too broad quietly deletes real visitors — people on VPNs, corporate proxies and cloud desktops all originate from networks that look like datacenters.
The deeper problem: a filter you cannot audit
Every option above shares the same weakness as GA4’s built-in filter. They all drop. Once traffic is gone it produces no count, so you cannot answer the two questions that actually matter:
How much did we remove, and was any of it real?
Those questions are not academic. Bot detection has false positives with a predictable shape: people behind a VPN or a corporate proxy, employees on cloud-hosted desktops, and — worst of all — an entire tenant whose traffic is proxied through their own backend to dodge blockers, which makes every one of their real visitors look like it came from a server. A system that drops turns each of those into silent, permanent data loss. A system that tags turns them into a filter you can switch off for thirty seconds to check.
That is the question worth asking any analytics vendor, and it is rarely on the marketing page:
- Drop or tag? Is automated traffic deleted as it arrives, or kept with a marker and left out of your reports?
- Can you see the excluded set? If not, you are trusting a number you have no way to verify.
- Is the reason recorded? “Bot” is a verdict. “HeadlessChrome” is evidence you can act on.
- Are sessions judged whole? If a filter drops individual hits, a session with one flagged hit survives as a truncated fragment with a false bounce and the wrong entry page. See what bot traffic does to funnels and retention for why that matters more than the raw counts.
How Pug handles it
Pug matches the incoming user agent against a maintained list of around 1,500 crawler, monitor and automation patterns — the same class of list GA4 uses, but including the headless and synthetic tooling that actually runs a web SDK. What differs is what happens next: the event is tagged, not dropped. Two server-side properties are written on it, one marking it as automated and one recording which pattern matched, and neither can be set or cleared by the client.
Every metric then excludes tagged traffic by default, and session metrics judge a whole session rather than individual hits, so a session with any automated activity is dropped entire instead of leaving a half-session behind. On the raw event surfaces — the live feed, the event list, profiles — a single control flips the traffic back into view, and the recorded reason is something you can break down by, so “how much did we remove, and what was it” is a question with an answer.
Pug is not alone in tagging rather than dropping; several tools take each approach, and it is worth knowing which one you are using before you trust a number. If you are evaluating a GA4 alternative for other reasons, this is a fair thing to add to the list.