Hide Your WordPress Login Page From Bots and Attacks
Every WordPress site's login sits at the same URL that every bot attacks: wp-login.php. Move it to a secret slug and send unauthorized visitors to a 404—removing the target entirely.
Every WordPress site on earth has its login at the same address: wp-login.php. Every brute-force bot knows it, every vulnerability scanner tries it first, and there’s nothing in stock WordPress to change that—the URL is hardcoded. So your login page gets hammered around the clock by scripts that will never stop, because they always know exactly where to knock. The most effective response isn’t a bigger lock. It’s moving the door.
The essentials
- Every WordPress login lives at
wp-login.php—a universal target every bot already knows. - The module moves login to a secret slug and redirects the old URL and
/wp-admin(for logged-out visitors) to a 404 or any page you choose. - It skips AJAX, REST API, XML-RPC, cron and CLI, so plugins, apps and scheduled tasks keep working.
- Reserved slugs (
wp-admin,login,xmlrpc.php…) are blocked, and the login slug is excluded from page caching—so you can’t accidentally break or expose it. - It’s off until you enable it, warns you to bookmark the URL, and recommends pairing with Fatal Error Recovery as a lockout safety net.
Why is wp-login.php such a problem?
Because WordPress gives you no built-in way to change the login URL, block direct access to wp-login.php, keep logged-out visitors out of /wp-admin, or redirect the attempts elsewhere. So the login page sits there, identical and predictable, on millions of sites.
The result is relentless automated traffic. Bots don’t need to succeed to cost you: they burn server resources, bury your logs under failed attempts, and can noticeably slow a small site just by knocking thousands of times a day. Rate limiting and CAPTCHAs fight that traffic once it arrives. Hiding the login removes the target so the traffic never arrives in the first place—if a bot can’t find the door, it can’t hammer it.
How do you hide your WordPress login page?
Activate the Hide Login Page module in Blaminhor Essentials, then set two things: a secret login slug that replaces wp-login.php, and where to send everyone else—your 404 or any page you choose. Logged-in users still reach the admin normally, and AJAX, REST, cron and CLI stay untouched, so nothing on your site breaks.
Two fields—your secret login slug and where to send everyone else—plus a built-in nudge to set up recovery before you switch it on.
Set a secret login URL
Replace wp-login.php with a slug you choose, so your login becomes yoursite.com/my-secret-door/ instead of the address every bot tries. Make it memorable but not guessable—avoid obvious choices like admin, login or signin. The module actively blocks reserved slugs (wp-admin, wp-login, xmlrpc.php and the like) so you can’t pick something that would collide with WordPress itself.
Send everyone else away
Once enabled, anyone reaching wp-login.php or /wp-admin without being logged in is redirected—by default to your 404, or to any URL you prefer (your homepage, a custom page). They never see a login form, and never learn one exists at that slug. Logged-in users reach the admin normally, and AJAX, REST API, XML-RPC, cron and CLI requests are untouched, so nothing on your site breaks. The custom login slug is even excluded from page caching, so a cache layer can’t accidentally serve or expose it.
Here’s what changes for each kind of request, so you can see nothing legitimate gets caught:
| Request | Default WordPress | With Hide Login Page |
|---|---|---|
wp-login.php in a browser (logged out) | Login form shown to anyone | Redirected to a 404 or the page you pick |
/wp-admin (logged out) | Bounces to wp-login.php | Redirected away—no login revealed |
| Your secret slug | Doesn’t exist | Shows the login form |
| AJAX | Works | Untouched—deliberately skipped |
| REST API | Works | Untouched—deliberately skipped |
| XML-RPC | Works | Untouched—deliberately skipped |
| Cron / WP-CLI | Work | Untouched—deliberately skipped |
What about locking yourself out?
That’s the one genuine risk of hiding a login: forget the custom URL and you’re on the outside too. The module builds in two safeguards.
- Bookmark the URL. The module shows a clear reminder before you enable it—save the slug somewhere you trust.
- Enable Fatal Error Recovery first. This companion module provides a secret recovery URL that always works, even if you lose your custom login address. Hide Login explicitly recommends turning it on before you activate—two modules from the same plugin that know about each other, which is exactly the kind of safety net separate tools never give you.
A practical example
Say you manage a client site and want the login invisible to bots and to the client alike:
- Activate Hide Login Page.
- Set the login slug to something like
client-access. - Set the redirect to
404. - Enable Fatal Error Recovery and save its recovery URL somewhere safe.
- Turn the protection on.
Now yoursite.com/wp-login.php and yoursite.com/wp-admin/ both return a 404. The only way in is yoursite.com/client-access/. Bots scanning for wp-login.php find nothing, brute-force scripts have no target, and your logs go quiet.
Simple security, no overhead
Moving your login doesn’t touch your passwords or your 2FA—it removes the target the automated attacks all depend on. No .htaccess edits, no server config, no performance cost: just a different URL, and a much quieter site. Pair it with the HTTPS Redirect and Fatal Error Recovery modules and your login surface is about as small as WordPress lets it get.
Hide Login Page is one of the 20+ tools in Blaminhor Essentials—free and open-source on WordPress.org.
– blaminhor
FAQ
Does hiding the login page actually stop brute-force attacks?
It stops the automated ones, which are the vast majority. Bots hammer wp-login.php because it's the same URL on every site; move login to a secret slug and they hit a 404 with nothing to attack. A targeted human who somehow finds your slug still needs your password, so keep that strong too.
Will hiding my login break AJAX, the REST API or cron?
No. The module deliberately skips AJAX, REST API, XML-RPC, cron and CLI requests, so plugins, apps and scheduled tasks keep working normally. Only human browser requests to the old login page and wp-admin by non-logged-in visitors are redirected away.
How do I change the wp-admin URL too?
You don't rename /wp-admin—it stays, but the module redirects any logged-out visitor who hits it straight to your 404 or chosen page, so nobody without a session ever sees a login. Once your login slug is secret, /wp-admin becomes a dead end for bots; logged-in users still reach it normally.
Is hiding the login better than limiting login attempts or 2FA?
It's complementary, not a replacement. Rate limiting and 2FA fight attacks once they reach your login; hiding the page means most never arrive, cutting the noise those tools have to handle. The strongest setup layers all three—a hidden slug, limited attempts and 2FA—rather than trusting any single one.
What if I forget my custom login URL and get locked out?
That's the one real risk, so bookmark the URL and pair the module with Fatal Error Recovery, a companion module that gives you a secret recovery link that always works. Hide Login even reminds you to enable it first. Reserved slugs like wp-admin or login are also blocked so you can't pick a self-defeating URL.
Will hiding my login interfere with page caching?
No. The module automatically excludes your custom login slug from page caching, so a cache layer can't accidentally store the login page, serve a stale version, or expose the slug in a cached URL. Everything else caches as normal—only the sensitive login route is deliberately kept out of the cache.
Comments