Locked Out of the WordPress Admin? The Most Common Causes at a Glance

When you can’t get into the WordPress admin, the first step is to pin down what exactly is happening. “I can’t get in” has very different causes, and each has its own route back. This overview sorts them by what you’re seeing and points you to the matching detail article.

Important: as soon as you’re back in, make a backup, especially if you’ll be touching the database, wp-config.php or theme code.

Quick Overview: What Are You Seeing?

What you see	Likely cause	Read on
Login form, password “wrong”, reset email never arrives	Wrong password, broken mail delivery or an outdated address on file	Password reset without email
Form reloads after submitting, no message	Cookies, wrong address in settings, HTTPS switch	Login loop
Login works, but menu items are missing	Administrator role lost	Lost admin rights
“Too many attempts”, block notice	Security or login-limit plugin	Plugin block
403, “Forbidden”, browser asks for a username and password	Server, firewall, .htaccess or directory protection	Server blocks you
Administrators in the user list you don’t know	Possible attack	Compromised account
Blank page	PHP error, often memory limit or a plugin	White screen of death
“There has been a critical error”	Fatal PHP error in a plugin or theme	Recovery mode
“Briefly unavailable for scheduled maintenance”	Maintenance file left behind after an update	Fix maintenance mode
“Error establishing a database connection”, 500	Database or server	WordPress errors overview

Password Reset Without Email

The login loads, but your password is rejected, and “Lost your password?” doesn’t help either: no email, or the address on file no longer exists. This is one of the most common cases, and usually the site’s email delivery is the problem, not the password itself. The WordPress documentation lists several routes for exactly this situation, depending on what you can still reach.

phpMyAdmin: In the wp_users table, edit your user, type the new password in plain text into user_pass, and choose MD5 in the “Function” column before saving. It looks like a hack, but it’s a documented route. WordPress checks hashes of 32 characters or fewer with MD5 and replaces them with a current hash on a successful login. You can read that in the source of the login functions, not just in tutorials. One note on the table: your prefix may differ from wp_; look for $table_prefix in wp-config.php.

WP-CLI: With SSH access you don’t need a database interface. wp user list shows the ID, then you set the password:

wp user list
wp user update 1 --user_pass='a-long-new-password'

If you need a fresh administrator, this creates one:

wp user create access access@example.com --role=administrator --user_pass='a-long-new-password'

Without --user_pass, WP-CLI generates a random password and prints it. If WP-CLI itself fails because a plugin breaks the site, the global --skip-plugins parameter helps (WP-CLI still loads plugins in the mu-plugins folder).

FTP only: Add wp_set_password( 'new-password', 1 ); to the active theme’s functions.php, where 1 is the user ID, and remove the line right after the first page load. Otherwise the password gets reset on every request. The step-by-step guide with a generator for SQL and functions.php is in Regain access to your WordPress admin.

If the reset email never arrives at all, check the site’s mail delivery once you’re back in.

The Login Page Keeps Reloading

You enter your username and password, press the button, and the login page appears again. No error, no “wrong password”. That usually means the credentials are fine, but WordPress can’t keep you logged in or sends you in circles. Check in this order.

1. Browser. Open the login in a private window or another browser. If it works there, cookies or cache were the problem. Sometimes WordPress shows a message: “Cookies are blocked or not supported by your browser” means the browser doesn’t accept cookies. “Cookies are blocked due to unexpected output” means something printed text before the login did its job. Usually that’s whitespace or a BOM marker before the <?php in wp-config.php or a plugin file. A “headers already sent” warning names the file and line where the output starts.

2. Address in the settings. The wp_options table holds the rows siteurl (WordPress address) and home (site address). If they differ from the address you log in on, for example after switching from http to https or from www to non-www, the cookie won’t match. Correct both values in phpMyAdmin or with WP-CLI:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

If you can’t reach the database, you can pin the addresses in wp-config.php:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

These constants override the database values without changing them. Remove them later and the database value applies again.

3. HTTPS and FORCE_SSL_ADMIN. There’s a detail many people miss: if siteurl starts with https, current WordPress versions switch FORCE_SSL_ADMIN on by themselves according to the source code, unless the constant is defined. The login then redirects to the HTTPS version whenever WordPress doesn’t recognise the request as HTTPS. If a reverse proxy, load balancer or CDN sits in front of your site, terminates HTTPS and passes requests on over plain HTTP, WordPress can’t tell, and you go round in circles. The WordPress developer documentation describes a fix for wp-config.php that reads the HTTP_X_FORWARDED_PROTO header:

define( 'FORCE_SSL_ADMIN', true );
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

This assumes the proxy actually sends the header. Ask your host or check the proxy configuration.

4. Plugins, theme, .htaccess. If none of that helps, rename /wp-content/plugins/ to plugins.hold as a test. WordPress then deactivates every plugin, you log in, rename the folder back and reactivate the plugins one by one. Damaged rewrite rules in .htaccess are another possible cause: rename the file and save under Settings > Permalinks, and WordPress writes its default block back.

How to make the login sturdier in the long run is covered in Securing your WordPress login.

You’ve Lost Your Administrator Rights

You can log in, but menu items are missing or you’re suddenly just a subscriber. This happens after failed migrations, through a faulty plugin, or as a result of an attack that downgraded your rights.

WordPress stores the role in the wp_usermeta table. The key is wp_capabilities, with your installation’s table prefix: if your prefix is abc_, you look for abc_capabilities. If you find the row for your user ID, set the value to

a:1:{s:13:"administrator";b:1;}

