You'd think several million extra page views would be a good thing
More traffic usually means more visibility, more enquiries, more business. So when we found a client’s site had received over 4 million extra page requests in three weeks, our first reaction should have been celebration.
It wasn’t. Because none of those additional 4 million hits were real people.
We’d noticed the site was slow to edit – nothing dramatic, just a bit sluggish. The instinct with something like that is to check for a hack – malware, an injected script, a compromised plugin – although that’s what hosting providers and the installed security software is normally very good at catching.
This wasn’t the issue… because when we dug into the hosting resource stats, we realised that the site had received over 4 million extra page requests in three weeks, from servers scattered across several countries.
Not a hack – a flood of traffic, deliberately aimed at overwhelming the site’s resources rather than breaking into it.
The part that actually surprised us
Hosting providers are genuinely good at spotting the first kind of problem – a hacked file, a malicious script, an email that shouldn’t be going out. What most of them aren’t set up to notice is the second kind: a site quietly getting smothered by request volume, with nothing “infected” to flag at all.
It’s a bit like having excellent security on the front door – checking IDs, watching for anyone who shouldn’t be there – while nobody’s watching the fire exit around the back, where the real volume gained access.
We only caught it because the site felt slower than it should, and we went looking. Three WordPress ecommerce websites, of the many hosted sites that we manage, had the same thing happen around the same time. None of the hosting providers involved – ours or the client’s – had flagged it.
What we changed
Two things, straightforward once we knew what to look for. First, we put in place code to block the specific pattern of traffic causing the problem.
Second, and more importantly, we requested that the ecommerce clients’ IT providers install a low-cost Cloudflare filter – the kind you’ve probably seen yourself, a brief black security banner (reassuring visitors that a security check is being done) for a second or two before the site displays, quietly identifying real visitors from suspicious traffic apart.
It sits there switched off, at no ongoing cost, until it’s needed – then it can be turned on in minutes, temporarily or permanently, without touching anything else on the site.
That’s now a standard recommendation for every ecommerce site we manage. Not because we expect this to happen often, but because the actual gap – hosting providers watching for hacks but not for this – isn’t something that’s going to close on its own.
If we hadn’t happened to notice the site felt slower than usual, we wouldn’t have known to look.
What this told us
Hosting providers and website security plugins are capable of identifying malicious hacking. But that’s not intended to catch this specific issue – Distributed Denial of Service (DDoS): a site quietly being smothered by sheer request volume, with nothing “infected” to flag.
So that’s the gap we now watch for. It’s part of why we keep an eye on site performance as a matter of course, not just when something’s obviously broken – a site running slower than it should is often the only early signal there is, and for an ecommerce site, slow is close enough to down.
A checkout that hesitates loses sales the same way a checkout that’s offline does – just more quietly.
Where we’ve taken it further
For every ecommerce site we manage, that now means a Cloudflare filter installed and ready – switched off, at no ongoing cost, until it’s needed, then live within minutes. No disruption, no scramble, and no enquiries or sales lost while someone works out what’s wrong.
For high-traffic, corporate and healthcare sites, we’ve gone a layer further again – adding proactive security scans and vulnerability checks that flag plugins or structural weak points before they become a problem, rather than after.
Catching something before it affects the site is always the cheaper outcome than fixing it once it has.
Both come from the same principle: a website isn’t something you build once and leave running.
The threats change, and staying ahead of them is part of the job – not a one-off fix, but an ongoing layer of care that gets added to as new patterns emerge.
If you’re not sure whether your own site has this kind of gap covered, it’s worth a conversation. You’re welcome to contact me anytime – no obligation.