GA4 Bot Traffic From China and Singapore: How to Tell It Apart From Real Users and Clean Your Reports

A spike of sessions from China and Singapore in GA4 was most likely not created by people: a Product Expert in the official Google Analytics community called this traffic non-human, and GA's built-in exclusion only covers known bots. Check it against engagement time, Search Console and server logs, use segments for reporting, and drop events with a foreign hostname using the GA4 filter introduced in June 2026. Restrict a country at the CDN only after checking, and always with an exception for verified bots.

What Is GA4 Bot Traffic From China and Singapore

GA4 bot traffic from China and Singapore is sessions without people: automated visits that Google Analytics records as users from those countries.

The wave started in autumn 2025, when site owners began reporting a sharp rise in sessions from China and Singapore with almost no engagement or conversions. A Product Expert in the official Analytics Help community described this traffic as inauthentic and non-human. According to the Google Analytics help center, GA automatically excludes only traffic from known bots and spiders: they are identified through Google's own research and the IAB list, and the exclusion cannot be turned off. As of September 2026 we found no reports that the problem has been fully resolved. The only notable change inside GA4 itself is the hostname filter, covered below.

First, find out whether these visits actually reach your server. Compare GA4 with your server logs or CDN analytics for the same dates. If the requests are there, bots are visiting your site, and you can stop them at the CDN level. If they are not, the data reached GA4 without touching your site, and a server or CDN rule will not affect it: you need segments and filters inside the analytics tool.

How Bot Traffic Hurts an Affiliate Site

The main damage is to your data. Sessions without people end up in your reports next to real ones, so average engagement metrics and geography stop reflecting real visitors.

For an affiliate site this turns into concrete mistakes. You judge pages by the conversion rate from sessions to offer clicks and sign-ups. If a noticeable share of sessions is fake, the denominator is inflated and conversion looks worse than it really is. You rewrite a review that was working, drop a bridge page that was converting, or draw conclusions from an A/B test influenced by bots rather than by page variants.

There is also a reputational risk. If you sell placements and show buyers raw GA4 numbers, the conversation gets awkward when they ask for Search Console access and see the gap. We cover how advertisers check such numbers in our article on verifying a publisher's traffic before buying a post or banner.

GEO deserves a separate note. According to Singapore's Ministry of Home Affairs, online gambling there is allowed only with one licensed operator, Singapore Pools. In mainland China gambling is strictly prohibited, with licensed state lotteries as the exception, as the Chambers legal guide notes. So real readers of casino reviews from those countries are usually few. If tens of percent of the traffic to casino and betting pages comes from them, that is a red flag in itself. Check this against your own offers: if you run Asian GEOs, the picture is different and you cannot exclude these countries automatically.

On SEO: we found no evidence that these sessions move rankings in search. They damage your reports, not the search results. What suffers are the decisions you make on those numbers. For realistic ROI benchmarks in the niche, see our breakdown of iGaming SEO in 2026.

How to Tell Bots From Real Users in GA4

The easiest place to start is the country report: Reports → User → User attributes → Demographic details. Menu names may differ in your interface; in that case, look for the "Demographic details" report. For each country, check the share of new users and the average engagement time.

What Bots Look Like in a Report: An Example

Below is a GA4 report for a small site.

The sample is small, but the picture is telling. Three things give the bots away at once. Three quarters of the users came from a single country. All 44 Singapore users are new, and none of them came back. And the average engagement time is zero.

The trap is the engagement rate. 52% looks decent, and by this metric Singapore traffic even beats the rest. The explanation is in the definition. According to the Google Analytics help center, GA4 counts a session as engaged if it lasted longer than 10 seconds, had a key event, or had two or more page views. With zero engagement time, the first criterion was not what triggered it: it was either two page views or a key event. Check which events are marked as key events in your property: any of them makes a session engaged.

Now let's calculate the rest. With 30 engaged sessions at a 50% rate, there are about 60 sessions in total. Singapore accounts for 44 of them, leaving 16 for everyone else, and 7 of those were engaged, about 44%. The average engagement time of the 14 real users comes to roughly seven minutes: 58 users multiplied by 1 minute 43 seconds, divided by 14 people. Real people read many times longer, yet look less engaged by percentage than the bots. So look at engagement time and the share of new users, not at the engagement rate.

Cross-Checking With Search Console

According to the Search Console help center, the Performance report shows clicks and impressions in Google search results, and the data can be grouped by country. If GA4 shows many sessions from China or Singapore while Search Console shows almost no search clicks from those countries, those visits did not come from Google Search.

Logs, CDN and Your Tracker

Compare server logs or CDN analytics for the days of the spike with what GA4 shows. There are two possible outcomes. If the requests are in the logs, bots really are visiting your site, and protection at the CDN level works. If there are no requests, the data reached GA4 without passing through your server, and the problem has to be solved inside analytics.

