If you look at the raw access logs of almost any WordPress site, you’ll see something that surprises most owners. Requests to wp-login.php and xmlrpc.php, often thousands per day, from addresses all over the world. These are automated bots trying username and password combinations, hoping to find a weak one.
Most of these attempts fail. But they don’t need to succeed often to be profitable for attackers. And even failed attempts cost you something: every request to the login page runs PHP and queries the database, which slows the site for real visitors. During heavy attacks, I’ve seen small sites go down entirely, not because anyone got in, but because the server was overwhelmed by login attempts.
Protecting the login is one of the most effective security improvements you can make. Here’s how I do it, in layers.
Understand what you’re defending against
Brute force attacks come in a few forms:
- Classic brute force, trying many passwords against one username.
- Credential stuffing, using username and password pairs leaked from other websites’ data breaches, betting that people reuse passwords.
- Distributed attacks, spreading attempts across thousands of IP addresses so simple per-IP blocking doesn’t catch them.
- XML-RPC amplification, using a feature of xmlrpc.php that lets one request try many passwords.
A good defence handles all of these, which is why layers matter.
Layer 1: Strong, unique passwords
Everything starts here. If every account uses a long, random, unique password, brute force becomes practically impossible and credential stuffing fails, because leaked passwords from other sites won’t work.
The practical way to achieve this is a password manager. Require it for everyone with access to your site. For client sites, I also check that nobody shares a single admin account, so access can be removed cleanly when someone leaves.
Layer 2: Two-factor authentication
Two-factor authentication, or 2FA, requires a second proof of identity after the password: usually a code from an authenticator app, a security key or a passkey. Even if a password is stolen or guessed, the attacker can’t log in without the second factor.
If you do only one thing from this guide, do this. Enable 2FA for every administrator, editor and shop manager. Several reputable plugins add 2FA to WordPress, and some security plugins include it.
A few practical points:
- Prefer authenticator apps or security keys over SMS codes, which can be intercepted through SIM swapping.
- Make sure each user saves their backup codes. Getting locked out of your own site is unpleasant.
- Enforce 2FA by role, rather than relying on people to turn it on voluntarily.
Layer 3: Avoid predictable usernames
Usernames like admin, administrator or the site’s domain name are the first ones bots try. Don’t use them. If you have an account called admin, create a new administrator with a unique username, log in with it and delete the old account, assigning its content to the new one.
Also make sure your public display name differs from your login username. WordPress shows display names on posts, and you don’t want it to reveal the login name.
Usernames can still be discovered through author archives and the REST API, so don’t rely on secrecy. Think of this as removing an easy shortcut, not as real protection.
Layer 4: Limit login attempts
WordPress itself doesn’t limit failed login attempts. A bot can try forever. Limiting attempts slows attackers down dramatically: after a few failures, the IP address is blocked for a period.
You can do this with a plugin, but there’s a performance trade-off. A plugin still has to load WordPress to check each attempt. Under a heavy attack, that’s a lot of work for your server.
Better options work before WordPress loads.
Rate limiting with Nginx
On servers you control, Nginx can limit how often each IP can request the login page:
This allows a handful of requests per minute from each address, plenty for a real person, while stopping rapid-fire bots. Adjust the PHP socket path to match your server.
Fail2ban
Fail2ban watches log files and blocks IP addresses at the firewall after repeated failures. Combined with a WordPress plugin that logs failed logins to the system log, it can block attackers at the network level, so their requests never reach the web server at all.
I use this setup on many servers I manage. Once configured, it quietly blocks thousands of attempts a day with almost no overhead.
A web application firewall
DNS-level firewalls and CDN security services can challenge or block suspicious login traffic before it reaches your server. They’re especially good against distributed attacks, because they see traffic patterns across many sites and can identify botnets.
Layer 5: Deal with XML-RPC
The xmlrpc.php file supports an older remote publishing protocol. It includes a method that allows many commands in a single request, which attackers abuse to try hundreds of passwords at once while appearing as one request to simple rate limiters.
If you don’t use services that depend on XML-RPC, such as certain Jetpack features or very old publishing apps, block it entirely at the server level:
On Apache:
If you do need XML-RPC for something specific, restrict it to the IP addresses that require it.
Layer 6: Restrict access by IP, where practical
If your team always works from fixed IP addresses, you can restrict the login page and admin area to those addresses. Everyone else gets a 403 error before WordPress loads.
This is extremely effective, but it doesn’t suit everyone. Remote teams, people on mobile data and customers who need to log in to accounts make IP restrictions impractical. For WooCommerce stores, where customers log in through their account page, be careful not to block them.
What about changing the login URL?
Moving the login page from wp-login.php to a custom address is popular. It does reduce the volume of automated attempts, because most bots only try the default URL. Your logs get quieter.
But it’s obscurity, not security. A determined attacker can often find the new address, and it doesn’t help against credential stuffing on the new URL. Some plugins also break when the login URL changes. I treat it as an optional extra on top of real protection, never as a replacement for 2FA and rate limiting.
Protect application passwords and API access
Since WordPress 5.6, users can create application passwords for API access. These bypass 2FA by design, because they’re meant for scripts and apps. That’s useful, but it means they need care:
- Only create them when needed, for specific integrations.
- Use dedicated users with minimal roles for integrations.
- Revoke them when an integration is no longer used.
- Review them periodically under each user’s profile.
If nobody on your site uses application passwords, consider disabling the feature.
Monitor login activity
Protection is only half the job. You should also know what’s happening:
- Use an activity log plugin to record successful and failed logins, new user creation and role changes.
- Get alerts when an administrator logs in from a new location or when a new admin account is created.
- Review your user list regularly and remove accounts that are no longer needed.
The sooner you notice something unusual, the smaller the damage. In several incidents I’ve investigated, a rogue administrator account had existed for weeks before anyone noticed.
Use HTTPS everywhere
Login credentials must always travel over HTTPS. If any part of your site still allows plain HTTP, passwords can be intercepted on public networks. Make sure SSL is active across the whole site, redirect HTTP to HTTPS and set FORCE_SSL_ADMIN in wp-config.php.
Frequently asked questions
Is a limit login attempts plugin enough?
It helps, but it’s only one layer. It doesn’t stop credential stuffing from distributed IPs well, and it uses server resources during attacks. Combine it with 2FA, XML-RPC blocking and, ideally, server-level or firewall protection.
Will 2FA annoy my team?
There’s a small adjustment period. Most authenticator apps make logging in quick, and many 2FA plugins let users trust a device for a set period. The protection is well worth a few seconds per login.
Should I block whole countries?
Geographic blocking can reduce attack traffic if you have no customers in certain regions. Attackers use servers and proxies everywhere, though, so it’s not a full solution. Use it carefully, especially if you sell internationally.
How do I know if someone has already logged in illegitimately?
Check your user list for unfamiliar accounts, review activity logs for unexpected logins and look for recently modified files. If anything looks suspicious, change all passwords, regenerate security keys in wp-config.php and investigate further.
Final thoughts
The WordPress login page will always be a target, simply because it’s the same on millions of sites. You can’t stop bots from knocking. What you can do is make sure the door is solid: strong unique passwords, two-factor authentication for everyone with power, rate limiting at the server, XML-RPC blocked and monitoring in place. Do that, and those thousands of daily attempts become harmless background noise.
