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.
OvKit includes a Hide Login URL feature under Features → Security. Set your custom slug, save, and you’re done. OvKit handles password reset URLs, logout redirects, registration flows, and compatibility with WooCommerce and two-factor auth plugins.
If something goes wrong, OvKit includes a recovery bypass — you won’t get locked out of your own site.
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 unauthenticated users. When you’re not logged in, /wp-admin returns a 404 instead of redirecting to the login form.
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 or remove the custom code from functions.php. OvKit also includes an emergency recovery URL for this exact scenario.
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: