The website is down, or it loads so slowly that it might as well be. Your host says the server is “under heavy load” or that your account has been limited. Someone mentions the word DDoS, and suddenly it sounds like a serious criminal operation has picked your bakery or accounting firm as a target.
Sometimes that is roughly what has happened. More often the picture is less dramatic and more fixable. This post explains what a DDoS attack is in plain words, how to tell it apart from a hack or a genuine rush of visitors, what your host and a CDN can do about it, and what you, as the owner, can realistically do.
What a DDoS attack actually is
DDoS stands for distributed denial of service. Strip away the jargon and it means this: a large number of computers send your website more requests than it can answer, so real visitors cannot get through.
“Distributed” is the important word. The traffic does not come from one machine you could simply block. It usually comes from a botnet, which is a collection of hacked devices such as home routers, cameras and old servers, all following instructions from one person. Each device sends a modest amount of traffic. Together they overwhelm the target.
There are two broad kinds, and the difference matters for what protects you.
- Network floods try to fill the pipe. They throw so much raw traffic at the server’s connection that nothing else fits. Only your host or a large network provider can absorb these, because the traffic has to be stopped before it reaches you.
- Application floods try to exhaust the website itself. They send requests that look like normal page visits, often to pages that are expensive for WordPress to build, such as search results, the login page, the cart or a page that cannot be cached. A small server can be brought down by far less traffic this way, because each request makes PHP and the database do real work.
For small business sites, the second kind is the one you are more likely to meet.
How it differs from a hack
A DDoS attack and a hack are different problems, and confusing them leads to the wrong fix.
A DDoS attack does not get inside the site. Nothing is changed, nothing is added, no passwords are taken. When the flood stops, the site comes back exactly as it was. It is like a crowd blocking the door of a shop: very disruptive, but nobody has been in the stockroom.
A hack means someone has access. You might see pages you did not create, redirects to other sites, unknown admin users or warnings in Google. Those signs do not come from a traffic flood. If you are seeing them, treat it as a hack, and start with our page on emergency help for a hacked website rather than looking for DDoS protection.
The two can overlap. A flood of login attempts is technically a brute-force attack, not a DDoS, since the aim is to guess a password rather than to knock the site over. On a small server it can still have the same effect of slowing everything down, and the same CDN and firewall measures help with both.
How it differs from a real traffic spike
A sudden surge of genuine visitors can knock a small site over too. A mention in the news, a viral post or a sale email to your whole list can all do it. The symptoms on the server look similar. The causes do not.
| Clue | Real traffic spike | Likely attack |
|---|---|---|
| Where visitors come from | A link, an email, social media or search you can identify | No referrer, or countries you never sell to |
| What they request | The page that was shared, then other pages | The same page, the login or search, over and over |
| What they do | Browse, sign up, buy, leave at different times | Nothing useful; no enquiries or sales rise |
| Analytics | Usually shows the visitors | Often shows little, because bots rarely run analytics scripts |
That last row catches many people out. The server logs show a storm while Google Analytics shows an ordinary day. That gap is itself a clue that the traffic is automated.
A third possibility is neither: aggressive crawlers. Some bots, including AI and SEO crawlers, request pages very quickly. They are not trying to take you down, but on modest hosting the effect can be similar.
What your host does during an attack
Hosts care about DDoS attacks because one attacked site can slow down every other customer on the same server. Most providers have some network-level filtering, and it handles a lot of background noise you never hear about.
When an attack is large, a host’s first duty is to its whole network. On shared hosting that can mean your site is rate-limited, temporarily taken offline, or the traffic to its address is dropped altogether until the attack passes. It feels unfair, since you are the victim, but it is a common response. Ask your host what its policy is before you need to know.
Hosts are usually less able to help with application floods, because those requests look like normal visits at the network level. That is where a CDN comes in.
What a CDN does
A CDN (content delivery network) such as Cloudflare puts its own network between visitors and your server. Visitors connect to the CDN, and it passes traffic on to your host. This helps in three ways.
- Scale. A large CDN network can absorb volumes of traffic that would flatten a single server. Cloudflare includes DDoS protection on its free plan.
- Caching. If the CDN can serve cached copies of your pages, many requests never reach WordPress at all.
- Filtering. Rate limits, bot checks and challenge pages can stop automated traffic while letting people through. Cloudflare’s “I’m Under Attack” mode, for example, shows visitors a short check before the page loads.
Most CDNs also include a web application firewall. We will not repeat that here; our post on website firewalls (WAF) explains what one does and how to turn it on without blocking real customers.
One catch: a CDN only protects traffic that goes through it. If attackers know your server’s real address, they can go around it. That address often leaks through old DNS records, a subdomain that points straight at the server, or email headers sent from the same machine.
What you can realistically do
You cannot stop someone from aiming traffic at your site. You can make it much harder for that traffic to hurt you, and you can be ready to act quickly.
Before anything happens
- Know where your DNS is managed and have the login. Putting a site behind a CDN means changing DNS. Doing that for the first time during an attack, while hunting for a forgotten password, is stressful.
- Consider putting the site behind a CDN now. It is easier to set up calmly, and it usually makes the site faster as well.
- Cache what can be cached. A page served from cache costs the server almost nothing.
- Set up uptime monitoring so you hear about an outage from an alert rather than a customer. Our post on website uptime monitoring explains what to watch.
- Ask your host what it does when a site is attacked and how to reach support out of hours.
While it is happening
- Confirm it is not a real spike or a hack, using the clues above.
- Contact your host and ask what they see. They can often tell you within minutes whether it is a flood and what kind.
- If you use a CDN, turn on its attack mode or tighten its bot settings until things calm down.
- Keep a short note of times and what you changed, so you can undo it later.
If the flood arrives with a demand for payment to make it stop, do not pay. Our post on website extortion emails covers how to handle threats like that.
A large, targeted DDoS attack is not the everyday risk for a small business site. Smaller floods, bad bots and the occasional overload are far more ordinary. Our website security maintenance covers CDN and firewall setup, monitoring and a plan for what to do when the site goes down, so the first time you deal with it is not in the middle of it.
Next in this series: Mixed Content Warnings After Moving to HTTPS
