Hide Your WordPress Login Page and Lock Down wp-admin
Point any automated scanner at a WordPress site and it will try /wp-login.php within the first few requests β it’s the single most predictable URL on the entire platform. Learning how to hide your WordPress login page removes that predictability entirely, and pairing it with a stricter full admin lockout for genuine emergencies covers two very different levels of the same problem.
Table of contents
- Why the default login URL is such an easy target
- How hiding the login page actually works
- Admin lockout: a stricter, separate tool
- What still works no matter which is enabled
- The fear that stops most people from trying this
- Why this is one layer, not the whole defense
- FAQ
Why the default login URL is such an easy target
Every unmodified WordPress install has its login form at the same predictable path. Automated brute-force tools don’t need to discover this β they assume it and start hammering it immediately, testing common username/password combinations around the clock, with no human ever choosing your specific site as a target. A large share of that traffic is entirely untargeted, which is exactly why a simple change to the login URL is disproportionately effective: it doesn’t stop a determined, targeted attacker, but it silently drops your site out of the pool that opportunistic, automated scanning ever reaches.
How hiding the login page actually works
WP Warden’s login page hiding doesn’t rename any file on your server. It intercepts requests early: an anonymous visit to the real /wp-login.php or /wp-admin gets a plain 404, as if nothing were ever there, while a separate, secret URL you choose quietly routes through to the real login form. Anyone already logged in is never affected β this only changes what an anonymous visitor sees.
Admin lockout: a stricter, separate tool
Disabling admin access entirely is a different, stronger action β and deliberately so. Where login-page hiding only affects anonymous visitors, a full admin lockout blocks wp-admin and wp-login.php outright, including sessions that are already logged in and even your own masked login URL if you have both enabled. This isn’t a bug or an overlap between the two features; it’s the intended behavior for a specific situation: a site under active attack, a suspected compromise being investigated, or a maintenance window where nobody β including you β should be making changes through wp-admin until it’s lifted.
What still works no matter which is enabled
Neither feature touches the parts of WordPress that need to keep running regardless of who’s locked out: wp-cron.php, admin-ajax.php, admin-post.php, and the REST API all stay reachable. That matters because plenty of front-end functionality β scheduled posts, AJAX-powered forms, anything built on the REST API β depends on those endpoints, and locking them along with the admin area would break the live site for visitors, not just protect the back end.
The fear that stops most people from trying this
The obvious worry with either feature is locking yourself out with no way back in short of FTP or a hosting control panel. Both are designed around that exact fear: they’re toggled remotely through WP Warden itself, over the same connection the site already uses to check in, and turning either off takes effect within a few minutes β no server access, no support ticket to your host, no waiting on a stuck request. If you ever do lock yourself out, the fix is a dashboard toggle, not a recovery mission.
Why this is one layer, not the whole defense
Moving your WordPress login page off the default URL removes the easy, opportunistic attacks β but it isn’t a complete defense against someone who’s genuinely targeting your specific site and finds the real URL some other way (a leaked link, a misconfigured plugin exposing it, a targeted phishing attempt). That’s exactly why it’s worth pairing with two-factor authentication: hiding the login page cuts down who even gets a chance to try logging in, and 2FA makes a correct password alone worthless to whoever does. Neither one is redundant with the other β they close different parts of the same overall risk.
FAQ
Should every client site have its login page hidden by default?
It’s a reasonable default for most sites β the downside is minimal (remembering or bookmarking one custom URL) and the upside (dropping out of opportunistic automated scanning) applies to essentially every public WordPress site regardless of size or traffic.
When would I actually use a full admin lockout instead of just hiding the login page?
When you specifically want nobody β including a legitimate but possibly-compromised session β accessing wp-admin at all, such as during an active incident investigation. It’s a short-term, situational tool, not something to leave permanently enabled the way login-page hiding often is.
Will hiding the login page break any plugins that link directly to wp-login.php?
A plugin or theme hardcoding a direct link to /wp-login.php for an anonymous visitor would hit the same 404 a bot does β worth a quick check on any custom “member login” links in your theme after enabling this, though the vast majority of normal WordPress login flows go through the standard route this feature is built to handle correctly.
Start a free 14-day trial and take your login page off the list of things bots can find.