The 'DDoS Attack' Almost No Small WordPress Site Actually Suffers

Most website owners who tell us they were hit by a DDoS attack were not hit by a DDoS attack. What actually happened is usually far more mundane: a scraping bot working its way through the product catalogue, a login endpoint being probed, or a genuine burst of interested visitors landing on a server that was never sized for the moment. I pulled the access logs on three separate "we're under attack" tickets this morning while writing this. None of them were a DDoS attack.

Mixing the two up matters more than it sounds. It leads a business owner to buy the wrong fix, ignore the right one, or lose a weekend convinced they are under siege when nothing malicious is happening at all. Getting the diagnosis right is the whole game. Everything else follows from it.

What a Real DDoS Attack Actually Looks Like Now

Distributed denial-of-service attacks are real, and they are getting bigger. Cloudflare's own network absorbed a record 7.3 terabits per second attack in May 2025, then watched that record fall again in the final quarter of the year to a 31.4 Tbps flood that lasted just 35 seconds. Across 2025 as a whole, Cloudflare logged attack volume more than double what it mitigated the year before (up 121%, by its own count), with network-layer floods making up more than three-quarters of everything it saw in the last quarter alone.

Those numbers describe traffic passing through one vendor's own infrastructure, so treat the exact figures as a single company's view rather than a universal count. The direction is not in doubt, though. Attacks are bigger, more frequent, and increasingly rented out as a paid service to whoever wants to knock a target offline for an afternoon. Cloudflare's own data also points to a sharp rise in ransom-driven DDoS threats, where an attacker demands payment before ever launching a flood, which tells you something about how commoditised this has become as a criminal business model rather than a targeted grudge.

Here is the part that matters for a business owner running one WordPress site: attacks at that scale are not aimed at a solo consultancy's booking page. They are aimed at gambling platforms, gaming infrastructure, and the hosting providers underneath them, because that is where the ransom money and the bragging rights are.

If a flood of that size ever did land on a shared server your site happened to sit on, every other site on that server would go down with you, and your hosting provider's own network team would already be firefighting before you noticed a slowdown. That is a real event. It is also an exceptionally rare one for the kind of site most readers of this article are running, and rarer still as something aimed specifically at you rather than caught in the blast radius of somebody else's fight.

What Is Actually Hitting Your Site Most of the Time

The traffic that actually causes trouble for small business sites has a name, and it is not DDoS. It is bots, and there are a great many more of them than most owners assume. Imperva's 2025 Bad Bot Report found that automated traffic, good bots and bad bots combined, overtook human browsing for the first time on record, crossing just over the halfway mark of all web traffic. Bad bots on their own accounted for a little over a third of everything, the sixth consecutive year that share has climbed.

Within that total, simple, high-volume bot activity, the kind that just hammers a URL repeatedly rather than trying anything clever, rose to roughly 45% of all bot attacks. That is a single vendor's benchmark rather than a universal figure, and results vary sharply by industry and by how much of your content is worth scraping in the first place, but the direction lines up with what we see across our own customer base. Price comparison scrapers, AI training crawlers, and SEO rank-checking tools now generate a meaningful share of the traffic hitting an ordinary business website, and none of them are being malicious. They are just relentless.

Picture a driving instructor in Leitrim who spent the best part of a month convinced a rival school was "DDoSing" his enquiry form. Bookings still came through, mostly, but the site felt sluggish every evening and he assumed the worst about a competitor he had fallen out with over a parking dispute. The server logs told a different story. A single scraping bot was working through his lesson price list every few seconds, day and night, indexing every combination of car type and package for a comparison site he had never heard of. No malice. No competitor. Just an automated crawler doing what automated crawlers do, at a volume nobody had designed the site to expect.

Why Getting the Diagnosis Wrong Costs You Twice

Here is the "so what" that most articles on this topic skip. Misdiagnosing the problem costs money in both directions. Assume you are under DDoS attack when you are actually being scraped, and you will spend on enterprise-grade mitigation you do not need while the actual cause, an unthrottled crawler, keeps chewing through your server resources unbothered. Assume "it's just bots, nothing to worry about" when the pattern is actually a credential-stuffing attempt against your login page, and you ignore the one signal that was worth acting on.

The fix has to start with verifying what is actually happening before deploying anything. Three questions settle it almost every time:

• How many distinct source addresses are involved? A handful, repeated relentlessly, points to a scraper or a targeted probe. Thousands of different addresses, each contributing very little, points to something closer to a genuine distributed flood.
• What is being requested? The same handful of product or pricing pages over and over is a scraper. Random URLs that do not exist on your site is usually a vulnerability scanner. Repeated POST requests to your login page is credential stuffing, a different conflict entirely.
• Does it correlate with anything real? A genuine traffic spike usually lines up with a mention somewhere, a promotion, or a seasonal pattern. A bot flood does not care what day it is.

