How to Use WPS Hide Login to Protect the WordPress Admin Page

The default WordPress login URLs — yoursite.com/wp-admin and yoursite.com/wp-login.php — are publicly known, making them the first target in automated brute force campaigns and credential-stuffing attacks. WPS Hide Login is a lightweight WordPress plugin that replaces these predictable endpoints with a custom URL of your choosing, so unauthenticated requests to the original paths are silently redirected rather than served a login form.

This guide covers the complete installation, configuration, recovery procedure, and layered security strategy for WPS Hide Login — including technical edge cases that most tutorials omit.

Why Changing the Default Login URL Matters

Security through obscurity is not a complete defense on its own, but it is a legitimate and measurable first layer. When bots cannot find a login form, they cannot submit credentials against it. Studies from hosting-level firewall logs consistently show that /wp-login.php and /wp-admin account for the overwhelming majority of WordPress HTTP 403/429 events — often thousands of requests per day on even modest sites.

Changing the login URL eliminates this attack surface at zero performance cost. Combined with strong passwords, two-factor authentication, and a web application firewall, it significantly raises the effort required for a successful intrusion.

If you are running WordPress on a VPS Hosting environment, you can reinforce this at the server level with Nginx deny directives or Apache .htaccess rules in addition to the plugin — a combination covered later in this article.

Security Layers: WPS Hide Login vs. Alternative Approaches

Before diving into the setup, it helps to understand where WPS Hide Login sits relative to other hardening techniques.

WPS Hide Login is most effective when combined with at least one of the server-level controls in this table. It is not a substitute for strong credentials or a WAF, but it eliminates the low-hanging fruit that automated tools rely on.

Step 1: Install the WPS Hide Login Plugin

1. Log into your WordPress dashboard.
2. Navigate to Plugins > Add New.
3. In the search field, type WPS Hide Login.
4. Click Install Now next to the plugin published by WPServeur, nofearinc, and Beee.
5. Click Activate once installation completes.

Verification tip: After activation, confirm the plugin is listed as active under Plugins > Installed Plugins. The plugin adds no visible front-end changes at this stage — configuration happens entirely in the settings panel.

Step 2: Configure the Plugin

After activation, the plugin injects its settings at the bottom of the Settings > General page rather than creating a dedicated menu item. This is intentional — it keeps the configuration low-profile.

1. Go to Settings > General in your WordPress dashboard.
2. Scroll to the WPS Hide Login section near the bottom of the page.

Choosing a Strong Login URL

In the Login URL field, replace the default value with a custom path. Treat this like a secondary password: it should be non-dictionary, non-obvious, and not derived from your brand name.

Weak choices to avoid:

• /mylogin
• /admin-login
• /wp-login-new
• /login

Better choices:

• A random alphanumeric string: /a7f3kx91
• A passphrase-style path: /morning-circuit-deploy
• A path that mimics a legitimate page: /resources/team-portal

The URL is case-sensitive on Linux-based servers (which includes virtually all Dedicated Servers and VPS instances running Ubuntu or CentOS). /MyLogin and /mylogin are treated as different paths.

Configuring the Redirection URL

The Redirection URL field determines where users are sent when they attempt to access /wp-login.php or /wp-admin directly. Choose this deliberately:

• Redirect to your homepage (/): Neutral, reveals nothing to the attacker.
• Redirect to a custom 404 page: Signals that the resource does not exist, which is technically accurate and discourages further probing.
• Redirect to a honeypot page: Advanced technique — redirect to a page that logs the visitor's IP for analysis.

Avoid redirecting to a page that contains a visible "Access Denied" message, as this confirms to an attacker that a login page exists somewhere on the site.

1. Click Save Changes.

Step 3: Log In Using Your New Login URL

After saving, the original login endpoints are deactivated immediately. Any request to /wp-login.php or /wp-admin will redirect to the URL you specified.

To access your dashboard:

1. Navigate to https://yoursite.com/your-custom-path in your browser.
2. Enter your WordPress credentials as normal.
3. The dashboard loads without any visible difference in behavior.

Important: WordPress's built-in "Lost your password?" and user registration flows also use /wp-login.php internally. WPS Hide Login handles these gracefully by rewriting the relevant form action URLs — but verify this works in your specific theme and plugin stack before deploying to production.

Step 4: Bookmark the New Login URL Immediately

