On October 15, 2026 one of the directories we run logged 2,031 visits from Singapore. A normal day brings between 2 and 30. Every visit used Chrome on Windows with a screen of 1280 by 1200, arrived with no referrer, opened one listing and left.
It was a scraper. Of the 2,207 pages viewed that day, 2,132 were different listing pages, each read once. Something was copying the directory one business at a time, and it had been at it on ten of our sites since September 18.
The Short Version
- The swarm came from cloud server ranges in Singapore and wore one browser fingerprint.
- We blocked it by country first. That leaked within a day.
- After our first abuse report it moved to a second cloud company's addresses in under 24 hours.
- Our analytics kept counting hundreds of fake visits a day even while the edge refused more than 11,000 requests.
- A second scraper in November used home connections in six countries and gave itself away in its headers.
What Happened
The first sign was in analytics, not in the server logs. A country that sends us almost nothing was suddenly the top source, with zero engagement.
The addresses belonged to a large cloud provider. We put a rule at the edge to refuse that traffic, started logging every refused request and sent the provider an abuse report on October 17 with the log attached.
In the day after that report the edge refused 2,375 requests from 1,182 different addresses on the same provider. Then, early on October 18, the swarm showed up on a second cloud company's range. It made 737 requests from 144 addresses before we added that range. A third provider's addresses let another 177 through.
We sent four abuse reports in all, each with its own log file. All four were delivered. None of them stopped the traffic that we could measure.
One Day On One Directory, October 15, 2026
Source, our own analytics and edge logs.
The Fingerprint
| What We Checked | What The Swarm Showed |
|---|---|
| Country | Singapore, later Singapore and Beijing |
| Browser And Screen | Chrome on Windows 10 at 1280 by 1200, a few at 1366 by 1366 |
| How It Arrived | Direct, every time |
| Pages Per Visit | One listing page, almost never the same one twice |
| Engagement | None |
No monitor is sold at 1,366 pixels wide and 1,366 tall. A square that odd points to an automated browser and not to a person.
Why The Block Leaked
By October 29 the edge was refusing 11,488 requests a day on one directory. Analytics still counted 508 fake visits that same day, on pages our Singapore log had never seen.
The reason took us a day to find. The requests that loaded our analytics tag were not arriving from Singapore at all, as far as our host could tell. The browser said Singapore. The connection came from somewhere else.
We widened the rule to refuse those cloud ranges from any country. The next 29 hours still put 1,635 fake visits into analytics. So we changed the page itself. It no longer loads analytics for that exact fingerprint, and it sends us a small log line when it sees one.
The swarm went quiet a few hours later, around five in the morning Pacific time on October 30. We did not stop it. It stopped, and we do not know why.
The Second Scraper Looked Nothing Like The First
On November 4 a different directory took bursts of up to 5,225 requests in 15 minutes, and about 40,000 in eight hours. Not one error.
We sampled 280 requests over two minutes. They came from 274 different addresses, nearly all home connections, in Bangladesh, Brazil, South Africa, Morocco, Colombia and Pakistan. More than half of them, 164, asked for one state's page.
Three things gave it away.
- It rewrote our links. All 621 links on that state page end in a slash. The scraper dropped the slash, so 146 of the 280 requests were redirects.
- Its language did not match its country. The language headers were spread evenly and had nothing to do with where the address was.
- Its headers argued with each other. Each request claimed the address had been typed in by hand and also named a page it had come from.
We blocked nothing that night. The listings are public. A limit per address cannot catch a visitor that uses each address once.
How To Spot It On Your Own Site
- One country jumps to the top of your traffic with no engagement.
- One screen size carries almost all of that traffic.
- Each visit reads one deep page, and nearly every page read is different.
- A sudden share of your requests are redirects for an address your own pages never link to.
- Your server log and your analytics disagree about where the visitors are.
What To Do About It
- Clean your numbers first. Filter the fingerprint out of every report before you make a decision from that data. Analytics will not remove past visits, and its built in bot filter only covers known bots.
- Log at the edge. Keep the address, network, country, path and browser string for every request you refuse. That file is your abuse report.
- Block by network, from any country. A country rule is the first thing that fails.
- Never block a crawler you have not checked. Real search crawlers can be confirmed. Google explains how to verify Googlebot. We left every verified search crawler alone.
- Report it, and expect little. Send the provider's abuse desk the log. It builds a record even when nothing changes.
- Decide what the data is worth. Against rotating home connections the honest choices are a challenge on the most copied section or letting public data be copied.
What We Got Wrong
We blocked by country first. It felt like a fix and it leaked inside a day.
We also assumed the edge log and the analytics count were two views of the same visitors. They were not. For weeks our traffic reports carried thousands of visits that no person made, and one public counter on our own site showed them until we filtered it.
Sources
- Our own analytics exports and edge logs from September 18 to November 4, 2026, and the four abuse reports we sent on October 17 and 18, 2026.
- Google Search Central, Verifying Googlebot and other Google crawlers.
- Analytics Help, Known bot traffic exclusion.