How to Set Up WordPress Brute Force Protection the Right Way

WordPress brute force protection is the practice of blocking automated login attacks before they crack your credentials or crash your site. Most guides treat this as a simple checklist. It is not. Wordfence alone blocks over 6.4 billion brute force attempts every month across its network. That is not a spike in activity. That is the permanent baseline your site operates in every single day.

Here is what most articles skip: you do not need to lose your password for a brute force attack to hurt you. The flood of login requests alone can exhaust your server resources and take your site offline. For WooCommerce stores running a Black Friday sale, that distinction matters enormously.

This guide covers what brute force attacks are, why even failed attacks are a problem, and eight concrete steps to lock down your WordPress site. You will also learn how to spot an attack in progress, which plugins are worth using, and what popular advice does not work as well as advertised.

What Is a WordPress Brute Force Attack?

A WordPress brute force attack is an automated attempt to gain access to your site by repeatedly guessing username and password combinations until one works. Bots fire these attempts at your login page continuously, often from thousands of different IP addresses at once.

The two main targets are wp-login.php and xmlrpc.php. Every WordPress site exposes both by default. Attackers know exactly where to look.

The Three Types You Need to Know

• Classic brute force tries every possible combination from scratch. It is slow but thorough. Most modern attacks do not work this way.
• Dictionary attacks use lists of common passwords, leaked passwords, and real words. The majority of automated login bots run dictionary attacks. A 2024 study found that 81% of successful WordPress hacks used stolen or weak passwords, which is exactly what dictionary attacks target.
• Credential stuffing attacks are different from both. Here, attackers take username and password pairs leaked from other data breaches and try them against your WordPress login. Your password might be strong and unique on your site, but if a user reused a password from a breached service, the bot already has the right credentials going in. This attack type requires a different layer of defense because rate limiting alone will not stop it.

WordPress login security starts with understanding which type of attack you are actually facing. The defenses are not identical.

Why Even Failed Attacks Are Dangerous

This is the part most tutorials skip entirely.

Every login attempt, whether it succeeds or fails, hits your server. A bot sending 500 requests per minute to your wp-login.php file is consuming CPU and memory 500 times per minute. Your hosting plan has limits. When those limits are hit, your site slows down. When they are exceeded, your site crashes.

For a standard blog, this is annoying. For a WooCommerce store, mid-sale, it is a direct revenue loss. There is no meaningful difference between your store going down from a successful hack and your store going down from a failed attack that affect your server. Customers cannot tell the difference. They just see a site that does not load.

The timing makes this worse. Research from Limit Login Attempts Reloaded shows that 38.3% of all brute force attacks happen in Q4. That is the holiday shopping season. Attackers target eCommerce sites when they know that reduced IT oversight and peak traffic already stress your infrastructure. If your store is not hardened before November, you are taking a real risk.

Also worth knowing: Brute force attacks and DDoS attacks overlap in their effect on your server. A large enough login flood produces the same result as a targeted traffic flood. If you have not read our WordPress DDoS protection guide, the two topics are closely related, and the defenses complement each other.

There is also a newer problem. Attacks assisted by AI can now defeat standard CAPTCHA solutions. In 2024, researchers trained an object recognition model that cracked Google’s reCAPTCHA v2 with a 100% success rate. Previous attempts managed around 70%. If your only defense against bots is a checkbox CAPTCHA, that defense has already been broken.

How to Set Up WordPress Brute Force Protection: 8 Steps

These steps work in layers. No single one is enough on its own. Together, they give attackers enough resistance that most bots move on to easier targets.

Step 1: Change the “Admin” Username and Use a Strong Password

WordPress no longer sets “admin” as the default username, but millions of older installs still use it. Attackers always try “admin” first because it often works enough to be worth attempting on every site.

Go to Users → Add User in your dashboard. Create a new account with a unique username and set the role to Administrator. Log out, log in as the new account, then delete the old “admin” user. When prompted, attribute all content to the new account. Do not skip that step, or your posts disappear.

For passwords, use a generated string of at least 16 characters with uppercase, lowercase, numbers, and symbols. Your browser’s password manager handles this for you. A password like admin123 can be cracked in under a second. A randomly generated 20-character string takes, on current hardware, longer than the known age of the universe.

Step 2: Limit Login Attempts in WordPress

By default, WordPress allows unlimited login attempts. There is no built-in cap. This is the single biggest reason brute force attacks work at all.

