Hundreds of failed logins before breakfast
A security plugin emails someone every few minutes about a blocked login attempt. Or the site goes slow for no obvious reason, and the host says the server is overloaded. Or a member of staff finds they are locked out because a bot guessed their username and triggered the lockout. In the logs there are thousands of requests to the login page from addresses all over the world, trying "admin" and a list of passwords.
Why your site is a target
It is not personal. Bots scan the internet for anything running WordPress and try the same login attacks everywhere. Several things make it easier for them:
- The standard login page is at the same address on every WordPress site
- xmlrpc.php accepts many password guesses in a single request
- Usernames are often visible through author pages or the site's own API
- Old accounts with weak or reused passwords still exist
- Nothing blocks the traffic before it reaches PHP and the database
That last point explains the slowdown. Every failed login is processed by WordPress itself, so thousands of them consume the same server resources as real visitors.
What the attacks are costing
| Effect | What you notice |
|---|---|
| Server load | Pages slow or time out, particularly on cheaper hosting |
| Account lockouts | Genuine staff are locked out by plugins reacting to bots |
| Alert fatigue | Security emails are ignored because there are so many |
| Break-in risk | One weak password is enough for full control of the site |
There is a quieter cost in time. Someone ends up resetting passwords for locked-out colleagues, reading security emails and asking the host why the site is slow. None of it is anyone's job, so it lands on whoever set the site up and interrupts whatever they were meant to be doing.
Alert fatigue deserves attention. When a plugin sends dozens of warnings a day, people filter them out, and the one warning that matters gets missed with the rest.
How we lock the login down
- Look at the logs to see which routes are being attacked and how the site currently responds.
- Put a web application firewall in front of the site, such as Cloudflare or the host's own, with rules that block known bad traffic and rate-limit login attempts before WordPress sees them.
- Disable xmlrpc.php if nothing needs it, or restrict it to the services that do, such as a specific app.
- Hide usernames from author archives and the public API, and make sure no account is called "admin".
- Require two-factor authentication for every account that can edit or publish, and remove accounts that are no longer used.
- Where the team logs in from known places, restrict the admin area to those networks or put it behind single sign-on with Microsoft 365 or Google Workspace.
- Tune alerts so people hear about things that matter, such as a new admin user, and not every blocked bot.
We avoid relying on obscurity alone. Moving the login URL cuts noise, but two-factor and the firewall are what actually protect the site.
What changes
The flood of bot traffic is stopped before it reaches the site, so pages stay responsive. Staff log in with a second factor and stop being locked out by bots. Alerts become rare and meaningful. Most importantly, a guessed password is no longer enough to take the site.
Is your login under attack?
- A security plugin sends constant failed-login emails
- The site slows down with no rise in real visitors
- Staff get locked out of the admin area
- Some accounts use short or shared passwords
- An account called "admin" exists
- Nobody uses two-factor to log in