GA4 spam traffic: how to spot and block it with the hostname filter

To block GA4 spam, first spot the fake traffic in an exploration, then list every one of your hostnames. Next, create a "Web hostname traffic" data filter in "Include only" mode, test it for a few days and activate it. Since September 21, 2026, this filter rejects data from any domain that is not on your list. It does not touch the Measurement Protocol or bots that actually visit your site, though. It does not clean your past data either. And it permanently deletes any legitimate domain you leave off the list.

On this page

What Google changed on September 21, 2026

Google added the hostname filter to GA4 on June 11, 2026, among the data filters in Admin. At the time it could only exclude: to block a spam domain, you had to know it and add it by hand, then start over with every new domain.

On September 21, 2026, the "What's new in Google Analytics" page announced the include mode. Google describes it as an allowlist of approved domains: anything not on it is rejected. According to Google, the allowlist simplifies configuration and needs little maintenance. The same announcement sets two rules that change how the filter should be configured:

• Events with no hostname are blocked automatically. According to Google, a missing hostname typically indicates spam or abnormal traffic.
• The Measurement Protocol is not filtered. Events sent from a server, with a secret key, pass the filter without being checked.

Many guides published before September 21 still describe a filter that can only exclude. On September 22, Search Engine Journal noted that Google's own help pages had not yet been updated. Since then, the help page on the web hostname traffic filter does list both operations: "Exclude" and "Include only".

The spam the filter blocks and the spam it lets through

