Bot Traffic in Google Analytics: How to Find and Filter It

TL;DR: Bot traffic in Google Analytics is almost always undercounted. GA4 filters bots that identify themselves by user agent, which leaves scrapers, card testers, click fraud, and residential-proxy traffic sitting inside your sessions, conversion rate, and channel reports. That inflates sessions, depresses conversion rate, poisons A/B tests, and misprices your paid media. This guide shows what GA4 catches, which metrics get distorted, a six-step audit to size the problem, and how to build a clean reporting baseline.

On this page

• What GA4 filters, and what it misses
• Five metrics bots quietly distort
• How to find bot traffic in Google Analytics: a six-step audit
• Build a clean reporting baseline
• Why filtering is not the same as fixing
• AI crawlers and shopping agents: the 2026 wrinkle
• Frequently asked questions

What GA4 filters, and what it misses

Bot traffic in Google Analytics is not a switch you flip once and forget. GA4 does apply a default exclusion for known bots and spiders, built from Google's own research plus the IAB and ABC International Spiders and Bots List. That list is a catalogue of user agent strings. It works on exactly one class of automation: the kind that announces itself, such as Googlebot, Bingbot, Screaming Frog, Ahrefs, uptime monitors, and social link previewers.

That is genuinely useful. It is also the easy half of the problem. The exclusion cannot help you with:

• Headless browsers running real Chrome. Puppeteer and Playwright ship a legitimate Chrome user agent by default, and most operators customize it anyway.
• Residential and mobile proxy traffic. The IP looks like a Comcast subscriber in Ohio, because it is one. Nothing in the request says "bot."
• Click fraud on paid campaigns. Automated clicks arrive through your ad URLs carrying your UTMs, so they land in Paid Search and Paid Social like any other visit.
• Scrapers that execute JavaScript. If the bot renders the page, your GA4 tag fires. A session is created, page_view is recorded, and it counts.
• Card testers and checkout probes. These often generate real add_to_cart and begin_checkout events, which is why funnel reports can look busy while revenue does not move.

Google's own documentation is honest about the scope here: the feature is called known bot-traffic exclusion. Known is the operative word. Anything designed not to be known passes straight through. So the practical rule for ecommerce teams is this: the bot share you can see in GA4 is a floor, not a measurement.

The gap matters more than it used to. Imperva's 2026 report put malicious automated traffic at roughly 40% of all internet traffic, with human traffic down near 42.5%. Radware's holiday analysis of ecommerce specifically found bad bots at 43% of store traffic during the 2025 peak season, up from 31% a year earlier. If your GA4 reports show a 2% bot share, the honest reading is not "we are clean." It is "we are only seeing the polite ones."

Five metrics bots quietly distort

The reason to care is not data hygiene for its own sake. It is that five numbers your team makes decisions on are being moved, and they are moved in a consistent direction that flatters volume and punishes efficiency.

1. Sessions and users (inflated)

Automation adds sessions with no purchase intent. Traffic looks like it is growing, so nobody investigates. This is the failure mode we covered in why bot traffic is never evenly distributed: a spike that reads as momentum is often just a new scraper finding your catalogue.

2. Conversion rate (deflated)

Orders sit in the numerator, bot sessions pile into the denominator. A store doing 2.4% on clean traffic reports 1.9% when a fifth of sessions are automated. Teams then spend a quarter running CRO tests against a number that was never a conversion problem.

3. Engagement rate and average engagement time (both directions)

Crude scrapers hit one URL and leave, dragging engagement down. Sophisticated ones scroll, wait, and click to defeat behavioural detection, which drags engagement up and makes the traffic look better than your real customers. Neither is a signal you want in a dashboard.

4. Channel and geography reports (misattributed)

Direct and Referral absorb most uninvited automation, which is why sudden Direct growth with flat revenue is a tell. Geography is often louder: sessions from countries you do not ship to, or a concentration in data centre metros such as Ashburn, Virginia. We catalogued the full pattern in seven signs of a bot attack.

5. ROAS, CAC, and experiment results (all downstream)

