How to Hide Your WordPress Login Page from Bots and Hackers
Your WordPress login page at /wp-admin is the #1 target for bots. Here's how to hide it behind a custom URL and stop brute force attacks cold.
Every WordPress site on the internet has its login page at the same address: yourdomain.com/wp-admin or yourdomain.com/wp-login.php. Every single one.
That means every bot, every script kiddie, and every automated attack tool knows exactly where to knock. They don’t need to discover your login page — it’s in the same place on all 810+ million WordPress installations worldwide.
I check server logs on client sites weekly. Without exception, /wp-login.php is the most hammered URL on every WordPress site I manage. Thousands of POST requests per day, all trying random username-password combinations. And this is before the site is even indexed by Google.
What is login page hiding?
Login page hiding means changing the URL where your WordPress login form lives. Instead of the default /wp-admin and /wp-login.php, you set a custom URL — something like /my-office or /dashboard-login or literally anything else.
When someone (or a bot) tries to access /wp-admin or /wp-login.php, they get a 404 error instead of your login form. Your actual login page still works perfectly — it’s just at an address only you know.
This is sometimes called “security through obscurity,” and critics will tell you it’s not “real” security. They’re technically right — it doesn’t patch vulnerabilities or strengthen passwords. But here’s the practical reality: it eliminates 99% of automated login attacks because bots don’t bother trying custom URLs. They hit /wp-login.php, get a 404, and move on to the next target.
Why should you care?
Server resource drain. Each brute force attempt against your login page triggers a full WordPress load — PHP execution, database connection, authentication check. Multiply that by thousands of attempts per day, and your server is spending significant resources on bot traffic instead of serving real visitors. On shared hosting, this can visibly slow your site.
Log noise. When every failed login attempt generates an entry, your security logs become useless. Finding a genuine suspicious event in a sea of automated noise is like finding a needle in a haystack. Hide the login page and your logs show only what matters.
Reduced attack surface. Brute force is only step one. Once a bot finds a responding login page, it might try more sophisticated attacks — XML-RPC multicall, application password exploits, or even zero-day login bypass vulnerabilities. No login page response means no escalation path.
Wp-admin redirect chain. Here’s a detail most guides skip: accessing /wp-admin when you’re not logged in triggers a redirect to /wp-login.php?redirect_to=... — this 302 redirect alone confirms to an attacker that WordPress is installed and the login endpoint exists. Hiding the login page breaks this confirmation chain.
The quick fix
Add this to your theme’s functions.php or site-specific plugin:
// Hide default WordPress login and redirect to 404
add_action( 'init', function() {
// Define your secret login slug
$secret_slug = 'my-secret-login'; // Change this!
$request = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );
$request = trim( $request, '/' );
// Allow the secret slug to load wp-login.php
if ( $request === $secret_slug ) {
require ABSPATH . 'wp-login.php';
exit;
}
// Block direct access to wp-login.php (except POST for active sessions)
if ( $request === 'wp-login.php' && ! is_user_logged_in() ) {
wp_safe_redirect( home_url( '/404' ), 302 );
exit;
}
});Warning: This is a simplified version. Production-ready implementations need to handle edge cases: password reset flows, registration pages, two-factor authentication plugins, and WooCommerce account pages. A basic snippet like this can lock you out if something goes wrong.
Always keep FTP/SFTP access ready. If you get locked out, you can rename or delete the plugin file to restore the default login URL.
The one-click solution
This is one feature where a plugin genuinely beats a code snippet. The edge cases are numerous and painful to debug.
Ovanap Admin Toolkit includes Hide login page URL under Admin Toolkit → Features → Security. Enter your custom slug and save. The toolkit serves the login form at the new address, returns a 404 for wp-login.php, sends logged-out visitors who open /wp-admin to the homepage, and points WordPress login, logout and password-reset links at the new URL. It warns you if WPS Hide Login or a similar plugin is already active. It has no special handling for WooCommerce account pages or two-factor plugins, so test those after you switch it on.
Next to the slug field is a Generate emergency bypass link button. It creates a single-use link, valid for 5 minutes, that opens the normal wp-login.php once. You have to be logged in to create it, so it does not help if you have already lost the custom URL; in that case use FTP (see below).
What happens after you fix this?
- Automated bot traffic to your login drops to near zero — bots hit
/wp-login.php, get a 404, and leave - Server resources freed up — no more thousands of PHP executions per day for bot requests
- Security logs become readable — only real activity shows up
- Attackers can’t confirm WordPress is installed — the
/wp-adminredirect chain is broken
The login page itself works exactly as before — same form, same functionality, same plugins. It’s just at a different address. Bookmark it, share it with your team, and forget about bots.
FAQ
Can I still access /wp-admin after hiding the login page?
If you’re already logged in, /wp-admin works normally — it takes you straight to the dashboard. The hiding only affects visitors who are not logged in. For them, /wp-admin no longer leads to the login form: the snippet above ends on a 404 page, and Ovanap Admin Toolkit sends them to the homepage.
What if I forget my custom login URL?
This is the most common concern, and it’s valid. Write it down. Store it in your password manager. If you do forget, you can access your site via FTP/SFTP and deactivate the plugin (rename its folder) or remove the custom code from functions.php. While you are still logged in, the slug is also shown in the toolkit under Admin Toolkit → Features → Security.
Does hiding the login page replace the need for strong passwords?
Absolutely not. Hiding the login page is one layer of security — it stops automated attacks. You still need strong, unique passwords, two-factor authentication if possible, and limited login attempts. Think of it as locking your front door AND not putting a “door here” sign on it.
Related reads: