WordPress DDoS Protection: What Actually Works

A DDoS attack is one of those threats that sounds dramatic until it happens to you. Then it's worse than you imagined. Not because the attack itself is sophisticated, but because the speed at which it takes a site offline leaves almost no time to react.

We manage roughly 200 WordPress sites, including political organizations that have been directly targeted. That experience has taught us something the rest of the industry's content largely misses: WordPress DDoS protection is an infrastructure problem, not a plugin problem. The protection that actually matters happens before traffic ever reaches your server.

This article covers what DDoS attacks are, why WordPress is specifically vulnerable, and what actually stops them. If you're here because your site is under attack right now, skip to what to do during an active attack.

What a WordPress DDoS Attack Actually Is

A DDoS (Distributed Denial of Service) attack floods a website with so much traffic from so many sources that it can't respond to legitimate visitors. Instead of a single attacker, a DDoS uses thousands or tens of thousands of compromised devices, known as a botnet, sending requests simultaneously to overwhelm the target.

The distinction between a DDoS attack and a traffic spike matters. A viral social media post might overwhelm your server with legitimate visitors. A DDoS attack overwhelms it with malicious traffic designed specifically to make your site unreachable. The response to each is different.

DDoS attacks fall into three categories, and understanding which one you're facing determines what kind of protection actually helps.

Volumetric Attacks

These are the brute-force approaches. Volumetric attacks flood your network connection with massive amounts of data, saturating your bandwidth before traffic ever reaches the server. Cloudflare recorded a 6.5 Tbps attack in early 2025, the largest ever publicly disclosed. For context, that's thousands of times more bandwidth than most hosting accounts provide.

No WordPress plugin, server configuration, or application-level setting can stop a volumetric attack. The traffic overwhelms the network pipe itself. Your server never even gets a chance to process the requests.

Protocol Attacks

Protocol attacks exploit weaknesses in network protocols to exhaust server resources. SYN floods, the most common type, send massive numbers of connection requests without completing them, filling up the server's connection tables until it can't accept legitimate connections. DNS floods prevent your domain name from resolving at all.

Like volumetric attacks, these target layers below WordPress. The operating system's network stack is overwhelmed before PHP ever runs.

Application-Layer Attacks

This is where WordPress becomes specifically relevant. Application-layer attacks send HTTP requests that look like legitimate traffic but are designed to exhaust server resources. Each request forces the server through the full PHP execution stack: loading WordPress core, initializing all active plugins, executing database queries, and rendering the page.

A typical WordPress site with 20 to 30 active plugins has a high per-request cost. Under normal traffic, caching handles this fine. Under an application-layer attack, thousands of concurrent requests each impose that full computational cost. The server runs out of PHP workers, memory, or CPU.

Application-layer HTTP DDoS attacks increased 118% year-over-year in early 2025. They account for over half of all DDoS attacks, and 94% of this traffic is encrypted (HTTPS), making it harder to inspect and filter.

Why WordPress Sites Are Particularly Vulnerable

WordPress isn't uniquely vulnerable to volumetric or protocol attacks. Any website can be targeted. But WordPress has specific characteristics that make application-layer attacks more effective, along with several built-in features that serve as attack-surface amplifiers.

The Per-Request Cost Problem

Every uncached request to a WordPress site triggers a predictable sequence: load WordPress core (roughly 50 files), initialize all active plugins, load the theme, execute database queries, run all registered hooks and filters, and render the template.

A page that takes 500 milliseconds and 50 megabytes of RAM to serve is fine under normal conditions. Under attack, that same cost multiplied by thousands of concurrent requests is devastating. The asymmetry is the core vulnerability: a simple HTTP request from an attacker triggers expensive processing on the server.

XML-RPC: The Attack Vector WordPress Gave Away for Free

WordPress's XML-RPC interface (xmlrpc.php) was designed for remote publishing and pingback notifications. It became one of the most notorious DDoS vectors in the ecosystem.

