Locking Down WordPress Admin Access: When to Hide vs. Fully Disable It
Hiding the login page is a good default for practically every WordPress site β it takes it out of the pool of automated bot traffic that assumes the default URL and never even discovers your site individually. But there’s a category of situation where hiding isn’t enough: an active security incident, where the honest answer to “who should be able to log in right now” is genuinely nobody, not even you, until the situation is understood.
Table of contents
- Hiding the login page versus disabling admin entirely
- How the full lockout works
- When this is actually the right tool
- FAQ
- Walking through how this plays out during a real incident
Hiding the login page versus disabling admin entirely
Hiding the login page deters opportunistic scanning β automated tools that assume the default /wp-login.php URL and never discover the real one. It does nothing, by design, to a session that’s already authenticated, and that’s exactly the gap that matters during an active incident: if an attacker already has valid credentials or a live session, moving the login URL doesn’t touch them at all.
How the full lockout works
WP Warden’s ability to disable admin access is deliberately stricter: switching it on blocks wp-admin and wp-login.php outright, including sessions that are already authenticated. It’s controlled remotely from the dashboard, and taking effect requires no server access β which matters specifically because the whole point of using it is speed during a moment where every extra minute counts against you.
When this is actually the right tool
The clearest case is a suspected compromise where you haven’t yet confirmed the scope of the problem. Locking wp-admin immediately, before doing anything else, means nobody β including a compromised account you haven’t identified yet β can make further changes while you investigate. It’s also genuinely useful for a planned maintenance window where multiple team members have access and you want a hard guarantee that no one, including a well-meaning teammate, makes an unplanned change mid-window. Throughout all of this, the public site keeps working exactly as normal: wp-cron, admin-ajax, admin-post, and the REST API stay reachable, so visitors never see any of it.
Walking through how this plays out during a real incident
A file integrity alert fires, suggesting a possible compromise, and the immediate instinct is to start investigating right away. The better first move is locking wp-admin entirely, before doing anything else β because if the account making changes to investigate is itself compromised, every action taken during that investigation risks making things worse rather than better. With admin access fully disabled, the site is frozen exactly as it was found, the public site keeps running untouched, and the investigation can proceed methodically rather than under pressure to move fast before anyone else touches anything.
FAQ
Does this also block sessions already logged in?
Yes β that’s what makes it stricter than login-page hiding; an already-authenticated session doesn’t bypass it.
Does the public site still work while this is active?
Yes β only wp-admin and wp-login.php are blocked; the front end keeps serving visitors normally throughout.
Start a free 14-day trial β no credit card required.