Recovery troubleshooting guide

WordPress password reset not working?

Work from the least invasive check to the most powerful. A broken email, an old reset link, the wrong database table, or an authentication plugin can each look like the same password problem.

6 min readUpdated 26 July 2026For authorized administrators
01The reset email never arrives.

Check delivery and the account’s actual email address before changing a password manually.

02The link is rejected.

Request a fresh reset link and use the newest complete URL in the same browser session.

03The new password will not sign in.

Verify the account, target site, password format, and any plugin or SSO login flow.

Match the symptom to the next check

SymptomLikely areaBest next action
No reset emailMail delivery or wrong account emailConfirm the user email and inspect the site’s mail delivery setup.
Invalid linkOld, incomplete, or superseded linkRequest one new reset and open the newest full URL.
Password rejectedWrong account, wrong site, or authentication overrideConfirm the user and test the site’s actual login path.
Manual reset failsWrong _users table or incompatible valueCheck the prefix and use WordPress or WP-CLI to create the hash.

Follow this recovery sequence

  1. 01
    Confirm the login URL and account identity.

    Make sure you are on the intended site—not staging, a subsite, or an old domain—and verify the account by login or email.

  2. 02
    Try one fresh email reset.

    Use “Lost your password?” once, then check mail delivery and junk folders. Open the newest reset link in full; do not reuse copied fragments from an older request.

  3. 03
    Use WP-CLI when shell access is authorized.

    Run the interactive password reset flow so WordPress handles hashing. See the WP-CLI recovery guide for the command and safeguards.

  4. 04
    Only then inspect the database path.

    Locate the correct users table, identify the authorized account, and use the phpMyAdmin guide for a deliberate fallback.

  5. 05
    Investigate authentication customizations.

    Security plugins, membership systems, single sign-on, LDAP, and multisite role rules can change the normal login flow. Review their logs and configuration rather than overwriting more password values.

Why a database reset can appear to succeed but still fail

Saving a value in phpMyAdmin only proves that a database row changed. It does not prove that it was the right WordPress installation, the right users table, the right account, or a password format the site will accept. Current Core-generated hashes begin $wp$2y$; a plain $2y$ value is not equivalent.

1 Correct database2 Correct user3 Compatible hash4 Actual login flow

If any link in that chain is unknown, stop and confirm it. The users-table guide helps with the first two checks, and the hash-format guide explains the third.

Once access is restored

  1. Set a fresh password through the normal WordPress profile screen and store it in a password manager.
  2. Fix the underlying recovery weakness: mail delivery, an incorrect account email, or missing two-factor recovery codes.
  3. Remove temporary hashes, exports, screenshots, and support notes containing sensitive values.
  4. Document the correct site, login path, and recovery owner without documenting the password itself.

Primary reference: WordPress password and login recovery guidance.