Limiting login attempts in WordPress means a bot gets locked out after a set number of failures, typically three to five. You add this via a plugin or, on Nginx/Apache, via server-level rate limiting.

The plugin route is simpler for most site owners. Look for a plugin that lets you set lockout duration and configure an email alert on lockout. We cover plugin options in a section below.

Step 3: Add Two-Factor Authentication (2FA)

Two-factor authentication for WordPress login means a correct password alone is not enough to get in. The attacker also needs access to a device or app that generates a time-sensitive code. Bots cannot pass this check.

As of 2025, WordPress core does not include 2FA. You add it via a plugin. Enable it at a minimum for all administrator accounts. Google Authenticator is the most widely used app for generating TOTP codes, and several WordPress plugins support it natively. Our WooCommerce Google Authenticator plugin handles this for WordPress and WooCommerce sites.

Worth Knowing: If you are running passkeys (WebAuthn) via your identity provider or a reputable plugin, those provide stronger protection than standard TOTP-based 2FA. Passkeys are phishing-resistant and cannot be in grabbed.

Step 4: Use a web application firewall (WAF)

A web application firewall for WordPress filters incoming traffic before it reaches your login page. The best option is an edge-level WAF, meaning one that sits in front of your server entirely rather than running as a WordPress plugin. Cloudflare is the most common example.

Edge WAFs block bad traffic before it ever touches your server. Plugin-based WAFs block it after it arrives. For sites with heavy traffic or shared hosting, the difference matters: a plugin-level WAF still consumes server resources to process each blocked request. An edge WAF does not.

For shared hosting on a tight budget, a security plugin with a built-in WAF is a reasonable starting point. For any WooCommerce store with real revenue at stake, move the WAF to the edge.

Step 5: Secure or disable XML-RPC

The xmlrpc.php file is a secondary login surface that most sites do not need. It was built to let external applications communicate with WordPress.

Today, most modern API integrations use the WordPress REST API instead. XML-RPC is largely a legacy feature, and it is a frequent brute force target because it allows multiple login attempts in a single request, which means bots can test hundreds of passwords in one HTTP call.

To block XML-RPC access via .htaccess, add this to your .htaccess file:

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Before you add that, check whether anything on your site depends on XML-RPC. The most common dependencies are Jetpack (though newer versions support the REST API), some mobile apps, and certain older third-party integrations.

Disable XML-RPC on your site, then test these connections. We see this in support regularly: a store owner blocks XML-RPC and then wonders why their mobile app stopped syncing orders.

Step 6: Password-protect the wp-admin directory at the server level

This adds a second layer of authentication before WordPress even loads. An attacker trying to reach your login page first hits an HTTP authentication prompt at the server level.

In cPanel, go to Files → Directory Privacy, find the wp-admin folder, check “Password protect this directory,” and create credentials. In Nginx or Apache, you can add HTTP basic authentication directly in your server config. For a detailed walkthrough of protecting your WordPress admin URL in Nginx, we have a dedicated guide.

Note: If you use the WordPress admin-ajax.php file for front-end functionality (most WooCommerce sites do), you need to add an exception, or those requests will break.

Step 7: Change or Hide your login URL

Moving your login URL to something else removes your site from the vast majority of automated scanning scripts, which look for the default path. It cuts down login attempt volume significantly.

This step is worthwhile. But do not treat it as real security. It is noise reduction, not a lock. If an attacker is specifically targeting your domain, a custom login URL will not stop them. More on this in the “what won’t protect you” section below.

Step 8: Keep WordPress core, plugins, and themes updated

According to Patchstack’s 2024 report, 96% of WordPress weakness are in plugins and themes, not core. An outdated plugin is an open door that does not require guessing any credentials at all. Brute force protection becomes irrelevant if an attacker can just walk in through a known plugin weakness.

Enable automatic updates for minor WordPress core releases. Review and update plugins and themes at least once a week. Remove anything inactive. Every deactivated plugin sitting on your server is an attack surface with no benefit.

How to Check If Your Site Is Under Attack Right Now

You do not always get a warning. Sometimes the first sign is your hosting provider emailing you about CPU overuse or your site simply becoming unreachable.

Signs to look for:

Your site slows down or times out without a traffic spike from legit sources. You start receiving email notifications about repeated failed login attempts. Users, including you, report being locked out. Your hosting dashboard shows CPU or memory usage spiking unexpectedly.

Reading your server logs

