How to Remove Bot Traffic from GA4 After a Spike

Olamide Sule, founder of Dolphin Analytics: a digital analytics expert based in London delivering solutions for agency and in-house clients.

Your GA4 sessions jumped overnight, most of them from one country, most of them Direct, and the conversion rate fell through the floor with them. We untangle spikes like this for agencies and in-house teams pulling their hair out with data challenges, and the first job is always the same: prove whether the spike is bots or a tracking fault before you touch a filter. Below is the walkthrough we give clients: how to spot fake traffic, what GA4 can and can’t remove, and where blocking actually works.

What is bot and spam traffic in GA4?

Bot traffic in GA4 is any session or event created by software rather than a person: crawlers, scrapers, automated browsers, AI agents and spam scripts. Google Analytics 4 removes known bots for you, so what reaches your reports is the traffic Google’s lists don’t recognise, which is why it looks like real visitors until you check the details.

GA4’s own exclusion is automatic. Google says traffic from known bots and spiders is automatically excluded, identified using Google research and the International Spiders and Bots List maintained by the Interactive Advertising Bureau. The same page says you cannot disable that exclusion or see how much traffic it removed. So there is no bot setting to tighten: anything you see has already slipped past it.

What slips past falls into three groups:

• Automated browsers. Headless Chrome and similar tools load your page, run the GA4 tag and create a session that looks human in the totals. The sudden one-country spikes in the forum threads that rank for this question fit this pattern, with Singapore and China named most often.
• Ghost spam. Events sent straight to your property without anyone visiting the site, often with a hostname that isn’t yours. GA4’s Measurement Protocol needs an api_secret, and Google warns that the API secret is private and must not sit in client-side code, because anyone holding it can send arbitrary data to your property.
• Your tag on someone else’s site. A scraped copy of your site, or a developer reusing your template, carries your measurement ID with it. Those sessions arrive under a hostname you don’t own.

Bots are not a fringe problem. Imperva’s 2025 Bad Bot Report found automated traffic accounted for 51% of all web traffic, the first time in a decade it passed human activity (Imperva, 2025).

How do you spot a fake traffic spike in GA4?

A fake spike in GA4 shows a cluster of sessions that share details no real audience would: one country or city, one traffic source, one browser version or screen resolution, and almost no engagement. Real campaign spikes spread across devices and pages and produce some key events. Check these signals before you filter anything.

Start in a standard report:

1. Open Reports > Acquisition > Traffic acquisition and set the date range to cover a week either side of the spike.
2. Add a comparison: Google’s comparisons guide says to click the comparison icon at the top right of the report, choose Create new, pick a dimension, set the match type and value, then click Apply. Use Country equals the country driving the spike.
3. Read Engagement rate for that comparison against the rest of the site. GA4 counts an engaged session as one that lasts longer than 10 seconds, has a key event, or has 2 or more page or screen views. A bot cohort usually sits close to zero.

Then build an exploration to fingerprint the cohort:

1. Go to Explore > Free form.
2. Add the dimensions Country, City, Session source / medium, Browser, Screen resolution, Hostname and Landing page. Google’s dimensions reference defines Hostname as the subdomain and domain names of a URL that people visited on your website.
3. Add the metrics Sessions, Engaged sessions and Key events.
4. Put Country in rows, then swap each other dimension in turn.

Signal	Real campaign spike	Bot spike
Country and city	Matches where you advertise	One country you don’t sell to, often one city
Source / medium	The campaign you ran	(direct) / (none) or a referrer you’ve never heard of
Browser and screen resolution	A normal spread	One browser version and one odd resolution
Hostname	Your own domains	A domain that isn’t yours, or (not set)
Engagement and key events	Some engagement, some key events	Engaged sessions near zero, no key events
Landing page	The page the campaign pointed at	The homepage, or a random product page, repeated

If the cohort fails four or more of those rows, treat it as bot traffic. If it fails only on source, look at your tracking first.

Is the spike bots, or is it broken tracking?

A Direct spike in GA4 is not always bots. When campaign parameters get stripped or overwritten, real visitors from paid search, email and affiliates land in (direct) / (none) and the source report looks just as strange. The difference shows in engagement: misattributed humans still browse and buy, while bots don’t.

In our audits, the Direct spikes that turn out to be human are often more expensive than the bot ones, because they hide which campaigns are working. The usual culprits are untagged campaign links, redirects that drop the referrer, and landing pages missing the GA4 tag. A bot filter fixes none of them, and filtering on Direct would throw away real customers.

If the suspicious sessions have normal engagement and normal key events, stop looking for bots and read our guide to why direct traffic is so high in GA4. If sessions fell rather than rose, start with the GA4 not working diagnostic instead.

How do you remove bot traffic from GA4?

You remove bot traffic from GA4 in layers, because GA4 has no custom bot filter: Google’s data filters overview lists developer, internal and web hostname traffic as the filter types. Filter out spam hostnames, stop automated browsers before the tag fires (in Google Tag Manager or at your CDN), and use segments to report around anything that already got in. Each layer catches a different kind of bot.

Step 1: Add a web hostname data filter

The web hostname filter removes events that arrive under domains you don’t own, which handles ghost spam and copied tags. Google’s web hostname traffic guide sets it out like this:

1. Go to Admin > Data collection and modification > Data filters.
2. Click Create filter and choose the Web hostname traffic template.
3. Name the filter and pick a match type: Exactly matches or Contains. Enter the unwanted hostname you found in the exploration.
4. Set the state to Testing and click Create.
5. After a day or two, open a free form exploration with the dimensions Test data filter name and Event name and the metric Event count, and confirm only unwanted hostnames match.
6. Switch the filter to Active.

