The bots in my Google Analytics weren’t the bots that mattered

Earlier this year, while we were going through primary school applications, I built a small website to make sense of the Department of Education’s enrolment figures. It became schoolnumbers.ie: every primary school in Ireland, its pupil numbers year by year, class sizes, and how the area around it is changing.

It’s a niche site. On a typical weekday somewhere between 70 and 130 people use it, almost all of them in Ireland. So when I opened Google Analytics on Tuesday evening and saw this, I sat up.

On Monday 19 October, 1,317 people from outside Ireland visited. The day before, it was 150. Most days it’s under 20. And 941 of them were, apparently, in Singapore.

Nobody in Singapore is that interested in Irish primary schools

Every one of those “visitors” looked the same:

• Windows, Chrome
• a screen exactly 1280×1200 pixels (1,363 of the 1,364 Singapore visitors)
• arrived “direct”: no search engine, no link
• one page, then gone, with zero seconds of engagement
• a brand-new visitor every time

The same fingerprint showed up labelled as the US, Brazil, Hong Kong, Germany, Vietnam, Japan and a dozen other countries. It’s one operation spread across a lot of IP addresses.

A quick search shows I’m far from alone. Since around September 2025, sites everywhere have been seeing “direct” traffic attributed to Singapore and to Lanzhou in China, with the same zero-engagement pattern. Wired covered it in February. On US government websites, Lanzhou was reportedly the top visiting city at 14.7% of visits, with Singapore second at 6.6%. Investigators have traced much of it to large Chinese cloud providers. Nobody has said who’s actually running it, or why. The leading guesses are collecting data to train AI models, or mapping how websites defend themselves against bots.

Is it even real?

One theory doing the rounds is that much of this is “ghost” traffic. These are fake visits sent straight to Google Analytics using the tracking ID that sits in every page’s source code. If so, the bot never touches your site at all, and nothing you do on your server can stop it. One write-up even tied that exact 1280×1200 screen size to ghost hits.

That’s testable. Google Analytics’ Realtime view has a “user snapshot” that shows a single visitor’s activity, including the exact URL and the second it was recorded. My server logs every request. If the visits are real, each one should appear in both places.

Google Analytics (Irish time)	Visitor “from”	Page	My server (UTC)
22:19:31	Singapore	a school page	21:19:30
22:19:31	Japan	a county patron page	21:19:30
22:21:34	Singapore	a county patron page	21:21:33
22:25:38	United States	a school page	21:25:35

All four matched. Each time, my server sent the page one to three seconds before Google Analytics recorded the visit. That’s the normal order: the page loads, then the analytics script runs and reports it. It takes a real browser, really loading the page.

Four is a small sample on one small site, but the timings were exact. On my site, at least, these aren’t ghost hits. It’s an automated browser that runs JavaScript and presents itself as Windows Chrome, rotating through 21 mostly old Chrome versions. It never sends a referrer, and it works its way through school, county and planning-area pages: 346 different pages in 357 loads in under five hours. It isn’t browsing. It’s copying.

The twist: Google Analytics was showing me about 1% of the story

Here’s what surprised me. Google Analytics only counts visitors whose browser runs its JavaScript, and most bots never do. So I looked at what the server actually handles.

In a little over four hours on Tuesday evening it served 14,674 requests, about one a second. Only around 6% looked like real people clicking around.

• Amazonbot made half of all requests. It’s Amazon’s crawler, and Amazon says it “may be used to train Amazon AI models”.
• A scraper forging Google referrals made 14%. Its requests claimed to come from Google search, several a second, landing on deep, oddly specific pages that no human searcher would ever reach.
• Reflectionbot, from the AI lab Reflection AI, made 11%.
• Bytespider, ByteDance’s crawler, made 4%.
• Bing, Google, Apple, Facebook and others made a handful each.
• Vulnerability scanners poked at /.env, /phpinfo.php and /.git, and all got 404s. Every public website gets these.

The Singapore bot that set off the alarm accounted for about 2% of requests. The thing that worried me in Google Analytics was a rounding error, and the real load was invisible to it.

I’d built a crawler trap without realising

Why was Amazonbot so busy? Nearly all of its 7,465 requests went to one feature: Find schools. That page lets you filter by county, distance from a place, school type, language, size and trend, then sort and page through the results. Every combination has its own URL. To a crawler that’s an almost endless supply of “new” pages, and my robots.txt didn’t say otherwise.

The crawlers were following my rules. My rules just had a hole in them.

Not all the bots are bad

Hidden in the logs was something I liked: 15 requests from ChatGPT-User and 8 from Claude-User. These aren’t crawlers. They’re fetches made because a real person asked ChatGPT or Claude a question, and the assistant read my page to answer it. They went to individual schools, County Mayo, and a planning area in Claremorris. They look like people asking about specific schools and towns.

Google Analytics can’t see those visits either, but they’re probably a growing share of how people find the site. I want to keep them.

What I’m changing

The data on the site is public anyway, and the server barely noticed, so this isn’t an emergency. But it’s worth tidying up before it grows.

1. Close the crawler trap. Add these lines to robots.txt:

   User-agent: *
   Disallow: /schools?
   Disallow: /schools.csv

   The plain Find schools page stays crawlable; the endless filter combinations don’t. The crawlers that obey robots.txt (Amazonbot, Reflectionbot, Googlebot, Bingbot) make up about two-thirds of all requests.

2. Mark filtered views as noindex, nofollow so search engines stop discovering new combinations.

3. Turn away Bytespider, which has a reputation for ignoring robots.txt.

4. Filter the Singapore pattern out of my Google Analytics reports, so the numbers I make decisions on are about people.

How to check your own site

If you’ve seen a Singapore or Lanzhou spike, here’s what I’d do:

1. Check the fingerprint. In GA4, look at screen resolution, operating system, traffic source and engagement time for those visitors. 1280×1200, Windows, direct and zero seconds is the giveaway.
2. Find out whether it’s real or ghost traffic. Open Realtime → View user snapshot, click a suspicious visitor’s page_view event, and note its page_location and time. Then look for the same URL at the same second in your server or CDN logs.
   • If it’s there, these are real page loads, and you can block them by network.
   • If it isn’t, they’re ghost hits, and only filtering inside Analytics helps.
3. Read your server logs, not just Analytics. Group requests by user agent. You’ll probably find crawlers you’ve never heard of doing most of the work.
4. Hunt for crawler traps. Filters, search results, calendars, sort orders: anything that turns one page into thousands of URLs. Disallow them in robots.txt.
5. Don’t block the helpers. ChatGPT-User, Claude-User and similar agents fetch pages for real people asking real questions.

---

schoolnumbers.ie is a free site built from Department of Education data. If you’re choosing a primary school in Ireland, have a look.