Skip to main content

Custom Login Path

Custom Login Path​

Last verified: 2026-07-08

Awthy can move the normal WordPress login form from wp-login.php to a custom site-local path. This reduces noise from automated requests that hard-code the default login URL, but it is not a secret or invisibility feature.

Not hidden​

Do not describe a custom login path as hidden. The active slug can be exposed by rewritten email links, browser history, bookmarks, support messages, theme output, plugins that call wp_login_url(), server logs, or any page that intentionally links to login.

Use the feature as a noise-reduction and workflow-control tool, not as the main account-security boundary. Passwords, two-factor authentication, passkeys, recovery, brute-force protection, and audit logging still matter.

Verify before enable​

Awthy uses a verify-before-enable workflow:

  1. Enter the new login-path slug.
  2. Send or copy the test link.
  3. Open the test link in a private window or another browser profile.
  4. Confirm the verification state in WordPress.
  5. Apply the custom path only after the test link works and administrators have saved the new address.

Do not apply a custom login path during an incident or rollout unless at least one administrator has confirmed the new link works outside the current browser session.

If you choose to email the new login link to administrators, treat that email as operational guidance, not a secret. The link may be forwarded, archived, indexed by mail search, or retained in backups.

Recovery options​

If administrators are locked out because the custom path was misconfigured or forgotten, define this constant in wp-config.php to restore wp-login.php:

define( 'AWTHY_DISABLE_LOGIN_PATH', true );

Server operators can also use WP-CLI:

wp awthy login-path disable

Remove the constant after confirming the login path is disabled or corrected; otherwise the recovery bypass remains active.

Multisite limitation​

Awthy does not support custom login paths on WordPress multisite. Multisite login routing, network admin URLs, and subsite behavior create too many ways to break legitimate access in v1.

Known conflicts​

Check these before enabling the feature:

  • Jetpack SSO or Jetpack Protect flows that hard-code wp-login.php.
  • Other hide-login plugins, especially WPS Hide Login or equivalent rewrites.
  • Host WAF rules or page-cache exclusions tied to wp-login.php.
  • Security plugins that intercept login requests before Awthy.
  • Hard-coded login URLs in emails, menus, theme templates, or support macros.

Rollback steps​

  1. Use AWTHY_DISABLE_LOGIN_PATH or wp awthy login-path disable.
  2. Confirm wp-login.php works in a private browser window.
  3. Remove or correct links to the broken custom path.
  4. Disable conflicting rewrite/security plugins before trying again.
  5. Re-enable only after a fresh verify-before-enable test passes.
Last updated on