How to Protect WordPress From Brute Force Attacks (9 Ways)

A brute force attack is a bot trying thousands of username and password combinations against your WordPress login until one works. Every WordPress site gets them, usually within hours of going live, and they cause two problems: a weak password eventually gets guessed, and the flood of login requests can take a shared-hosting site offline. RoadToBlogging went down this way years ago, with an “Internal Server Error” caused by bots hammering wp-login.php with usernames like admin, administrator, and roadtoblogging.

This guide covers 9 ways to protect a WordPress site from brute force attacks, from the two that stop almost everything (two-factor authentication and a firewall) to the extras worth adding on a busy site. Updated October 2026.

How Brute Force Attacks Hit WordPress

Bots target three entry points: the login page (wp-login.php), the XML-RPC endpoint (xmlrpc.php, which allows many login attempts in a single request), and the REST API user listing, which reveals real usernames. They use lists of leaked passwords and common usernames, and they come from thousands of IP addresses at once, so blocking one address does little. Protection has to work at the account and firewall level.

1. Turn On Two-Factor Authentication

This is the one step that defeats brute force entirely: even a correct password is useless without the code from your phone. Install a 2FA plugin such as Two-Factor (by WordPress core contributors), WP 2FA, or the 2FA built into Wordfence, Solid Security, or Jetpack. Use an authenticator app (Google Authenticator, Authy, 1Password) rather than email codes, enable it for every administrator and editor, and save the backup codes somewhere safe. If you do nothing else on this list, do this.

2. Use Strong, Unique Passwords and Unusual Usernames

Bots try “admin”, “administrator”, your domain name, and the author names shown on your posts. Change the admin username to something unrelated to the site, and set a different display name so your login name is not printed on every post.

Passwords should be long (16+ characters), random, and unique to this site. Let a password manager (Bitwarden is free, 1Password is excellent) generate and store them. WordPress’s own password generator on the profile page is fine too. A reused password from a leaked site is how most accounts are actually broken, not by guessing.

3. Install a Firewall Plugin With Login Protection

A security plugin blocks IPs after a few failed logins, recognizes known attacker networks, and limits requests to the login page. Wordfence (free) is the most complete: its brute force settings lock out an IP after a set number of failures, block logins with invalid usernames immediately, and block the usernames attackers try most. Solid Security (formerly iThemes) and Jetpack Protect do the same job. Install one; two will conflict.

4. Put Cloudflare in Front of the Site

Cloudflare sits between visitors and your server, so an attack hits Cloudflare’s network instead of your hosting account. On the free plan: set the Security Level to Medium or High, create a firewall rule that challenges or rate-limits requests to /wp-login.php and /xmlrpc.php from outside your country, and turn on Bot Fight Mode. If you are under attack right now, switch on Under Attack Mode; it stops bots within a minute.

5. Disable XML-RPC

XML-RPC lets an attacker test hundreds of passwords in one request, which gets around login attempt limits. Unless you use the WordPress mobile app or a remote publishing tool that needs it, turn it off. Wordfence and Solid Security have a toggle, the Disable XML-RPC plugin does it in one click, or add this to your .htaccess file:

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

Jetpack needs XML-RPC, so if you use Jetpack, use its own brute force protection instead and leave the endpoint on.

6. Limit Login Attempts

If you do not want a full security plugin, Limit Login Attempts Reloaded does one thing well: it locks out an IP after a chosen number of failed attempts, with increasing lockout times, and emails you about repeated attackers. The original Limit Login Attempts plugin mentioned in the first version of this post was abandoned; use the Reloaded fork. The security plugins in step 3 already include this.

7. Change the Login URL

Most bots look for /wp-login.php and /wp-admin specifically. Moving the login page to a custom address (for example /my-secret-door) with the free WPS Hide Login plugin makes the automated attacks disappear from your logs. It is security by obscurity and will not stop a targeted attacker, so treat it as a way to reduce server load rather than a replacement for 2FA. Write the new URL down; if you forget it, you will need FTP access to disable the plugin.

8. Hide Usernames From the REST API and Author Pages

By default, visiting yoursite.com/wp-json/wp/v2/users lists every author’s login name, and ?author=1 redirects to the admin’s author page. Wordfence and Solid Security can block both; Rank Math and Yoast can disable author archives. With real usernames hidden, bots are back to guessing both halves of the login.

9. Keep Backups and Keep Everything Updated

Brute force protection is only one layer. Outdated plugins are the most common way sites are actually compromised, so turn on automatic updates for WordPress and trusted plugins, delete plugins and themes you do not use, and keep off-site backups (UpdraftPlus or your host’s backups) so a breach is an inconvenience rather than a disaster.

If Your Site Is Under Attack Right Now

1. Turn on Cloudflare Under Attack Mode if you use Cloudflare.
2. Contact your host; most can block the attack at the server level within minutes.
3. Change every administrator password and confirm 2FA is on.
4. Check Users in the dashboard for accounts you did not create.
5. Run a Wordfence scan afterward to confirm nothing was changed.

Frequently Asked Questions

How do I know if my WordPress site is being brute forced?

A security plugin will show failed login counts and lockouts. Without one, signs include a suddenly slow or unavailable site, hosting resource warnings, and access logs full of POST requests to wp-login.php or xmlrpc.php.

Is Jetpack’s brute force protection enough?

It blocks a large share of known attacker IPs and is a good baseline, but it does not add 2FA or limit XML-RPC abuse. Pair it with two-factor authentication at minimum.

Does a CAPTCHA on the login page help?

Yes. Cloudflare Turnstile or reCAPTCHA on the login form stops most automated attempts. Wordfence, Solid Security, and most form plugins can add one.

Should I rename wp-admin?

No. Renaming the admin folder breaks plugins and themes. Change the login URL with a plugin instead, which achieves the same hiding effect safely.