Visitors Holding Steady Doesn’t Mean Nothing Happened
A marketing agency we work with recently came to us for help. They run a client’s brand site, and the client had flagged “traffic looks off.” When the agency opened the Cloudflare dashboard, daily requests had collapsed from over 30,000 to somewhere between 5,000 and 7,000 — and they never recovered.
Over that same window, unique visitors barely moved, maybe even ticked up slightly. The agency’s first reaction was relief — visitors are fine, so it’s probably nothing — but that combination hides a different problem: if real human traffic didn’t change, the 20,000-plus vanished requests were never real people to begin with.
That’s the signature of automated traffic: a script can fire tens of thousands of requests a day, but most traffic tools still count it as one visitor, or a handful. Requests collapse while visitors hold steady — nine times out of ten, that means something that used to show up every single day just stopped. Most teams see visitor counts intact and close the ticket right there, without ever asking what actually went missing. This time the agency asked that one extra question, and that’s what brought them to us.
The Extra Step: Check the Server’s Own Raw Log
This is the step we took once we got involved: don’t stop at Cloudflare’s free overview panel — go back to the raw log the client’s own server keeps, which should be the last line of defense. Every request that reaches the server gets written down there.
Most of the time, this step hits a wall immediately. A lot of sites run Apache’s default common log format — source IP, timestamp, requested URL, status code. No User-Agent field. Whether it was Googlebot, some AI assistant, or a poorly-written scraper, that log never recorded who it was, from day one. It’s not that the data got deleted or forgotten — that field simply never existed, going back to whenever the site was first configured. common is Apache’s bare-bones built-in format, and plenty of mid-size and larger companies’ own sites are still stuck on it: an agency or vendor set it up at launch with defaults, and nobody’s looked at the logging config since.
Getting User-Agent captured means manually switching the format to combined — and even then it only applies going forward. It can’t recover data that’s already gone, which means even fixing it right now doesn’t tell you who those missing requests used to be.
Most Agencies Never Get This Far
Catching “requests halved but visitors didn’t” already puts you ahead of what most marketing teams ever check — most people never go back and compare whether the requests line and the unique-visitors line in Cloudflare are moving together. And even once you catch the anomaly, the next step — checking raw server logs to find out who — runs into the same wall: whether the logs capture enough to identify anything was a decision made when the site was built, not something you can retrofit once you actually need it.
A free dashboard tells you the volume changed. It doesn’t tell you who changed — that takes deliberate configuration and someone actually watching. This is exactly why most agency reporting stops at “there’s an anomaly” and can’t say what the anomaly actually was — not for lack of diligence, but because answering it requires two layers of technical work (traffic analytics plus server log configuration), and most marketing toolkits only reach the first one.
Two Things You Can Do Right Now
First, concrete and immediate: check whether the client’s log format is still stuck on common. If it’s Apache, find the CustomLog line in the vhost config and switch the format to combined — at minimum you’ll start capturing User-Agent going forward, so the next anomaly leaves something to investigate. If you don’t manage the server yourself, one question to the host or engineer settles it: “Does our access log record User-Agent?”
Second, and harder: capturing the data doesn’t mean anyone looks at it. Catching “requests halved but visitors didn’t” depends entirely on someone habitually putting those two lines side by side — most of the time nobody does, and the anomaly passes by unexamined, unquestioned. This is exactly the step agencies come to us for: not replacing their first-line traffic report, but adding the second look, once the dashboard says “something’s off,” to work out what it actually was and whether it’s worth acting on. Want to check your own setup first? Run a free analysis and see where things stand. Have a client site stuck at “there’s an anomaly but no explanation”? Write to [email protected] — we’ll take a look and get back to you.