The WordPress admin login URL is one of the most predictable things about a WordPress site. Every automated bot knows to check /wp-login.php, and a significant portion of server traffic on any public WordPress installation consists of credential stuffing and brute-force attempts against this single file. While a robust password policy and a login lockout plugin are the primary defenses, redirecting direct browser-level GET requests to wp-login.php adds a lightweight layer of obscurity that stops the least sophisticated automated attacks before they start.
This snippet does not implement true login URL obfuscation, the login page is still accessible when accessed correctly. What it does is redirect direct navigation to wp-login.php in a browser, which catches bots that request the page before attempting credentials, and reduces the visibility of your login endpoint to casual scanners.
The Code
Add this to your functions.php or a site-specific plugin. It runs on init and checks whether the current request is a direct browser-level GET to wp-login.php from an unauthenticated visitor.
What’s Allowed Through
The snippet includes several important exclusions to avoid breaking legitimate login flows.
Requests with certain action parameters are allowed through: logout, lostpassword, rp (reset password), resetpass, and postpass (password-protected post entry). Blocking these would break logout, password recovery, and protected content access.
POST requests are always allowed through, this covers the actual login form submission when a user enters credentials. Blocking POST requests would prevent login entirely.
Logged-in users are allowed through by the ! is_user_logged_in() check, which means authenticated users navigating to wp-login.php directly, for example, to switch accounts, won’t be unexpectedly redirected.
Customising the Redirect Destination
By default, the snippet redirects to home_url( '/' ), your homepage. You can change this to any URL: a custom login page built with a form plugin, a 404 page, or a branded landing page. Using 302 (temporary redirect) rather than 301 (permanent) is intentional, it prevents browsers and proxies from caching the redirect, which is important if you ever change the destination URL or want to restore normal login page access.
This Is Not a Complete Security Solution
Redirecting the login page provides security through obscurity, which is a supplementary measure rather than a primary one. It should be combined with strong password requirements, two-factor authentication, and a login attempt limiting plugin or server-level rate limiting. Bots that submit credentials directly via POST will bypass the redirect entirely, so the login endpoint itself still needs to be hardened independently of this snippet.
add_action( 'init', function() {
// Allow legitimate login requests through
if (
isset( $_GET['action'] ) &&
in_array( $_GET['action'], [ 'logout', 'lostpassword', 'rp', 'resetpass', 'postpass' ], true )
) {
return;
}
// Allow POST requests (actual login form submissions)
if ( $_SERVER['REQUEST_METHOD'] === 'POST' ) {
return;
}
$script = isset( $_SERVER['SCRIPT_FILENAME'] ) ? basename( $_SERVER['SCRIPT_FILENAME'] ) : '';
if ( $script === 'wp-login.php' && ! is_user_logged_in() ) {
wp_redirect( home_url( '/' ), 302 );
exit;
}
} );