Someone told you that every WordPress site logs in at the same address, /wp-login.php or /wp-admin/, and that hackers know it. The suggested fix is to move the login page to an address only you know. A plugin will do it in a minute, and it sounds like an obvious win.
It is a reasonable idea, but it is often oversold. Changing the WordPress login URL does a few useful things and leaves the real risks exactly where they were. Here is an honest account of both, so you can decide whether it is worth doing on your site.
What changing the login URL actually does
A plugin such as WPS Hide Login lets you choose a new address for the login page, for example /team-entry/. After that, visiting /wp-login.php or /wp-admin/ while logged out no longer shows the login form. Depending on the plugin, the visitor gets a “not found” page or is sent somewhere else.
Nothing about your passwords, accounts or the way WordPress checks a login changes. The same form still sits behind the new address. It has just moved.
What it helps with
Less noise from simple bots
Many automated login attacks are simple. A script goes straight to /wp-login.php on thousands of sites and tries common passwords. If the page is not there, that script gives up on your site. Your security plugin’s log of failed logins gets much shorter, and you are more likely to notice the attempts that do matter.
Less load on the server
Each login attempt makes WordPress do real work, including checking the password against the database. On small shared hosting, a heavy wave of attempts can slow the whole site. Moving the login page means many of those requests hit a quick “not found” instead.
Fewer lockout emails
If you use a login limiter, a moved login page usually means far fewer “an address was locked out” notifications filling your inbox.
All of this is real, and on a busy or underpowered site it can be worthwhile. But notice that none of it is about stopping a determined attacker.
What it does not do
It is not a lock
This approach is sometimes called “security through obscurity”. The door is in a different place, but it opens exactly the same way. If someone finds the new address, they face the same password check as before. If your password is weak or has leaked from another site, a hidden login page will not save you.
Other doors stay open
WordPress accepts logins in more places than the login page.
- xmlrpc.php can accept username and password attempts, and many of them in one request. Changing the login URL does not affect it. Our post on XML-RPC explains whether you can turn it off safely.
- Front-end login forms. If you run WooCommerce, the My Account page has its own login form. Membership and course plugins often add one too. These log people in through WordPress directly, wherever the main login page has gone.
- Application passwords and the REST API allow other tools to log in on your behalf. They are useful, but they are not hidden by moving the login page.
The new address can leak
Your theme may have a “Log in” link in the footer. A password reset email may contain the address. A plugin might link to it, or a staff member might bookmark it on a shared computer. Once it is out, it is out, and bots that find it will start using it.
The things that actually stop break-ins
If the goal is to stop someone getting into your site, the order of priority is clear.
- A strong, unique password for every administrator, stored in a password manager.
- Two-factor authentication for every account that can change the site. Even a correctly guessed password is not enough on its own. Our guide to WordPress two-factor authentication shows how to set it up.
- A limit on login attempts, so an address that keeps getting it wrong is blocked for a while.
- Turning off or restricting XML-RPC if nothing on your site uses it.
- A firewall in front of the site that blocks known attack traffic before it reaches WordPress.
These are covered in detail in our post on WordPress brute-force attacks. Changing the login URL is a reasonable extra on top of them. It is never a replacement for any of them.
The downsides people forget
Locking yourself out
The usual problem is simple: someone forgets the new address. The plugin’s settings are inside the admin area you can no longer reach. The fix is to open the site files through your host’s file manager or FTP, find the plugin’s folder inside wp-content/plugins/, and rename it. WordPress then deactivates the plugin and the normal login address works again. It is easy once you know, but stressful at the wrong moment. If you are stuck in some other way, our guide to WordPress login problems may help.
Conflicts with other plugins and caching
Some plugins and themes assume the login page is at wp-login.php and build links to it. Caching can also store an old redirect. After you change the address, log out, clear any cache, and test logging in, logging out and resetting a password, ideally in a private browser window.
Confusion for the people who maintain the site
If a developer, a staff member or a maintenance provider needs to log in and does not know the new address, they will lose time or assume the site is broken. Write the new address down somewhere safe that the right people can find, such as your password manager.
So, should you do it?
It is worth considering if your security log is full of failed attempts, if login traffic is slowing a small hosting plan, or if you simply want fewer lockout notifications. It is not worth it if it means skipping two-factor authentication or a login limit because you feel “covered”.
If you do change it, choose an address that is not obvious (avoid /login/ or /admin/), record it in your password manager, and test the whole login and password-reset flow afterwards.
Getting the basics in place
If you are not sure which of these protections your site already has, it is quick to check. Our website security maintenance service includes a one-time audit and basic hardening from ₹1,999 onwards, covering logins, two-factor authentication and the other doors. Whether moving the login page is worth it for your site is part of that check.
Next in this series: What a Website Security Audit Actually Checks
