How to Fix WordPress Login Page 404 After Hiding Login

How to Fix WordPress Login Page 404 After Hiding Login

If your WordPress login page starts returning a 404 after you hide the login URL, the problem is usually a conflict between your security plugin, rewrite rules, or cached redirects.

This guide shows how to regain access safely while keeping your login page protected.

Why the login page becomes a 404

Most WordPress sites use wp-login.php and /wp-admin/ as standard entry points.

When a plugin or custom rule hides or changes that path, WordPress may stop recognizing the new URL if the configuration is incomplete, causing a 404 Not Found response instead of a login screen.

This often happens after using security tools such as WPS Hide Login, Hide My WP, iThemes Security, or custom rewrite rules in .htaccess or a web server configuration.

The issue can also appear after a migration, a staging-to-production push, or a cache plugin update.

Check whether the hidden login slug is correct

The most common cause is a simple mismatch between the new login slug and the URL you are visiting.

If you changed the login path from /wp-login.php to something like /my-login, you must use the exact custom slug.

• Confirm the login slug in the plugin settings.
• Look for typos, extra slashes, or case differences.
• Test the URL in a private browser window.
• Try the login link from the plugin’s own settings page if it provides one.

If the slug is correct but still returns 404, the rewrite rules may not be active or a cache layer may be serving an outdated response.

Flush WordPress permalinks and rewrite rules

WordPress depends on rewrite rules to map friendly URLs to the correct internal files.

When those rules are stale, custom login URLs can fail even though the plugin is installed properly.

1. Log in through any working admin path.
2. Go to Settings > Permalinks.
3. Click Save Changes without changing anything.

This refreshes the rewrite rules.

If you are locked out, you can also force a rules refresh by temporarily disabling and re-enabling the plugin that hides the login page.

Clear all caching layers

A 404 can be cached by a plugin, host-level cache, CDN, or browser cache.

If the login URL was recently changed, a stale cache may still point visitors to the old route or a blank response.

• Clear your WordPress cache plugin.
• Purge server cache from your hosting dashboard.
• Clear CDN cache if you use Cloudflare or another CDN.
• Test in incognito mode or a different browser.

For security plugins that create a hidden login page, caching should usually exclude the custom login slug and wp-login.php fallback rules if the plugin recommends it.

Temporarily disable the login-hiding plugin

If you are completely locked out, disable the plugin that hides the login page.

This is the fastest way to determine whether the problem is caused by the plugin itself or by another layer such as caching or server rules.

How to disable it safely

• Use SFTP or your hosting file manager.
• Open wp-content/plugins/.
• Rename the plugin folder, for example from wps-hide-login to wps-hide-login-disabled.

Renaming the folder deactivates the plugin.

Once it is disabled, WordPress should fall back to the default login URL, allowing you to log in and review the plugin settings.

Verify .htaccess or server rewrite rules

On Apache servers, a malformed .htaccess file can block the custom login route.

On Nginx, an incomplete server block can produce the same symptom.

If the login page was hidden through custom code, the rewrite directive may no longer match the new URL.

Look for rules added by the plugin or by manual edits.

A missing rewrite condition, incorrect order, or conflicting redirect can make the login path unreachable.

If you recently moved the site, compare the active rules with a known-good backup.

• Back up the current configuration before editing.
• Check for duplicate redirect directives.
• Ensure the login slug is excluded from broader redirects.
• Reload Nginx or Apache after changes if needed.

Check for conflicts with security and redirect plugins

WordPress security and redirect plugins can override each other.

A plugin that changes the login URL may conflict with another plugin that forces canonical URLs, blocks bots, or redirects non-authenticated visitors.

Common conflict sources include redirection managers, firewall plugins, maintenance mode tools, and multilingual plugins that alter URL routing.

If the hidden login page worked before and now 404s after a new plugin install or update, disable the newest plugin first and retest.

Use the default recovery paths

Many login-hiding plugins offer a recovery method or backdoor if you forget the custom URL.

Check the plugin documentation for a reset mechanism, emergency login link, or email-based recovery step.

Some plugins also allow access through a special query string or by renaming a file on the server.

If you cannot find a recovery path, contact your host for help restoring plugin access or reverting the site from a backup.

For managed WordPress hosting, support teams can often identify rewrite and cache issues quickly.

Regain access without exposing the login page

Once you are back in the dashboard, review the hidden login configuration carefully.

The safest setup is one that changes the login slug, keeps a documented recovery method, and does not rely on fragile custom redirects.

Security practices to keep in place

• Use a unique login slug that is hard to guess.
• Store the slug in a password manager or internal admin note.
• Keep a tested recovery method available.
• Update plugins regularly to avoid rewrite bugs and compatibility issues.
• Exclude the login route from aggressive caching and optimization rules.

When the 404 comes from the server, not WordPress

If the login URL returns 404 before WordPress loads, the issue may be server-side rather than plugin-related.

This is common when the web server blocks the custom path, the document root is wrong, or the site was migrated without transferring rewrite settings.

Indicators that the problem is server-side include a generic 404 page with no WordPress branding, no login form, and failure across multiple browsers and devices.

In that case, your host may need to inspect Nginx rules, Apache virtual host settings, or security modules such as ModSecurity.

Fast troubleshooting checklist

• Confirm the custom login slug exactly matches the plugin setting.
• Flush permalinks by saving settings again.
• Clear plugin, server, CDN, and browser caches.
• Disable the login-hiding plugin by renaming its folder if needed.
• Inspect .htaccess or Nginx rewrite rules for conflicts.
• Temporarily disable redirect or security plugins that may interfere.
• Ask your host to check server-level rewrites if WordPress never loads.

Once you identify the layer causing the 404, you can restore access and reapply login hiding with a cleaner configuration.