WordPress DDoS Protection: How to Keep Your Site Online

WordPress DDoS protection is the combination of tools, server configurations, and network-level defenses that stop attackers from flooding your site with fake traffic until it crashes.

It sounds straightforward. But with 20.5 million DDoS attacks recorded in Q1 2025 alone, nearly matching the entire total from 2024, most WordPress sites are still running on the same basic setup they had three years ago. The problem is not that protection is hard to find. It is that most guides point you toward one or two tools and call it done.

This article covers what actually makes WordPress sites vulnerable, how DDoS attacks exploit specific WordPress files and endpoints, and how to build a layered defense that holds up, including what to do if an attack is already underway.

What a WordPress DDoS Attack Actually Looks Like

A DDoS (Distributed Denial of Service) attack floods your server with requests from thousands of devices at once. The goal is to exhaust your server’s resources: CPU, memory, or bandwidth, until legitimate users can no longer reach your site. The devices doing the flooding are usually part of a botnet: a network of compromised machines controlled by an attacker without their owners knowing.

There are three distinct types to understand, because the protection that works against one does not always work against another.

• Volumetric attacks try to saturate your bandwidth. The sheer volume of data overwhelms your network before any request even reaches WordPress. Cloudflare recorded a 6.5 Tbps volumetric attack in early 2025, the largest ever publicly disclosed.
• Protocol attacks target your server’s network stack, overloading firewalls and load balancers rather than WordPress itself. SYN floods are the most common example.
• Application-layer attacks are the most relevant for WordPress. Instead of flooding bandwidth, they send HTTP requests that look like real traffic. Each request forces your server through the full WordPress execution stack: loading PHP, initializing all active plugins, running database queries, and rendering output. A WordPress site with 20 to 30 active plugins has a high cost per request. Under normal traffic, caching handles this well. Under an attack sending thousands of concurrent requests, the server runs out of PHP workers fast.

Application-layer HTTP DDoS attacks increased 118% year-over-year in early 2025. That is the attack type most likely to hit a WordPress or WooCommerce site.

How to Tell It’s a DDoS Attack (Not Just a Traffic Spike)

A sudden traffic surge could be a viral post or a DDoS attack. Here is how to tell the difference.

With a genuine traffic spike, requests come from many different locations but follow normal browsing patterns: people land on your homepage or a specific post, stay for a while, and click around. Server load rises, but your error logs stay mostly clean.

With a DDoS attack, you will see requests hitting the same endpoint repeatedly from hundreds or thousands of IP addresses. Your server logs fill up with POST requests to /xmlrpc.php or GET requests to /wp-login.php at a rate no human browsing session could produce. CPU and memory spike hard and fast. Your hosting provider may alert you to unusual resource use before you even notice the slowdown.

Check your access logs first. On Apache, run grep xmlrpc.php /var/log/apache2/access.log | wc -l and check the count. A high number of POST requests from different IPs in a short window is a strong indicator. On Nginx, check /var/log/nginx/access.log.

If your login page shows large numbers of rapid, varied login attempts from many IPs, that is more likely a brute-force attack than a DDoS. The two often run together, but they need different responses.

The WordPress Attack Vectors Attackers Actually Use

Most guides treat xmlrpc.php, wp-login.php, and the REST API as separate issues. Attackers do not. They probe all three and hit whichever one is easiest. Here is what each one actually does in a DDoS context.

xmlrpc.php: Two Threats, Not One

The xmlrpc.php file is a legacy WordPress feature that allowed remote publishing from old desktop apps and early mobile clients. It has two specific DDoS uses that are often confused.

The first is pingback abuse. Attackers send spoofed pingback requests through your xmlrpc.php to flood a third-party target, without your knowledge. In one documented attack, security researchers at Sucuri found over 162,000 legitimate WordPress sites unknowingly hitting a single target through this method. Your site becomes part of the botnet. Your hosting provider may suspend you. You will not know it happened until you check your logs or get a notice.

The second is brute-force amplification. The system.multicall method lets an attacker bundle hundreds of password attempts into a single HTTP request. A plugin watching /wp-login.php for suspicious login activity will not see any of it. The requests never touch that file.

