WordPress runs 40.2% of all websites, according to W3Techs, and 58.7% of the sites whose content management system can be identified. That share makes it the most targeted CMS by simple arithmetic, and it means attack tools ship with WordPress-specific modes. The useful question about WordPress DDoS protection is not whether your site will be targeted, but where the attack gets stopped.
The short answer: not inside WordPress.
Why a security plugin cannot stop a flood
A security plugin is PHP code running on your server. For it to block a request, that request has already crossed your network port, completed a TCP handshake and a TLS negotiation, taken a web server worker and started a PHP process. The plugin then spends more CPU deciding to say no.
That is fine against someone trying passwords one at a time. It is useless against a flood, because a flood works by exhausting exactly the resources the plugin needs to run: the port, the connection table, the PHP workers and the CPU. Some firewall plugins load before WordPress itself to save work, but they still run on the same machine. A volumetric attack fills the port before any software on the server gets a vote.
Plugins still earn their place for malware scanning, login hardening and file integrity checks. They are the last line of defence, not the first.
The endpoints attackers actually hit
A WordPress flood rarely bothers with the cached homepage. It goes for the URLs that make PHP and the database work on every single request.
| Target | Why it hurts | Default exposure |
|---|---|---|
/xmlrpc.php |
Every call runs PHP, and one request can carry many calls | Enabled by default since WordPress 3.5 (December 2012) |
/wp-login.php |
Each attempt runs a deliberately slow password hash | Always on |
/wp-admin/admin-ajax.php |
Plugin actions run uncached, often for logged-out visitors | Depends on your plugins |
/?s= search |
A database query per request, rarely cached | Always on |
| Random query strings | Most page caches treat a new URL as a cache miss | Depends on your cache rules |
| WooCommerce cart and checkout | Tied to a session, so never served from cache | 19.8% of WordPress sites run WooCommerce |
XML-RPC deserves its own paragraph
XML-RPC predates the WordPress REST API, and some older apps and integrations still talk to sites through it. WordPress 3.5, released on 11 December 2012, switched it on for every site and removed the settings option to turn it off. Two of its methods matter to an attacker:
system.multicallexecutes a list of method calls from a single HTTP request. A rate limit that counts requests per IP address under-counts the login attempts packed inside them.pingback.pingmakes your server fetch a URL supplied by the caller, to check that the page really links to you. The Pingback specification has carried a warning since a 2007 erratum that this fetch can be abused for denial of service. It also means a stranger can make your server connect to a machine they control, and see your server's real IP address.
If nothing you use needs XML-RPC, block /xmlrpc.php at the proxy or the web server. If something does, allow it only from the addresses that need it.
What has to sit in front of the site
WordPress DDoS protection works when the attack is absorbed before it reaches your server. That means a DDoS protection proxy: your DNS points at the proxy, the proxy terminates TLS and filters the traffic, and only clean requests are forwarded to your origin server.
A proxy that is useful for WordPress does four things:
- Absorbs volumetric floods at layers 3 and 4 on its own network, so your port never sees them.
- Challenges bots with a JavaScript or redirect check that browsers pass and scripts usually do not. That is the right tool for
wp-login.phpand cache-busting floods. - Filters by source and behaviour: GeoIP and ASN blocking, rate limits per path, and rules for
xmlrpc.php. - Keeps the origin private, with the origin firewall accepting web traffic from the proxy only.
Point 4 is where most set-ups fail. If your server's real address is still reachable, an attacker skips the proxy and floods the origin directly. Pingbacks, old DNS records, mail headers and subdomains left off the proxy are the usual leaks. Once the proxy is live, restore real visitor IPs so that your logs, rate limits and comment spam filters keep working; getting real visitor IPs on your backend covers the web server side.
Slow, low-volume attacks need the same layer. Protecting against Slowloris with a layer 7 proxy shows an attack no plugin can see coming, and how a DDoS protection proxy works walks through the filtering layers in order.
Sizing a proxy plan from your own traffic
Proxy plans are sold by clean traffic, meaning the traffic that passes the filters and reaches your site, and by the size of flood the network absorbs. Dropped attack traffic is not the number to plan around. Your legitimate monthly transfer is.
Take that figure from your current host's bandwidth graph. As a rough guide, if an average page view transfers 2 MB, including the images and scripts served through the proxy:
| Plan | Clean traffic a month | Page views at 2 MB each | Layer 4 absorption | Monthly price |
|---|---|---|---|---|
| Micro | 3 TB | about 1.5 million | 10 Gbps | €49 |
| Small | 5 TB | about 2.5 million | 25 Gbps | €139 |
| Business | 15 TB | about 7.5 million | 50 Gbps | €399 |
| Enterprise | Unmetered | no cap | 100 Gbps included, up to 1 Tbps | €710 |
Annual billing takes 10% off. Every plan includes unlimited domains, SSL, the robot-detection web challenge, GeoIP blocking, WAF support and live logs; the larger plans add ASN blocking and advanced flood filters. A shop with a heavy checkout, or a news site that spikes, should size for its busiest month rather than an average one.
A checklist for putting WordPress behind a proxy
- Lower the DNS TTL a day before the switch, then point the A record at the proxy.
- Firewall the origin so that ports 80 and 443 accept connections from the proxy's addresses only.
- Block or restrict
/xmlrpc.php, and turn off pingbacks if you do not use them. - Put a challenge in front of
wp-login.php, and rate-limitadmin-ajax.phpand search. - Exclude
/wp-admin/and the WooCommerce cart and checkout from caching rules, but not from filtering. - Restore real visitor IPs in the web server and in any security plugin.
- Watch the live logs for a week and tune the rules before an attack, not during one.
If the site itself has outgrown its host, WordPress hosting requirements lists the signs, and managed WordPress hosting takes the server work off your hands entirely.
Where to start
NexonHost's anti-DDoS proxy for websites sits in front of any WordPress site, wherever it is hosted, with no migration: plans start at €49 a month for 3 TB of clean traffic and 10 Gbps of layer 4 absorption, with unlimited domains on every plan. If you want the same protection for servers and APIs as well as websites, remote DDoS protection covers the whole estate.
Specifications and pricing are as of 28 September 2026 — check the product pages for current figures.
Sources
- Usage statistics and market share of WordPress, W3Techs. 40.2% of all websites, 58.7% of sites with a known CMS, WooCommerce on 19.8% of WordPress sites. Retrieved 28 September 2026.
- Version 3.5, WordPress.org documentation. Released 11 December 2012; XML-RPC enabled by default and its Writing Settings option removed. Retrieved 28 September 2026.
- IXR_Server::multiCall() and wp_xmlrpc_server, WordPress Developer Resources. The multicall handler and the
pingback.pingmethod. Retrieved 28 September 2026. - Pingback 1.0, Stuart Langridge and Ian Hickson, including the 2007 erratum on denial of service. Retrieved 28 September 2026.
- NexonHost store, remote protection plans: clean traffic, layer 4 absorption, features and billing cycles. Retrieved 28 September 2026.
- Computed: 3 TB ÷ 2 MB = 1.5 million page views; 5 TB ÷ 2 MB = 2.5 million; 15 TB ÷ 2 MB = 7.5 million.