Here's how it works: attackers send pingback requests to thousands of WordPress sites, each containing the victim's URL. Every WordPress site then makes an HTTP request to the victim to "verify" the pingback. The result is thousands of legitimate WordPress sites simultaneously hammering the target.

WordPress 6.x and later have deprecated XML-RPC, and most security tools disable it by default. But many legacy sites still have it enabled. The lesson is instructive: a well-intentioned feature created a massive attack surface that persisted for years before the ecosystem addressed it. Compromised WordPress plugins create a similar dynamic, where trusted software becomes an attack vector that site owners don't think to question.

Other WordPress-Specific Attack Surfaces

wp-login.php is resource-intensive by design. Every login attempt triggers a database lookup, password hash computation (deliberately slow for security), and session management. Even failed logins consume significant server resources. Sustained login flooding doubles as both a brute-force credential attack and a resource-exhaustion attack.

WordPress search executes database queries that bypass page caching. Attackers can fire rapid search requests with complex queries to force full-text database scans, consuming CPU and memory without hitting any cached content.

wp-cron.php fires on every page load by default to check for scheduled tasks. Under attack, every malicious request triggers this evaluation. If heavy cron tasks are pending, they may execute simultaneously across thousands of concurrent requests, multiplying the damage.

Where WordPress DDoS Protection Actually Happens

This is the part that most content on this topic gets wrong, and it's the reason plugin-based DDoS protection is largely marketing.

Here's the request path for a WordPress site:

Attacker > Internet backbone > CDN/Edge network > Origin server > Web server > PHP > WordPress > Plugin

A WordPress security plugin sits at the very end of that chain. By the time a plugin evaluates whether a request is malicious, the bandwidth has already been consumed, the TCP connection established, the web server has accepted the request, PHP has started executing, WordPress core has loaded, and all active plugins have initialized.

The plugin can block the request from completing, but the resource damage is already done. Under heavy attack, the server runs out of capacity before the "protection" plugin can process the backlog. It's like installing a lock on the bedroom door to protect against a flood. The lock works fine. The water doesn't care.

"Before WAFs existed, the response was to shut down the PHP application entirely and wait out the attack until the bot stopped getting positive response codes. You'd literally take the site offline yourself because there was nothing else you could do."

That was the state of DDoS defense before edge-level protection existed. Today, the picture is very different.

Edge-Level Protection: What Actually Works

Effective DDoS mitigation happens at the network edge, before traffic reaches your server. This is the architectural model behind services like Cloudflare, which operates a 348 Tbps global network across 335 cities. For perspective, the largest DDoS attack ever recorded (6.5 Tbps) used less than 2% of that capacity.

Edge protection works through several mechanisms:

Traffic absorption. Attack traffic hits the CDN's distributed network, not your origin server. There's no single point to overwhelm because the traffic is spread across hundreds of data centers worldwide.

Autonomous detection. Modern edge networks identify and filter attack traffic without human intervention. Cloudflare mitigated a 5.6 Tbps attack from 13,000 compromised IoT devices in 80 seconds with zero human interaction. That matters because 89% of Layer 3/4 attacks end within 10 minutes. By the time a human notices an alert, the attack is often already over.

Always-on filtering. Traffic flows through the edge network constantly, so protection doesn't need to "spin up" when an attack begins. This eliminates the gap between detection and mitigation that makes on-demand DDoS services largely ineffective.

Bot detection and rate limiting. Application-layer attacks that appear as legitimate HTTP requests get filtered using behavioral analysis, browser verification challenges, and rate limiting at the edge, all before they consume server resources.

Origin Server Hardening

Edge protection handles the heavy lifting, but origin server configuration matters for defense-in-depth. These steps won't stop a DDoS on their own, but they're important layers in a complete strategy.

At the web server level: Block xmlrpc.php in Apache or Nginx configuration (not via a PHP plugin, which still requires PHP execution for every request). Rate-limit wp-login.php and wp-admin at the web server. Configure connection limits and timeouts.