WordPress also maintains a legacy entry wp_user_level, which is 10 for administrators. If it’s missing after a migration, add it. After a move with a changed table prefix, the role can seem to vanish: the data still sits under the old prefix in the key while the site looks for the new one.

With shell access it’s much simpler:

wp user set-role 1 administrator

The fastest route without either is still a fresh admin user via the database or code, as described in Regain access to your WordPress admin. If the loss of rights came as a surprise, it’s worth checking afterwards whether the site was compromised.

Locked Out by a Security Plugin

A security or login-limit plugin has blocked you or your IP, for instance after too many failed attempts or after an update that changed its rules. You usually see the plugin’s own block notice, sometimes “This has been disabled” or a custom error page.

The fastest route: take the plugin out via FTP. Rename the plugin’s folder under /wp-content/plugins/, log in, then rename it back. Loosen the setting specifically rather than switching the plugin off for good. You can also wait until the block expires, but FTP is more reliable.

Two pitfalls: some security tools live in wp-content/mu-plugins/. WordPress loads must-use plugins automatically, and you can’t switch them off in the admin. Renaming in the plugins folder won’t be enough then; you have to move the file out of mu-plugins. Hosts often use this folder for their own features. Rules can also sit in .htaccess. If the block persists with the plugin disabled, look there.

403 or a Password Prompt Before the Login

Two symptoms that are easily mixed up.

The browser asks for a username and password before the WordPress form even appears. Then there’s a server password protection in front of wp-login.php or wp-admin, set up by your host, an agency or yourself. These credentials differ from your WordPress login. How such protection works and where it breaks is covered in Securing wp-admin with directory protection.

A 403 page (“Forbidden”) comes from the server or a firewall, not from WordPress. Typical triggers are rules in .htaccess that restrict wp-login.php or wp-admin to certain IP addresses (and yours has changed), a web application firewall at your host or an upstream service, or a plugin that writes such rules. You can usually tell because the error page doesn’t look like your website. Check:

1. Does the login work from another network, for example over mobile data? Then it’s an IP restriction.
2. Is there a rule for wp-login.php or wp-admin in .htaccess?
3. Does your hosting’s error log say which rule triggered?

If it’s your host’s firewall, only their support can help. There’s nothing to repair on your side. For a 500 instead of a 403, see Fixing a 500 Internal Server Error in WordPress.

Unknown Administrators or Changed Credentials

If you see administrators in the user list that you didn’t create, or your profile email has changed, this is no longer an access problem but a security incident. That also applies if you can’t log in at all because your account has disappeared. In phpMyAdmin, a query shows who is an administrator:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Replace wp_ with your prefix. An account with an unfamiliar name and a suspicious registration date is a red flag, but don’t delete it blindly. Secure the current state first, then follow the process in WordPress hacked? Detect and clean up malware. A new login without fixing the cause leaves the door open.

Recovery Mode After a Critical Error

Since WordPress 5.2 there’s recovery mode. If a plugin or theme triggers a fatal PHP error, WordPress shows “There has been a critical error on this website” and sends an email to the administrator address from the general settings, or to the address set via WP_RECOVERY_MODE_EMAIL. The email contains a secret link. It takes you to wp-login.php, sets a cookie, and after you log in the admin shows which plugin or theme caused the error. WordPress pauses it for your session.

Two things to know:

• By default the email is sent at most once a day, and according to the source the link stays valid at least that long. If the first email got lost, a new one may take a while.
• You still need to log in. Recovery mode doesn’t replace the login, it only routes around the faulty code.

If the email never arrives, the FTP route remains: rename the suspect plugin or theme. A full walkthrough is in Critical error: using recovery mode properly.

Instead of the Login, You Get a Blank Page or an Error

Then access isn’t the problem, the site itself is throwing an error:

• Blank page, especially in the admin: often a memory limit that’s too low, see increase the WordPress memory limit. Other causes and diagnosis via the debug log are in fixing the white screen of death.
• “critical error”, database error, 500 or parse error: sort it out via the overview of WordPress errors.

Application Passwords Are Not a Login Substitute

Sometimes the thought comes up that an application password from your profile could serve as a back door. It can’t. Application passwords are meant for programs that access WordPress through the REST API or XML-RPC, and according to the WordPress core team explicitly not for interactive sign-in by humans. You can’t use them on wp-login.php. If you’re locked out, you need one of the routes above.

You Can’t Reach the Server at All

No backend, no FTP, no hosting login? Then the fix starts one level down: reset your (s)FTP credentials through your hosting panel, or use your host’s “forgot password” function. Once hosting access is back, every other route is open to you again. For next time, a current backup with a tested restore turns an outage into an annoyance.

When It’s Time to Get Help

You can solve some of this yourself. At these points it’s worth stopping before you keep editing the database:

• You have no access to hosting, FTP or the database, and your host can’t help.
• There are administrators you don’t know, or the site behaves oddly.
• Several causes overlap, for example a login loop after a move with a changed table prefix.
• It’s a shop or a site that earns money, and you don’t want to guess.

For urgent cases we have a dedicated WordPress emergency page. We can usually be reached during our service hours (Monday to Friday, 8 am to 6 pm), but we don’t promise a fixed response time without a maintenance contract. We estimate the effort up front.

---

Not sure which case is yours, or not keen on databases and FTP? Drop us a line and we’ll get you back into the admin. And if you’d like someone to look after the site permanently: a WordPress maintenance plan covers updates, backups and security monitoring on an ongoing basis.