wp-login.php Flooding

This is the bluntest attack vector. Attackers send thousands of requests to the WordPress login page to exhaust server resources or eventually guess credentials.

Research from Cloudflare data shows that 98% of HTTP requests to WordPress admin paths are attack traffic. That means for every legitimate admin login on an unprotected site, roughly 49 malicious requests are firing in the background.

WordPress REST API Endpoint Abuse

Less discussed, but growing. The REST API is a modern interface that allows plugins, themes, and external tools to interact with WordPress using JSON. Attackers send unauthenticated requests to REST API endpoints at high volume.

Each request still executes PHP and hits the database. Application-layer HTTP DDoS attacks increased 118% year-over-year in early 2025, and REST API endpoints are increasingly part of that picture.

Worth knowing before you go further: A common recommendation is to disable the REST API entirely for unauthenticated users. That creates a serious problem for WooCommerce, which we cover next.

WooCommerce Specific DDoS Risks

This is the section most security guides skip entirely.

A standard WordPress blog has one main attack surface: the homepage, posts, and the login page. A WooCommerce store has several more.

Checkout and Cart Pages

Each checkout request involves session handling, inventory checks, payment gateway communication, and order creation. That per-request cost is significantly higher than a simple blog post. Attackers targeting application-layer vulnerabilities know this.

A few thousand concurrent checkout requests can bring a store to its knees faster than the same number of homepage requests.

Product Search on Large Catalogs

A search query on a catalog with thousands of products triggers a database-heavy operation. Automated requests hitting your search endpoint at volume will exhaust your database connections quickly.

This is a common pattern in attacks against WooCommerce stores.

The REST API Trade-Off

WooCommerce depends on the REST API. The product blocks in the block editor, cart synchronization, mini-cart updates, and order management all use it. If you disable the REST API for unauthenticated users, you will break your storefront.

Product blocks stop rendering. The minicart stops updating. Checkout fails for some users, depending on your theme and setup.

The correct approach is not to disable the REST API. It is to rate-limit it and restrict sensitive endpoints to authenticated users only. More on that in the next section.

Timing Matters

We see WooCommerce stores hit during their busiest periods: sales events, product launches, and holiday campaigns. The attack timing is not always coincidental. A competitor or a motivated attacker knows when your site needs to be online the most.

Patchstack’s 2026 State of WordPress Security report found that the median time from public vulnerability disclosure to first mass exploitation was just five hours. For WooCommerce stores, that window is tight, especially if you are managing a store during a high-traffic period and monitoring is not in place.

For a broader view of hardening your WooCommerce store beyond DDoS, our WooCommerce security checklist covers the full security picture.

How to Layer Your WordPress DDoS Protection

No single tool stops all attack types. A plugin alone will not stop a volumetric attack. A CDN alone will not block application-layer attacks targeting your authenticated endpoints. You need layers.

Layer 1: DNS-Level WAF and CDN

This is the most important layer and the one most sites skip because it costs money.

A web application firewall at the DNS level sits in front of your server. Traffic from visitors hits Cloudflare or Sucuri first, before it ever reaches your origin server. Volumetric attacks are absorbed at the edge network. Application-layer traffic is filtered before PHP runs.

This is fundamentally different from a plugin-based WAF. A security plugin like Wordfence is an application-level WAF. It blocks traffic after it hits your server. During a volumetric attack, your server is already overwhelmed before Wordfence sees the request. Application-level WAFs are useful for many threats. They are not the right tool for DDoS mitigation on their own.

• Cloudflare: The free plan includes basic DDoS mitigation. Layer 7 (application-layer) protection requires the Business plan, currently around $200 per month. For WooCommerce stores with meaningful revenue, this is not optional; it is the cost of doing business.
• Sucuri: Starts at $199.99 per year. Runs at the DNS level. Their team reports blocking hundreds of thousands of attacks for high-traffic sites on an ongoing basis.

During an active volumetric attack, Cloudflare’s “I’m Under Attack” mode adds a JavaScript challenge that blocks most bots while letting real browsers through.

