WordPress login pages are among the most attacked endpoints on the web. Automated bots scan for standard WordPress installations and attempt thousands of username/password combinations per minute. Here's how to build layered protection against brute force login attacks, from basic credential hygiene through to server-level rate limiting.
WordPress powers roughly 43% of all websites. Its login URL (wp-login.php) is at the same location on every default installation. Attackers don't need to discover where the login is, they already know. Automated botnets try common usernames (admin, administrator, the site domain name, the business name) against password lists compiled from past data breaches, running thousands of attempts per minute against tens of thousands of sites simultaneously.
There are two distinct attack types to understand. Pure brute force tries every possible character combination, impractical against strong passwords, but effective against weak ones. Credential stuffing uses real username/password pairs leaked from other sites' data breaches, effective even against users who think their password is unique but have reused it. The protections in this guide address both.
This sounds obvious but it eliminates the majority of attacks. A random 20-character password cannot be brute-forced by any realistic attack, even with unlimited attempts, the mathematical space is too large. A password manager (Bitwarden, 1Password) generates and stores strong passwords so the complexity doesn't fall on memory.
Change the username from "admin" to something non-obvious. Create a new Administrator account with a different username, log in with it, then delete the "admin" account and reassign its content. With both the username and password as unknowns, the attacker has to guess both correctly simultaneously. At scale, they'll move on to softer targets.
Install Limit Login Attempts Reloaded. Configuration steps: go to Settings > Limit Login Attempts. Set "Allowed Retries" to 4 or 5. Set "Lockout Period" to 20 minutes. Set "Long Lockout Period" to 24 hours and "Allowed Lockouts" to 3 (meaning after 3 lockout cycles, the IP is blocked for 24 hours).
Under "Trusted IP Origins," set the correct value for your server environment. On most shared hosting this is REMOTE_ADDR. If you're behind Cloudflare or another reverse proxy, it may need to be HTTP_CF_CONNECTING_IP (for Cloudflare) or HTTP_X_FORWARDED_FOR. Using the wrong setting causes the plugin to see the proxy's IP rather than the attacker's, which means everyone behind that proxy gets locked out when the lockout triggers.
Check the plugin's log (Settings > Limit Login Attempts > Logs tab) after a week. You'll see which IPs are most aggressive. IPs that trigger multiple lockouts can be added to the plugin's blocklist manually, or submitted to Wordfence's block list if you're running both.
Two-factor authentication is the most reliable brute force defence available. Even if an attacker has the correct username and password (obtained via data breach, phishing, or successful brute force), they still cannot log in without access to the second factor, your phone's authenticator app.
Install WP 2FA. After activation, run through the setup wizard: scan the QR code with Google Authenticator, Authy, or 1Password, then enter the 6-digit verification code to confirm pairing. Save the generated backup codes in your password manager, these are one-time-use codes that let you log in if you lose your phone. Under WP 2FA > Policies, set 2FA as required for the Administrator role (and Editor if you have multiple editors).
If you're already running Wordfence, its built-in 2FA (under Wordfence > Login Security) achieves the same result without an additional plugin. Either approach is equally effective.
Install WPS Hide Login. Under Settings > WPS Hide Login, set your new login URL slug to something non-obvious and not guessable. Avoid /login, /admin, /wp, /signin, these are all tried automatically. Something specific to your site (a word or phrase that has meaning to you but isn't publicly associated with the site) is ideal.
Important: save the new URL in your password manager before saving the plugin settings, and share it with any other admins. If you forget the custom URL, you can recover access by renaming or deleting the plugin folder via FTP/file manager, which disables the plugin and restores the default URL.
Changing the login URL doesn't substitute for strong passwords and 2FA, a targeted attacker or one who inspects your page source can discover the login URL. Its value is eliminating the high volume of generic automated traffic that hits the default location constantly, reducing server load and cleaning up your access logs.
XML-RPC is a legacy remote API for WordPress that allows brute force attacks to be amplified, a single request to xmlrpc.php can test hundreds of username/password combinations using the multicall method. Most sites don't use it. If you're not using Jetpack or a mobile app that requires XML-RPC, block it entirely.
Add this to your .htaccess file:
<Files xmlrpc.php>
deny from all
</Files>Alternatively, most comprehensive security plugins (Wordfence, iThemes Security) include a toggle to disable XML-RPC. Check your server access logs for the volume of requests hitting xmlrpc.php, on a typical site without XML-RPC usage, these are all attack traffic.
Cloudflare's free plan allows you to create WAF rules that challenge or block requests to wp-login.php from suspicious sources. Create a rate-limiting rule: if a single IP sends more than 5 requests per 10 seconds to wp-login.php, block it for 1 hour. In the Cloudflare dashboard: Security > WAF > Rate Limiting Rules > Create Rule.
This is more efficient than plugin-level protection because the server never needs to execute PHP to handle the blocked request. Cloudflare absorbs the attack traffic at its edge before it touches your origin server. For sites under sustained attack that's overwhelming PHP process limits, moving to Cloudflare can be the difference between the site staying up and going down.
Use both: Cloudflare rate limiting at the CDN level, and a WordPress plugin as a fallback for requests that reach the server directly (bypassing Cloudflare) or via the origin IP.
Check Limit Login Attempts Reloaded's log after a week to confirm lockouts are being triggered and the attacker IPs are being tracked. In Wordfence's firewall log, look for blocked requests with the reason "Brute Force", high numbers confirm attacks are happening but being blocked. If you moved your login URL, check your access logs for requests to the old wp-login.php location, those will all be attack traffic that's now hitting a 404 instead of a login form.
HostBible's infrastructure blocks known malicious IP ranges at the network level before requests reach your WordPress installation. Plugin-level limiting handles everything else.
View Hosting Plans