Being locked out of the WordPress admin has half a dozen causes that all look the same: the login page rejects you, or loads and does nothing, or redirects somewhere else.
Work through these in order. Each is faster than the one after it, and the first two solve most cases.
First: is it the password or the site
Use the "lost password" link. If the reset email arrives and works, that was the whole problem.
If no email arrives, that is informative on its own: WordPress mail is broken, which is a common and separate problem, and it means every other password reset on the site is failing too. Fixing WordPress email has the detail.
If the reset link says the key is invalid, the site's address setting is probably wrong, which is the third section below.
Reset the password directly
When the email route is unavailable, change it in the database.
In phpMyAdmin, open the wp_users table: noting that the prefix may not be wp_: find your user, and edit user_pass. Set the function to MD5 and type the new password in the value field.
WordPress uses stronger hashing, and it accepts an MD5 hash on login and immediately replaces it with a proper one. This is the standard emergency route and it works.
Take a database export first. You are editing the table that controls access. Managing databases with phpMyAdmin has the detail.
Create a new administrator
When the account itself is gone, deleted, or its role changed, adding a user through the database is fiddly. Adding one through code is not.
Put this in the active theme's functions.php, temporarily:
add_action('init', function () {
if (!username_exists('tempadmin')) {
$id = wp_create_user('tempadmin', 'a-long-password-here');
(new WP_User($id))->set_role('administrator');
}
});
Load any page on the site once, log in as that user, then remove the code immediately. Leaving it in place is a permanent backdoor with a password in plain text in a theme file.
Delete the temporary account once you have fixed the real one.
The redirect loop: the address is wrong
If the login page redirects endlessly, or sends you to a different domain, the site address setting does not match the address you are using.
Fix it without database access by adding constants to wp-config.php:
define('WP_HOME','https://example.com');
define('WP_SITEURL','https://example.com');
These override the database immediately. Log in, correct the settings, then remove the constants so the settings screen works again. Changing the WordPress site URL goes into why this happens.
A plugin is blocking you
Security plugins lock accounts and block addresses after failed logins: including yours, and including when the failures were somebody else's attempts on your username.
Rename the plugin's folder in wp-content/plugins/ over FTP or File Manager. WordPress cannot load it and deactivates it silently.
If you are not sure which plugin, rename the whole plugins folder. That deactivates everything at once; renaming it back restores them, though they stay deactivated and need switching on individually.
Log in, then reactivate one at a time to find the culprit, and add your address to its allow list before reactivating it.
A white screen instead of a login form
A fatal error with error display off. The login page is PHP like everything else.
Rename the plugins folder as above. If that does not help, rename the active theme's folder, which forces a default theme.
Then read the error log, which names the file and line: guessing takes longer than looking. Understanding error logs goes over finding it.
Two-factor when you have lost the device
Use a recovery code if you saved one. If not, deactivate the two-factor plugin by renaming its folder, log in, and set it up again on the new device.
That is also a reminder of what two-factor cannot protect against: anyone with file access can turn it off. It secures the login, not the server, which is why file access is the thing to guard.
Cookie and cache problems
A login that appears to succeed and returns you to the login form is usually cookies.
Try a private window first. Then clear cookies for the domain specifically. Then check whether a caching layer is caching the login page; it should never be, and a cached login page produces exactly this symptom. For the exclusions, see caching layers.
Once you are back in
Find out why it happened, because "locked out for no reason" is occasionally the first sign of something else.
Check the user list for administrators you did not create. An unfamiliar admin account is the most common persistence mechanism after a compromise. Cleaning up a hacked site walks through what to do next if you find one.
Then set up a second administrator account with its own strong password, stored somewhere you can reach without this site working. Most of the routes above exist because there was only one way in.
Establish whether the session or the account is the problem
Two very different faults look identical from the login screen, and one command separates them.
curl -sI https://example.com/wp-login.php | head -1 curl -s https://example.com/wp-login.php | grep -o 'id="loginform"' | head -1 curl -sI https://example.com/wp-admin/ | head -3
A login form that renders correctly means the site is running and the problem is your credentials or your browser. A form that does not render, or a redirect loop before it appears, means the site is broken and no password will help.
Try a different browser and a private window before anything else. A stale cookie produces a login that appears to succeed and returns you to the form, which is the single most common report and requires no changes to the site at all.
Get back in without the administration screen
Every recovery route needs access by some other means, and the fastest is the command line if the account has it.
wp user list --role=administrator --fields=ID,user_login,user_email wp user update admin --user_pass='yeni-sifre' wp user create recovery [email protected] --role=administrator --user_pass='gecici' wp plugin deactivate --all
Creating a second administrator rather than changing the existing one is frequently better, because it leaves the original account untouched for whoever owns it.
Where there is no shell, the same operations are possible through the database, and through a file placed temporarily in the site that performs one action and is then deleted. The file route is the last resort, since anything that can reset a password can be found by somebody else. Using WP-CLI covers reaching these commands.
Close the route you used
Recovery leaves things behind, and each one is a way back in for somebody who is not you.
Delete any temporary file immediately. Remove the recovery account once the original works. Re-enable whatever was disabled, one item at a time, confirming the site still loads after each.
wp user list --role=administrator --fields=user_login,user_registered wp plugin list --status=inactive --field=name ls -la ~/public_html/*.php | grep -vE 'index|wp-(config|load|blog|settings|login|admin|cron|links|mail|signup|activate|trackback|comments)'
The last command lists loose files in the root that are not part of a standard installation. A forgotten reset script sitting there is exactly what an automated scan looks for, and it will be found long before anybody remembers leaving it.