Layer 2: WordPress-Specific Hardening

Once edge protection is in place, tighten the WordPress-specific attack vectors. Here are the steps in order of impact.

1. Block or Restrict xmlrpc.php at the Server Level

Do not use the xmlrpc_enabled filter in PHP. That filter only blocks authenticated methods, pingbacks and system.listMethods still work. Block it at the server level instead.

On Apache, add to .htaccess:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

On Nginx:

location = /xmlrpc.php {
  deny all;
}

Do not delete the file itself. WordPress core updates will restore it. Block access instead.

Exception: If you use Jetpack, it relies on xmlrpc.php for its connection to WordPress.com. Keep xmlrpc.php accessible, but whitelist Jetpack’s IP ranges instead of blocking all access.

2. Rate limit wp-login.php

Your WAF or CDN should handle this. In Cloudflare, create a rate-limiting rule for requests to /wp-login.php, five requests per minute per IP is a reasonable starting point. Increase or decrease based on your legitimate admin usage patterns.

If you are on Apache without a CDN layer, you can add basic rate limiting in .htaccess using mod_evasive, though a server-level solution is better.

3. Rate-Limit and Selectively Restrict REST API Endpoints

To protect WooCommerce without breaking it, restrict unauthenticated access to sensitive endpoints only. Add this to your functions.php or a code snippet plugin:

add_filter( 'rest_authentication_errors', function( $result ) {
  if ( ! is_user_logged_in() ) {
    // Allow public WooCommerce endpoints, block everything else
    $allowed = [ '/wc/v3/products', '/wc/v3/cart' ];
    $route = $_SERVER['REQUEST_URI'] ?? '';
    foreach ( $allowed as $endpoint ) {
      if ( strpos( $route, $endpoint ) !== false ) {
        return $result;
      }
    }
    return new WP_Error( 'rest_restricted', 'REST API access restricted.', [ 'status' => 403 ] );
  }
  return $result;
} );

Adjust the $allowed array to match the endpoints your store uses.

4. Disable Pingbacks and Trackbacks

Go to Settings → Discussion in your WordPress dashboard. Uncheck “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts.” This removes one pingback abuse vector at the WordPress level.

5. Enable Page Caching

A cached response does not execute PHP or hit the database. Even during an attack, cached pages can continue serving while your server handles the flood.

Tools like WP Rocket, W3 Total Cache, or server-level caching via Redis object cache all reduce the per-request cost that makes application-layer attacks effective. For reducing TTFB and server load generally, our guide on reducing TTFB in WordPress walks through the options.

6. Add CAPTCHA to High-Risk Forms

Login pages, checkout, account registration, and comment forms are the first targets during an application-layer attack. Adding CAPTCHA (Google reCAPTCHA, Cloudflare Turnstile, or hCaptcha) to these forms adds friction that slows automated requests significantly.

Our WooCommerce Advanced Captcha plugin supports multiple CAPTCHA types across all WooCommerce forms, including login, checkout, account creation, and affiliate registration.

Layer 3: Monitoring and Early Warning

Protection is only as good as your ability to detect a problem early. Set up these monitoring points:

• Cloudflare Analytics or your CDN dashboard: Shows traffic volume, blocked requests, and threat scores in near real-time
• Wordfence activity log: Useful for spotting application-level patterns, even if it is not your primary DDoS defense
• Server access logs: The most detailed source, check request patterns to /xmlrpc.php, /wp-login.php, and /wp-json/ endpoints
• Hosting provider alerts: Most managed WordPress hosts will alert you to unusual CPU or bandwidth spikes before you notice the slowdown

According to NetScout data, more than 27,000 botnet-orchestrated DDoS attacks were recorded in March 2025 alone, with service providers targeted on average every two minutes. At that volume, passive monitoring is not enough, you need active alerting.

For more structured security monitoring, our article on using a SIEM to monitor a WordPress site covers how to centralize and automate threat detection.

What to Do During an Active WordPress DDoS Attack

Most guides tell you how to prevent an attack. Almost none tell you what to do once one is already happening. Here is a practical sequence.

