How to Protect Your WordPress Login Page From Brute-Force Attacks

Protect your WordPress login page by reducing guesses, blocking bad traffic, and requiring stronger proof of identity. WordPress is a high-value target because it powers about 43% of all websites, so attackers routinely scan for /wp-login.php and weak passwords at huge scale.

TLDR: A secure WordPress login should use multi-factor authentication, login attempt limits, strong passwords, and server-level blocking. For example, a small WooCommerce store with five staff accounts can cut thousands of automated guesses per week by limiting each IP address to 5 failed attempts per 15 minutes. Add a firewall and disable XML-RPC if you do not need it. Do not rely on a hidden login URL alone; it helps, but it is not real protection by itself.

Why Brute-Force Attacks Are So Common

A brute-force attack is simple. A bot tries username and password combinations until one works. It may try “admin” with common passwords. It may use leaked credentials from old breaches. It may rotate IP addresses to avoid basic blocks.

This is not a clever movie-style hack. It is noisy, repetitive, and cheap. That is why it works. Many WordPress sites still use weak passwords, shared admin accounts, or no login rate limits. Honestly, it feels ridiculous that one bad password can undo months of good work, but that is exactly what happens.

1. Use Strong Passwords and Remove Weak Usernames

Start with the obvious control. Every administrator, editor, shop manager, and developer must use a strong password. A good password should be long, unique, and stored in a password manager. Length matters more than weird substitutions. A 20-character passphrase is better than “P@ssw0rd2025”.

Also remove the default admin username if it exists. Attackers try it first because it is common. Create a new administrator account with a unique username, assign it full rights, then delete the old admin user. When deleting it, assign its content to the new account.

Bad: admin / Summer2024
Better: martha.siteops / a long password from a password manager
Best: unique username, unique password, and multi-factor authentication

2. Turn On Multi-Factor Authentication

Multi-factor authentication, often called MFA or 2FA, adds a second step after the password. This can be an authentication app, a hardware key, or a one-time code. If an attacker guesses or steals a password, they still cannot log in without the second factor.

Use MFA for all administrator accounts. If your site handles payments, memberships, medical content, legal documents, or customer data, require it for every privileged user. The guidance also treats MFA as a strong control against account takeover.

Authentication apps are usually better than email codes. Email accounts get compromised too. SMS is better than nothing, but app-based codes or security keys are safer.

3. Limit Login Attempts

WordPress does not strictly lock down repeated failed logins by default. That is a problem. A bot can hammer the login form again and again unless something stops it.

Install a reputable security plugin or configure your hosting firewall to limit failed login attempts. A sensible rule is:

Allow 5 failed attempts from one IP address.
Lock that IP for 15 to 30 minutes.
Increase the block time after repeated lockouts.
Notify administrators after repeated attacks against a real username.

Do not set the rule so strict that real users get locked out all day after one typo. Expect to waste time on support tickets if the lockout policy is too aggressive. Balance security with usability.

4. Add a Web Application Firewall

A web application firewall, or WAF, filters traffic before it reaches WordPress. It can block known malicious IPs, suspicious request patterns, fake user agents, and login floods. Some hosts include this. You can also use a security plugin or a DNS-level service.

A firewall is useful because brute-force traffic consumes resources. Even failed logins can slow a site. On shared hosting, a large attack can make the admin area crawl. That means normal tasks, such as updating products or publishing posts, take longer than they should.

5. Disable XML-RPC If You Do Not Need It

XML-RPC is a WordPress feature used by some apps and external services. Attackers also abuse it for login attempts. The file is usually located at /xmlrpc.php. If you do not use remote publishing, Jetpack features, or mobile app posting, consider disabling it.

You can block XML-RPC through a security plugin, your host’s control panel, or server rules. Test after making the change. Some integrations may rely on it. If something breaks, switch to a more selective rule instead of opening it fully again.

6. Change the Login URL, But Do Not Trust It Too Much

Changing the login URL from /wp-login.php to a custom path can reduce automated noise. It is useful. It is not enough.

Security by obscurity fails when it becomes your only defense. A plugin conflict, exposed redirect, cached page, or user mistake can reveal the new address. Use a custom login URL as a supporting measure, not the main control.

If you do change it, save the new login address in your password manager. Share it only with users who need access. Keep a recovery method ready in case a plugin breaks the login route.

7. Protect User Enumeration

User enumeration lets bots discover valid usernames. For example, WordPress author archive pages may reveal login names. Attackers then only need the password.

Set public display names that differ from login usernames. Block obvious enumeration requests where possible. Many security plugins can stop requests such as /?author=1 from exposing account names. Also avoid publishing posts under administrator accounts. Use editor accounts for content work instead.

8. Keep WordPress, Plugins, and Themes Updated

Brute-force protection is not only about passwords. Outdated plugins can create new login bypasses or privilege bugs. A strong password will not save a site if an old plugin lets attackers create an admin account.

Update WordPress core, plugins, and themes on a regular schedule. Remove anything unused. Fewer plugins mean fewer possible entry points. Keep a backup before major updates, then test the main pages, checkout, forms, and login process.

9. Restrict Access by IP When Practical

If only a small team needs administrator access, IP restrictions can be very effective. You can allow logins only from office IPs, a VPN, or a fixed list of trusted addresses. This is common for business sites where staff work from known locations.

This method is less practical for fully remote teams with changing networks. It can still work if everyone connects through a company VPN. Be careful, though. A wrong rule can lock out your whole team. Keep hosting or server access available as a backup.

10. Monitor Logs and Act on Patterns

Security tools are only useful if someone checks them. Review failed login reports. Look for repeated attempts against the same username, attacks from the same country, or sudden spikes after a plugin vulnerability is announced.

Set alerts for administrator logins, new admin account creation, and plugin changes. These events matter. If they happen at 3:12 a.m. and nobody on your team was working, investigate right away.

A Practical Login Security Checklist

Use unique, long passwords for every account.
Enable MFA for administrators and privileged users.
Limit failed login attempts by IP address.
Use a firewall at the plugin, host, or DNS level.
Disable XML-RPC if it is not required.
Change the login URL as an extra layer only.
Hide or limit username exposure.
Keep WordPress, plugins, and themes updated.
Back up the site before major security changes.
Monitor login logs and respond to strange activity.

Brute-force attacks are predictable. That is good news. You do not need exotic tools to stop most of them. You need layered controls, clean account habits, and steady monitoring. Start with MFA and login limits, then add firewall rules and account hardening. The sooner you do it, the less time your site spends absorbing pointless password guesses from bots.