DDoS Protection for WordPress: A Plain Guide

A DDoS attack floods your website with so many junk requests from so many machines at once that real visitors cannot get through. DDoS stands for Distributed Denial of Service. Distributed means the traffic comes from thousands of scattered devices, so you cannot just block one address and be done.

The goal is not to break in or steal data. The goal is simply to keep your site busy answering nonsense until it has nothing left for genuine customers. A shop that will not load loses sales the same way a shop that has been hacked does, which is why availability is a security concern in its own right.

Attacks come in two broad shapes. Some try to saturate your connection with sheer volume of data. Others send requests that look almost like normal page loads, but in numbers no real audience would ever produce. Both aim at the same result: your server runs out of capacity and stops responding.

WordPress is an easy target because every uncached page request runs PHP and queries the database. Serving a static file is cheap. Building a WordPress page from scratch means loading the core, running active plugins, and asking the database for content. A flood of uncached requests forces that expensive work over and over until the server has nothing left.

Popularity is the other half of the problem. Because WordPress runs a large share of the web, attackers already know the default addresses to hammer: wp-login.php, xmlrpc.php and wp-admin. They do not have to study your site. They point existing tooling at the URLs that every WordPress install shares.

The xmlrpc.php endpoint deserves a special mention. It was built to let apps and services talk to WordPress, and it accepts multiple actions bundled into a single request. That bundling means one HTTP request can create far more work than usual, so attackers use it to amplify the load each request produces. Most sites do not need it enabled.

Layer 3/4 attacks aim at raw network capacity; layer 7 attacks aim at your application. The numbers refer to layers of the networking model. Layer 3 and 4 handle addresses and connections, the plumbing that moves data. Layer 7 is where your actual website lives: the HTTP requests that ask for pages.

A layer 3/4 attack, often called a volumetric flood, tries to fill your pipe with more data than it can carry. Think of a motorway jammed with empty cars: nothing about any single car is wrong, but together they stop anyone moving. These attacks are large and blunt, and they are best absorbed by a network that can soak up the volume before it reaches you.

A layer 7 attack is quieter and more cunning. Each request looks like a real visitor loading a real page, so you cannot block it by its shape alone. The attacker just sends far more of these requests than any genuine audience would, and picks the expensive pages on purpose: search results, filtered product listings, the login form. This is the kind of attack a WordPress site feels most sharply, because each request lands squarely on PHP and the database.

The practical takeaway: you cannot defend against both from inside WordPress. Volumetric floods must be absorbed by a network built for it, and layer 7 floods must be identified and dropped before they reach PHP. Both defences live in front of the site, never on it.

A plugin cannot stop a DDoS because it only runs after the request has already reached your server and loaded WordPress. By the time a security plugin decides to block a request, PHP has started, the plugin itself has loaded, and the server has already spent the resources the attacker wanted it to spend. The request is refused, but the cost has been paid.

There is a simple mental model here. A plugin is a security guard standing inside the building, checking each person as they reach the front desk. That works for a trickle of visitors. It does nothing when a crowd of tens of thousands pushes through the door at once, because the guard cannot check people faster than they arrive, and the lobby fills up regardless.

What actually works is filtering at the perimeter, before the request ever reaches your container. Traffic is inspected, obvious junk is dropped, and only clean requests are passed through. This is why every credible DDoS defence is a layer that sits in front of the site, and why no plugin, however good, can replace it. Plugins are still useful for login limits and hardening, but they are not a DDoS defence.

Stay calm, confirm it is actually an attack, and lean on the filtering layer in front of your site rather than fighting from inside WordPress. Panic edits under load often make things worse. The first job is to work out whether you are seeing an attack or a genuine traffic spike, then let your host's protection do what it is built to do.

Confirm the pattern first. A real surge (a newsletter, a viral post) usually comes from many sources with normal browsing behaviour and normal geography for your audience. An attack tends to hammer the same few endpoints, comes from unusual places, or produces request rates no human audience would generate. Your access logs and uptime alerts tell this story quickly.

Then reduce what the attacker can reach. Put the site behind full-page caching if it is not already, so cacheable pages never touch PHP. Disable xmlrpc.php if you do not use it. Temporarily rate-limit or lock down wp-login.php, which is a favourite target. If you host with a platform that filters traffic upstream, raise it with them: the useful controls live at the perimeter, not in your theme.

If you are on G7Cloud, the most important step is the one you do not have to take manually: attack traffic is filtered before it reaches your site, and per-minute uptime monitoring means we and you are alerted the moment availability dips. You are not watching a graph alone hoping it recovers.

ScaleShield is a firewall and bot-protection layer that sits in front of every G7Cloud site and inspects each request before it reaches your container. Known exploit patterns, credential-stuffing attempts and automated junk are dropped at the perimeter, so that traffic never consumes the CPU, memory and database time that serve your real visitors.

This is the whole point of filtering upstream. Because ScaleShield decides before your container is involved, a flood of bad requests is absorbed and discarded without ever starting PHP on your site. Your dedicated container keeps its resources for genuine traffic, which is what keeps the site responsive while an attack is in progress rather than after it ends.

It runs on every plan, including the Free plan, alongside free automatic TLS with wildcard certificates. There is no separate security add-on to buy and no premium tier to reach before your site is protected. You can read the full picture on the ScaleShield firewall and bot protection page.

Isolation matters here too. On G7Cloud, every site runs in its own dedicated container with its own database, never shared tables and never shared PHP workers. So even under pressure, one site's load cannot spill into another's. Filtering keeps the bad traffic out; isolation keeps the blast radius contained if any does get through.

Harden a WordPress site by reducing how much work each request can trigger and by choosing hosting that filters traffic before it reaches you. WordPress-level hardening cannot absorb a flood on its own, but it shrinks the attack surface and makes upstream filtering more effective. The two work together.

In practice, hardening buys you margin, not immunity. A leaner site with caching on and xmlrpc.php off will shrug off small floods that would have tipped over a bloated one. But a determined attack still needs to meet a filtering layer before your server, and dedicated resources of your own so that neither noisy neighbours nor a flood can starve your site.

"On our platform, the sites that ride out an attack calmly are the ones where the flood never reached PHP in the first place. Hardening helps, but the perimeter is where the fight is won."

If you want the mechanics of the isolation and filtering that make this hold up under pressure, how our WordPress hosting works walks through it, and WordPress security beyond plugins covers the wider hardening picture. It also explains why managed WordPress hosting beats shared hosting here: shared hosting rarely filters attack traffic upstream. Availability itself is covered on the uptime monitoring page.

Short answers to the questions people ask most when a WordPress site is at risk of, or already under, a DDoS attack. The theme throughout is the same: filter in front of the site, keep dedicated resources, and monitor so you know the moment something changes.