"Spam" covers several problems in GA4. The hostname filter solves only one: data that reaches your property without coming from your pages. Your measurement ID (your property's "G-" code) can be read in the source of any page on your site. Anyone can use it to send fake visits or fake events without ever loading one of your pages.

The last row often matters more than the others. GA4 already excludes known bots, combining Google's own detection with the Interactive Advertising Bureau's (IAB) international list. That exclusion cannot be turned off, and Google does not show how much it removes. Bots missing from the list reach your reports with your hostname, and the hostname filter can do nothing about them.

The wave of fake traffic from China and Singapore

Since mid-September 2025, site owners around the world have been seeing direct traffic from China (often from Lanzhou) and Singapore. The thread opened on October 6, 2025 in the Google Analytics Help Community has been marked by more than 470 people as the same question they had. Several of them describe traffic doubling overnight.

On November 10, 2025, Raúl Revuelta, a Diamond Product Expert in the Google Analytics Help Community, summed up in that thread what Google's teams had established. According to him, the spikes are likely caused by a new form of non-human traffic that bypasses the standard filtering systems. He describes three signs:

• sessions that contain only the initial events (session_start and page_view), with no other interaction;
• unusual concentrations of older devices and operating systems;
• sudden spikes from unexpected countries or cities, often labelled "(not set)".

He recommended starting with exclusion segments in explorations, which delete no data. He also said a long-term spam detection fix was in development. As of October 13, 2026, we found no announcement of that fix in Google Analytics' "What's new" page.

Does the hostname filter block this wave? Search Engine Watch asked the question on September 29, 2026 and concluded that nobody had tested it yet. The answer depends on the hostname those sessions carry in your property. With an empty or foreign hostname, the filter blocks them. With yours, it lets them through. Step 1 is there to find out before you pick a tool.

Who sends this traffic and why?

Nobody knows. Google has confirmed that it is non-human traffic, but it has named neither its origin nor its purpose. None of the hypotheses going around has been proven. Here they are, with their authors, for the curious:

• Harvesting content to train AI. This is the most widespread hypothesis. Breached Company (Andrew, founder of CISO Marketplace, February 17, 2026) sees it as industrial-scale data harvesting. Thomas Hillary, of Octiv Digital, reports a SEOSpot analysis that traces part of this activity to Alibaba and Baidu infrastructure. Its limit: it explains real visits, not data sent to GA4 with no visit.
• Reconnaissance and testing of evasion techniques. The same Breached Company article reports a minority view among analysts: these bots would be mapping sites (servers, content delivery networks, protections) or testing their ability to get past firewalls and anti-bot tools.
• Probing for security flaws. Kyle Rushton McGregor, of KRM Digital (December 31, 2025), notes visits that land on 404 error pages and non-existent paths, a sign of bots probing for known vulnerabilities.
• A misleading location. Tim Ito, of Marketing Nice Guys (April 1, 2026), points out that GA4 locates a visit from its IP address: a cloud server, a proxy or a VPN shows the data centre's city, not a person's. According to Breached Company, the traffic may be routed through Singapore and the Lanzhou location may be inaccurate.
• Traffic with no apparent purpose. Marcin Polak, of Delante (December 30, 2025), describes bots that wander through sites at random, down to filter and parameter URLs no visitor would click, like traffic "for the sake of traffic".

Some of these articles come from companies that sell security or measurement tools: read them as leads, not findings. For your GA4 property, the practical answer does not depend on the motive. It depends on the hostname those sessions carry and on whether they show up in your server logs.

Step 1: spot the spam in GA4

Don't filter anything before you have looked. In GA4, open a free-form exploration and compare recent months with a quiet period. Put country, city, hostname and session default channel group in rows. Then add operating system with version and screen resolution. As values, use sessions, engaged sessions, average engagement time and key events.

Fake traffic usually leaves several of these traces at once:

• a sudden rise in direct traffic, with no campaign or publication to explain it;
• cities or countries where you don't sell, such as Lanzhou or Singapore for a Quebec business;
• sessions with no engagement, under ten seconds, with a single page view;
• old systems (Windows 7 comes up often in reports) and screen resolutions that repeat exactly;
• a "(not set)" hostname or a domain that isn't yours;
• no key events: fake traffic rarely fills in a form.

Then compare with your server or Cloudflare logs. According to a DefiniteSEO analysis published in November 2025, a good share of the China and Singapore visits never show up in those logs. That is the sign of data sent straight to GA4, with no visit.

Step 2: list your hostnames

The include mode flips the work around: you no longer track the spammers' domains, you keep an exact list of your own. A forgotten domain stops sending anything from the moment the filter is active. That data does not come back.

In the same exploration, keep the "Hostname" dimension in rows and pick a long period that covers your sales peaks: a booking engine used only in high season will not show up in a slow month. Then sort each hostname into one of four columns:

• Your domains: the main domain (with and without "www") and every subdomain that sends data.
• Legitimate third-party services: a booking engine, a ticketing platform or a payment page that carries your GA4 tag.
• Spam and copies: domains you don't recognize, a staging environment, an old site.
• Empty hostnames, shown as "(not set)": the filter will block all of them.

Then run the exploration again, filtered on your sale and lead events (purchase, generate_lead or your own key events). This is the check that matters most: a lost page view skews a report, a lost sale skews the profitability calculation of your campaigns.

The pitfalls of the list: payment gateways, cross-domain and empty hostnames

Payment gateways: two settings not to confuse

A payment gateway raises two different problems, fixed in two different places.

In the most common case, the customer pays on the provider's page (Stripe, PayPal, Moneris) and then returns to your confirmation page. Your tag does not run on the provider's page: its domain sends no data and does not belong in the filter. The problem lies elsewhere. On the return trip, GA4 can count the provider as the source of the visit and take the credit for the sale away from the campaign that brought it in. That is fixed under "List unwanted referrals", in your data stream's tag settings. Google's own example there is a customer paying on a payment provider's domain.

The second case is rarer and more dangerous. Some tools hosted on a provider's domain accept your GA4 tag: a booking engine, a ticketing platform, a hosted payment page or an external cart. Those pages then send events with the provider's hostname, often the most valuable ones in the journey (begin checkout, purchase). Without that hostname on the list, the filter can delete them. The hostname of your sale events, found in step 2, settles the question.

Cross-domain

If your measurement follows visitors from one domain to another (a store on a separate domain, one site per language, a separate blog, a landing page tool hosted by the vendor), every domain must be on the list. The cross-domain configuration and the hostname filter do not talk to each other: adding a domain to one does not add it to the other. A payment domain left out of the filter can make purchases vanish from GA4 while the rest of the journey looks normal.

"www" and subdomains

The filter offers four ways to compare: exact match, "begins with", "ends with" and "contains". It does not accept regular expressions. Benjamin Mangold, Google Analytics trainer and founder of Loves Data, recommends exact match and one hostname at a time. With exact match, "example.com" and "www.example.com" are two different hostnames: you need both.

The broader options open a door. "Contains example" also accepts "example-copy.net". "Ends with .example.com", with the dot, accepts all your subdomains without accepting a domain that merely ends with the same letters.

Events with no hostname

The filter automatically blocks any event with no hostname. Most of the time, that really is spam. But a custom setup can also produce events with no hostname, for example when the page location is replaced with a bare path ("/thank-you/" instead of the full address). If your sale or lead events show "(not set)" as their hostname, fix the setup before you activate the filter.

Google's legitimate copies

When a visitor reads your site through Google Translate, the page is served on a Google domain (for example "www-example-com.translate.goog"). If your tag fires there, those visits arrive with that hostname. The agency FourFront pointed out in August 2026 that these Google domains are legitimate sources. Keeping them on the list or not is a decision to make, not an oversight to discover later.

The ten-filter limit

A property accepts ten data filters at most, all types combined: internal traffic, developer traffic and hostname. Active "Include only" filters add up: an event is kept if it matches any one of them. If you already have an include filter for another purpose, review it before adding one.

Step 3: create the GA4 hostname filter in testing state

You need the Editor role or above on the property to create a data filter. In GA4, open "Admin", then "Data filters" under "Data collection and modification". Choose "Create filter", then the "Web hostname traffic" type. Name the filter, choose the "Include only" operation, the match type and the hostname, then leave the state on "Testing".

Step 4: validate the test

Allow 24 to 36 hours, then let the test run a few days to cover a normal week. In testing state, GA4 deletes nothing: it labels the affected events with the "Test data filter name" dimension. Build an exploration with that dimension and the event name in rows, then event count as values. Then filter on your filter's exact name. Check that none of your legitimate hostnames appear and that no sale or lead event is there.

Step 5: activate the filter and note the date

Open the filter, set the state to "Active" and save. The filter takes effect within 24 to 36 hours. Keep the validation exploration: you will use it again after every change.

The activation date becomes a break in your data series: sessions and conversion rate may shift without any change in your real traffic. Record the date where your team will see it, then compare periods after that date with each other, as with Shopify's change in how it counts sessions.

Step 6: clean up your past data

A data filter applies only to data received after it is created. The months hit by spam stay as they are. Three tools let you read them without the fake traffic, without deleting anything.

An exclusion segment in explorations

This is the method recommended in the Google Analytics Help Community for the China and Singapore wave. In an exploration, create a session segment that excludes the fingerprint you found in step 1. The example given in the thread: exclude sessions where the country is Singapore and the duration is under ten seconds. Combine at least two conditions (a location and a duration, or a hostname and a system) so you don't drop real customers from the same country. Then apply the segment to every exploration you use for analysis.

A comparison in standard reports

Segments only apply to explorations. In standard reports (acquisition, pages, conversions), add a comparison that excludes the hostname or locations of the fake traffic instead. It hides the data in the current view without deleting it. You have to redo it report by report, so keep the list of conditions in a document the whole team uses.

A filter in your dashboards

If your reporting runs through Looker Studio or the BigQuery export, apply the same filter there once and for all. It is often the simplest way to keep management dashboards clean.

One limit to know: explorations go back no further than the property's data retention period (2 or 14 months in the free version of GA4). Standard reports are not affected by that setting. To compare one year with another, check that retention is set to 14 months. It does not apply retroactively, though.

Step 7: keep the list up to date

Every new domain goes on the list the day it goes live: a new store, a campaign microsite, a booking tool, a site in another language. Name the person responsible. The filter gives no warning when it blocks a legitimate domain: it keeps no record of what it has discarded. Also rerun the step 1 exploration every month, since spam changes shape.

What the hostname filter does not do

It lets the Measurement Protocol through

The Measurement Protocol is used to send events from a server, such as a refund or a sale closed offline. It requires a secret key created in the data stream settings. Google asks that it be kept confidential and never exposed in a site's code: a leaked key lets anyone send arbitrary data into your property. If spam arrives that way, replace the key. To go further, server-side tagging lets you validate requests before they reach GA4. It does require more setup and paid hosting.

It does not check the real origin

The filter reads the hostname the request declares. A spammer who sends fake data using your own domain therefore passes the filter. The include mode reduces spam; it does not make it go away.

It cannot see bots that visit your site

A bot that actually loads your pages carries your hostname. Those are spotted by their behaviour (step 1) and blocked before they reach your site, at your host or in Cloudflare. Blocking a whole country also shuts out the real customers who are there: if you do it, keep an exception for verified bots such as Googlebot.

Our own site as an example

On falia.co, the measurement tag loads only if the page's hostname is exactly "falia.co" or "www.falia.co". Staging copies and workstations therefore send nothing to GA4. Payment for the consultation happens on Stripe's page, where our tag does not run, and the visitor then returns to our confirmation page. Stripe therefore belongs in the unwanted referrals, not in the hostname filter.

A check in the code has one limit, though: it only sees visits that go through our pages. Requests sent straight to GA4 with our measurement ID go through no page at all. That is the door the include mode closes. For our site, the list comes down to two hostnames in exact match. Pages read through Google Translate are not on it: our tag does not load there.

Most business sites have a longer list. A Shopify store with a blog on another domain, one site per language or a booking engine is enough to double it. That is why the hostname exploration comes before the filter, never after.

To then connect clean data to your sales, see Conversion tracking: connecting your campaigns to actual sales. The limits of measurement without consent are explained in Consent and measurement: understanding Google Consent Mode's limits.

Frequently asked questions about GA4 spam