How to Change the WordPress Login URL

Changing the WordPress login URL can reduce automated traffic aimed at the predictable wp-login.php endpoint, but doing it correctly requires more than adding a simple redirect.

WordPress uses its login endpoint for several related workflows:

• normal user authentication;
• administrator reauthentication;
• password recovery;
• password reset;
• logout;
• registration where enabled;
• internally generated login links;
• redirects from protected administration screens.

A custom login URL therefore needs to preserve the complete WordPress authentication lifecycle.

The goal is normally to change this:

https://example.com/wp-login.php

into something such as:

https://example.com/team-access/

while preventing ordinary visitors from continuing to use the predictable default endpoint.

That sounds simple. The complication is that WordPress itself generates URLs pointing to wp-login.php, and several of those URLs use different functions and filters.

A complete implementation must account for all of them.

This guide explains how WordPress generates login URLs, why renaming wp-login.php is the wrong approach, how routing and generated links should be handled, which authentication flows need testing and where a custom login URL fits into a broader WordPress security strategy.

How the default WordPress login URL works

On a standard WordPress installation, the login page is located at:

https://example.com/wp-login.php

The official WordPress Logging In documentation confirms that wp-login.php is the standard authentication page.

A logged-out visitor requesting:

https://example.com/wp-admin/

is normally redirected into the login workflow.

The simplified sequence is:

/wp-admin/
    ↓
WordPress checks authentication
    ↓
user is logged out
    ↓
wp-login.php
    ↓
credentials submitted
    ↓
authentication
    ↓
authenticated session

Changing the public login URL means modifying how users reach this authentication workflow without damaging the workflow itself.

wp-login.php does more than show the login form

The WordPress Core wp-login.php file reference shows that the endpoint handles several actions beyond ordinary sign-in.

Depending on the request, it participates in flows including:

?action=logout

?action=lostpassword

?action=resetpass

?action=rp

?action=register

This is why simply preventing all access to the file without reproducing or routing the required actions can break authentication-related features.

Do not rename the physical wp-login.php file

The first rule is straightforward:

Do not rename WordPress Core's
wp-login.php file.

For example, do not change:

/wp-login.php

into:

/secret-login.php

inside the WordPress installation itself.

wp-login.php is a Core file. WordPress updates can replace Core files, and WordPress functions, plugins and integrations can depend on the standard login architecture.

The correct model is:

Keep wp-login.php internally
        ↓
create a custom public route
        ↓
route that request into
WordPress authentication
        ↓
restrict ordinary direct access
to the default public endpoint

This keeps the Core authentication machinery intact while changing how visitors reach it.

The broader principle is consistent with the official WordPress Hardening documentation: Core files should not be manually altered as a security strategy.

WordPress generates login URLs through wp_login_url()

WordPress provides the function:

wp_login_url()

to retrieve the site’s login URL.

The official wp_login_url() documentation shows that Core normally begins with:

site_url( 'wp-login.php', 'login' )

The function accepts two useful parameters:

wp_login_url(
    $redirect,
    $force_reauth
)

The first can preserve a destination the user should reach after authentication.

For example:

wp_login_url(
    admin_url( 'edit.php' )
);

can generate a login URL that ultimately returns the authenticated user to the Posts screen.

WordPress provides the login_url filter

Before returning the generated URL, WordPress applies:

login_url

The official login_url filter documentation confirms that the filter receives:

$login_url
$redirect
$force_reauth

This makes it possible for a custom authentication system to change URLs generated through wp_login_url().

A simplified example might look like:

add_filter(
    'login_url',
    function (
        $login_url,
        $redirect,
        $force_reauth
    ) {

        $url = home_url(
            '/team-access/'
        );

        if ( ! empty( $redirect ) ) {
            $url = add_query_arg(
                'redirect_to',
                $redirect,
                $url
            );
        }

        if ( $force_reauth ) {
            $url = add_query_arg(
                'reauth',
                '1',
                $url
            );
        }

        return $url;
    },
    10,
    3
);

But this code alone does not create the custom route or prevent direct requests to wp-login.php.

It only changes URLs generated through the corresponding WordPress API.

A login_url filter alone does not change the actual endpoint

This distinction is fundamental.

The:

login_url

filter changes generated URLs.

It does not automatically intercept a direct browser request to:

/wp-login.php

and it does not automatically make:

/team-access/

execute the WordPress login controller.

A complete implementation therefore needs two related systems:

1. Incoming request routing

2. WordPress-generated login URLs

Incoming request routing

The application needs to recognize:

/team-access/

as the custom authentication route.

That can be implemented through:

• WordPress routing;
• request interception;
• a dedicated authentication plugin;
• carefully designed web-server rules combined with application logic.

Generated URL handling

WordPress and plugins should also receive the custom URL when they ask WordPress for the login address.

