One evening a client wrote to me, mildly alarmed. Since the previous day, a large share of their site's traffic had been coming from a domain they had never heard of. The domain held no editorial pages at all: it redirected to a traffic-selling platform, with a utm_source parameter in the destination URL so the platform could credit the visitors it was sent. Their website was acting as an advertising channel — without their knowledge — for a shop selling fake visitors.
The mechanism has not gone away, but the tools have. Back then you dealt with this using Universal Analytics view filters: a working view, a raw view, exclusions written as regular expressions. Those views no longer exist, and much of the advice still circulating online points at an interface that has been switched off.
So here is where the question stands: what Google Analytics 4 filters on its own, the three settings still in your hands, and the distinction that now matters most — invalid bot traffic on one side, AI crawlers on the other. Not the same problem, and not fixed in the same place.
Referral spam is a business model, not a bug
Understand the intent before you decide what to filter. A site that sends robots to thousands of other sites is not trying to damage you. It wants to be noticed. Its domain name appears in your acquisition reports, you search for it out of curiosity, and you land on a cheap traffic offer. The acquisition channel is your own measurement tool.
On the other side there is demand: a manager whose bonus depends on a visit count, a publisher who has to justify an audience figure to an ad network. Buying visitors costs less than earning them. Fake traffic is not a technical accident; it is a commercial offer with customers.
Two families are worth separating. Robots that genuinely visit your pages, run the measurement script and leave a trace in your server logs. And "ghost" referral spam, which never touched your site: it sends requests straight to the measurement protocol using your property identifier. The second kind is rarer than in the Universal Analytics era, because the Measurement Protocol now requires a server-side API secret, but it has not gone.
What the tool filters without asking you
Google Analytics 4 automatically excludes traffic from known bots. The documentation is explicit on two points that are routinely overlooked: you cannot switch this exclusion off, and you cannot see how much traffic it removed. Identification relies on Google's own data and on the international bot list published by the IAB.
That list — the IAB/ABC International Spiders and Bots List — is updated monthly and maintained by the Alliance for Audited Media, under the supervision of an editorial policy committee. It is a list of known signatures: it catches declared, well-behaved robots, and by construction misses any robot presenting itself as an ordinary browser.
Two consequences follow. A clean acquisition report proves only that whatever remained was not recognised as a bot. And you will never reconcile your analytics numbers with your server logs exactly, because part of the gap is, by design, invisible to you.
The three levers that remain in your hands
Referrals to exclude
This is the direct setting against referral spam. In Admin, open the web data stream, then the tag settings, then the entry for List unwanted referrals. You pick a match type and enter the domain. The limit is 50 exclusions per data stream.
Be careful about what this setting does: it adds the ignore_referrer parameter to the events concerned. The visit is still counted. It simply stops being attributed to the parasite domain and moves into direct traffic. That also makes it the standard fix for payment gateways, which are not spam but distort attribution the same way. It does not remove traffic.
Data filters
Data filters act before processing: internal traffic, identified by IP range, and developer traffic, identified by debug mode. Two rules matter, and both are unforgiving. A filter is not retroactive: it applies from the moment it is created and leaves your history untouched. And filtered data is never processed, so it will not appear in Google Analytics or in BigQuery.
Put plainly: a filter that is too broad destroys data permanently. On the sites I configure, I document the excluded IP range in a file the whole team can reach. An office move or a change of internet provider is enough to make the filter useless, and nobody notices for months.
Blocking further upstream
The third lever is not in the measurement tool at all. It is your server, your hosting or your CDN. A robot blocked at the application firewall consumes no bandwidth and no server resources, so the filtering question never arises. It is the only lever that treats the cause, which makes it worth revisiting when you work on page speed and server load. It demands cautious rules: too aggressive, and it blocks real visitors and crawlers you want.
| Lever | Acts on | Retroactive | Main risk |
|---|---|---|---|
| Unwanted referrals | Source attribution | No | Traffic is still counted, as direct |
| Data filters | Collection, before processing | No | Permanent loss of data |
| Server or CDN blocking | The request itself | No | Blocking legitimate visitors |
Invalid bots and AI crawlers: two different subjects
Directors often ask me whether "AI bots are distorting their numbers". The answer is almost always no. Take volume first. The Bad Bot report published by Imperva in 2025, covering traffic across its own network during 2024, concludes that automated traffic overtook human activity, at 51% of web traffic, with 37% attributed to malicious bots. That is a security vendor's perimeter, not the whole web: read it as an order of magnitude for sites behind that kind of service.
On the AI side, the analysis Cloudflare published on 1 July 2025, covering May 2024 to May 2025, gives a useful breakdown: GPTBot accounted for 30% of AI bot traffic in May 2025, ahead of ClaudeBot at 21%, Meta-ExternalAgent at 19% and Amazonbot at 11%. Those figures describe the Cloudflare network.
The technical difference is decisive. These crawlers fetch HTML; the overwhelming majority do not execute the JavaScript of your measurement tag, so they create no session. They inflate your server logs, your bandwidth and sometimes your hosting bill — but not your reported audience. Referral spam does the opposite: it costs your servers almost nothing and pollutes your reports.
Nor are these crawlers interchangeable. Google documents Google-Extended, which only controls whether your content is used for Gemini model training and has no effect on your presence in Search. It is declared in robots.txt like any other user agent:
User-agent: Google-Extended
Disallow: /Blocking anything that looks like a robot is a good way to disappear from the sources of traffic you depend on. If you are unsure what a rule does, check its effect on how your pages are crawled and indexed first.
The diagnostic order I follow
When an unknown domain appears among your traffic sources, I follow the same order.
- Check whether there is a trace in the server logs. If there is none, it is ghost spam sent straight to the measurement protocol, and server-side blocking would achieve nothing.
- Look at the behavioural signature: one page view, zero duration, a single operating system, a single city, a spike that appeared overnight. A genuine referrer produces a distribution, not a block.
- Examine where the domain leads, without opening it in a production browser. A redirect to a traffic offer settles it.
- Add the referral exclusion, then check a week later that direct traffic absorbed the volume. That confirms the setting is live.
- Annotate the date of the change in your dashboards or monthly report. Without an annotation, the break in the curve will be read as a drop in traffic six months later.
That last step is the one everyone skips, and the one that costs the most. I have watched boards worry about a fall in traffic that was nothing more than a clean-up done properly.
Does it hurt your search rankings?
No, not directly. These visits never pass through Google's index, and they are not inbound links you acquired. The real risk is decisional: you set a budget, judge a campaign or rebuild a page on numbers that do not describe human beings.
So I treat cleaning up analytics as a precondition for any keyword and traffic analysis, not a maintenance chore. The same applies when you scope an SEO audit: establish that the measurement is trustworthy first, or every conclusion is built on sand. A technical audit fed by unreliable data points you at the wrong pages.
Common questions
What exactly is referral spam?
Artificial visits, generated by robots, whose only purpose is to make a domain name appear in the traffic source reports of the targeted site. The curious owner looks the domain up, and it redirects to a commercial offer — very often the sale of traffic. It is a prospecting channel that hijacks your own measurement tool.
Does Google Analytics 4 already filter bots?
Yes. It automatically excludes traffic from known bots, using Google's own data and the IAB international bot list. The exclusion cannot be switched off, and the excluded volume is not visible to you. It covers known signatures only, so a robot presenting itself as an ordinary browser passes straight through.
How do I exclude a parasite domain from my reports?
In the property admin, open the web data stream, then the tag settings, then the section for unwanted referrals. You can declare up to 50 exclusions per data stream. The setting does not delete the visit: it stops it being attributed to that domain, and it moves into direct traffic.
Are data filters retroactive?
No. A data filter applies from the moment it is created and does not alter history already collected. The data it discards is never processed, and will not appear in the analytics interface or in an export to a data warehouse. That makes the operation permanent, so define the scope carefully before activating it.
Do AI crawlers distort my audience figures?
As a rule, no. They fetch the HTML of your pages without executing the JavaScript of your measurement tag, so they create no session. They do appear in your server logs and consume bandwidth, which can weigh on performance and on your hosting bill. Two separate problems, two different sets of tools.