This step is operationally critical. Bookmark the new URL in your browser and store it in your password manager alongside your credentials. If you manage multiple WordPress installations, document the custom URL in your internal runbook or secrets vault.

Do not rely on memory. The recovery process for a forgotten custom login URL requires file system access, which is disruptive in a production environment.

Step 5: Test All Redirect Paths

Testing should be systematic. Open a private/incognito browser window (to avoid cached session data) and verify each of the following:

• https://yoursite.com/wp-login.php — should redirect to your specified URL, not show a login form.
• https://yoursite.com/wp-admin — should redirect, not show a login form or dashboard.
• https://yoursite.com/wp-admin/admin-ajax.php — this endpoint must remain accessible; WPS Hide Login correctly exempts it from redirection to avoid breaking AJAX-dependent plugins.
• https://yoursite.com/your-custom-path — should display the WordPress login form correctly.
• Password reset email links — trigger a password reset and confirm the link in the email routes through your custom login path, not the original one.

If admin-ajax.php is blocked, you will see broken front-end functionality in themes and plugins that rely on AJAX calls. This is a known edge case when combining WPS Hide Login with aggressive caching or custom Nginx rules.

Step 6: Server-Level Reinforcement (Recommended)

For environments where you have server access, add a hard block at the web server layer so that even if the plugin is deactivated, the default paths remain protected.

Nginx — add inside your server {} block:

location = /wp-login.php {
    return 301 https://yoursite.com/;
}

location ^~ /wp-admin/ {
    # Allow admin-ajax.php for front-end AJAX
    location = /wp-admin/admin-ajax.php {
        try_files $uri =404;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
    return 301 https://yoursite.com/;
}

Apache — add to your .htaccess file above the WordPress rewrite block:

<FilesMatch "^wp-login.php$">
    Order Deny,Allow
    Deny from all
</FilesMatch>

These rules operate independently of WordPress and PHP, meaning they intercept requests before WordPress bootstraps — a meaningful performance and security advantage.

Step 7: Combine with Complementary Security Plugins

WPS Hide Login addresses URL discoverability. It does not protect against:

• Credential attacks via the XML-RPC endpoint (/xmlrpc.php)
• Vulnerabilities in themes or plugins
• Authenticated attacks from compromised accounts

Layer it with the following:

• Limit Login Attempts Reloaded: Enforces lockout policies after a configurable number of failed attempts. Works on your custom login URL, not just the default one.
• Wordfence Security: Provides a learning-mode firewall, real-time threat intelligence feed, and file integrity monitoring. Its two-factor authentication module is particularly valuable.
• Disable XML-RPC: If you do not use the WordPress mobile app or Jetpack, disable /xmlrpc.php entirely — it is a separate brute force vector that WPS Hide Login does not touch.
• WP 2FA: Adds time-based one-time password (TOTP) authentication as a second factor, making credential theft alone insufficient for access.

If your site is hosted on a plan with VPS with cPanel, you can also configure ModSecurity rules at the server level to rate-limit login attempts independently of WordPress plugins.

How to Recover Access If You Forget the Custom Login URL

This is the most operationally sensitive scenario. If you lose the custom login URL and cannot access the dashboard, the plugin must be disabled at the file system level.

Method 1: File Manager via Hosting Control Panel

1. Log into your hosting control panel (cPanel, Plesk, or equivalent).
2. Open the File Manager and navigate to /wp-content/plugins/.
3. Rename the folder wps-hide-login to wps-hide-login-disabled.
4. WordPress will automatically deactivate the plugin because the folder name no longer matches.
5. Access your site via yoursite.com/wp-login.php — the default URL is now active again.
6. Log in, retrieve or reset your custom URL configuration, then rename the folder back to wps-hide-login to reactivate.

Method 2: FTP/SFTP Access

# Connect via SFTP (replace with your actual credentials)
sftp user@yoursite.com

# Navigate to the plugins directory
cd /public_html/wp-content/plugins/

# Rename the plugin folder to deactivate it
rename wps-hide-login wps-hide-login-disabled

Method 3: WP-CLI (If Available on Your Server)

If your hosting environment supports WP-CLI — common on VPS Hosting and managed server plans — this is the fastest recovery method:

# Deactivate the plugin from the command line
wp plugin deactivate wps-hide-login --path=/var/www/html

# Confirm it is deactivated
wp plugin list --path=/var/www/html

After logging in via the restored default URL, reactivate the plugin from the dashboard and reconfigure your custom path.

Method 4: Database Direct Edit

As a last resort, you can remove the plugin's stored option directly in the database. This is appropriate when file system access is unavailable but database access (via phpMyAdmin or MySQL CLI) is.

-- Remove WPS Hide Login configuration from wp_options
DELETE FROM wp_options WHERE option_name = 'whl_page';
DELETE FROM wp_options WHERE option_name = 'whl_redirect';

After executing these queries, the plugin will revert to default behavior (no URL hiding) even while still technically active, allowing you to log in via /wp-login.php.

Potential Pitfalls and Edge Cases

Caching conflicts: Full-page caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) may cache the redirect response for the old login URL. After configuring WPS Hide Login, purge all caches and verify that the redirect is not being served from cache with an incorrect destination.