The most direct method is checking your server’s access logs for patterns. In cPanel, access logs are under Metrics → Raw Access. In Nginx, the default log path is /var/log/nginx/access.log.

Look for repeated POST requests to /wp-login.php or /xmlrpc.php. If you see the same IP or user agent hitting those endpoints hundreds of times in a short window, you are watching a brute force attempt in progress.

A quick command to check in a Linux environment:

grep "POST /wp-login.php" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

This shows the top 20 IP addresses hitting your login page, sorted by attempt count.

To help with longer-term monitoring, consider whether a SIEM tool can monitor your WordPress site for authentication errors. It is overkill for a small blog, but for a high-traffic WooCommerce store, continuous monitoring makes sense.

What to do if you spot an active attack

Block the attacking IPs at the server or Cloudflare level immediately. If you are using a caching plugin, purge the cache and check your login logs after a few minutes to see if new IPs have taken over. Temporarily activate geographic IP blocking if the attack is coming from a reduced region. Then patch whatever let the attack through in the first place.

WordPress Security Plugins for Brute Force Protection

You do not need a plugin for every step above. Some of the most important protections, server-level WAF, XML-RPC blocking, and the wp-admin directory protection, are better handled at the server level. Plugins are the right tool when server access is limited or when you need a simpler interface.

What to look for in a brute force protection plugin:

A quality plugin for this purpose handles login attempt limiting, IP blocking with adjustable lockout duration, email alerts on lockout, and ideally 2FA integration. Bot detection is a meaningful bonus. The plugin should not be blocking legitimate bots like Googlebot in the process. Some aggressive security plugins have done this and quietly tanked SEO rankings for site owners who never noticed.

One of the most practical tools for WooCommerce stores is adding an advanced CAPTCHA to login, checkout, and registration forms. Our WordPress CAPTCHA plugin covers login, registration, lost password, checkout, and several other form types with Cloudflare Turnstile and hCaptcha support, both of which hold up better against current AI-assisted attacks than standard reCAPTCHA v2.

If you want a security plugin with a broad feature set, look for one that includes a WAF, login protection, and file monitoring in a single install. Running two or three separate security plugins on one site causes conflicts and slows your site down more than the attacks would.

What Won’t Protect You (And What Actually Will)

Some widely recommended techniques provide less protection than people assume. It is worth being direct about this.

• Hiding your login URL: This reduces the volume of automated attacks hitting your site because most bots scan for the default path. That is genuinely useful. But it does not stop a determined attacker, and it sometimes causes problems when your own team or third-party services cannot find the login page. Use it as one layer in a stack, not as a standalone solution.
• reCAPTCHA v2 (the “I’m not a robot” checkbox): AI models can now defeat this with 100% success. Researchers demonstrated this in 2024. If you are using basic image-based reCAPTCHA as your primary bot defense, that defense has been broken. Switch to Cloudflare Turnstile or hCaptcha, both of which use behavioral signals rather than image puzzles and are harder for current AI models to defeat.
• Security-through-obscurity alone: Changing your database prefix, hiding your WordPress version number, and similar measures reduce information leakage. That is worth doing. But none of it stops a bot that is targeting your login endpoint specifically. Credential stuffing attacks do not need to know your database prefix.
• The layered defense model: The only approach that works reliably is defense in layers. Think of it as: edge filtering (Cloudflare WAF, rate limiting) blocks the flood before it reaches your server → server-level config (.htaccess rules, directory protection) stops requests that slip through → WordPress-level plugins handle what the server layers miss → application-layer hardening (strong passwords, 2FA, updated plugins) covers the cases where everything else fails. Each layer catches what the one above it misses.

Most compromised WordPress sites are missing two or more of these layers, not all of them. A solid WooCommerce security checklist covers the full stack if you want a thorough reference.

Wrapping Up

WordPress brute force protection is not one setting you flip on. It is a set of overlapping defenses that make your site expensive enough to attack that automated bots move on.

The key points: limit login attempts, add 2FA for all admin accounts, handle XML-RPC carefully, and put a WAF in front of your server at the edge level if your site has any real traffic or revenue attached to it. Do not rely on reCAPTCHA v2 alone, especially heading into Q4.

If you run a WooCommerce store, take the Q4 timing data seriously. A failed brute force flood during your peak sales period produces the same result as a successful one: a site that doesn’t load and customers who don’t come back.

Start with steps two and three from this guide. Limiting login attempts and adding 2FA are the two changes that stop the largest proportion of attacks with the least complexity.

Frequently Asked Questions