At the WordPress level: Disable WP-Cron and use a server-side cron job instead. Add full-page caching so cached responses bypass PHP entirely. Minimize active plugin count to reduce per-request overhead.

At the infrastructure level: Hide your origin IP address. Configure your origin firewall to only accept traffic from your CDN's IP ranges. Use authenticated origin pulls so that even if someone discovers your server's IP, direct requests get rejected.

These measures won't stop a volumetric attack. Nothing at the server level can. But they reduce the attack surface for application-layer attacks and ensure that traffic bypassing the CDN can't reach your server directly.

Why "WordPress DDoS Protection Plugins" Are Marketing

Several WordPress plugins market DDoS protection features. The technical reality deserves an honest assessment.

PHP-based security plugins like Wordfence, Shield Security, and All-In-One WP Security provide rate limiting and IP blocking that can handle small-scale brute-force attempts. But against a real DDoS attack, each blocked request still costs server resources because the plugin only runs after PHP has loaded and WordPress has initialized. Under sustained attack, this overhead compounds rather than mitigates.

Wordfence Premium costs $149/yr and offers no DDoS mitigation. Cloudflare Free ($0) provides 348 Tbps of absorption capacity. AWS Shield Advanced, for comparison, costs $3,000/mo. The pricing disconnect tells you where actual DDoS mitigation lives.

Cloud-based WAF services like Sucuri that offer a WordPress plugin for configuration are a different category entirely. Their protection comes from the cloud proxy, not the WordPress plugin. The plugin is just a management interface. This distinction gets lost in marketing.

The honest framing: a cloud-based WAF/CDN operating at the network edge provides genuine DDoS mitigation. A PHP-based plugin running inside WordPress does not, regardless of what its feature list claims.

Who Gets Targeted and Why

The motivations behind DDoS attacks reveal who should be most concerned. According to Cloudflare's customer surveys:

• Competitors: 39-40% of attacks (consistently the number one motivator)
• State-level actors: 17%
• Disgruntled users or customers: 17%
• Extortionists: 11-14% (growing rapidly, up 78% quarter-over-quarter in late 2024)

Competitive motivation is the most relevant in the WordPress world. Businesses attacking rival businesses is far more common than the dramatic nation-state narrative. But for political organizations, advocacy groups, and nonprofits, the calculus is different.

Political and Advocacy Organizations Face a Different Threat

Organizations involved in advocacy, elections, or controversial causes face DDoS risk for structural reasons. Their content is time-sensitive, so taking a site offline during a fundraising push or election cycle has an outsized impact. They typically lack dedicated security teams. And attacks against them are driven by ideological opposition rather than financial motives, making them harder to predict and deter.

We have firsthand experience with this. We've fought bots from China, Russia, and Egypt targeting our political clients.

The most serious case involved a political action committee's donations page. Attackers from Egypt targeted the donations page specifically, not the whole site, a few weeks before a major national election. The goal was to stop the organization from collecting donations during the final push, which would hurt their ability to fund campaign advertising.

"The FBI got involved because it was considered a direct threat against the democratic process of the United States. That's the kind of scenario we're talking about when attacks become targeted."

That client, a major political organization and SuperPAC, has been under our protection for over 16 years with zero downtime due to DDoS attacks. That track record isn't because of any WordPress plugin. It's because their traffic passes through Cloudflare Enterprise WAF, and their origin server accepts traffic only from Cloudflare's network.

Cloudflare recognized this threat category early. Their Project Galileo program, launched in 2014, provides enterprise-grade DDoS protection at no cost to qualifying advocacy organizations, citizen journalists, and human rights groups. Their Athenian Project does the same for election infrastructure. By 2020, 229 state and local governments across 28 states were using it.

These programs exist because the threat is real and because the organizations most at risk are often the least equipped to defend themselves.

Ransom DDoS

A growing pattern is extortion-based DDoS, where attackers demonstrate their capability with a brief attack, then demand payment to prevent sustained attacks. Reports of ransom DDoS grew 78% quarter-over-quarter in late 2024. Political organizations and nonprofits are particularly vulnerable because they often lack both the technical resources to defend themselves and the financial reserves to absorb the disruption.