Calculate conversion from your tracker data and affiliate postbacks, not from GA4 sessions. For more on traffic quality control in affiliate programs, see the affiliate marketing guide.

How to Remove Bot Traffic From GA4: Options and a One-Hour Plan

Comparing the Options

Segments and report filters do not delete data, so they are the safe option for analysis. For example, create a segment in Explorations that excludes China and Singapore for sessions shorter than 10 seconds. The threshold here is an example; adjust it to your site.

Since June 2026, GA4 has a tougher tool: the hostname filter. You will find it under Admin → Data collection and modification → Data filters, and it can be created by a user with the Editor role or higher. First open the Hostname dimension and see what sessions from China and Singapore show. If the hostname is not yours, add it to the filter. If the hostname matches yours, a hostname filter will not help.

The filter has limitations. It excludes events, matches the hostname only by exact match or "contains", and applies only to new data, and excluded events are not processed in GA4. Google provides a Testing mode: matched events are flagged with the "Test data filter name" dimension so you can verify the filter before activating it. Start there and check that no real visitors are caught. If you have several domains or subdomains, list all legitimate hostnames in advance.

A Cloudflare Rule for Singapore and China Traffic That Won't Block Googlebot

If your site sits behind Cloudflare, bots that actually open your pages can be stopped with a WAF rule. Here is a version that worked in practice:

(ip.geoip.country eq "SG" and not cf.client.bot)

It reads as: a request from Singapore (country code SG) that is not from a verified bot. The not cf.client.bot condition keeps the rule from hitting Googlebot, Bingbot and other verified crawlers. Cloudflare describes the same approach in its example on allowing search engine bots: requests from a list of countries are challenged, while search engine and other verified bots are let through.

To cover China as well, add the country code CN:

(ip.src.country in {"SG" "CN"} and not cf.client.bot)

Both fields appear in Cloudflare's documentation: ip.src.country in current examples and ip.geoip.country in earlier ones.

How to create the rule. In the Cloudflare dashboard, open the WAF custom rules, click "Create rule", switch to the expression editor and paste the formula. For the action, start with Managed Challenge, as in Cloudflare's example. Use Block only when you are sure you have no real visitors from those countries.

Then check two things.

• After a day or two, compare Singapore sessions in GA4 before and after. If they dropped noticeably, you were dealing with bots that open pages. If they barely changed, that data reaches GA4 without going through Cloudflare, and you need segments in Explorations and the hostname filter.
• Open the Crawl stats report in Search Console and make sure Googlebot still gets through without errors.

A country rule will also hit real people from those countries, for example users on a VPN. If you run Asian GEOs, limit it to specific addresses or ASNs instead of the whole country.

The One-Hour Plan

1. Look at the share of China and Singapore in GA4 for the last 90 days and compare it with the period before autumn 2025. Note the average engagement time and the share of new users by country.
2. Open Explorations and create a segment without those countries for analysis.
3. Cross-check with Search Console by country and with logs for the days of the spike. Determine whether these visits reach your server.
4. Open the Hostname dimension for those sessions. If the hostname is foreign, create a hostname filter in Testing mode.
5. If the requests in the logs are real, enable a CDN rule with Managed Challenge and an exception for verified bots (the Cloudflare example above). Keep a hard Block for a last resort.
6. After applying rules, open the Crawl stats report in Search Console and confirm Googlebot passes without errors. If you need to check indexing at scale, a bulk indexing check can help.
7. Calculate conversion and engagement from the cleaned segment and from your tracker. Base landing page decisions on those, not on overall GA4 figures.
8. Write down the date the spike started and come back in a month. Google has not announced a full fix, so the segment and filter will need adjusting.

Common Mistakes

Turning on the hostname filter straight in Active mode. It does not affect past data, and excluded events are not processed, so use Testing mode first.

Blocking a country at the CDN and considering the problem closed. If the data reaches GA4 without going through your server, the block has no effect on it.

Restricting a country without an exception for verified bots. In Cloudflare's example, the not cf.client.bot condition is there precisely so the rule does not hit search crawlers.

Relying on the engagement rate. As the example above shows, for bots it can be higher than for real people.

Mistaking the spike for audience growth and showing it to partners or in a media kit. The gap will show up the first time someone checks it against Search Console.

Summary

Start with an hour of work: cross-checking GA4, Search Console and logs will show how many of your visitors are people and whether the bots reach your server. Then use a segment for analytics and, if needed, a hostname filter and a CDN rule with an exception for verified bots. Block a whole country only if it is justified after checking. If you run an affiliate site, recalculate your conversion on the cleaned data before changing any pages. For broader context on organic search in the niche, see the SEO guide for affiliates.