Otherwise the site can become internally inconsistent:

Custom route works:
/team-access/

but WordPress still generates:
/wp-login.php

This is why a simple Apache or Nginx rewrite is not necessarily a complete WordPress solution.

Password recovery needs separate handling

A custom login system must not stop at normal authentication.

WordPress generates lost-password links through:

wp_lostpassword_url()

The official wp_lostpassword_url() documentation shows that WordPress normally constructs a URL based on:

wp-login.php?action=lostpassword

WordPress then applies the:

lostpassword_url

filter.

The official lostpassword_url documentation confirms that developers can modify the generated recovery URL.

A custom login implementation therefore needs to preserve flows such as:

/team-access/?action=lostpassword

or provide an equivalent route that still invokes WordPress’s password-recovery logic correctly.

Password reset emails must continue to work

The complete process is:

User selects Lost your password?
        ↓
WordPress accepts identifier
        ↓
reset key is generated
        ↓
email is sent
        ↓
user opens reset URL
        ↓
reset key is validated
        ↓
new password is created

Changing only the first page but breaking the reset URL sent by email produces a login system that appears functional until somebody actually forgets a password.

Test the entire password-recovery workflow after changing the login endpoint.

Logout URLs also point to wp-login.php

Logout has its own WordPress function:

wp_logout_url()

The official wp_logout_url() documentation shows that Core builds the logout URL from:

wp-login.php?action=logout

and protects logout with a WordPress nonce.

A typical generated URL therefore resembles:

/wp-login.php
?action=logout
&_wpnonce=...

The nonce is important because logout changes authentication state.

Do not break the nonce-protected logout flow

A custom URL system should preserve:

• the action=logout value;
• the logout nonce;
• the optional post-logout redirect;
• WordPress session invalidation.

Do not replace logout with a simple unauthenticated redirect that skips the normal WordPress session logic.

Generated Log In/Out links depend on these functions

WordPress also provides:

wp_loginout()

which uses the normal login or logout URL according to the current authentication state.

The official wp_loginout() documentation demonstrates why changing WordPress-generated URLs coherently is more reliable than replacing random links in HTML after they have already been generated.

wp-admin behavior must remain intentional

The login endpoint and the administration directory are related, but they are not the same thing.

/wp-login.php
→ authentication

/wp-admin/
→ administration interface

A visitor who is not authenticated and requests:

/wp-admin/

normally gets redirected to authentication.

After introducing a custom login URL, decide what the logged-out /wp-admin/ request should do.

A coherent implementation might produce:

/wp-admin/
    ↓
user logged out
    ↓
/team-access/
    ↓
authentication
    ↓
/wp-admin/

Do not globally block everything under wp-admin

The wp-admin directory contains application endpoints used beyond ordinary administration screens.

For example:

/wp-admin/admin-ajax.php

may be required by front-end functionality.

A security rule that blindly blocks every logged-out request containing:

/wp-admin/

can therefore damage unrelated site functionality.

This is another reason to use application-aware logic rather than treating URL strings as the entire WordPress security model.

Choose the custom login slug carefully

The custom path should be valid, memorable for authorized users and unlikely to collide with existing WordPress content.

Examples might include:

/staff-access/

/portal-entry/

/team-gateway/

rather than extremely obvious alternatives such as:

/login/

/admin-login/

/secure-login/

/wp-login-new/

Those predictable names can still be included in generic scanner wordlists.

A custom slug is not a password

There is no requirement to create something resembling:

/7hQp9xL2zA83-login/

and then treat it as a secret credential.

A less predictable route can reduce opportunistic traffic, but authentication must remain secure after someone learns the URL.

For the security implications specifically, see Does Hiding wp-login.php Actually Help Security?.

The broader defensive model is covered in WordPress Login Security Layers, Explained.

Avoid collisions with existing content

Before selecting:

/team-access/

check whether that path is already used by:

• a Page;
• a post-type archive;
• a taxonomy;
• a plugin endpoint;
• a multilingual route;
• an e-commerce account endpoint;
• a server-level redirect.

A collision can cause unpredictable routing behavior.

How TheOneWP Custom Login URL handles the change

TheOneWP Custom Login URL provides a dedicated interface for changing the public WordPress login endpoint without manually renaming Core files.

The goal of the module is to preserve WordPress authentication while changing how the login screen is publicly reached.

A configuration might change:

/wp-login.php

to:

/team-access/

while applying configured behavior to requests for the original login locations.

Changing the public route is different from redesigning the login page

These are separate concerns:

Custom Login URL
→ where authentication is reached

Custom Login Page
→ what authentication looks like

Changing colors, logos and form styling does not change the authentication endpoint.

Changing the endpoint does not automatically redesign the form.

Keeping those responsibilities separate makes the authentication system easier to maintain and troubleshoot.

Changing the login URL is also different from Redirect After Login