The DDoS Threat by the Numbers

The scale of the DDoS landscape has shifted dramatically in recent years:

• 20.5 million DDoS attacks in Q1 2025 alone, nearly matching the 21.3 million attacks recorded in all of 2024
• 358% year-over-year increase in total DDoS attacks in Q1 2025
• 98% of HTTP requests to WordPress admin paths (/wp-admin/) are attack traffic
• 89% of attacks end within 10 minutes, faster than any human response

That last point is why always-on protection matters. If 89% of attacks are over within 10 minutes, any solution that requires human activation or DNS changes is already too late. The attack has done its damage and moved on before anyone can respond.

The 98% stat about wp-admin traffic is worth sitting with. For every legitimate admin login on an unprotected WordPress site, there are approximately 49 malicious requests. That background noise doesn't make headlines, but it constantly degrades performance and consumes server resources.

Low-and-Slow DDoS: The Attacks That Get Through

Traditional DDoS is a volume game. Flood the server, crash it, move on. Modern edge networks like Cloudflare stop 99.9% of those attacks. What still gets through is something different entirely.

Low-and-slow DDoS attacks use pools of IP addresses spread across multiple countries. Instead of hammering a site with thousands of requests per second, they hit forms a few times per minute from each IP. The traffic volume from any single source stays well below WAF rate-limiting thresholds, so the requests pass through as normal visitor traffic.

The damage accumulates gradually. No single request looks malicious. No spike triggers an automated response. But over hours or days, the effect is real: server resources degrade, response times creep up, and legitimate visitors experience a slower, less reliable site.

Database Flooding as a DDoS Strategy

One of the more effective low-and-slow techniques targets databases rather than server uptime. Attackers flood forms with fake applications, registrations, or submissions. This overlaps significantly with WordPress spam registrations, where deliberately throttled bots create fake accounts to stay under detection thresholds. The goal isn't to crash the server in one burst. It's to exhaust processing and storage resources over time, degrading the site gradually rather than taking it down all at once.

This connects directly to the donations-page scenario described above. Attackers targeting a political organization's donation forms aren't just trying to block transactions in the moment. They're filling the database with garbage that consumes processing power, slows queries, and makes the entire site sluggish during the exact period when performance matters most.

For political and membership organizations running donation or registration forms, this is the DDoS variant that demands the most attention. It bypasses edge-level protections because each submission looks legitimate. Detecting it requires human monitoring: watching form submissions for patterns, reviewing database growth rates, and correlating unusual activity with performance degradation.

Cloudflare Free vs. Enterprise: What You Actually Get

Every article on this topic recommends "use Cloudflare" without explaining the significant gap between tiers. Here's what actually matters for WordPress DDoS protection at the CDN level.

The core DDoS absorption is the same across all tiers, including the free plan. Cloudflare includes unmetered DDoS mitigation at every level. They don't charge based on attack volume, and the 348 Tbps network capacity is available whether you're on the free plan or Enterprise. A free Cloudflare plan provides more actual DDoS mitigation capacity than any premium WordPress security plugin at any price.

The difference between tiers isn't absorption capacity. It's everything else.

For a single site that just needs volumetric DDoS protection, the free tier is genuinely effective. For sites that face application-layer attacks, need custom WAF rules to handle WordPress-specific patterns (xmlrpc.php blocking, wp-login rate limiting, REST API restrictions), or require guaranteed response times during an incident, the Enterprise tier is where those capabilities live.

We run Cloudflare Enterprise WAF across our entire fleet. That gives us the ability to write custom rules targeting WordPress-specific attack patterns and deploy them across all sites simultaneously. When we identify a new attack vector on one site, the rule protecting against it is live across 200 sites within minutes.

What to Do During an Active DDoS Attack

If your WordPress site is under attack right now, here's a realistic timeline of what happens and what you can do.

