If you have ever seen a spike of sessions in GA4 with 100% engagement rate and zero conversions, or a "direct" traffic surge from a country you don't sell to, you have already met bot traffic. GA4 does filter some of it, but not nearly as much as most people assume. This article explains what GA4 filters by default, which bots still get through, why it matters, and how to clean it up without hurting your own visibility.
GA4 automatically excludes traffic from known bots and spiders. That sounds comprehensive, but "known" has a narrow meaning here: bots on the IAB/ABC International Spiders and Bots List plus a set of crawlers Google itself identifies. These are bots that declare themselves, usually through an honest User-Agent string.
Anything that doesn't announce itself is not filtered. You cannot turn this filter off, and you cannot extend it. So the default is a floor, not a ceiling.
Bot traffic that reaches your GA4 reports falls into two broad groups.
Some "traffic" never touches your website at all. Spammers send hits directly to Google's collection endpoint using your Measurement ID, which is public in your page source. Because no request ever reaches your server or CDN, you cannot block it with a firewall, WAF, or CDN rule. The only place to deal with it is inside GA4 itself. This is the classic source of fake referrals, junk event names, and language-field spam.
These execute JavaScript, so they fire your tag like a real browser would. Common types:
| Type | What it is | Why GA4 doesn't filter it |
|---|---|---|
| Datacenter traffic | Scripts running on cloud/hosting IPs, often through proxies | Uses a normal browser User-Agent |
| Web scrapers | Machines copying content, prices, or listings at scale | Rotates UAs and IPs to avoid detection |
| Headless browsers | Puppeteer, Playwright, Selenium: real Chrome without a screen | Executes JS and renders pages like a human |
| AI agents operated by humans | Browser agents completing tasks on someone's behalf | Behaves like a session, but is not a customer |
| Ad tech verification bots | Ad platforms and brand-safety vendors checking your content and ad placements | Rendering the page is the point; many don't declare themselves |
| Search engine renderers | Indexers that render pages with a full browser | Undeclared rendering fetches slip past UA-based filters |
| Social network preview bots | Facebook, LinkedIn, Slack, etc. fetching your page to verify it exists before showing a link | Some render JS and fire tags in the process |
Not all of these are malicious; verification and search bots are doing useful work. But none of them are customers, and every one of them inflates your sessions, distorts engagement, and drags down conversion rates.
Real insight and clean data. Bot sessions dilute every ratio you care about: engagement rate, conversion rate, pages per session, revenue per user. Landing page comparisons and A/B test readouts become unreliable when an unknown share of visitors is automated.
Protecting AI-driven ad optimization. If you run Google Ads, Meta, or any platform with automated bidding and you feed it conversion data from GA4 or a tag on your site, bot traffic becomes training data. Smart bidding learns which audiences, placements, and times "convert", and if bots trigger events, the algorithm optimizes toward the segments bots come from. Clean signals mean your budget goes to real people. Dirty signals cost you twice: once for the wasted click, and again for every future bid the model gets wrong.
GA4 supports Developer Traffic and Internal Traffic data filters that act on the traffic_type parameter. Most guides show how to exclude traffic_type=internal. The more robust pattern is the reverse: mark verified human traffic on your page and configure the filter to include only that traffic.
The workflow:
traffic_type value on every hit, for example, traffic_type=human for verified visitors, and something else (or nothing) for the rest.The advantage of "include only" is that it also handles endpoint spam: hits sent directly to Google without your page's traffic_type value simply never match the include rule, so they are dropped even though they never touched your server. We cover the exact tag setup in our guide to filtering bot traffic in GA4 via Google Tag Manager.
Rules and lists only go so far, because headless browsers, residential proxies, and AI agents don't have a fixed IP or User-Agent to filter on. Transfon Gateway evaluates each visitor with server-side signals, ASN and datacenter classification, browser integrity checks, and behavioral analysis, then exposes the verdict on the page through its JavaScript API. You use that verdict to set traffic_type before your analytics or ad tags load, so filtering happens on every hit with no manual list maintenance. Traffic that should never reach the site at all (scrapers, click bots, automated attacks) is blocked at the edge before it can fire a tag.
Combined with a GA4 include-only filter, this gives you a report that reflects real people, and conversion signals your ad platforms can safely learn from.
Don't block whole countries or regions. It's tempting when a spike comes from somewhere you don't do business, but geo blocks are a blunt instrument: you lose legitimate visitors, travelers, expats, and partners, and you end up with missing data instead of clean data. Bots also move; a proxy network will simply route through the next country.
Don't block AI spiders and search crawlers. AI assistants and search engines are becoming a primary way people discover content. Blocking their crawlers to "reduce bot traffic" can drain your visibility across search and AI answers. The right approach is to let declared, well-behaved crawlers index your site and keep them out of your analytics, not out of your site. Cleaning GA4 is a measurement problem; solve it in measurement.
traffic_type rule, driven by a bot detection service such as Transfon Gateway, to filter automatically.Data Privacy and Security, Performance and User Experience, Regulation Compliance, User and Revenue Growth