A resource limit hit during a genuine traffic spike, a scraping bot, and a credential-stuffing run against wp-login.php all feel identical from inside the WordPress dashboard. They demand completely different responses, and guessing wrong wastes both money and time.

This is not a rare pattern. A sluggish afternoon convinces an owner they dodged a targeted attack. A premium volumetric protection add-on gets bought and quietly renews every month afterwards. The actual cause, an AI crawler indexing every product variant on the site, keeps crawling unaffected, because volumetric protection was never built to solve a scraping problem in the first place. Nobody checked the logs before buying, and nobody checked again after.

What Actually Stops the Common Case

The traffic that actually threatens a small business site, most of it bot-driven rather than malicious in the DDoS sense, is stopped closer to the server than most owners realise. Nginx, the web server underneath most managed WordPress platforms including Web60's, can apply rate limiting at the edge using a leaky bucket approach: define how many requests a single source can make per second, and anything above that gets slowed down or dropped before it ever reaches PHP.

That matters practically because PHP workers are expensive to spin up and easy to exhaust. A handful of aggressive bots can burn through your available workers long before your server's CPU shows any strain, which is exactly why a site can feel slow to a real visitor while the hosting dashboard still shows everything as green.

Fail2ban does a related but different job. It watches log patterns for behaviour like repeated failed logins, then bans the offending address at the firewall level for a set period. We have written before about how fail2ban and rate limiting work together against WordPress login page attacks, which is a related but genuinely distinct problem from the scraping and resource-exhaustion traffic covered here. Object caching through Redis, and page-level caching through FastCGI, handle a third piece of the puzzle: they mean a bot hammering your product catalogue does not force WordPress to rebuild the same pages from the database every single time, which keeps the site responsive for the paying customer arriving at the same moment.

I got this wrong myself early on. A client site spiked hard one afternoon and, without verifying the logs properly first, I spent an evening tightening firewall rules against what I assumed was a targeted attack. The actual cause was a legitimate news aggregator re-fetching a badly cached RSS feed every ninety seconds. No malice, just an inefficient integration on our side. Lesson learned: verify before you deploy a fix for a threat you have not actually confirmed.

Here is the honest limit of all of this. Fail2ban and IP-based rate limiting identify abuse by source address. A genuinely distributed flood, using thousands of different addresses each making only one or two requests, does not trip any single-IP threshold, because no single IP looks suspicious on its own.

That is not a flaw specific to any one hosting platform. It is a structural limit of address-based defence, and it is why the layered approach, rate limiting, fail2ban, caching, and someone actually watching the logs, matters more than any single control. For the fuller picture of what a hardened WordPress security stack should cover beyond this specific problem, our complete guide to WordPress security and backups walks through the rest of it.

Web60's enterprise-grade Irish infrastructure runs this stack, Nginx rate limiting, fail2ban intrusion prevention, and Redis object caching, as standard on every site in production, not as an add-on a customer has to remember to switch on. That is the difference between hosting that happens to run WordPress and hosting that was actually built to survive what the internet throws at a public website. If you are weighing up whether to build your own WordPress site rather than pay an agency, this groundwork already being in place from day one is worth factoring into that decision.

When You Do Need Real DDoS-Grade Protection

None of this means dedicated DDoS mitigation is a waste of money for everyone. If you run an e-commerce operation processing real transactions at volume, a media site that can go viral overnight and needs to survive the traffic that follows, or you already know you are a target because of a public dispute or a controversial campaign, a dedicated scrubbing service sitting in front of everything is a sensible, separate spend. That is a real use case, and it is not the one this article is written for.

Most local firms running a single WordPress site are not in that category. They do not need enterprise volumetric protection sized for a 30 terabit flood. They need the unglamorous basics done properly and consistently: rate limiting, intrusion detection, caching, and logs somebody actually looks at. Spending on the first when you need the second is how a business ends up paying twice, once for a service that never gets used and again for the problem it was never designed to solve.

Conclusion

The Leitrim driving instructor never found out who he thought was targeting him, because nobody was. The fix, once we looked at the right data, took an afternoon: throttle the crawler, cache the price list properly, move on. That is the shape of most "attacks" a small business owner will ever encounter.

The next time your site slows down and your instinct says "we're being attacked," check the logs before you reach for a bigger firewall or a more expensive plan. Most of the time the answer is a bot doing its job too aggressively, not an adversary with a grudge. Knowing the difference is what lets you spend on the right thing, worry about the right thing, and get back to running the business the website was built for.

Infrastructure that already handles rate limiting, intrusion detection, and caching properly will not stop you from ever wondering what is going on. It will give you a straight answer when you ask, instead of a dashboard that insists everything is fine while your site clearly is not. That answer, more than any firewall, is what actually lets you stop guessing and get back to work.

Sources

Cloudflare 2025 Q4 DDoS Threat Report

Cloudflare: Defending the internet, how Cloudflare blocked a monumental 7.3 Tbps DDoS attack

Imperva 2025 Bad Bot Report