This is the expensive one. Invalid clicks consume budget and register as sessions, so cost per session looks reasonable while cost per order climbs. Smart bidding then optimizes toward whatever cohort produced the most events, which can include the fake ones. And because bot sessions distribute across your test variants, they add noise without adding signal, which means A/B tests need more traffic and longer runtimes to reach significance. Some never do.

How to find bot traffic in Google Analytics: a six-step audit

You cannot get a perfect number from GA4 alone, but you can get a defensible estimate in about an hour. Run these six checks over a 90-day window.

1. Plot sessions against revenue. In a single Exploration, chart sessions and purchases by day. Healthy stores move together. Divergence, especially a step change that starts on one specific date and never reverts, is your first flag.
2. Break out sessions by country and city. Add city as a secondary dimension. Look for volume from markets you do not sell to and for clusters in known hosting regions. Compare each segment's conversion rate to your site average.
3. Audit Direct traffic. Filter to Direct, then look at landing pages. Real direct traffic lands on your homepage, brand campaigns, and saved product pages. Bot direct traffic lands deep in collection pagination, on search result URLs, or on the same product page thousands of times.
4. Check operating system and browser mix. Look at the tail, not the top. Unusual Linux desktop share, ancient browser versions, or a single Chrome build overrepresented by orders of magnitude are all worth a look.
5. Compare funnel steps to orders. Build a funnel from page_view to add_to_cart to begin_checkout to purchase. When add_to_cart volume climbs but purchase does not, you are likely looking at cart-probing automation rather than a checkout usability issue.
6. Reconcile GA4 against your platform and your CDN. Shopify analytics, your GA4 property, and your edge or CDN logs will never match exactly, but the shape of the gap is informative. Server-side logs see requests that never execute JavaScript, which is precisely the population GA4 is blind to. Our walkthrough of how to tell if Shopify traffic is bots covers that reconciliation in detail.

One caution on step 6. Not everything non-human is unwanted. Search crawlers, AI assistants you want citing you, monitoring, and partner integrations all need access. Sorting the two groups is its own exercise, which is why we wrote a separate primer on good bots versus bad bots. Verify claimed identity rather than trusting the string: Google publishes a reverse DNS and IP verification process for exactly this reason, and anything claiming to be Googlebot that fails it is not Googlebot.

Build a clean reporting baseline

Once you know roughly how much of your traffic is automated, the next job is making sure your reports stop lying to you. Four moves, in order of effort.

Confirm the default exclusion is on. It is enabled by default per data stream, but it gets missed on new streams and on properties migrated in a hurry. Check it, then stop thinking of it as protection.

Filter internal and developer traffic. Your own team, your agency, your staging monitors, and your QA scripts all generate sessions. Define internal traffic by IP in Admin, then apply the data filter. Set it to Testing first so you can see what it removes before it becomes permanent, because active filters are not retroactive.

Add an unwanted referrals list. This handles referral spam and self-referrals from payment gateways and app subdomains, which quietly break attribution on every order that passes through them.

Build a real-users segment in Explorations. This is the highest-value step and the one most teams skip. Create a session-scoped segment that requires at least one meaningful engagement event, then exclude the geographies and city clusters your audit flagged. Report your CRO and experiment numbers against that segment, and keep raw sessions for traffic-cost analysis. Two numbers, clearly labelled, beats one number nobody trusts.

Why filtering is not the same as fixing

Here is the limit of everything above. Filtering changes what you see. It does not change what happens.

A scraper you have excluded from GA4 is still hitting your origin. It still consumes server capacity, still competes with real shoppers for resources during peak, still pulls your pricing and inventory for a competitor's repricing engine, and still costs you money on every request. Card testing you filtered out of reports still generates gateway fees and chargeback risk. Click fraud you segmented away has already spent the budget.

There is a performance cost too, and it lands on the customers you do want. When automated request volume spikes, response times degrade for everyone, and slower pages convert worse. That is the compounding version of the problem: bots inflate your denominator, and separately they make your numerator smaller by slowing the site down. We have written about that interaction in site speed, bot traffic, and conversions.

