Bot and spam traffic in GA4 is filtered in four layers: turn on internal traffic filters for your own IP ranges, add a hostname filter to block Measurement Protocol spam, build engagement-based segments that drop zero-second sessions, and detect the rest server-side or in GTM before the tag fires. GA4’s automatic IAB bot list runs on top of all of that, but it only catches bots that identify themselves honestly.
That gap is why teams keep finding bot traffic in reports they thought were clean. Headless browsers, referral spam, internal QA traffic, and AI crawlers all pass straight through the IAB list, and each one inflates session counts while deflating engagement and conversion rates.
The newsletter
Join our KISS newsletter
One short read a week on what actually moves revenue, in a free email. Read by 10,000+ operators and founders.
No spam. Unsubscribe in one click.
I.What bot traffic does to a number
Bots do not add noise. They move a fixed set of numbers in a fixed direction, which is why the damage reads as a trend rather than as an error.
A.Three numbers, two directions, one cause
A bot hit is a session. It lands in the denominator of every rate you compute and in the numerator of none of them. So sessions and pageviews rise, engagement rate falls because bot sessions sit under a second and never fire a scroll event, and conversion rate falls because the conversions are unchanged while the sessions they are divided by are not. Three movements, one cause, and none of them looks like a data fault from inside the report.
The fourth number is attribution, and it fails differently. Referral spam spoofs the referrer header, so the report credits a domain the spammer wants promoted. That corruption does not stay inside the acquisition report: it propagates into every channel comparison built on top of it, and into the source and medium buckets that already absorb the traffic GA4 cannot classify. Once spam referrals mix into a channel table, ranking channels by conversion rate ranks them partly by how much spam each one attracted.
B.Why the distortion survives review
A random error averages out and a directional one compounds, and this one is directional. If bots are a roughly stable share of traffic, every rate you report is wrong by a roughly stable factor, which is exactly the condition under which nobody notices. The numbers are internally consistent, they move sensibly week to week, and the only sign of trouble is that the site looks slightly worse at converting than it is. That reads as a content problem, and teams spend quarters fixing it.
The exception is what makes it dangerous rather than merely annoying. A stable bot share is a constant offset; an unstable one is a fake trend. A scraper that starts on a Tuesday, a competitor running a price monitor before a launch, an uptime check reconfigured to hit twenty URLs instead of one: each of these arrives as a step change in sessions with no matching movement in conversions, which is the exact signature of a successful campaign that failed to convert. Teams write post-mortems about that. The event being explained never happened.
It also hides from the view most people open. Bot traffic concentrates in small, unglamorous rows that a sessions-ranked table pushes off the screen. Invert the sort. Rank sources by engagement rate ascending instead of by sessions descending and the same rows become the first thing you see.
Traffic sources sorted by engagement rate, lowest first
Campaign performance view| Source / medium | Sessions | Engagement rate |
|---|---|---|
| (not set) / (not set) | 640 | 1% |
| seo-tool.example / referral | 910 | 3% |
| (direct) / (none) | 4,120 | 54% |
| google / organic | 3,880 | 61% |
II.Why filtering cannot close the gap
Every filter is a rule about a signal the client declares, and the clients most worth excluding are the ones choosing what to declare.
A.The signals you filter on are the ones bots control
GA4 excludes traffic matching the IAB/ABC International Spiders and Bots List. That list is a set of user agent strings, which means it works on exactly one class of bot: the kind that announces itself. Googlebot, Bingbot, Screaming Frog and Ahrefs all do, because being identifiable is part of their job. Nothing else has that incentive.
Four categories walk past it, and they fail the list for four different reasons. Headless browsers run Puppeteer, Playwright or Selenium, execute your JavaScript and fire your tag exactly like a person, because they are a real browser with no window. Measurement Protocol spam never touches your site at all: it posts fabricated hits straight to GA4’s endpoint, so there is no user agent to inspect. Internal traffic from your own team, QA and staging is not a bot and no bot list will ever contain it. And AI crawlers, including GPTBot, ClaudeBot, PerplexityBot, Google-Extended and Bytespider, are covered inconsistently and mostly fetch raw HTML without executing JavaScript, so they never reach your tag and appear only in server logs.
Measurement Protocol spam deserves a note of its own, because it is the one category that is a security problem rather than a measurement one. The endpoint accepts hits for any property whose measurement ID and API secret the sender holds, and a measurement ID sits in your page source in plain view. Anyone who wants rows in your reports can post them from anywhere, with any referrer, at any volume, and there is no request to your servers to compare against. That is also why the fix for it is structurally different from the fix for everything else in this list.
The one signal a bot cannot fake cheaply is rhythm. A user agent is a string, a referrer is a header, an IP is a rented address. Timing is a consequence of how the client is built, and automated clients repeat themselves in a way audiences never do.
Daily sessions before and after an automated crawl starts
Activity report viewB.What the filters cost when they work
Two of the four layers are cheap and you should run them. Internal traffic filters live under Admin, Data Streams, Configure Tag Settings, Define Internal Traffic, and take your office, VPN and development IP ranges. Hostname validation is a data filter that admits only your own hostnames, and it eliminates Measurement Protocol spam outright, because a hit that never visited your site cannot carry a hostname it never saw. Both are rules about facts you control rather than facts the client asserts, which is why they hold.
The other two carry a bill. GA4 data filters apply going forward only, so every month of contaminated history stays contaminated and every year-over-year comparison straddles the change. And a filter that is slightly too wide removes real customers, which produces a chart indistinguishable from an organic collapse. Test in filter testing mode before activating, and if traffic drops after a filter change, read our traffic drop diagnosis guide before concluding anything about rankings.
Which leaves the residue: headless browsers that render your page. Catching those means moving the decision before the tag fires, either at the edge, where you can check data center IP ranges and request rates, or in Google Tag Manager, where a custom JavaScript variable can read navigator.webdriver, a 0x0 screen resolution, or the browser APIs a real browser always exposes, and block the GA4 tag on a match. This works, and it is an arms race. Every check you write is public in your page source, and the countermeasure is one flag in the automation library.
III.Counting something a bot has no reason to do
If the filters are a losing race on the signals bots control, the way out is to change what you count rather than what you exclude.
A.An act, not a hit
A scraper wants your HTML. A headless browser wants a rendered DOM. A Measurement Protocol spammer wants a line in your acquisition report. None of them wants an account, a verified email, a completed onboarding step or a payment, because none of those produce anything the operator can use. The economics of automated traffic are what make the filter unnecessary: past the first meaningful action, the population self-cleans.
Where automated traffic stops following
Funnels report viewThis is a reporting discipline before it is a tooling choice. Pick the first step in your funnel that requires a human intention and treat the rows above it as reach rather than as performance. Rate metrics computed above that line will always carry an unknown bot share; rate metrics computed below it barely move when your filtering changes, which is the test that tells you the line is in the right place.
The line is usually one step earlier than teams expect. A form submission is not enough on its own, because form spam is a well-established industry and the bots that run it are specifically built to complete forms. Email verification, a payment method, or a second session from the same identified person are all acts with a cost attached, and cost is the thing that filters. Pick the earliest act with a cost, not the earliest act with a conversion label on it.
Person-level tools take the same position by construction. KISSmetrics counts events attached to identified people, and a Funnels or Cohorts report built on those events has no bot population to exclude, because a crawler never became a person. Pricing follows the same logic: 100,000 events a month free, $99 for 500,000 on Growth, $299 for 2 million on Silver. You are not paying for traffic you would have filtered.
B.What this does not fix
Moving your decisions below the line does not let you stop measuring above it. Every acquisition question, what a channel costs, whether a landing page earns its placement, how a campaign is pacing, is a question about the top of the funnel, and that is precisely the region bots occupy. You still need the session layer, and you still need the two cheap filters, because a channel comparison distorted by spam referrals will misallocate budget whether or not your conversion metric is clean.
Two blind spots remain and neither is closed by a person-level store. The first is AI crawlers that never execute JavaScript: they consume real bandwidth and real content, and they appear in no client-side tool at all. Server logs are the only place they exist, which makes a periodic log review the only way to size them. The second is the gap between what your server serves and what your analytics records. Compare total server-side requests to GA4 sessions on a fixed schedule and watch the ratio rather than the absolute figure. A ratio that moves without a release or a campaign behind it is a filtering change or a bot campaign, and it is worth finding out which before the next reporting cycle inherits it. Our GA4 data accuracy audit sets out the rest of the reconciliation.
Verdict
Stop trying to make the session count clean. It is not achievable and it was never the number you needed. Run the two filters that rest on facts you control, internal IP ranges and hostname validation, because they are cheap, permanent and cannot be spoofed by the traffic they exclude. Then stop. Every layer past those is a rule about a signal the bot chooses, which means the rule has a shelf life and you have signed up to maintain it forever.
Spend the effort instead on moving your decision metrics below the first act a bot has no reason to perform: a sign-up, a verified account, a purchase, a returning session from a known person. Report everything above that line as reach, with the bot share explicitly unknown, and everything below it as performance. A conversion rate that does not flinch when you change a filter is the only one worth taking to a budget meeting, and it is the one you can have this quarter rather than after the next round of detection rules.
One analytics idea a week
Short, specific, written by the team building the product. No digest, no roundup.
Continue Reading
How to Audit GA4 for Data Accuracy (And What to Do When the Numbers Don't Add Up)
If you have ever compared GA4 numbers to your backend and found a 20-40% gap, you are not alone. This guide provides a systematic audit process to identify where your data is leaking and what to do about it.
Read articleGA4 Traffic Dropped Suddenly? Here's a Systematic Diagnosis Guide
A sudden traffic drop triggers immediate panic. But before assuming the worst, you need a systematic diagnosis process. Most drops have a technical cause that is fixable once identified.
Read articleGA4 (not set) in Source/Medium: Causes and Fixes
Diagnosis takes an hour. Three of the six causes are configuration bugs that close permanently; the other three are browser policy, consent law and intermediaries rewriting your links, and no GA4 setting touches them.
Read article