Skip to main content
Blog|
Learning center

WordPress login URL: where to find wp-admin and how to change it

|
Apr 7, 2026|10 min read
LEARNING CENTERWordPress login URL: where tofind wp-admin and how tochange itHOSTNEYhostney.comApril 7, 2026

Every WordPress site has a login page. It is how you access the admin dashboard to create content, manage plugins, update settings, and run your website. If you have just set up WordPress for the first time, are managing a site someone else built, or simply cannot remember where to log in, finding the login URL is the first step.

This guide covers the default WordPress login URLs, what to do when the login page is not working, why you might want to change the URL for security reasons, and how to get back in when you are completely locked out.

Default WordPress login URLs#

WordPress uses two URLs for admin access. Both work out of the box on every WordPress installation.

/wp-login.php

https://yoursite.com/wp-login.php

This is the actual login page. It displays the username and password form. When you submit your credentials, WordPress authenticates you and redirects to the dashboard. This file exists in the root of every WordPress installation and is the endpoint that handles authentication.

/wp-admin/

https://yoursite.com/wp-admin/

This is the admin dashboard URL. If you are already logged in, it takes you straight to the dashboard. If you are not logged in, WordPress automatically redirects you to wp-login.php first, and after authentication, redirects you back to the dashboard.

Most people use /wp-admin/ as their login bookmark because it works either way – logged in or not.

With a subdirectory installation

If WordPress is installed in a subdirectory rather than the root of the domain, the login URL includes that directory:

https://yoursite.com/blog/wp-login.php
https://yoursite.com/blog/wp-admin/

This is common when WordPress powers the blog section of a site while the main domain runs something else.

With WordPress Multisite

On a WordPress Multisite network, each site has its own login URL:

https://site1.yournetwork.com/wp-login.php
https://site2.yournetwork.com/wp-login.php

The network admin dashboard is at /wp-admin/network/ on the main site. Individual site dashboards are at their respective /wp-admin/ URLs.

When wp-admin is not working#

If you type /wp-admin/ and do not get the login page or dashboard, the cause depends on what you see instead.

White screen or blank page

A blank page usually means a PHP error is crashing before WordPress can render anything. This is the WordPress white screen of death. The most common causes are a plugin conflict, a theme error, or exhausted PHP memory. Enable WordPress debug mode by adding this to wp-config.php :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Then check wp-content/debug.log for the specific error. A fatal error from a plugin means that plugin is crashing WordPress before the login page can load.

500 Internal Server Error

A 500 error on the login page typically points to a server configuration issue, a corrupted .htaccess file (on Apache), or a PHP-FPM problem. Try renaming .htaccess via SFTP and loading the page again. If the 500 disappears, regenerate the file from Settings > Permalinks in the dashboard.

403 Forbidden

A 403 error means the server is actively denying access. This could be a security plugin blocking your IP, a server-level firewall rule, or file permission issues. If you recently installed a security plugin that restricts access to wp-admin by IP address, and your IP changed, the plugin is blocking you.

Login page redirects in a loop

You enter your credentials, the page refreshes, and you are back at the login screen with no error message. This is the login redirect loop, and it happens when WordPress sets authentication cookies but cannot validate them on the next request. Common causes are mismatched WordPress URL settings, cookie issues, and caching plugins serving cached versions of the login page.

Too many redirects

The browser shows “ERR_TOO_MANY_REDIRECTS.” This is usually caused by incorrect WordPress Address and Site Address settings (Settings > General), particularly when they do not match (one has www , the other does not) or when HTTP/HTTPS is misconfigured. Clear your browser cookies for the site and check the siteurl and home values in the wp_options database table.

Connection refused or timeout

If the login page does not load at all, the issue is not WordPress-specific. The web server or PHP-FPM may be down, or a firewall may be blocking your connection. Check if the rest of the site loads. If nothing loads, the problem is at the server level.

Why bots target wp-login.php#

The WordPress login URL is the same on every WordPress site. Bots do not need to discover it – they already know where it is. Automated scripts scan IP ranges and domain lists continuously, find WordPress installations, and start trying credentials against /wp-login.php .

This is not hypothetical. It happens to every WordPress site, usually within hours of going live. The attacks are automated and relentless. A typical WordPress site receives dozens to hundreds of failed login attempts per day from credential stuffing bots cycling through leaked password databases.

Each failed login attempt consumes server resources. WordPress has to load core, query the database, hash the submitted password, and return a response. At scale, brute force attacks against the login page can slow down your entire site because login attempts compete with legitimate visitors for PHP workers.

This is the primary motivation for changing the login URL: it removes the low-hanging fruit. Bots that blindly request /wp-login.php get a 404 instead of a login form.

How to change the WordPress login URL#

Changing the login URL is a form of security through obscurity. It does not make your site fundamentally more secure (a determined attacker can still find the login page), but it eliminates the automated bot traffic that hits every WordPress site indiscriminately. That reduction in noise is worth something, especially on sites without server-level bot protection.

Using a plugin

The simplest approach. Several plugins handle this:

WPS Hide Login is the most focused option. It does one thing: changes the login URL. After installation, go to Settings > WPS Hide Login and set your custom URL (for example, /my-login ). The plugin redirects /wp-login.php and /wp-admin/ requests from logged-out users to a 404 page.

iThemes Security (now Solid Security) includes a “Hide Backend” feature among its broader security toolkit. It changes the login URL and adds other protections.

All-in-One WP Security also includes login URL modification as part of a larger security plugin.

The important thing with any of these plugins: bookmark your new login URL immediately. If you forget the custom URL, you will need SFTP or SSH access to disable the plugin and restore the default login page.