So treat clean analytics as diagnosis, not treatment. The treatment is deciding, at the edge and before the request reaches your store, which automation gets served, which gets challenged, and which gets refused. That decision has to happen in milliseconds, and it has to distinguish a paying customer on a shared mobile IP from a scraper on the same network. Rate limiting alone will not do it, and neither will blocking by country, which tends to cost real revenue.

AI crawlers and shopping agents: the 2026 wrinkle

Two recent shifts make GA4's blind spot bigger.

First, AI crawler volume is now material. GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and a long tail of smaller agents index product catalogues continuously. Most declare themselves, so the well-behaved ones are filterable. But their infrastructure cost is real even when their analytics cost is zero, and imitators using those names without the matching IP ranges are a growing share.

Second, agentic browsing is showing up in ecommerce traffic. When a shopping agent browses for a customer, it is neither a bot you want to block nor a session you want to count as a human visit. In GA4 today it looks like a strange human: unusual engagement pattern, no scroll depth, sometimes no viewport at all.

This breaks naive bot classification. The old binary of "human good, bot bad" no longer maps to intent, because a meaningful slice of automated traffic in 2026 has a real buyer at the other end of it. Our take is in AI shopping agents and ecommerce. The operational implication: stop maintaining one number for traffic. Maintain three buckets, humans, agents acting for humans, and unwanted automation. Any model that collapses those into a single sessions metric will keep producing decisions that do not survive contact with revenue.

Frequently asked questions

Does GA4 automatically remove all bot traffic?

No. GA4 excludes traffic matching the IAB and ABC International Spiders and Bots List plus Google's own known-bot research. That covers declared crawlers such as Googlebot, Bingbot, and common SEO tools. It does not cover headless browsers with normal user agents, residential proxy traffic, click fraud, or scrapers built to look human. Treat the reported bot share as a lower bound.

How much of my ecommerce traffic is probably bots?

It varies enormously by brand, category, and how much paid media you run. Industry reporting for 2026 puts malicious automation near 40% of all internet traffic and around 43% of ecommerce traffic during peak season. Individual stores range from about 1% to well over 30%. The distribution is the point: you cannot infer your number from a benchmark, you have to measure it.

Why did my conversion rate go up after filtering bot traffic?

Because your conversion rate was always higher than reported. Bot sessions sat in the denominator while contributing no orders. Removing them does not create revenue, it corrects a metric. The useful consequence is that CRO work gets prioritized against a real baseline instead of an artificially depressed one.

Can bot traffic affect my Google Ads performance and ROAS?

Yes, in two ways. Invalid clicks spend budget directly. Less obviously, if automated sessions generate events that your bidding strategy treats as signal, smart bidding can optimize toward acquiring more of them. Google filters some invalid traffic and issues credits, but detection is not complete, and the analytics distortion persists in your own reporting either way.

Should I block AI crawlers to clean up my analytics?

Blocking for analytics reasons alone is the wrong trade. Declared AI crawlers are already excluded from GA4 by user agent, so they are not what is skewing your reports. The real questions are infrastructure cost, whether you want AI assistants citing your catalogue, and whether imitators are abusing those user agent strings. Decide crawler policy on those grounds, not on dashboard tidiness.

What is the difference between filtering bots in GA4 and blocking them at the edge?

Filtering is a reporting change applied after the request has already been served. Blocking at the edge is an infrastructure change that stops the request before it reaches your store, which is what actually recovers server capacity, protects pricing and inventory data, reduces gateway abuse, and keeps peak-traffic response times stable for real shoppers.

See what is actually in your traffic

Most brands find their bot problem the slow way: a quarter of flat conversion rate, a CRO roadmap built on a broken baseline, and a peak season where the site got slow for reasons nobody could name. Clean analytics tells you the size of the problem. Edge enforcement removes it.

Nostra runs both sides from the edge. Edge Protect classifies and stops unwanted automation before it reaches your store while letting search crawlers, AI assistants, and real shoppers through, and our Edge Delivery Engine keeps the pages customers do see fast under load. If your sessions and your revenue have stopped moving together, start with a traffic breakdown or book a demo and we will show you the split on your own domain.