When Analytics Said Nothing, Bots Were 90% of the Traffic

For months, ChinaGlobalSouth was under constant attack.

The site was already protected by several well-known WordPress security tools: Wordfence, Sucuri, All In One Security. But the attacks kept coming. Cloudflare’s Under Attack Mode was being triggered almost every day, and the team could not understand why.

The problem was not simply that the site was “slow.”
The real question was: why was a news site constantly behaving like it was under siege?

At first, we looked at the usual sources: Google Analytics, Plausible, server logs, Cloudflare signals. Nothing looked obviously abnormal. Human traffic seemed normal. The site would stabilize for a while, then suddenly fall back into Cloudflare UAM again.

We installed Shield ( SysWP Shield), and the attacks dropped significantly. For a while, they even stopped. Shield was already creating adaptive rules on the fly, but something still felt incomplete: we were defending against symptoms without fully seeing the traffic pattern.

That is when we realized the core problem:

Traditional analytics tools are built to understand visitors. They are not built to clearly expose hostile request behavior.

So we started looking at the raw traffic differently. That work became Radar SysWP Radar.

And the picture changed completely.

More than 60% of the traffic was automated bot activity, including SEO spam attempts, fake browser user agents, scraping clients, and abnormal request patterns designed to overload, pollute, or manipulate the site.

Example attack patterns we found:

1. SEO spam injection through WordPress search

Bots were injecting spam keywords into the ?s= search parameter, trying to get those terms indexed through the site’s own search result pages.

Examples included spam signatures like:

cleantalkorg2.ru
batmanapollo
Stock Market breaking news english
Психолог Онлайн
encoded external URLs
This was not normal search traffic. It was an attempt to use the site’s HTML as an SEO spam surface.

1. Fake browser user agents

One repeated user agent looked like a browser, but it was not a real one:

Mozilla/5.0 AppleWebKit/605.1.15 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/605.1.15
The problem: AppleWebKit/605 belongs to Safari-like traffic. Real Chrome usually reports AppleWebKit/537.36, and the platform block was missing. This was a scraper pretending to be a browser, badly.

The volume was also increasing hour by hour.

1. Non-browser HTTP clients

We also saw clients that should almost never appear as normal reader traffic on a news website:

Embarcadero URI Client/1.0
Go-http-client/2.0
These are automation clients, not typical human visitors.

Once Radar exposed the real traffic, we could train Shield’s AI with the correct signals. Instead of guessing, we could build rules based on actual attacker behavior.

The result: the attacks were identified, classified, and blocked much more effectively.

The lesson was simple:

You cannot protect what you cannot see.

Performance, security, and observability are no longer separate problems. On modern WordPress sites, especially publishers and high-traffic content sites, bot traffic can look like a hosting issue, an SEO issue, or a Cloudflare issue.

But sometimes the real problem is hidden in plain sight: thousands of requests pretending to be normal traffic.

Radar gave us visibility. SysWP Radar
Shield gave us enforcement. SysWP Shield
Together, they turned a confusing performance problem into a clear security response.