How to secure WordPress login page

Start with the baseline

Before you add plugins or rename URLs, make sure the basics are already true. WordPress admin must be served over HTTPS, every Administrator should use a unique password from a password manager, and old accounts should be removed instead of left "just in case." Login security fails quietly when the weak point is a contractor account from three years ago.

Use OWASP authentication guidance as the north star: strong passwords, multi-factor authentication, generic error messages, throttling, and careful recovery flows. WordPress can support all of that, but most sites need a little hardening to get there.

One important framing point: hiding wp-login.php is not a replacement for 2FA, CAPTCHA, or lockouts. It is a noise filter. The actual security comes from making password guessing fail, alerting you when it happens, and limiting what a compromised account can do.

Hide the login URL, but do not call it security

Changing the public login URL from /wp-login.php to something like /staff-access/ cuts down automated bot traffic because most commodity scanners do not spend time discovering custom paths. That can reduce log noise, server load, and accidental lockouts triggered by bots.

Do it carefully:

1. Use a maintained plugin or server rule. A plugin such as WPS Hide Login can work, but keep it updated. If your stack supports it, a web-server rewrite is even cleaner.
2. Keep /wp-admin/ behavior predictable. Authenticated users should still reach the dashboard. Unauthenticated users can be redirected to your custom login path or a 404.
3. Document the new URL. Store it in your password manager entry for the site. Do not rely on memory or a Slack message.
4. Do not leak it in public HTML. Login links in footer menus, membership widgets, and cached pages defeat the point.

The right expectation: hiding the login URL reduces opportunistic traffic. It does not stop targeted attackers, browser password theft, malware on an admin laptop, or attacks against xmlrpc.php.

Require two-factor authentication

Two-factor authentication is the single biggest improvement for WordPress login page security. Passwords get reused, phished, and leaked. A second factor makes a stolen password much less useful.

For most WordPress sites, require 2FA for these groups first:

• Administrators and Super Admins. They can install plugins, edit settings, and create other users.
• Editors on publisher sites. They can publish or alter public content and often have access to sensitive drafts.
• Shop managers and membership staff. They may see customer records, orders, subscriptions, or private member data.
• Developers and agency accounts. These accounts are often over-privileged and shared across multiple client sites.

Prefer authenticator apps, passkeys/WebAuthn where supported, or hardware keys for high-risk accounts. SMS is better than no 2FA, but it is weaker than app-based or hardware-backed factors. WordPress.org itself encourages 2FA for accounts that can affect the ecosystem, which is a good signal for how seriously admin access should be treated.

Do not skip recovery planning. Generate backup codes, store them in a shared business password vault, and define who can reset a lost factor. A 2FA rollout that locks out the only owner account creates a different kind of incident.

Use CAPTCHA only where it helps

CAPTCHA is useful against automated login attempts, but it should be used as friction, not as your primary control. A CAPTCHA on every login can irritate legitimate users and still fail against human-solved or token-farmed attacks.

A better setup is conditional:

1. Show CAPTCHA after one or two failed attempts from the same IP or username.
2. Use it on password reset and registration forms, where bots also cause damage.
3. Combine it with rate limiting so solving one challenge does not allow unlimited guesses.
4. Choose an option that fits your privacy posture, such as Cloudflare Turnstile, hCaptcha, or reCAPTCHA.

CAPTCHA should not replace account lockouts or 2FA. It is there to slow down automation enough that your lockout and alerting rules can do their job.

Set sane lockout and rate-limit rules

A good WordPress login lockout rule has to balance two failures: letting attackers guess forever, and letting attackers lock your real users out with a few forged attempts. Permanent lockouts sound strict, but they are easy to abuse.

A practical starting point:

• 5 failed attempts per username or IP in 15 minutes triggers a temporary lockout.
• 15 minute first lockout, then exponential backoff for repeated abuse.
• Separate counters for IP and username so distributed attacks still get throttled.
• Generic errors such as "Invalid login" instead of revealing whether the username exists.
• Admin alerts when a privileged account sees repeated failures or a successful login after a burst of failures.

At the edge, add a WAF or CDN rule for /wp-login.php and your custom login path. A limit like 10 POST requests per minute per IP is usually generous for humans and harsh for bots. For WooCommerce or membership sites, test carefully because customers may share office networks, mobile carriers, or VPN egress IPs.

Reduce username leakage

Attackers need both a username and password. WordPress often leaks usernames through author archives, REST API responses, comment markup, and predictable admin names. You do not need to make usernames secret forever, but you should stop handing attackers a clean list.

1. Do not use admin, the domain name, or a visible author name as an Administrator login.
2. Set display names that differ from login names.
3. Block or normalize author enumeration routes if your site does not need public author archives.
4. Review REST API user exposure, especially on sites with many staff accounts.

The goal is not perfect secrecy. The goal is to remove the easy path where a bot harvests your author slugs and immediately starts credential stuffing those names.

Do not forget xmlrpc.php and application passwords

A hardened login page does not help if the same credentials can be guessed through xmlrpc.php. If you do not use Jetpack, legacy mobile app workflows, or old publishing tools, block XML-RPC outright. If you need it, rate-limit it aggressively and allowlist trusted services.

Also review WordPress application passwords. They are useful for API integrations, but stale tokens behave like passwords that bypass 2FA. Remove old application passwords and create integration-specific tokens instead of sharing one long-lived credential.

How Lockora audits login security

Lockora maps login-page hardening into concrete findings instead of vague advice. The audit checks for exposed default login paths, missing 2FA on privileged accounts, lack of lockout or rate-limit controls, public username signals, XML-RPC exposure, weak Administrator usernames, and suspiciously stale high-privilege accounts.

The value is not just detecting that a control is missing. Lockora groups related findings into the likely attack path: "admin username is public, default login is exposed, no lockout rule was detected, and XML-RPC is reachable." That is the difference between a checklist and an audit you can act on.

Common questions

Should I rename wp-login.php?

Yes, if you understand the tradeoff. It reduces automated noise and lowers bot traffic, but it is not a standalone security control. Use it with 2FA, lockouts, CAPTCHA, and XML-RPC hardening.

Which WordPress users need 2FA?

All Administrators, Super Admins, developers, agency accounts, shop managers, and anyone who can publish or access customer data. Subscribers usually do not need mandatory 2FA unless the site stores sensitive member information.

What is the best lockout rule?

Start with 5 failed attempts in 15 minutes, a 15 minute lockout, exponential backoff for repeated abuse, and alerts for privileged accounts. Tune from logs after a week.