WordPress login is not working? Fix it by symptom

“Login not working” covers about ten different failures. WordPress might reject your password. It might accept it and bounce you back to the form. The login page might be missing, a security plugin might have locked you out, or the site might be crashing before the form even loads. Each of these has a different fix.

The most common mistake in support threads is resetting the password again and again. That only works when the password was the problem. So start with one question: does WordPress reject your credentials, or does it accept them and then fail? If you aren’t sure you’re even on the right login page, our guide on how to sign in to WordPress covers the default addresses first.

Which kind of login failure do you have?

Watch what happens after you click Log In. Each symptom points to a different layer of the site.

What you see	Where the problem usually is	Start here
“The password you entered is incorrect” or “unknown username”	The account or the password	Basic checks, then a password reset
The form reloads or returns to itself, often with reauth=1 in the address	Cookies, site URLs, cache, CDN or a plugin	The loop section below
“Cookies are blocked or not supported by your browser”	Authentication cookies	The loop section below
“Too many failed attempts”, a greyed-out button, a CAPTCHA that never passes	A security or login plugin	The security plugin section below
/wp-admin returns a 404 or sends you to the homepage	A login-hiding plugin, redirect rules or the host	The hidden login page section below
“There has been a critical error” or a blank white page	A PHP fatal error	The fatal error section below
“Error establishing a database connection”	The database or the server	Your host. A password reset can’t help here.

Run these checks before changing anything

These checks take two minutes, you can’t break anything with them, and they tell you whether the problem is in your browser or on the site.

1. Check the username or email. WordPress’s documentation says usernames and passwords are case-sensitive. Your public display name isn’t your username.
2. Check autofill. A password manager may be filling in an old password, especially if you reset it recently.
3. Try a private window, then a second browser. If login works there, the cause is your browser’s cookies or an extension. If it fails everywhere and for other admins too, the problem is on the site.
4. Use the exact address the site normally uses. Same domain, same HTTPS, same www or no www. If you log in at one version and the site lives at another, the browser can drop the cookie.
5. Stop retrying for 15 minutes if you’ve failed several times. Lockout plugins can extend the block with every new attempt.

If WordPress rejects your password

Use the “Lost your password?” link on the login page. If the email never arrives, check spam first. WordPress’s troubleshooting FAQ says site email can fail when the server’s mail setup isn’t configured. The email may also be going to a different address from the one you expect. The admin notification address in Settings and your user account’s email are separate fields, and they don’t have to match.

Also check that you’re using the right account. WordPress.com and a self-hosted WordPress site have separate logins. Your host, your domain registrar and WooCommerce.com each have their own login as well.

If the reset email doesn’t work, your hosting account is the fallback. Most hosts let you reset or create WordPress users from their control panel. With SSH and WP-CLI you can do it directly:

wp user list --fields=ID,user_login,user_email,roles
wp user update 1 --user_pass='temporary-long-password'

Log in, then set a proper password from your profile right away, because the temporary one is now in your shell history. Editing user_pass in phpMyAdmin is the last resort. DreamHost’s knowledge base calls that method “no longer recommended”. Old recipes that tell you to paste an MD5 hash are a common source of failed attempts.

If the reset worked but the old password still seems to apply, the site may have a server object cache. DreamHost documents this on DreamPress Pro, where running wp cache flush over SSH clears the stale data.

If the right password sends you back to the login form

This failure has nothing to do with the password. WordPress accepted your credentials but couldn’t set or read its login cookie, or a redirect sent you somewhere else first. WordPress’s Advanced Administration Handbook lists these causes:

• browser cookies are disabled, or a plugin conflicts with the login
• the cookie domain doesn’t match the site
• some URLs use HTTP and others HTTPS
• a server cache is serving the login page
• the WP_HOME and WP_SITEURL constants conflict, or the home and siteurl database options don’t match
• redirect rules at a CDN, proxy, Nginx, Apache or the host

Check the site URLs first, especially after a move

Migrations are a common trigger. Duplicator reviewed more than 8,000 of its support tickets and found that nearly 1 in 10 migration tickets were wp-admin lockouts after a successful move, usually from URL mismatches or redirect loops. Read the stored values over SSH:

wp option get home
wp option get siteurl
grep -E "WP_HOME|WP_SITEURL|COOKIE_DOMAIN" wp-config.php

WordPress’s wp-config documentation explains the two settings. WP_SITEURL is where the core files live and WP_HOME is the public address. Constants in wp-config override the database options. Don’t just set both to the same value. On sites installed in a subdirectory they are meant to be different. If old URLs are left in the content, back up first and preview the fix before running it:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run

Then look at caches you can’t clear from the browser