CDN and reverse proxy considerations: If your site sits behind Cloudflare or another reverse proxy, ensure that /wp-login.php and /wp-admin are not cached at the CDN layer. These paths should always bypass cache. Cloudflare's default "Bypass Cache on Cookie" rule handles this for most WordPress setups, but verify it explicitly.

Multisite installations: WPS Hide Login has limited compatibility with WordPress Multisite networks. On subdomain-based multisite, each subsite's login URL must be managed carefully. Test thoroughly in a staging environment before deploying to a production multisite network.

Plugin conflicts: Some membership plugins, e-commerce platforms (WooCommerce's "My Account" page), and LMS plugins generate their own login forms that post directly to /wp-login.php. After enabling WPS Hide Login, audit all custom login forms on your site to ensure their action attributes are updated or handled by the plugin's URL rewriting.

SSL requirement: Always run your custom login URL over HTTPS. Submitting credentials over HTTP exposes them to network interception regardless of how obscure the URL is. If you have not yet secured your site, SSL Certificates are a prerequisite — not an optional add-on.

Technical Decision Checklist

Use this checklist before and after deploying WPS Hide Login in a production environment:

• [ ] Custom login URL is non-dictionary, non-brand-derived, and stored in a password manager
• [ ] Redirection URL for blocked paths is configured and tested in an incognito window
• [ ] admin-ajax.php remains accessible (test with a front-end AJAX-dependent feature)
• [ ] Password reset email links route through the custom login path correctly
• [ ] All full-page caches purged after plugin activation
• [ ] CDN/reverse proxy confirmed to bypass cache for login-related paths
• [ ] Server-level block on /wp-login.php and /wp-admin added as a defense-in-depth layer
• [ ] XML-RPC endpoint assessed and disabled if not required
• [ ] Complementary plugins (rate limiting, 2FA, WAF) active and configured
• [ ] Recovery procedure documented and tested in a staging environment
• [ ] SSL certificate active and enforcing HTTPS site-wide

FAQ

Does WPS Hide Login prevent all brute force attacks?

No. It prevents automated attacks that target the known default login URLs. If an attacker discovers your custom login URL — through source code exposure, server logs, or social engineering — brute force attempts can resume. Always combine URL obfuscation with rate limiting and two-factor authentication.

Will WPS Hide Login break WordPress automatic updates or cron jobs?

No. WordPress core updates, plugin updates, and wp-cron.php do not use /wp-login.php for authentication. They use nonces and application passwords or direct file execution. WPS Hide Login does not interfere with these processes.

What happens to the login URL if I deactivate WPS Hide Login without renaming the folder?

Deactivating the plugin through the WordPress dashboard immediately restores /wp-login.php and /wp-admin as functional login endpoints. Your custom URL stops working. This is reversible — reactivating the plugin restores the custom URL configuration.

Can I use WPS Hide Login on a WordPress Multisite network?

With caution. The plugin works on the network's primary site but has inconsistent behavior on subsites, particularly in subdirectory multisite configurations. Test on a staging clone of your network before deploying, and review the plugin's GitHub issue tracker for known multisite conflicts with your WordPress version.

Is it safe to share the custom login URL with other administrators?

Treat the custom login URL as a sensitive credential. Share it only through encrypted channels (a password manager's sharing feature, an encrypted messaging app) and never embed it in plain-text emails or documentation stored in publicly accessible repositories.