Renaming /wp-login.php to /my-secret-login moves the login form. It does not change what answers at the old path, what your plugin folders advertise, or what your home page tells a scanner about the stack underneath. A login-URL renamer solves one of those problems. The reader searching “hide wp-admin” usually wants all three solved, and the gap between the two is where most of the confusion lives.
What a login-URL renamer actually changes
A plugin like WPS Hide Login does one thing, and does it well: it changes the slug your login form responds to, and it stops the default /wp-login.php and /wp-admin from serving that form to logged-out visitors. For a solo blog whose only real problem is the password-guessing bot hammering the default form, that single change cuts the noise meaningfully. It is free, it is light, and it does not pretend to be more than it is. If that is the whole problem you have, you can stop reading here.
The reason “hide wp-admin” keeps coming up on Quora and the support forums, though, is that the people asking it have usually already done the rename and noticed it didn’t do what they hoped. The bots kept coming. The site still showed up in BuiltWith as WordPress. Something was still leaking. Three somethings, usually.
Leak one: the old path still costs you a full WordPress boot
When a login-URL renamer “blocks” the default path, the request to /wp-login.php still loads WordPress. PHP starts, the plugin stack initializes, and only then does the renamer plugin decide to return a 404 to the logged-out visitor. The visitor sees a 404. Your server still did the work of booting WordPress to produce it.
On a quiet site nobody notices. On a site taking tens of thousands of probes a day, that is tens of thousands of full WordPress boots spent generating 404s. The attempt count in your security dashboard might look great. The CPU graph tells a different story.
The architectural alternative is to reject the request at the rewrite layer, in the Apache .htaccess or nginx config, before PHP is ever invoked. The probe to the old path returns 404 from the server, WordPress never loads, and the request costs you almost nothing. Same 404 the visitor sees. A very different cost on your side, and a different security posture, because anything that would have exploited a PHP-level flaw never reaches PHP.
Leak two: your plugin and theme folders still announce the stack
Change the login URL and a bot that can’t find the form does not give up on your site. It pivots. The next cheap move in the script is to fingerprint what you run, because a known-vulnerable plugin is a better door than a guessed password.
That fingerprinting reads the paths your own HTML hands over. /wp-content/plugins/woocommerce/, /wp-content/plugins/elementor/, the ?ver= strings on your enqueued scripts, the readme.txt sitting in each plugin folder. None of that is behind the login. It is in the page source of your home page. Patchstack counted 11,334 WordPress vulnerabilities disclosed in 2025, and 91% of them live in plugins rather than core. A scanner that can read your plugin inventory off the page source can match that inventory against the disclosure list in milliseconds. Renaming the login form does nothing to this, because the login form was never where the inventory leaked.
Closing this leak means relocating the plugin and theme paths and stripping the version strings, so the same scanner reads asset URLs that carry no wp-content, no plugin slug, and no version to match. The vulnerability scan finds no matching signature. That is a different operation from renaming a login URL, and most single-feature renamers don’t attempt it.
Leak three: REST, AJAX, and the generator tag keep talking
Even with the login form moved and the plugin paths changed, WordPress has a few other mouths. The wp-json REST API answers at its canonical route and will, by default, enumerate your usernames through /wp-json/wp/v2/users. admin-ajax.php sits at its default path. The <meta name="generator" content="WordPress 6.x"> tag and the RSD link in your <head> announce the CMS by name to anything that reads HTML. CMS detectors like Wappalyzer and BuiltWith key on exactly these signals.
A login-URL renamer touches none of them. To a fingerprinting tool, a site with a renamed login but a default REST route, a default generator tag, and wp-content in its asset URLs is still, unambiguously, WordPress. The “hide wp-admin” goal the reader started with is only partly met.
The honest comparison
Here is the same set of capabilities across a single-purpose login-URL renamer and a path-and-fingerprint reconfiguration layer. The renamer wins the row that matters to it: footprint. It is the right tool when the login slug is genuinely the only thing you need to change.
| Capability | Login-URL renamer (e.g. WPS Hide Login) | Path + fingerprint layer (e.g. WP Ghost) |
|---|---|---|
| Changes the login slug | Yes | Yes |
| Old path rejected before PHP loads (rewrite-layer 404) | No – WordPress boots, then 404s | Yes |
Relocates wp-content / wp-includes / uploads | No | Yes |
| Relocates plugin and theme paths (fingerprint) | No | Yes |
Removes generator tag, ?ver=, RSD from output | No | Yes |
Restricts/relocates wp-json and admin-ajax.php | No | Limits REST enumeration, relocates routes |
| Footprint | Very light, single-purpose | Heavier, broad config surface |
| Free tier | Yes | Yes |
All-in-One Security sits in between: it renames the login URL and adds a .htaccess-based firewall, but it does less with wp-content, plugin paths, theme paths, and the HTML fingerprint than a dedicated path layer does. That is the honest read from running these on real sites, not a knock on AIOS, which is a reasonable free baseline for a blog.
What we actually run, and why it isn’t a renamer
Across our WordPress properties at Squirrly the prevention layer is WP Ghost’s Paths Security, which changes the 30-plus default paths and rejects probes to the old ones at the rewrite layer, paired with its theme-and-plugin fingerprint removal so the page source stops handing over the stack. That sits alongside Wordfence for the malware scan and live traffic view, and Cloudflare in front for network-level noise. WP Ghost is not a Wordfence replacement and it is not a renamer with extra steps. It is the layer that changes what answers at the default paths and what the HTML reveals, which is a different job from both scanning files and renaming a single URL.
The reason this matters for the “is this just obscurity” reflex: the request to the old path returns 404 before any application code runs, and the fingerprint a scanner reads is genuinely not in the output anymore. Nothing is sitting at the original location under a different name. The response surface changed. That is the distinction between relocating an endpoint and hiding one.
Skip the path layer if
If your site is currently infected, a path change does nothing for you. The attacker is already in the file system, past the front door. Run a scanner first. Wordfence or MalCare to find and clean the infection, then think about prevention.
If you run a single low-traffic blog and the only symptom is brute-force noise on the login form, a free login-URL renamer plus 2FA genuinely may be all you need. Don’t add a broad reconfiguration layer to solve a problem you don’t have.
And if you manage a portfolio, or run WooCommerce, or have ever watched a scanner pull your plugin list off the page source and try a known CVE within the hour, that is when the difference between renaming the form and reconfiguring the paths stops being academic.
FAQ
Is renaming wp-login.php enough to stop brute-force attacks?
It stops the bots that only probe the default path, which is most of the cheap automated traffic. It does not stop a bot that fingerprints your plugins and tries a known exploit instead of guessing the password. Pair the path change with rate limiting and 2FA so the login flow is protected even if the new URL is discovered.
Does WPS Hide Login change the wp-admin path too?
It stops the default /wp-admin from serving the login form to logged-out users and redirects them, but it does not relocate the admin path architecture, the plugin and theme paths, or the REST and AJAX endpoints. The site still fingerprints as WordPress through those signals.
Why does my site still show as WordPress in BuiltWith after I renamed the login?
Because BuiltWith and Wappalyzer don’t read your login URL. They read the generator meta tag, the /wp-content/ paths in your asset URLs, the ?ver= strings, and the wp-json REST link in your <head>. Renaming the login touches none of those. Removing the WordPress signature means stripping those signals from the page output, which a login renamer doesn’t do.
Is changing default WordPress paths just security through obscurity?
The request to the old path returns 404 at the rewrite layer before PHP loads, and the fingerprint a scanner relies on is removed from output, not relabeled. The login flow underneath still has its rate limiting, 2FA, and password hashing doing the same work. It is one control in a layered stack, not a replacement for any of them, which is the opposite of relying on a single secret mechanism.
Will relocating wp-content and plugin paths break my caching plugin or site?
Modern caching plugins (WP Rocket, LiteSpeed Cache) and Cloudflare are tested-compatible with path changes. The usual thing to watch is legacy JavaScript that hard-codes /wp-admin/admin-ajax.php; code that uses wp_localize_script picks up the new path automatically. Test on staging, then watch the logs for a week before trusting it on production.
Do I still need a firewall and a scanner if I change the paths?
Yes. Path changes reduce who finds you and what they can fingerprint. They do not scan files for malware, and they do not patch a vulnerable plugin once a determined attacker targets you directly. Keep a scanner (Wordfence, MalCare) for detection and keep your plugins updated. The path layer buys time; it doesn’t replace patching.