Clearing your browser cache doesn’t touch the host’s page cache, a caching plugin, a CDN, or an object cache in wp-content/object-cache.php. Exclude wp-login.php and any custom login address from page caching, then clear the server cache. In one Reddit case the loop came from a CDN the host had switched on. Turning it off fixed the loop. If someone else controls your DNS or CDN, for example a former developer’s Cloudflare account, changes inside WordPress may not help.

“Cookies are blocked due to unexpected output”

This variant means something printed output before WordPress could send its cookie headers. In one resolved WordPress.org thread, the cause was two blank lines at the end of the theme’s functions.php. The poster had already allowed cookies and cleared them, and neither helped. Look for whitespace after a closing ?> in functions.php, wp-config.php or a recently edited plugin file.

When a security or login plugin is the cause

Lockout, CAPTCHA, 2FA and login-hiding plugins protect the login page, and they also cause many of the lockouts people report. Two resolved WordPress.org threads show the pattern:

• A Wordfence user could enter a username and password, but the Login button greyed out. The cause was mismatched reCAPTCHA keys. Updating the keys fixed it.
• A site running Wordfence 2FA looped back to the form and never showed the code field. Reinstalling Wordfence and redoing the QR code didn’t help. Deactivating a second plugin, Invisible reCaptcha, did.

Without dashboard access, open your host’s file manager or SFTP, go to wp-content/plugins, and rename the suspect plugin’s folder, for example wordfence to wordfence-off. WordPress deactivates a plugin whose folder it can’t find. Log in, fix the setting that caused the problem, and turn the plugin back on. Don’t leave it off as the fix.

If the login page itself has disappeared

Plugins such as WPS Hide Login move the login page on purpose. Their documentation says that while the plugin is active, /wp-login.php and /wp-admin become inaccessible, so guessing the default address won’t work. The custom address is stored as whl_page in the options table, or in sitemeta on multisite:

wp option get whl_page

Deleting or renaming the plugin’s folder brings back the default login. A cached 404 or a short redirect loop can follow, so clear the cache before assuming it failed.

How to find a plugin conflict without breaking the live site

If you can still reach any admin screen, use the Health Check & Troubleshooting plugin. Its troubleshooting mode turns plugins off and switches to a default theme for your user only. Visitors keep seeing the normal site while you turn plugins back on one at a time.

If you’re locked out completely, rename folders one at a time, starting with whatever changed most recently. Renaming the whole plugins folder gets you in fastest, but it also switches off forms, checkout and security for every visitor, and it doesn’t tell you which plugin was at fault. Updates are a frequent trigger. In one thread, WPO365 version 42.2 sent /wp-admin to the homepage, and rolling back to 41.3 fixed it. Our guide to fixing WordPress plugins that stop working covers the isolation method in more detail.

When the login page shows an error instead of a form

A critical error message or a white screen is a PHP fatal error, not a login problem. WordPress’s Recovery Mode documentation says WordPress can email the admin a special login link after some fatal errors. Through that link you can deactivate the failing plugin or theme. It only works for some fatal errors, so if no email arrives, read the PHP error log before you start guessing. The file path in the error usually names the plugin. Our WordPress white screen guide walks through it.

“Error establishing a database connection” means WordPress failed before it could show the form. Check the database name, user and password in wp-config.php against your hosting panel, and contact your host if they match.

Customers can’t log in to a WooCommerce store

Store customers log in through a different path from admins. WooCommerce’s documentation says the My Account page is set under WooCommerce → Settings → Advanced, and that page needs the [woocommerce_my_account] shortcode to show the sign-in form. For Social Login, WooCommerce lists these causes:

• wrong provider keys
• default (plain) permalinks
• cURL missing on the server
• cached authentication requests

Exclude /wc-api/*, the wc-api query argument and wp_woocommerce_session* cookies from caching. Facebook login also fails when iThemes Security’s “Filter Long URL Strings” is on.

When to stop and get help

Stop and get help in any of these situations:

• The fix needs SSH, the database, server logs, DNS or CDN settings, and you don’t have that access.
• Plugin isolation didn’t identify a cause.
• You see admin accounts, must-use plugins or redirects that nobody recognises. Treat that as a possible compromise rather than a login bug, and read our guide to WordPress malware removal before changing anything.

Ask the original developer or agency first, then your host. Also check now who owns the domain, the hosting and the CDN account. A developer who disappears with your registrar login is a bigger problem than any login loop.

If you’d rather not do this yourself, SiteSelf handles WordPress bug fixes like this one. You describe the symptom in chat. It needs hosting (SSH) access for file, cache and log work, says what it’s about to change and whether it can be undone, and reports what it checked afterwards.