Redirect After Login controls where an authenticated user goes after successful login.

The sequence is:

Custom Login URL
        ↓
user reaches authentication
        ↓
credentials verified
        ↓
optional 2FA
        ↓
Redirect After Login
        ↓
destination

The login endpoint and the post-login destination therefore solve different problems.

Changing the login URL is not enough for login security

A custom WordPress login URL can reduce automated traffic aimed at predictable paths.

It does not replace direct authentication controls.

Consider an attacker who already knows:

/team-access/

At that point the custom route itself contributes little against password guessing.

The next layers need to do the work.

Rate-limit repeated attempts

If the threat is repeated password guessing, use a control designed for repeated password guessing.

The OWASP Authentication Cheat Sheet recommends login throttling and discusses account lockout controls.

See How to Limit Login Attempts in WordPress.

TheOneWP Access Manager adds login-attempt controls, temporary lockouts, IP rules and authentication logging.

Use two-factor authentication for privileged accounts

A custom login URL becomes much less relevant once an attacker has the correct password.

Two-factor authentication changes:

correct password
→ authenticated

into:

correct password
+
valid second factor
→ authenticated

The OWASP Multifactor Authentication Cheat Sheet recommends MFA as a major defense against password-related compromise.

TheOneWP Two-Factor Authentication adds a second authentication factor to WordPress accounts.

Monitor login activity

A hidden login URL does not make monitoring unnecessary.

Track both:

• failed attempts;
• successful logins.

A thousand rejected bots may matter less than one unexpected successful Administrator login.

See How to Monitor WordPress Login Attempts.

Other authentication surfaces remain separate

Changing wp-login.php does not automatically change every authentication mechanism available on a WordPress installation.

XML-RPC

The XML-RPC interface is available through:

/xmlrpc.php

when relevant functionality remains enabled.

If the site does not require XML-RPC authentication, review that surface independently.

See XML-RPC in WordPress, Explained and What Is XML-RPC in WordPress, and Why Disable It?.

Application Passwords

WordPress provides Application Passwords for programmatic authentication.

These credentials are designed for API access and cannot simply be treated as part of the interactive browser login page.

Changing the public login URL does not revoke or relocate Application Password authentication.

Front-end login forms

Membership, LMS and e-commerce plugins may expose their own authentication forms.

Examples can include:

• customer account pages;
• membership portals;
• course dashboards;
• custom front-end login forms;
• single sign-on systems.

Test each authentication path separately rather than assuming a custom wp-login.php route changes every form on the site.

Compatibility testing is essential

A login URL affects one of the most important recovery paths on a WordPress installation.

Test the change in staging before relying on it in production.

A practical testing matrix should include:

Normal login

• Open the custom URL while logged out.
• Authenticate with a valid account.
• Confirm the expected destination.
• Confirm invalid credentials are handled correctly.

Default wp-login.php

• Request /wp-login.php directly.
• Confirm the configured response occurs.
• Confirm the normal login form is not unintentionally exposed.

wp-admin while logged out

• Request /wp-admin/.
• Confirm authentication is routed through the custom login path.
• Confirm the intended admin destination is preserved.

Password recovery

• Select Lost your password?
• Submit a valid account identifier.
• Receive the recovery email.
• Open the reset link.
• Set a new password.
• Log in using the new password.

Logout

• Generate a normal WordPress logout link.
• Confirm the nonce remains valid.
• Confirm the session ends.
• Confirm any configured post-logout destination works.

Reauthentication

Some WordPress operations can require the user to authenticate again.

Because wp_login_url() supports:

$force_reauth

test flows that request fresh authentication rather than assuming an existing cookie is sufficient.

Check caching, CDN and server rules

Authentication pages should not be treated like ordinary cacheable public pages.

The official WordPress Logging In documentation specifically notes that wp-login.php and authenticated sessions should be excluded from page caching.

When a custom login route is introduced, update the corresponding infrastructure rules.

Check:

• WordPress page-cache plugins;
• server-level caching;
• Cloudflare or another CDN;
• reverse proxies;
• Nginx configuration;
• Apache rewrite rules;
• security middleware.

If:

/team-access/

becomes the login page, it should normally receive the same cache exclusions that previously applied to:

/wp-login.php

Avoid redirect loops

Incorrect routing can produce:

/wp-login.php
→ /team-access/
→ /wp-login.php
→ /team-access/
→ ...

The WordPress login documentation identifies conflicting site URLs, HTTPS settings and proxy configuration as common causes of redirect loops more generally.

When troubleshooting, review:

• WP_HOME;
• WP_SITEURL;
• HTTP versus HTTPS;
• proxy headers;
• CDN redirects;
• WordPress plugin redirects;
• web-server rules.

Use WordPress URL APIs in custom development

Custom themes and plugins should not generate login links by concatenating:

