Why renaming wp-login.php isn’t enough to secure your WordPress site

Security best practices often recommend renaming your WordPress login URL to deter brute-force attacks, but this solution only scratches the surface. While changing /wp-login.php to something like /my-login can reduce automated login attempts, it does little to obscure the underlying WordPress stack from determined attackers. Here’s what remains exposed—and how to fix it.

The illusion of security: what a login rename actually changes

A common misconception is that altering the login URL transforms your site into a less detectable target. However, this approach only solves one small part of the problem. Attackers don’t rely solely on the default login path to identify WordPress installations. Instead, they look for secondary patterns that reveal your CMS, plugins, and themes—even after the login form is moved.

• The old login path still triggers a full WordPress boot before returning a 404.
• Plugin and theme directories remain visible in your site’s source code.
• REST API endpoints and generator tags continue broadcasting WordPress-specific signals.

These persistent traces make it easy for bots to fingerprint your site, regardless of a renamed login URL.

The three hidden leaks in a standard WordPress setup

Even with a plugin like WPS Hide Login active, three critical security gaps persist. Addressing them requires a more comprehensive approach than simply changing a URL.

Leak 1: unnecessary server load from default login paths

When attackers probe /wp-login.php, your server still loads WordPress before rejecting the request. This means PHP processes initialize, plugins load, and database queries may run—all for a 404 response that could have been served instantly at the server level. On high-traffic sites, this creates unnecessary CPU strain.

To block these probes efficiently, configure your web server to reject requests to the old login path before PHP even loads:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/(wp-login\.php|wp-admin) [NC]
  RewriteCond %{HTTP_COOKIE} !wordpress_logged_in [NC]
  RewriteRule .* - [R=404,L]
</IfModule>

location ~* ^/(wp-login\.php|wp-admin) {
  if ($http_cookie !~* "wordpress_logged_in") {
    return 404;
  }
}

This ensures the 404 response comes from the server, not WordPress, reducing resource waste.

Leak 2: exposed plugin and theme fingerprints

Attackers don’t stop at the login page. They scan your site for clues about your stack, including plugin directories and theme files. Even if your login URL is hidden, these paths remain visible in your site’s HTML source:

• /wp-content/plugins/woocommerce/
• /wp-content/themes/your-theme/style.css
• /wp-content/plugins/plugin-name/readme.txt (version disclosure)

A 2025 Patchstack report found 11,334 WordPress vulnerabilities, 91% of which originated in plugins. Attackers match these paths against known vulnerabilities in milliseconds. To close this gap, relocate plugin and theme directories and remove version strings from public assets.

Leak 3: REST API and generator tags broadcasting your stack

WordPress emits several identifiable signals that persist even after a login rename:

• A <meta> tag declaring the WordPress version
• REST API links in the page source
• Default paths for wp-json and admin-ajax.php

Tools like Wappalyzer and BuiltWith detect WordPress installations using these signals. Disabling them requires deeper configuration changes, not just a plugin switch.

The trade-offs of a login renamer vs. a full security strategy

Login URL renamers like WPS Hide Login excel at simplicity but fall short in comprehensive security. Compare their capabilities against a more robust approach:

| Capability | Login-URL Renamer | Full Security Stack | |------------|-------------------|--------------------| | Changes login slug | Yes | Yes | | Rejects old login path pre-PHP | No | Yes | | Relocates plugin/theme paths | No | Yes | | Removes version strings and generator tags | No | Yes | | Restricts REST API username enumeration | No | Yes | | Footprint | Minimal | Broader configuration | | Free tier available | Yes | Often paid |

A login renamer is a lightweight first step, but sites needing stronger protection should consider integrating server-level firewalls, asset relocation, and REST API hardening.

How to verify what you’ve actually secured

After making changes, test your site’s visibility using these commands in a clean, incognito browser session (logged out):

# Check for generator tags or REST API links
curl -s  | grep -iE 'generator|api.w.org|/wp-json'

# Verify old login path returns 404 without PHP processing
curl -s -o /dev/null -w "%{http_code}\n" 

# Test REST API username enumeration
curl -s 

• If the first command returns matches, your stack fingerprint is still visible.
• If the second returns 200 (or a slow 404), PHP is still booting for the old login path.
• If the third returns a list of users, enumeration remains open.

Renaming the login URL is a useful tactic, but true security demands addressing the broader footprint of your WordPress installation.