Security May 7, 2026

Hiding the WordPress login URL: when it helps and when it does not

Replacing /wp-login.php with a random slug drops 99% of log noise. A complementary layer to strong passwords and 2FA.

The standard WordPress login URL is /wp-login.php (with /wp-admin redirecting to it). It is the first thing every bot probes. Replacing it with a random slug is classic security through obscurity - not a substitute for strong passwords and 2FA, but it removes 99% of log noise and reduces server load.

Why this matters

A typical WordPress site on shared hosting receives between 5,000 and 50,000 automated login attempts per month from bots hammering /wp-login.php. Every one of those requests boots PHP and WordPress, consuming memory and CPU. In extreme cases the host suspends the account for 'high resource usage'. Moving the login to /portal-7q3k means bots hit a static 404 that costs almost nothing. The logs become readable: instead of thousands of 'failed login from' lines hiding the one important IP, you see only real attempts. It also removes the first step of any targeted attack - a bot that cannot find the login URL cannot even start guessing passwords. Combined with 2FA and rate limiting, the probability of compromise drops dramatically.

How to detect

The audit issues a GET to https://example.com/wp-login.php - a 200 with a login form means the URL is exposed. Manually: open the URL in a private window. If you see the standard login page, it is exposed. /wp-admin should redirect to the new login URL (if you have one configured) or return 404.

How to fix

  1. In RankPlus's scan optimisation page enable 'Custom login URL', or install 'WPS Hide Login' (free, popular).
  2. Pick an unguessable slug: do not pick 'login', 'admin', 'wp', 'signin', the company name or the domain name. Do pick a random word or combination like 'portal-7q3k', 'access-x9m2', 'enter-h3p7'.
  3. Save the new URL in a password manager alongside the credentials. This is critical - there is no built-in recovery if you forget.
  4. Sign out and back in via the new URL to verify it works.
  5. Visit /wp-login.php and /wp-admin/ while signed out - both should return 404 (or redirect to the home page). If not, the plugin is not catching the path.
  6. Combine with brute-force protection (Wordfence) and 2FA for admins. URL hiding is a first layer, not the only one.
  7. If you have REST API endpoints used by other plugins, confirm they are not blocked (the plugin usually handles this).

Common mistakes

Do not forget the URL! This is the most serious mistake - an admin who does not store the new URL in a password manager can end up locked out. If that happens, the rescue: FTP into wp-content/plugins/, rename the folder of the URL-hiding plugin to 'wps-hide-login_disabled', and /wp-login.php returns. Do not pick a predictable slug - 'admin2' is not better than 'admin'. Do not rely on URL hiding alone - an attacker who Google-Dorks the new URL (because another site links to your new login) bypasses the protection. Do not forget to update every automation that uses the login URL - backup plugins that connect to the site, monitoring services, and so on.

Verifying the fix

Open https://example.com/wp-login.php in a private window - should be 404. Same for /wp-admin/. The new URL should display the login form. Compare server logs after a week: before the change, 1000+ login attempts per day; after, only a handful.

Tip: Do not forget the URL. Store it in at least two places (password manager + an encrypted document). If you forget, the only path back is FTP into the plugin folder and renaming it.
More in this category ← Back to all docs