The login page is the single most attacked URL on almost every WordPress site, because it's the one place where a correct guess is worth something: full administrator access. Most advice about "securing the login page" leads with the least effective fix and buries the most effective one. This is the reverse order — the controls that actually reduce credential-based compromise, ranked by how much they matter, not by how easy they are to explain.
Moving wp-login.php: obscurity, not security
Plenty of plugins let you rename or relocate the login URL away from the default /wp-login.php. It's worth being honest about what this does and doesn't accomplish: it removes your login page from the huge volume of fully automated, untargeted scanning traffic that hits /wp-login.php on every WordPress site indiscriminately, all day, regardless of whether that particular site looks interesting. That's a real, measurable reduction in noise — smaller log files, less server load from bot traffic, fewer alerts to triage.
What it doesn't do is stop a targeted attacker. Anyone specifically trying to get into your site can find the real login URL in minutes — it's often still linked from theme files, exposed through wp-json discovery endpoints, or just guessable from a short list of common relocated paths. Treat a moved login URL as noise reduction, not as a control that stops a determined attacker. It's a reasonable thing to do; it's not a reason to skip anything below.
Rate-limit and lock out repeated failed logins
This is the control that actually neutralizes brute-force guessing, because it removes the thing that makes guessing viable in the first place: unlimited free attempts. Out of the box, WordPress itself doesn't lock out or rate-limit failed login attempts at all — that has to be added, either through a plugin or at the server/firewall layer.
A commonly recommended, reasonable starting point: lock out an IP address after somewhere around 3 to 5 failed attempts, for a lockout window of roughly 20 to 30 minutes. That's long enough to make an automated guessing script's job impractical, without being so aggressive that a real user who mistypes their password twice gets locked out for a day. Tighten either number if your site is a frequent target; loosen the attempt count slightly if you have a lot of legitimate users who share office IP addresses.
Two-factor authentication: the single highest-leverage control
If you only do one thing on this page, this is it. A rate limit slows down guessing; two-factor authentication makes a correctly guessed or phished password insufficient on its own to get in. NIST's digital identity guidelines (SP 800-63B) list a second authentication factor — a time-based one-time code, a hardware key, or an authenticator app — as one of the highest-leverage single controls against credential-based account takeover, and that holds just as true for a WordPress admin account as for any other login.
Turn it on for every account with administrator or editor-level access — not just the one you personally use day to day. An old developer or agency account with a weak, never-rotated password and no second factor is exactly the kind of account that gets picked off first, because nobody's watching it closely. We cover exactly this pattern in our breakdown of dormant admin accounts.
Get rid of "admin" as a username, and stop leaking real ones
A username like admin or administrator hands an attacker half the puzzle before they've made a single guess — they only need the password, not the username too. If any account on your site still uses one of these, create a new administrator account with a non-obvious username, move ownership of content to it, and remove the old one.
That fix only holds if your real usernames aren't already public somewhere else. Two default WordPress behaviors give them away for free: visiting yoursite.com/?author=1, ?author=2, and so on redirects to that user's author archive at a URL containing their actual username, and requesting yoursite.com/wp-json/wp/v2/users returns a JSON list of every registered user's name and slug — usually the same as the login name. Neither requires being logged in. Restricting the REST API users endpoint to authenticated requests and disabling the plain ?author= redirect closes both without affecting anything a normal visitor needs. We've also covered how an unusual login pattern on a legitimate account gets flagged in this breakdown of login-location alerts.
CAPTCHA and bot challenges: a supplementary layer, not a substitute
A CAPTCHA or similar bot-challenge on the login form adds real friction against fully automated, unsophisticated scripts, and it's a reasonable extra layer to stack on top of the controls above. It is not a replacement for any of them — a challenge that only filters out naive bots does nothing against a targeted attacker running a script built to solve or bypass it, and it does nothing at all about a password that was already correct. Use it to cut noise on top of rate-limiting and 2FA, not instead of either.
What login hardening doesn't cover
Everything above reduces the odds of a credential-based compromise specifically — someone getting in by guessing, stuffing, or phishing a password. It does nothing for a compromise that never touches the login form at all, like an unauthenticated vulnerability in a plugin that lets an attacker skip login entirely. We walk through exactly that kind of bug in what cross-site scripting actually is, and cover the broader set of non-login hardening changes in the hardening checklist that actually matters. Login security and site hardening are two different halves of the same problem — a site that only does one is still exposed on the other.
Rate limits and 2FA stop credential guessing. Something still needs to watch for what a plugin vulnerability lets through instead.
Install free →