What happens to the old URL

After changing the login URL, requests to /wp-login.php return a 404 error. Bots that hit the default URL get nothing. Existing bookmarks and password manager entries for the old URL stop working – update them before making the change.

A warning about plugin-based URL changes

If the plugin that hides your login URL is deactivated, deleted, or crashes, the default /wp-login.php URL is immediately accessible again. The custom URL is enforced by the plugin, not by the server. This means a plugin update that breaks compatibility, a PHP error that disables plugins, or a manual deactivation from SFTP all restore the default login URL.

This is not necessarily a problem – the default URL is how you recover if you forget the custom one. But it does mean that changing the login URL is a layer of defense, not a wall.

Server-level protections that matter more#

Changing the login URL stops automated bots that blindly request /wp-login.php . It does not stop a targeted attacker who can find your login page through other means (checking for the wp-admin cookie, looking at redirect headers, or simply trying common custom URLs).

The protections that stop actual attacks are at the server level:

Rate limiting restricts how many login attempts a single IP can make. After a threshold (for example, 5 failed attempts in 10 minutes), the IP is temporarily blocked. This makes brute force attacks impractically slow. When rate limiting is enforced at the web server level (Nginx or Apache), the request never reaches PHP, which means it consumes almost no server resources compared to a WordPress-level limit that still loads PHP and the database before deciding to block.

Fail2ban monitors server logs for failed login patterns and automatically bans offending IPs at the firewall level. A typical configuration watches the WordPress authentication log, counts failed attempts, and adds a firewall rule to drop all traffic from the offending IP after a threshold. The ban is temporary (usually 15-60 minutes) and automatic. Unlike application-level plugins, fail2ban operates at the network layer, so banned IPs cannot even establish a TCP connection to the server.

Bot detection identifies automated traffic based on behavior patterns – request rate, missing cookies, known bot signatures, IP reputation – and blocks or challenges it before it reaches WordPress. This is critical for stopping distributed attacks that rotate through thousands of IPs to stay under per-IP rate limits. No single IP triggers a ban, but the aggregate behavior across all IPs is clearly automated.

Web application firewalls like ModSecurity inspect request content for attack patterns (SQL injection, XSS, path traversal) and block malicious requests regardless of which URL they target. A WAF protects the login page even if an attacker discovers the custom URL.

On managed WordPress hosting, these protections are typically built into the platform. You do not need to configure rate limiting, fail2ban, or bot detection yourself – the hosting provider handles it at the infrastructure level.

How to get back in when locked out#

Lockouts happen. A forgotten password, a security plugin blocking your IP, a changed login URL you did not bookmark, or a compromised site where an attacker changed the admin credentials. The complete guide to getting back into WordPress covers every scenario in detail. Here is the quick version for the most common situations.

Forgotten password

Click “Lost your password?” on the login page. If the reset email does not arrive (common on servers with restricted outgoing email), use WP-CLI over SSH:

wp user update admin --user_pass=NewSecurePassword123

Or reset it directly in the database:

UPDATE wp_users SET user_pass = MD5('NewSecurePassword123') WHERE user_login = 'admin';

The database method sets an MD5 hash, which WordPress will automatically upgrade to a stronger hash on the next login.

Blocked by a security plugin

If a security plugin is blocking your IP or you forgot the custom login URL, deactivate the plugin via SFTP. Rename its folder in wp-content/plugins/ :

wp-content/plugins/wps-hide-login/ → wp-content/plugins/wps-hide-login-disabled/

This deactivates the plugin without deleting it. The default /wp-login.php URL works again immediately. Log in, fix whatever caused the issue, and rename the folder back.

Blocked by server-level protection

If fail2ban or a server firewall blocked your IP after too many failed attempts, wait for the ban to expire (typically 15-60 minutes) or contact your hosting provider to remove the ban. On Hostney, IP bans from failed login attempts expire automatically, and you can check your IP status through the control panel.

Best practices for WordPress login security#

Whether you change the login URL or not, these practices protect your login:

Use strong, unique passwords. A 20+ character password generated by a password manager is effectively immune to brute force. The password does not need to be memorable because the password manager remembers it.

Enable two-factor authentication. Even if an attacker obtains your password (through a data breach, phishing, or credential stuffing), they cannot log in without the second factor. Plugins like WP 2FA and Wordfence Login Security add TOTP-based two-factor authentication to WordPress.

Limit login attempts. If you do not have server-level rate limiting, a plugin like Limit Login Attempts Reloaded adds application-level rate limiting to slow down brute force attacks.

Keep WordPress updated. Core updates include security patches for the login and authentication system. Running outdated WordPress with known vulnerabilities puts the entire site at risk, not just the login page.

Do not use “admin” as a username. It is the first username every brute force script tries. Use a unique username that is not publicly visible on your site.

WordPress login on Hostney#

On Hostney, every WordPress installation uses the standard /wp-admin/ login URL by default. Server-level protections are active on all accounts:

  • Rate limiting on  wp-login.php  restricts the number of login attempts per IP
  • Bot detection identifies and blocks automated credential stuffing attacks before they consume PHP resources
  • IP bans from excessive failed attempts expire automatically
  • Container isolation ensures that brute force traffic targeting one site does not affect other accounts on the server

If you want to change the login URL, you can install WPS Hide Login or any similar plugin through the WordPress dashboard. The server-level protections continue working regardless of what URL the login page is at.

If you are locked out of your WordPress admin, SSH access is available on all plans through the Terminal Access section in the control panel. You can use WP-CLI to reset passwords, deactivate plugins, and restore access without needing to contact support.