How to Stop DDoS Attacks on WordPress Sites
Nobody expects it. You wake up, check your site, and it’s just… gone. Or you get a frantic message from a client at 11pm saying their store is down. You log into your hosting panel, and the server load graph looks like someone drew a vertical line. No warning, no explanation, just traffic hammering your server until it keels over.
That’s a DDoS attack. And if you run a WordPress site and haven’t thought about the issue yet, it’s worth an hour of your time now rather than a very stressful night later.
This guide covers what’s actually happening during one of these attacks, why WordPress keeps ending up in the crosshairs, and the specific steps you can take to make your site a much harder target. If you’re looking for broader strategies beyond WordPress specifically, you can also read our complete guide on how to prevent DDoS attacks across websites and online services.
What Is a DDoS Attack, Really?
DDoS is short for Distributed Denial of Service. It’s not a hack in the traditional sense; nobody’s trying to steal your database or guess your password. The goal is simpler and more blunt: send so much traffic to your server that it stops being able to respond to real visitors. If you want a more beginner-friendly breakdown of how these attacks work, types of DDoS attacks, and real-world examples, refer to our full explanation of what a DDoS attack is.
The “distributed” part is what makes it difficult to defend against. The traffic doesn’t come from one place; it comes from thousands of devices at once. Compromised devices include laptops, home routers, baby monitors, and security cameras. These devices have been quietly recruited into what’s called a botnet, usually without their owners having any clue. So when you try to block the attack by banning one IP address, you’re only addressing a small part of the problem.
For WordPress specifically, a few spots get hit more than others. The XML-RPC endpoint is a big one; it was built for remote publishing, but it’s been abused for years. The login page at wp-login.php gets hammered constantly. The REST API too. These are known targets, which is part of why WordPress sites end up in attackers’ scripts so often.
Why WordPress Sites Are Targeted
WordPress runs somewhere north of 40% of all websites on the internet. That’s not a security flaw; it’s just a matter of numbers. If you write an attack script that works against WordPress, you’ve written something that can hit hundreds of millions of sites. Attackers are not necessarily targeting you specifically. You’re just in a massive pool.
What makes smaller WordPress sites especially vulnerable is the infrastructure gap. A big e-commerce platform has engineers on call, enterprise-grade hosting, and DDoS mitigation baked into their network. Is it a small business or a blogger? Usually, a $10/month shared hosting plan is used, and no one is watching the logs. The same attack that causes a blip for a large company can knock a smaller site offline for hours or long enough for the host to suspend the account entirely.
7 Ways to Protect Your WordPress Site from DDoS Attacks
1. Put a CDN with DDoS Mitigation in Front of Your Site
If you do nothing else on this list, do so. A CDN, or content delivery network, sits between the public internet and your actual server. When attack traffic hits, it hits the CDN’s network first, not yours. By the time Cloudflare (or Sucuri, or BunnyCDN) has processed the request, your origin server may never even see it.
Cloudflare’s free plan has basic DDoS protection included. For most personal sites and small businesses, that’s enough to deflect the kind of opportunistic floods that are most common. If you’re running something more critical, such as an online store or a membership site, the Pro plan offers more granular controls. The big thing to know about is “Under Attack Mode.” You can flip it on in seconds from your Cloudflare dashboard when something looks off, and it immediately starts challenging suspicious visitors before they touch your server.
2. Install a Web Application Firewall (WAF)
A CDN handles volume. A WAF handles intent. It examines the actual content of incoming requests, including the headers, parameters, and patterns, and blocks anything that appears to be probing for vulnerabilities or attempting to exploit your application.
Wordfence has a solid WAF built into its free plugin. Cloudflare’s WordPress plugin can also apply firewall rules at the edge before requests even arrive. If your host runs ModSecurity at the server level, that’s another layer working quietly in the background. No single tool blocks everything, but layering them means that if an attack slips past one, another tool catches it.
3. Disable XML-RPC (If You Don’t Need It)
XML-RPC was WordPress’s way of letting third-party apps talk to your site remotely, things like the old WordPress mobile app or desktop publishing tools. Most people stopped needing it years ago, but it’s still enabled by default. And it’s one of the endpoints that gets hammered most in DDoS and brute-force campaigns.
Check whether you actually use it yourself. If you’re not running Jetpack and you don’t publish via a remote app, you don’t need it on. A plugin called Disable XML-RPC kills it in one click, or you can block it directly inside Cloudflare’s firewall rules. Either way, it takes five minutes and removes a target that attackers actively look for.
4. Limit Access to wp-login.php
Your login page is probably getting hit right now; most WordPress sites are. Bots cycle through login attempts constantly, looking for weak passwords or just trying to overwhelm the page.
A few things help here. IP allowlisting locks the login page down so only your IP can reach it at all overkill for some, perfect for others. If your IP changes a lot, that gets annoying fast. Two-factor authentication is a better everyday option; even if a bot guesses your password, it still can’t get in without the second factor. Limit Login Attempts Reloaded is a free plugin that automatically blocks IPs after a set number of failed tries. And if you want to go a step further, WPS Hide Login moves your login URL to something completely custom; bots scanning /wp-login.php find nothing.
You probably don’t need all four. Pick two that fit how you work and actually set them up.
5. Choose DDoS-Aware Hosting
Your hosting provider is your last line of defense if everything else fails. Shared hosting plans are particularly vulnerable: if your site gets hit, all the other sites on the same server also go down.
Look for hosts that specifically mention DDoS protection in their infrastructure. Kinsta, WP Engine, SiteGround, and Cloudways all offer architecture that’s better equipped to handle traffic spikes. If you’re on a budget-tier shared host with no DDoS mitigation, consider this your sign to upgrade.
6. Set Up Rate Limiting
Rate limiting controls how many requests a single IP address can make to your server in a given time window. It won’t stop a true distributed attack (the whole point is thousands of different IPs), but it handles smaller-scale floods and automated bots effectively.
Cloudflare makes the process easy to configure without touching any code. Alternatively, your hosting control panel may include rate limiting options, or you can configure it at the server level if you’re on a VPS.
7. Keep Everything Updated and Hardened
This one feels basic, but it matters more than people give it credit for. Attackers regularly use outdated plugins and themes as entry points to compromise sites and conscript them into DDoS botnets. If someone compromises your site and uses it in an attack on someone else, you face an entirely different set of challenges.
Run updates regularly. Remove plugins you don’t use. Please disable the file editor in the WordPress dashboard. Use strong, unique passwords and a password manager. Security hardening and DDoS protection aren’t entirely separate problems; they’re interconnected.
What to Do If You’re Already Under Attack
If attackers are actively targeting your site right now, here’s your triage list:
- Enable Cloudflare’s “Under Attack Mode” immediately; this adds a JavaScript challenge to every visitor
- Contact your host; they may need to null-route traffic at the network level
- Check your server logs to identify patterns, such as the same user agent or the same URL that someone is hammering. If you’re unsure what warning signs to look for, here’s a detailed guide on how to detect a DDoS attack early before it escalates into a full outage.
- Temporarily block entire regions if the attack traffic is concentrated geographically; most CDN dashboards make this possible
- Don’t restart your server repeatedly; it won’t help and wastes time
After the attack subsides, do a proper post-mortem. What got hit? What got through? Use that information to patch the gaps before the next wave.
A Realistic Defense Stack for Most WordPress Sites
You don’t need an enterprise budget to protect yourself well. A practical baseline looks something like this:
- Cloudflare (free or Pro) for CDN and DDoS absorption
- Wordfence or Cloudflare WAF for application-layer filtering
- Limit Login Attempts Reloaded for brute-force protection
- XML-RPC disabled
- A host with at least some infrastructure-level DDoS mitigation
- Regular backups stored off-server (so you can recover even if the worst happens)
This isn’t a perfect setup, but it handles the vast majority of attacks targeting typical WordPress sites without requiring a DevOps team or a hefty monthly security budget.
Frequently Asked Questions
Almost certainly not. Free and very cheap hosting plans share resources across many sites and have no meaningful DDoS mitigation. If protection matters to you, invest in a managed WordPress host or at minimum use Cloudflare in front of your site.
Yes, for most small and mid-sized sites, Cloudflare’s free plan provides meaningful protection. It won’t stop the most sophisticated volumetric attacks, but it handles the kind of attacks that target typical WordPress sites quite effectively. Upgrading to Pro or Business adds more advanced controls.
In most cases, no. The attack is about keeping people out, not breaking things. Once the traffic stops, your site typically comes back fine. The bigger risk is your hosting provider; if the attack is using enough resources, some hosts will suspend your account to protect their other customers. Getting that reversed can take a day or two of back-and-forth with support.
The first sign is usually the site slowing to a crawl or going completely unresponsive. Please check your hosting control panel; if the server load or bandwidth graphs appear completely abnormal, that is your signal. Pull up your access logs and look for the same IP (or the same endpoint, like /wp-login.php) being hit hundreds of times in minutes. A flood of requests from dozens of different IPs to the same URL is a very clear pattern.
For the majority of sites, yes. The only time you’d want to keep it enabled is if you’re actively using Jetpack features that depend on it, the official WordPress mobile app to publish, or some older third-party publishing tool. If you’re uncertain whether you use it, disable it and see if anything breaks. You can always turn it back on.
Technically yes; practically, almost never, at least not by you. The traffic comes from hijacked devices all over the world, so the IPs you see aren’t the attackers; they’re victims. Actually tracing it back to a real person requires law enforcement involvement across multiple countries, and that rarely happens for attacks against small sites.
You can get decent baseline protection for free. Cloudflare’s free plan plus a free security plugin covers a lot. If you want more serious mitigation, Cloudflare Pro runs about $20/month and includes better bot management and firewall controls. Add in a managed WordPress host that has DDoS infrastructure built in, and you’re probably looking at $30–$60/month total. While enterprise-grade solutions are available at much higher levels, most sites reading this guide don’t require them.
Final Thought
DDoS protection for WordPress isn’t something you set up once and forget. It’s an ongoing practice checking your firewall rules, reviewing traffic anomalies, and keeping your stack updated. The good news is that most attacks targeting WordPress sites are opportunistic, not personal. Make yourself a harder target than the next site, and attackers will move on.
The tools exist. The knowledge is accessible. The only question is whether you act before the next quiet Tuesday turns into a disaster.