Move wp-login.php to a URL only you know
Custom Login URL replaces wp-login.php and direct wp-admin access with a slug you choose, and decides exactly what happens to anyone who still tries the old address.
- A custom slug for the login page, no plugin conflicts to manage.
- Direct wp-login.php and wp-admin requests get a 404, a redirect, or a custom page.
- Every WordPress-generated login link updates automatically, nothing breaks.
- Not a password replacement, but removes nearly all automated login traffic.
Login URL slug
Pick a secret path. Avoid "login", "admin" and other obvious words.
If wp-login.php is accessed directly
What does Custom Login URL do?
When the custom_login_url module is active, TOWP_Custom_Login_Url intercepts every request on init at priority 1, before WordPress's own auth_redirect() can fire. A request for the chosen slug transparently loads the real wp-login.php; however, a request for wp-login.php itself, or for wp-admin from a logged-out visitor, gets the configured response instead: a normal 404, a redirect to any URL, or a custom HTML page. Because the module also rewrites login_url, site_url, network_site_url and wp_redirect wherever WordPress builds a login link internally, password resets, logout links and redirect-after-login all keep pointing at the new address automatically.
Nearly every WordPress attack starts at the same URL
Automated login traffic doesn't need to search for anything, since the target address is identical on virtually every WordPress site.
wp-login.php is the same on every install
Automated login attempts don't need to guess anything; wp-login.php and wp-admin sit at the same predictable address on virtually every WordPress site.
A strong password doesn't stop the requests from arriving
Even a login that never succeeds still consumes server resources and fills logs with noise, request after request, from bots that never stop trying.
Move the door, then decide what's behind the old one
The module relocates the login form to a slug you choose and gives the original address a deliberate, configurable response instead of leaving it open.
A slug only you choose
The login page moves to a custom path, transparently serving the real wp-login.php without changing anything about how login itself works.
A real response for the old address
Direct requests to wp-login.php or wp-admin get a 404, a redirect, or a custom HTML page, whichever fits.
Every internal link stays correct
Password resets, logout links and redirect-after-login all continue to work, because the module rewrites them automatically.
A complete relocation, not just a redirect
Every capability below is present in the supplied PHP class and its settings registration.
A custom slug for login
The chosen slug transparently loads wp-login.php on init, before WordPress's own redirect logic ever runs.
wp-login.php and wp-admin both covered
Direct requests to either address get intercepted for logged-out visitors, with AJAX and admin-post requests exempted so the frontend keeps working.
404, redirect, or custom HTML
A blocked request can render the theme's real 404 page, redirect anywhere, or show a full HTML page written in settings.
Every login link rewritten
login_url, site_url, network_site_url and wp_redirect all get filtered, so anything WordPress builds internally points at the new slug.
A genuine theme 404, not a fake page
The 404 response redirects to a guaranteed-nonexistent post ID, so WordPress renders the active theme's actual 404 template.
admin-ajax.php and admin-post.php exempted
These two endpoints stay reachable even for logged-out visitors, since many frontend features depend on them.
Where relocating login helps most
The module supports any site tired of automated noise at a predictable address.
Reducing automated login noise
Cut the volume of automated requests hitting wp-login.php, since most never even discover the new address.
Sites already hardened elsewhere
Pair a relocated login page with strong passwords and two-factor authentication as one more layer, not a replacement for either.
Cleaner security logs
Once most automated noise disappears, whatever remains in the logs is small enough to actually review.
Less noise, nothing broken
The module combines relocation, response control and full link rewriting in one setting.
One early check, fewer requests later
The verified implementation acts before most of WordPress's own request handling even starts.
One early check per request
The interception happens once, at init priority 1, before most of WordPress's own request handling begins.
Fewer requests reach PHP at all
Once the old address stops attracting traffic, fewer full WordPress bootstraps happen for requests that were never going to succeed.
A lightweight regex check
Matching the request path against wp-login.php and wp-admin is a simple, fast pattern check, not a database query.
Fires early, stays honest about its limits
The code acts before WordPress's own redirect logic and is explicit about what it does and doesn't protect against.
Fires before WordPress's own redirect
Because the intercept runs on init at priority 1, it happens before auth_redirect() can send a logged-out visitor toward the real login page.
Frontend AJAX stays exempt
admin-ajax.php and admin-post.php are explicitly excluded from the block, so legitimate frontend functionality doesn't break.
Redirect targets are validated
A configured redirect URL passes through esc_url_raw() and wp_safe_redirect(), the same safe-redirect pattern WordPress uses internally.
Not a substitute for a strong password
The module is explicit about its own limits: it reduces automated traffic, but it doesn't make any individual password or account stronger.
Built around native WordPress URL and request hooks
The supplied code integrates through APIs present in WordPress core. No compatibility claim beyond the verified implementation is assumed.
init, priority 1
The intercept runs early enough to act before WordPress's own login-redirect logic, on every request.
login_url, site_url, network_site_url
All three core filters get rewritten so anything WordPress itself generates points at the new login slug.
wp_redirect filter
Any redirect WordPress issues toward wp-login.php gets rewritten to the custom slug instead.
TheOneWP versus common alternatives
Compare the verified Custom Login URL implementation with a typical single-purpose login-hiding plugin.
| Capability | TheOneWP Custom Login URL | Other common solutions |
|---|---|---|
| Moving the login page | A custom slug, transparently serving the real wp-login.php | Usually requires a dedicated single-purpose plugin |
| Response to the old address | Choice of 404, redirect, or custom HTML page | Often just a blank error or a fixed redirect |
| Internal link rewriting | login_url, site_url, network_site_url and wp_redirect all covered | May leave some WordPress-generated links pointing at the old address |
| wp-admin protection | Direct wp-admin access blocked for logged-out visitors too | Frequently limited to wp-login.php only |
| Administration | One slug field and one behavior choice in TheOneWP settings | Requires managing a separate plugin |
Relocate the login page in four steps
Save the new address before the old one stops working, then confirm the configured behavior.
Enable Custom Login URL
Activate the module from the TheOneWP Login settings tab.
Choose a slug
Pick a path that isn't an obvious word like login or admin; save the setting.
Choose what happens to the old address
Select 404, redirect, or a custom HTML page for anyone who still requests wp-login.php or wp-admin directly.
Bookmark the new address and test
Save the new login URL somewhere safe, then confirm the old address returns exactly the response you configured.
Relocate the login page without locking yourself out
A relocated login page is only useful if the new address is saved somewhere reliable.
Bookmark the new URL before saving
Save the new login address somewhere accessible immediately after changing the slug, since the old one will stop working right away.
Avoid obvious words in the slug
A slug like login or admin defeats much of the purpose, so pick something that isn't an easy first guess.
Pair it with strong authentication
This module reduces traffic to the old address; it doesn't replace a strong password or two-factor authentication.
Test the chosen behavior once
Visit the old wp-login.php address in a private window after configuring it, to confirm the 404, redirect or custom page behaves as expected.
Avoid assumptions that cause lockouts or confusion
The module is powerful but has a specific, limited scope worth understanding clearly.
Treating it as a password replacement
Moving the login URL cuts automated traffic; it doesn't make an individual account any harder to compromise once someone finds the new address.
Forgetting to save the new address
Once the slug changes, the old wp-login.php stops working immediately, so the new address needs saving somewhere before that happens.
Writing an incomplete custom HTML template
The custom template behavior expects a full HTML page; a partial fragment can render incorrectly in a visitor's browser.
Custom Login URL FAQ
These answers come directly from the verified class and its settings registration.
What does Custom Login URL do?
It replaces wp-login.php and direct wp-admin access with a slug you choose, and applies a configurable response, 404, redirect, or custom HTML, to anyone who still requests the old address.
Does this make my password stronger?
No. The module is explicit that it doesn't strengthen any individual password; it reduces the volume of automated traffic that reaches the login form at all.
What happens if someone visits the old wp-login.php address?
They receive whichever response is configured: a normal 404 rendered by the active theme, a redirect to any URL, or a custom HTML page.
Does moving the login URL break password reset or logout links?
No. The module rewrites WordPress's own login_url, site_url, network_site_url and wp_redirect calls, so internal links keep pointing at the new address automatically.
Is wp-admin also protected, or just wp-login.php?
Both. Direct access to wp-admin gets blocked for logged-out visitors the same way wp-login.php is, with admin-ajax.php and admin-post.php exempted.
Will this break AJAX functionality on the front end?
No. admin-ajax.php and admin-post.php are explicitly excluded from the block, since many frontend features depend on them.
What does the "Show 404" option actually do?
It redirects the request to a post ID that can never exist, so WordPress renders the active theme's genuine 404 page rather than a generic error.
Can I write my own HTML page for the old address?
Yes. The custom template option accepts full HTML, including a {home_url} placeholder that gets replaced with the site's homepage URL.
What happens if I forget my new login slug?
Since the old wp-login.php address is blocked, access to the site's own database or files becomes necessary to check or reset the stored slug value.
When does the redirect to the custom slug happen?
On the init hook at priority 1, early enough to run before WordPress's own auth_redirect() function can send a visitor toward the default login page.
Stop letting bots find your login page.Move it somewhere only you know.
Use Custom Login URL to relocate wp-login.php and wp-admin behind a custom slug, with a real response for anyone who still tries the old address.