If you have edge protection (Cloudflare or similar) already in place: Your site is likely still up. The attack traffic is being absorbed at the network edge. Check your CDN's analytics dashboard to confirm the attack is being mitigated. If application-layer attacks are getting through, you may need to increase the challenge threshold or enable "Under Attack" mode, which adds a JavaScript challenge to all visitors.

If you don't have edge protection: The realistic timeline looks like this:

1. Attack begins. HTTP flood hits your server.
2. Within 5-15 seconds: PHP workers saturate. Response times spike. New requests queue.
3. Within 30 seconds: Memory exhaustion. Server starts returning 503 errors.
4. Within 1-2 minutes: Server becomes unresponsive. If the attack is volumetric, SSH access may fail too.
5. Within 5-15 minutes: Your hosting provider may null-route your IP address to protect their other customers, taking down all your sites on that server.
6. 5-60 minutes later: You notice (monitoring alert, customer complaint, hosting provider email).
7. 15-60 minutes after that: You start trying to fix it, activating a CDN, changing DNS, contacting your host.
8. DNS propagation: Even after you activate CDN protection, DNS changes take anywhere from 5 minutes to 48 hours to propagate globally.

The gap between steps 1 and 7 is the problem. By the time you can react, the attack may already be over, having achieved its goal of taking your site offline during a critical window.

"Cloudflare is only your first level of defense. Good security monitoring and good development reaction are both critically important."

This is why always-on protection isn't optional for any site where downtime matters. Reactive DDoS mitigation isn't mitigation. It's damage control after the fact.

DDoS Protection at Scale: The Fleet Approach

Protecting one WordPress site from DDoS is conceptually straightforward: put it behind a CDN with edge protection. Protecting 200 sites introduces operational complexities that change the equation.

When we identify a new WordPress-specific attack pattern, whether it's a new xmlrpc.php exploitation technique, a novel wp-login.php flooding pattern, or application-layer attacks targeting a specific REST API endpoint, we write a WAF rule once and deploy it across every site in the fleet. One rule protects 200 sites simultaneously.

Centralized monitoring also means we see attack patterns emerging before they reach individual sites. If three sites start seeing the same unusual traffic pattern on a Tuesday morning, we can preemptively tighten rules across the rest of the fleet before the attackers get to them.

"We don't allow any sites on our server where traffic isn't going through Cloudflare Enterprise WAF."

That's a non-negotiable policy, and it's specifically because of threats like DDoS. Clients who push back on the requirement are overruled on this point. When you look at DDoS statistics showing 20.5 million attacks in a single quarter, the rationale is straightforward.

The Honest Answer About WordPress DDoS Protection

No one can guarantee that a DDoS attack won't affect your site. Anyone making that claim doesn't understand the threat. What proper infrastructure does is shift the odds dramatically in your favor by absorbing the vast majority of attack traffic at the network edge, before it ever reaches your server.

"We can't guarantee attacks won't happen. What we can guarantee is 24/7/365 immediate response without disrupting the donation cycle."

The key takeaways:

DDoS protection is an infrastructure decision, not a plugin decision. The protection that matters happens at the network edge, not inside WordPress. A PHP-based plugin can't prevent traffic from overwhelming the server before PHP executes.

Even free Cloudflare provides more DDoS mitigation than any premium security plugin. The 348 Tbps network capacity is the protection. Wordfence Premium at $149/yr provides zero DDoS mitigation. Cloudflare Free at $0 provides 348 Tbps of absorption.

Always-on protection isn't optional. With 89% of attacks ending within 10 minutes, any solution requiring manual activation is too slow.

WordPress has specific vulnerabilities that amplify DDoS impact. XML-RPC, wp-login.php, wp-cron.php, and the per-request computational cost of the plugin architecture all create attack surface that needs to be addressed at the infrastructure level.

Low-and-slow attacks require human vigilance, not just automated defenses. The attacks that get through modern WAFs are designed to avoid triggering rate limits. Detecting database flooding, form spam, and gradual resource degradation requires active monitoring and pattern recognition.