1. Contact your hosting provider first: Call or open a ticket immediately. Tell them what you are seeing. They have network-level tools you do not. They can identify traffic patterns, add temporary IP blocks at the server infrastructure level, and tell you whether the attack is volumetric or application-layer based on what they are seeing on their end.
2. Enable “I’m Under Attack” mode in Cloudflare (if you use it): This adds a JavaScript challenge to every request. Real browsers pass it automatically. Bots do not. It will cause a brief delay for legitimate visitors, but it keeps your site accessible during most attacks.
3. If you use Sucuri, switch to Paranoid Mode: This blocks a much wider range of requests and can significantly reduce the attack load reaching your origin server.
4. Check your server logs to identify the pattern: Look at which endpoint is being hit. /xmlrpc.php suggests pingback or brute-force amplification. /wp-login.php is login flooding. /wp-json/ or a specific product or checkout URL suggests an application-layer attack targeting WooCommerce. The pattern tells you where to tighten rules.
5. Block concentrated IP ranges if possible: If the attack is coming from a narrow range of IP addresses or a single country, add a temporary block in your WAF. A fully distributed attack from thousands of unique IPs is harder to filter this way, but many attacks are less distributed than they appear.
6. Do not make major configuration changes mid-attack: This is the step most people get wrong. Changing your theme, deactivating plugins at random, or reconfiguring your database during an active attack makes diagnosis harder and often creates new problems. Tighten rules at the WAF level. Avoid touching WordPress core settings until the attack subsides.
7. Prepare a communication plan: If you run a WooCommerce store, your customers need to know what is happening. A brief notice, “We’re experiencing higher than normal traffic and working to restore full service”, is better than a blank error page. If you have a team, assign one person to customer communication and keep others focused on technical response.

Research shows 89% of DDoS attacks end within 10 minutes. If your mitigation layers are in place before the attack starts, most attacks will pass without causing lasting damage. The attacks that cause real harm are the ones that hit unprotected sites or sites where the owner spends the first 30 minutes wondering what is happening.

Common Mistakes That Leave WordPress Sites Exposed

Here is where most sites go wrong, even after “setting up protection.”

• Treating a security plugin as DDoS protection: Wordfence, Solid Security, and similar plugins are valuable tools. They scan for malware, block known bad IPs, and add login protection. But they are application-level. During a volumetric attack, your server is overwhelmed before these plugins process the request. They are part of a defense stack, not the whole stack.
• Blocking xmlrpc.php but leaving pingbacks on: Blocking the file at the server level stops external access to xmlrpc.php directly. But pingback requests can still come through the REST API in some configurations. Turn off pingbacks in Settings → Discussion as well.
• Disabling the entire REST API: As covered above, this breaks WooCommerce. Rate-limit and restrict specific endpoints instead.
• Using cheap shared hosting without DDoS mitigation: On shared hosting, you share a server with other sites. A DDoS attack targeting your site affects every other site on that server. Your hosting provider may suspend your account to protect others. Managed WordPress hosting with built-in DDoS mitigation costs more for a reason.
• Only watching wp-login.php: Most security dashboards highlight login attempt data because it is easy to collect. Attackers shifted significant effort to the xmlrpc.php and REST API endpoints years ago. If your monitoring only covers /wp-login.php, you have blind spots.

Patchstack’s data shows that highly exploitable WordPress vulnerabilities increased by 113% year-over-year in 2025, with more high-severity vulnerabilities found than in the previous two years combined. Gaps in your protection stack are not staying gaps for long.

Conclusion

WordPress DDoS protection is not one plugin or one setting. It is layers: a DNS-level WAF to absorb traffic before it reaches your server, WordPress-specific hardening to close the xmlrpc.php, wp-login.php, and REST API attack vectors, caching to reduce per-request cost, and monitoring to catch problems early.

For WooCommerce stores, the stakes are higher because downtime during peak periods means direct revenue loss. The REST API trade-off matters. The WooCommerce-specific attack surface matters.

Start with edge-level protection, harden your WordPress installation, and have a clear plan for what to do if an attack starts. The sites that recover quickly are the ones that already know what to do before the attack happens.

Frequently Asked Questions