home_url() . '/wp-login.php'

or hardcoding:

https://example.com/wp-login.php

Instead, use WordPress APIs such as:

wp_login_url()
wp_logout_url()
wp_lostpassword_url()

This gives other plugins and authentication layers an opportunity to modify the appropriate URLs.

Example login link

$login_url = wp_login_url(
    get_permalink()
);

The current page can then be restored after successful authentication.

Example logout link

$logout_url = wp_logout_url(
    home_url( '/' )
);

WordPress handles the logout nonce and requested redirect correctly.

Example lost-password link

$lost_password_url =
    wp_lostpassword_url();

Using the appropriate APIs reduces assumptions about WordPress’s public authentication structure.

Do not confuse the login URL with login identifiers

Changing where the login form lives is separate from controlling which account identifier users may submit.

WordPress normally supports authentication using:

username
or
email address

A custom login URL does not change that behavior automatically.

See WordPress Login: Username vs. Email, Which Is More Secure?.

TheOneWP Restrict Login Identifier addresses that separate part of the authentication workflow.

Likewise, public identifier exposure should be reviewed separately using How Attackers Collect WordPress Usernames and Email Addresses.

A safe implementation strategy

Changing the WordPress login URL should be treated as an authentication-routing change rather than a cosmetic redirect.

A practical sequence is:

1. Back up the site before changing authentication routing.
2. Test the change in staging where possible.
3. Choose a custom slug that does not collide with existing content.
4. Keep the physical wp-login.php Core file unchanged.
5. Create the custom public authentication route.
6. Handle direct requests to the default login endpoint.
7. Update URLs generated through wp_login_url().
8. Preserve redirect_to destinations.
9. Preserve forced reauthentication behavior.
10. Preserve lost-password and reset-password workflows.
11. Preserve nonce-protected logout.
12. Handle logged-out /wp-admin/ requests appropriately.
13. Review front-end login forms.
14. Review XML-RPC and Application Passwords separately.
15. Exclude the custom login URL from page caching.
16. Test CDN and web-server routing.
17. Test normal login, recovery, reset, logout and reauthentication.
18. Keep rate limiting and 2FA active independently.
19. Monitor the new endpoint for abusive traffic.

If administrators can no longer reach the login page after deployment, restore access through the hosting environment, filesystem, WP-CLI or another trusted recovery method rather than randomly changing database values without understanding which layer created the route.

WordPress login URL checklist

• Do not rename wp-login.php.
• Do not modify WordPress Core files.
• Choose a unique custom login slug.
• Avoid collisions with Pages, archives and plugin endpoints.
• Use WordPress routing or a dedicated module for the custom endpoint.
• Handle generated login URLs as well as incoming requests.
• Preserve redirect_to.
• Preserve forced reauthentication.
• Test wp_login_url().
• Test wp_lostpassword_url().
• Test wp_logout_url().
• Test password-reset emails.
• Test logout nonces.
• Test logged-out access to /wp-admin/.
• Test front-end account forms.
• Check WooCommerce or membership integrations.
• Check multilingual routing.
• Exclude the custom login route from page caching.
• Check CDN and proxy rules.
• Check HTTPS behavior.
• Monitor for redirect loops.
• Keep rate limiting enabled.
• Use strong, unique passwords.
• Enable 2FA for privileged users.
• Monitor successful and failed authentication.
• Document the custom URL for authorized administrators.
• Maintain a recovery path in case the custom routing fails.

Related guides

• Does Hiding wp-login.php Actually Help Security?
• WordPress Login Security Layers, Explained
• A WordPress Login Hardening Checklist
• How to Limit Login Attempts in WordPress
• How to Monitor WordPress Login Attempts
• WordPress Brute-Force Attacks, Explained

Final recommendation

Changing the WordPress login URL is a useful hardening measure when it is implemented as part of the complete authentication workflow rather than as a crude redirect.

Keep the physical wp-login.php Core file unchanged. Create a different public route, update WordPress-generated login URLs and make sure password recovery, password reset, logout, reauthentication and logged-out wp-admin requests continue to work correctly.

Use WordPress functions such as wp_login_url(), wp_lostpassword_url() and wp_logout_url() in custom development so authentication URLs remain compatible with the site’s routing system.

TheOneWP Custom Login URL packages this responsibility into a dedicated module so administrators can configure a different public login route without renaming or editing WordPress Core files.

The security benefit should still be understood accurately. A custom login URL can reduce automated traffic against the predictable default endpoint, but it does not replace password security, request throttling or a second authentication factor.

Combine it with controls such as Access Manager for login-attempt and IP restrictions and Two-Factor Authentication for stronger protection of privileged accounts.

The safest implementation is therefore not merely “change /wp-login.php to another string.” It is to change the public entry point while preserving every authentication function WordPress expects behind it.