High-risk organizations need enterprise-grade protection. Political organizations, advocacy groups, and nonprofits face threats that go beyond what basic CDN plans handle. Custom WAF rules, advanced bot management, and dedicated support during incidents aren't luxuries for these organizations. You can't effectively defend against DDoS at that threat level with basic tools alone.

If a DDoS attack hits your WordPress site and you don't have edge-level protection, you're completely exposed. Adding that layer is the single most impactful change you can make for DDoS resilience. If you're running a basic CDN plan on a high-value or politically exposed site, it may be worth evaluating whether your current tier provides the WAF customization and support your threat profile requires.

For a broader view of how DDoS fits into the overall WordPress threat landscape, our WordPress security threats hub covers every major attack category and how the defense layers connect. Our Cloudflare WAF deep dive explains how edge-level protection works in practice across our fleet. For recommendations on security tools that actually provide value at the application layer, see our WordPress security plugins guide.

Organizations that face elevated DDoS risk due to their mission or public profile, especially advocacy organizations and campaign sites, need infrastructure built for that threat level from day one, not bolted on after the first attack.

Frequently Asked Questions

Can a WordPress plugin stop a DDoS attack?

No. A PHP-based security plugin runs at the very end of the request chain. By the time the plugin evaluates whether a request is malicious, your server has already consumed bandwidth, established the TCP connection, loaded PHP, bootstrapped WordPress, and initialized all active plugins. The plugin can block the request from completing, but the resource damage is already done. Real DDoS protection happens at the network edge through a service like Cloudflare, where attack traffic is absorbed before it reaches your server.

Is Cloudflare's free plan enough for DDoS protection?

For basic volumetric DDoS absorption, the free plan is genuinely effective. Cloudflare includes unmetered DDoS mitigation at every tier, and the 348 Tbps network capacity is available whether you're on the free plan or Enterprise. The difference is in everything else: custom WAF rules for WordPress-specific attack patterns, advanced bot management, granular rate limiting, and 24/7 dedicated support during incidents. For a simple brochure site, free is fine. For a political organization or membership site facing targeted attacks, the free tier won't give you the customization or support you need.

What should I do if my site is under DDoS attack right now?

If you already have Cloudflare or another CDN in place, check your analytics dashboard to confirm the attack is being mitigated. If application-layer attacks are getting through, enable "Under Attack" mode which adds a JavaScript challenge to all visitors. If you don't have edge protection, your options are limited. Your hosting provider may null-route your IP to protect other customers on the server. The realistic path is to sign up for Cloudflare, update your DNS, and wait for propagation, but that can take anywhere from 5 minutes to 48 hours. That gap is exactly why always-on protection needs to be in place before an attack happens.

Why would someone DDoS my small WordPress site?

Competitive motivation accounts for 39 to 40 percent of DDoS attacks. Businesses targeting rival businesses is more common than dramatic nation-state scenarios. But even if you're not being specifically targeted, your site can still be affected. Volumetric attacks sometimes hit IP ranges rather than individual sites, and shared hosting environments mean an attack on one site can degrade performance for everyone on the same server. For political organizations, advocacy groups, and nonprofits, the risk goes up significantly because attacks are driven by ideological opposition and timed to cause maximum disruption.

What's a low-and-slow DDoS attack?

It's a DDoS variant designed to bypass traditional rate limiting. Instead of flooding your site with thousands of requests per second, attackers use pools of IP addresses spread across multiple countries and hit your site just a few times per minute from each one. No single source triggers your firewall's detection threshold. But over hours or days, the cumulative effect degrades your server's performance, slows database queries, and makes the site sluggish for real visitors. These attacks are harder to detect and harder to stop because they look like normal traffic. Catching them requires human monitoring and pattern recognition, not just automated defenses.

If you're evaluating your security posture, our WordPress security services page explains what's included. You can also read about why organizations choose FatLab for WordPress security and how our approach differs from typical hosting providers.