Your WordPress login page is being tested right now — probably by a bot you will never see, trying passwords you would never choose.
That is how WordPress attacks work: bots find the familiar login page and start guessing. To learn how to protect WordPress from brute force attacks, you do not need an expensive stack — just layers that make guessing slower, harder, or pointless.
The key takeaway up front: no single setting stops a determined attacker. Strong credentials plus two-factor authentication plus login limits plus server-level blocking is what actually works.
What Brute Force, Credential Stuffing, and Password Spraying Are
A brute force attack is automated password guessing against your login form. Three variations hit WordPress most often:
- Classic brute force and dictionary attacks: many passwords tried against one known username, often “admin,” using lists of common and previously leaked passwords.
- Credential stuffing: username and password pairs stolen from a breach on another site are replayed on yours, betting that you reused the same login.
- Password spraying: one or a few common passwords are tried against many usernames, staying under simple per-account lockout limits.
Here is a concrete scenario: a small business owner reuses one password for her email, hosting, and WordPress admin accounts. It leaks in an unrelated breach, and bots soon try that exact pair on her login. No clever hacking — just reuse, automation, and no second factor. That is why password reuse is more dangerous than a merely short password.
WordPress, by default, places no limit on login attempts — a bot can keep trying unless you add a limit or firewall rule.
How to Protect WordPress From Brute Force Attacks With Stronger Logins
Start with the account itself. Use a long, unique password for every admin account, generated and stored by a password manager, and never reused on email, hosting, or social accounts.
Delete or rename the “admin” username. Bots try it first because it used to be the default. Create a new administrator with a less predictable username and remove the old one — though author pages can expose usernames, so treat this as one layer, not a secret.
Give every person the lowest role they need. Fewer admins means fewer high-value targets. Turn on WordPress two-factor authentication for admins and editors. Core does not include 2FA, so add it via a reputable plugin or identity provider. Then a stolen password alone is not enough — the attacker also needs your authenticator code. This is the single most effective change most site owners can make.
After suspicious login activity, check for wider damage — see how to check if your WordPress site is hacked.
Limit Login Attempts WordPress Owners Should Set From Day One
A WordPress brute force protection plugin stops unlimited guessing: when you limit login attempts WordPress bots face, a typical setup temporarily locks an IP out after around five failures. Well-known options include Limit Login Attempts Reloaded, Wordfence, and Jetpack Security — pick one maintained tool, not several that can conflict.
Keep the threshold sensible: too high gives bots too many guesses; too low locks out a whole office sharing an IP. Remember that a botnet rotating IPs can dodge per-IP limits — hence 2FA and server-level controls. Whitelist your static IP only if you have one, and do not rely on generic login errors alone.
If your team needs help hardening a live site without breaking logins for real users, our WordPress security and maintenance services cover exactly this kind of setup.
Block wp-login.php Attacks and Disable xmlrpc WordPress Access You Do Not Need
Your login form is not the only door: attackers also target wp-login.php directly and abuse xmlrpc.php, which can accept many attempts in one request via multicall.
To block wp-login.php attacks, move protection upstream: use a WAF or CDN to rate-limit or challenge login traffic before it reaches your server, and ask your host what server rate limiting it already applies. Restrict wp-admin by IP only with stable team IPs, and add a CAPTCHA such as Cloudflare Turnstile if bots persist.
When you disable xmlrpc WordPress access, first check whether anything needs it. The classic mobile app and Jetpack historically used XML-RPC, though modern connections increasingly use the REST API. If nothing needs it, disabling it removes a whole attack surface; if something does, restrict and rate-limit it instead.
Changing your login URL only cuts low-effort bot noise; determined scripts can often discover it. Treat it as a bonus layer, never your main defense.
How to Protect WordPress From Brute Force Attacks at the Server Level
Plugin-only protection has a real limit: it runs inside WordPress, so every blocked attempt still reaches your server and costs resources. During a heavy flood, that can slow your site even when no login succeeds:
| Defense layer | What it stops | Its limit |
|---|---|---|
| Strong, unique passwords + non-default username | Easy guessing and reused credentials | Useless if the password leaks with no second factor |
| WordPress two-factor authentication | Login with a stolen password alone | Only helps if enabled for privileged accounts |
| Limit login attempts plugin | Unlimited guessing from one IP | Distributed botnets can rotate IPs |
| WAF / CDN rate limiting | Floods reaching your server | A misconfigured rule can block real users |
| Server rules for wp-login.php and xmlrpc.php | Direct and API-based guessing | Requires host access and testing |
| Updates + backups | Known-vulnerability exploits and data loss | Updates do not stop guessing; backups only help if tested |
Keep WordPress core, themes, and plugins updated, and remove unused ones rather than leaving them unpatched — outdated software drives many real compromises. Stay current with core releases, such as the WordPress 7.1.4 security update. Keep tested backups off your server, and restore one to staging at least once.
Sources: WordPress brute force guidance, Wordfence brute force documentation, Limit Login Attempts Reloaded.
Active Attack Triage: What to Do When Bots Hammer Your Login
If logs suddenly show hundreds of failed logins, do not panic, and do not rush to change passwords mid-flood. Work in this order:
- Check the logs first. Which usernames, how many IPs, and do requests hit
wp-login.php,xmlrpc.php, or both? A handful of IPs suggests a simple block; thousands points to a distributed attack needing edge blocking. - Rate-limit or challenge login traffic at the edge. Turn on your CDN or WAF challenge for login and XML-RPC paths, or ask your host to rate-limit them temporarily.
- Harden accounts first. Enable 2FA for privileged accounts, reset admin passwords only if you suspect compromise or reuse, and remove unrecognized accounts.
- Block the worst offenders, then watch. Block repeat IPs at the firewall level, disable XML-RPC if nothing needs it, and monitor for a shift to new IPs or endpoints.
- Check for a login you missed. Review successful logins, new admins, and modified files. If anything looks wrong, treat it as a possible compromise.
If the flood continues, contact your host for broader firewall rules a plugin cannot apply.
Frequently Asked Questions
Does changing my WordPress login URL stop brute force attacks?
No — not by itself. It reduces noise from simple bots, but does nothing against a stolen password, and attackers can often discover the new URL. Use it only as an extra layer.
How many failed login attempts should I allow?
Around five before a temporary lockout is a sensible starting point for most small sites. Adjust for team size and whether users share an office IP.
Is a WordPress brute force protection plugin enough on its own?
For light, single-IP guessing, often yes. For a heavy flood, no: plugin blocks still consume resources, and rotating IPs dodge per-IP limits. Pair it with 2FA and WAF/CDN limiting.
Should I disable xmlrpc.php?
If nothing needs XML-RPC, yes — it removes a guessing route entirely. If something does, restrict and rate-limit it instead.
What if I get locked out of my own site?
Use your plugin’s unlock method (often an email link), try another network, or ask your host to clear it. Document recovery before tightening settings.
The Takeaway That Actually Protects Your Site
Learning how to protect WordPress from brute force attacks is not about one magic plugin. It is about making guessing unprofitable: a unique password, a second factor, a retry limit, and edge rules that keep floods off your server.
Do the unglamorous layers today — 2FA on, login limits on, XML-RPC reviewed, backups tested — and the bots will move on to an easier target. That is the whole game.
If you would like help applying this checklist to your own site, contact us and we will walk through it with you.
