Quick answer: Most WordPress login attacks are automated guessing at wp-login.php and XML-RPC. Protect the login by using unique usernames (never “admin”), strong passwords from a password manager, two-factor authentication for every administrator, a limit on failed attempts, and XML-RPC disabled or restricted if you do not need it. Add extra protection such as IP restrictions or a firewall for the admin area where it fits, and review login activity regularly. These steps are cheap and stop the large majority of opportunistic attacks.
Why the login page gets so much attention
WordPress powers a very large share of websites, so attackers write tools that target it at scale. They do not need to know anything about your business. Bots work through long lists of sites and try common usernames and leaked passwords, again and again.
The usual targets are:
- /wp-login.php, the standard login form
- /xmlrpc.php, an older remote publishing interface that can accept many login attempts in a single request
- User enumeration, where bots discover real usernames before guessing passwords
Every one of these can be hardened without hurting real users. Login protection is one layer of a wider plan; our guide to WordPress security covers the rest.
1. Get rid of predictable usernames
Many older sites still have an account called “admin” or a username that matches the site name. Bots try these first.
To fix it:
- Create a new administrator account with a username that is not obvious
- Log in as the new user
- Delete the old “admin” account and attribute its content to the new user when WordPress asks
Also check the “Display name publicly as” setting in each user profile. If the public author name is the same as the login username, you are publishing half of the credentials on every post.
2. Use strong, unique passwords
A unique, long password generated by a password manager is far harder to guess than any “clever” password a person invents. Reused passwords are a major risk: if a password leaks from another service, bots will try it on your site.
Ask everyone with an account to use a password manager, and remove accounts for people who no longer need access. A shared team vault makes it easy to hand over access safely when someone joins or leaves.
3. Limit login attempts
By default, WordPress allows unlimited login attempts. Limiting them slows down guessing attacks dramatically.
Common approaches:
- A dedicated plugin such as Limit Login Attempts Reloaded
- The login protection features in a security plugin like Wordfence
- Rate limiting at the server or firewall level
Sensible settings lock out an IP address for a period after a handful of failed attempts, with longer lockouts for repeat offenders. Set a whitelist for your own office IP if lockouts become a nuisance.
Server-level or edge protection is more efficient than plugin protection, because blocked requests never reach WordPress. If you use Cloudflare, rate limiting and firewall rules on the login path are worth setting up. See Cloudflare for WordPress for the general setup.
4. Turn on two-factor authentication
Two-factor authentication means a stolen or guessed password is not enough to log in. The second factor is usually a time-based code from an authenticator app such as Google Authenticator or Authy.
Make it mandatory for:
- All administrators
- Editors and shop managers
- Anyone who can install plugins or change settings
Plugins like Two Factor, Wordfence Login Security and others add this to WordPress. Store backup codes safely so a lost phone does not lock you out. We covered setup options in WordPress two-factor authentication.
5. Deal with XML-RPC
XML-RPC lets external apps publish to WordPress. Some older mobile apps, Jetpack features and remote publishing tools still use it. For many sites, nothing uses it at all, and it is mainly an attack surface. Its system.multicall method can carry many password guesses in one request, which helps attackers avoid simple attempt limits.
Options:
- Disable XML-RPC completely if nothing needs it, using a plugin or a server rule
- Block it at the server or firewall, while allowing specific services that need it
- If you rely on Jetpack, check which features need XML-RPC before blocking
Test after making changes, especially any app or service that publishes to your site.
6. Reduce user enumeration
Bots can often discover usernames by visiting ?author=1 on your site, which redirects to an author archive URL containing the username. The REST API users endpoint can also list authors.
To reduce this:
- Make sure display names and author slugs do not match login usernames
- Use a security plugin or small code snippet to block author scans for logged-out visitors
- Restrict the REST API users endpoint to logged-in users if your site does not need it public
This will not stop a determined attacker, but it removes easy wins.
7. Consider changing or protecting the login URL
Plugins such as WPS Hide Login move the login page to a custom URL. This cuts noise from bots that only try /wp-login.php. It is not real security on its own, because the new URL can leak, but it reduces load and log clutter.
Stronger options for the admin area:
- IP allow lists for /wp-admin/ and the login page, if your team logs in from fixed addresses
- HTTP basic authentication on the login page as an extra gate
- A web application firewall in front of the site
Choose based on how your team works. IP restrictions are excellent for an office team and awkward for remote editors.
8. Use HTTPS everywhere
Logins should only ever happen over HTTPS so credentials are not sent in plain text. Most hosts provide free certificates through Let’s Encrypt. Make sure the whole admin area is forced to HTTPS, not just the front end.
9. Give people only the access they need
Not everyone needs to be an administrator. Writers can be Authors or Contributors. Content managers can be Editors. Shop staff can be Shop Managers. Fewer administrator accounts means fewer high-value targets. See WordPress user roles for how to match roles to tasks.
Review accounts every quarter and remove anyone who has left or no longer needs access.
10. Watch login activity
Logging helps you spot trouble early. A security or activity log plugin can record:
- Successful and failed logins
- New user accounts
- Role changes
- Plugin and theme changes
Set alerts for new administrator accounts and logins from unexpected countries if your plugin supports it. A sudden spike in failed logins is usually just bots, but a successful login you do not recognise needs immediate action.
If an account is compromised
- Change the password and force logout of all sessions
- Check for new admin users, unknown plugins and modified files
- Reset passwords for all administrators
- Review recent changes to content and settings
- Scan the site with a malware scanner
If you find signs of deeper compromise, follow a full clean-up process. Our guide to a hacked WordPress site walks through it.
FAQ
Is hiding the login URL enough?
No. It reduces bot noise but should be combined with strong passwords, two-factor and attempt limits.
Will limiting login attempts lock out real users?
Occasionally, if someone mistypes a password several times. Short lockout periods and a clear reset process keep this manageable.
Should I disable XML-RPC?
If nothing on your site uses it, yes. Check Jetpack and any publishing apps first.
Close the easy doors
Login security is mostly about removing easy wins for automated attacks. Unique usernames, strong passwords, two-factor, attempt limits and a few sensible restrictions go a long way. If you want help hardening and maintaining your WordPress site, see our Turn visitors into customers service.
