Checked for accuracy and updated on August 13, 2026.
Every WordPress site ships with the same login URL by default. Anyone who knows WordPress — which includes every bot and brute-force tool targeting it — knows exactly where to go: add /wp-login.php to the domain and start trying combinations. Changing that URL to something non-standard doesn’t fix every security problem, but it eliminates the constant low-level noise of automated login attempts hitting a predictable address, and it takes about two minutes to set up.
Setting It Up
WPS Hide Login handles this cleanly — 2 million+ active installs, actively maintained. Install and activate it from Plugins → Add New, then go to Settings → General and scroll to the WPS Hide Login section. Enter a memorable but non-obvious slug (not login, admin, or anything close to the original), save, and the default /wp-login.php and /wp-admin/ addresses become inaccessible to anyone not already logged in — requests to them 404 or redirect instead.
Open a new tab and confirm the new URL loads before closing anything, then bookmark it — this is genuinely the most common way people lock themselves out, since the old URL stops working the moment you save. If that happens, recovery means deactivating the plugin via FTP or the hosting file manager. Trigger a password reset once to confirm the email link still resolves correctly, and if other people log in to the site — editors, clients, developers — send them the new URL before they go looking for the old one. The plugin also supports multisite, with a network-wide default login URL settable from the network admin.
The Gap This Doesn’t Close: WordPress’s Own REST API
This is the part most “hide your login” guides skip, and it undercuts the whole point if left open: WordPress’s REST API exposes a users endpoint — /wp-json/wp/v2/users — that, by default, hands back every author’s display name, numeric ID, and a slug that on most sites is the exact string someone types to log in. No authentication required, no special access needed, documented behaviour that ships on by default. An attacker doesn’t need to guess a username if the site is quietly listing them at a public URL, and moving the login page does nothing to close it — it’s a completely separate endpoint.
WordPress core (since 4.7.1) already limits some of this by scoping REST exposure to post types explicitly configured for it, but the users endpoint itself still needs deliberate closing on most sites: a security plugin like Wordfence or Solid Security can require authentication for it, or a small custom function can make it return a 401 instead of the author list. Worth checking directly — visit yourdomain.com/wp-json/wp/v2/users in a browser; if it returns a JSON list of names and IDs instead of an error, that’s real, currently-live exposure worth closing alongside the login-URL change, not after it.
How Far to Take This
WPS Hide Login is the right tool for a quick, lightweight change and nothing else — it does one thing reliably. For a broader set of login protections — brute-force limiting, two-factor authentication, IP blocking, and REST API hardening in one place — a heavier plugin like Solid Security or Wordfence covers all of it alongside login-page renaming, worth it for sites handling payments, sensitive user data, or multiple contributors. For a standard informational or small business site, WPS Hide Login plus a strong password, 2FA, and a closed REST API users endpoint is a genuinely complete picture — see the guide to securing a new website for how these pieces fit together into a fuller checklist.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.