Google’s web hostname traffic guide says filter state changes take 24 to 36 hours to apply, that filters only work on new data, and that you need Editor access or above. The data filters overview adds that excluded data is never processed and will never be available in Google Analytics or BigQuery. Leave the filter in Testing until you are sure it isn’t catching your own domains.

Step 2: Block automated browsers in Google Tag Manager

A GTM trigger exception stops your GA4 tags firing for browsers that announce they are automated. The navigator.webdriver property indicates whether the browser is controlled by automation, and returns true in Chrome when the --headless or --enable-automation flag is used.

1. In GTM, go to Variables > User-Defined Variables > New > Custom JavaScript. A Custom JavaScript variable must be an anonymous function that returns a value. Paste:

   function () {
     return navigator.webdriver === true;
   }

   Name it JS - Is automated browser.

2. Create a trigger of the same type as your Google tag’s firing trigger (for example Initialization, set to Some Initialization Events), with the condition JS - Is automated browser equals true. Name it Block - Automated browser.

3. Open your Google tag, click Triggering, and under Exceptions click Add and choose the new trigger. Repeat for each GA4 event tag; we give each one an exception trigger of the same type as its firing trigger, so the block always matches. Google calls this a trigger exception, or blocking trigger: it stops the firing trigger under the conditions you set.

4. Preview the container, confirm normal visits still fire, then publish.

The check only catches bots that are honest about being automated. Stealth bots hide the flag, so pair it with Step 3.

Step 3: Block bots at the edge with Cloudflare

If your site runs behind Cloudflare, blocking at the edge stops bots before the page, and the tag, ever load. Cloudflare’s Bot Fight Mode identifies traffic matching patterns of known bots and challenges it, and is available on Free plans. To turn it on, open the dashboard’s Security Settings, filter by Bot traffic and toggle Bot Fight Mode. Cloudflare’s own page warns that it can’t be customised, may challenge legitimate API or mobile app traffic, and can’t be skipped with WAF custom rules, so test your checkout and any app endpoints after switching it on.

For finer control (blocking one country’s automated traffic but keeping its customers, say), move collection server-side, where you can inspect each request before it reaches GA4. Our server-side tracking guide covers that set-up.

Step 4: Report around what already got in

Segments let you exclude a bot pattern from analysis without deleting anything. Google’s segments guide describes a segment as a set of conditions that filters the data in a report, and lists user, session and event segments.

1. In Explore, open your exploration and click the + beside Segments.
2. Choose Session segment, then at the bottom of the builder click Add group to exclude. In the new group’s dropdown, pick Temporarily exclude, which the guide says excludes for the periods of time when the condition is met. Permanently exclude drops anything that has ever met it.
3. Inside that exclude group, add conditions that match the bot fingerprint, such as Country exactly matches the spike country and Screen resolution exactly matches the odd value. Name it Excl - Bot cohort and click Apply.

Combine at least two dimensions. Excluding a whole country also removes any real customers there.

What doesn’t remove bot traffic in GA4?

Two GA4 settings look like bot fixes but aren’t. Listing a spam domain as an unwanted referral does not delete the sessions, and the internal traffic filter is built for your own known IP addresses, not for bots that rotate theirs. Both have a place, just not this one.

• Unwanted referrals. Google’s unwanted referrals guide says Analytics appends ignore_referrer with a value of true to matching events. The referrer stops showing as a source, but the session still counts, usually as Direct.
• IP filters. The internal traffic filter is set under Admin > Data collection and modification > Data streams > your web stream > Configure tag settings > Show more > Define internal traffic, and Google caps a property at 10 data filters. Bots spread over cloud IP ranges would exhaust that long before you caught them.

Can you remove bot traffic from historical GA4 data?

No. GA4 data filters only process data from the moment they are active, and Google’s data filters overview says they do not affect historical data. For past date ranges, the bot sessions stay in the property for good.

What you can do is report around them. Apply the Excl - Bot cohort segment to explorations covering the spike, add a matching comparison to standard reports, and add a note to any client report explaining the date range and the pattern you excluded. If you export to BigQuery, filter the same fingerprint out of the event table before it feeds your dashboards.

When should you call someone about bot traffic?

Most single spikes are a one-afternoon fix with the steps above. Bring in help when any of these is true:

• The spike keeps coming back after the hostname filter and the GTM exception are live, which means stealth bots your setup can’t see.
• Bot sessions are firing key events, so Google Ads or Meta are bidding against fake conversions.
• The suspicious sessions engage like humans, and you can’t tell bots from broken attribution.
• A client report has gone out with the inflated numbers and you need a clean, defensible restatement.

We set up, audit and fix GA4 and Google Tag Manager tracking for agencies and in-house teams, and telling bots apart from broken attribution is a regular part of that. Whether the spike is fake visitors or real visitors filed under the wrong source, the fix starts inside the tracking, not in the report. Trustworthy numbers matter most when an ad platform is optimising on them, as one agency found.

For a US agency and its wealth-management client, we fixed the tracking, so the agency could see what was actually happening in Meta, and they kept their client.

Start with Sonar, our free scanner, to see which tags and pixels fire on your site from the outside in one click. If you already know you need someone inside the account, our paid GA4 audit reviews the property and container and comes back with written findings. Otherwise, tell us what’s broken, or book a call.