Most WordPress admin lockouts are not really technical mysteries. They happen during a handover, after a plugin change, when an old staff email still owns the account, or when nobody is sure which login is still authoritative. If you are the business owner, operations lead, or agency contact responsible for a live site, the goal is not to get in somehow. It is to restore access quickly, leave a clean audit trail, and avoid creating a second problem you have to clean up later.
The safest order is still the right one: use WP-CLI first, use direct database changes only if that is the only access left, and treat old MD5-style password resets as an emergency bridge rather than normal practice. That keeps the recovery narrow, reversible, and much easier to explain to a client or internal team afterwards.
Start with the lowest-risk recovery path
If you have shell access, WP-CLI is usually the best option because WordPress handles the user update itself. That matters on production sites where you want fewer manual edits and fewer hidden side effects.
wp user list --role=administrator --fields=ID,user_login,user_email --format=table
wp user update 1 [email protected] --skip-email
wp user update 1 --user_pass='A-long-unique-password' --skip-emailThis is the clean sequence for most incidents: identify the right administrator account, restore a reachable email address, and only change the password if the normal password-reset flow still cannot be used. If the site is multisite, check the right network or site context before making changes. WP-CLI supports --network for listing users and --url=... for targeting the correct site context.
If a plugin or theme error is blocking normal access, WP-CLI can still help. Running recovery commands with --skip-plugins and --skip-themes can get you around code that has nothing to do with the user account itself.
In most business environments, this is preferable to creating a throwaway emergency admin user. Extra administrator accounts tend to survive the incident, stay undocumented, and become the next security or ownership problem.
Use direct SQL only when it is the only door left open
Sometimes wp-admin is down and WP-CLI is unavailable, but you still have database access. In that case, keep the change as small as possible. First confirm the actual users table name and the record you are touching. Many sites do not use the default wp_ prefix, and rushed edits to the wrong row are a common cause of accidental lockouts.
SELECT ID, user_login, user_email
FROM yourprefix_users
ORDER BY ID;If the issue is an outdated or inaccessible email account, update only the email first. That often restores the standard Lost your password? route without forcing a password change during the incident.
UPDATE yourprefix_users
SET user_email = '[email protected]'
WHERE ID = 1;That is usually the lowest-risk database fix because it preserves the existing login history and avoids touching password storage at all.
MD5 still works as a fallback, but it is no longer the finish line
WordPress still accepts legacy password hashes for compatibility, and the official reset documentation still includes database-only MD5 recovery methods. But current WordPress versions now hash passwords with bcrypt by default, so old MD5-era advice is incomplete if it presents that method as normal.
If database access is truly your only option, an MD5 update can still get you back in:
UPDATE yourprefix_users
SET user_pass = MD5('temporary-strong-password')
WHERE ID = 1;Treat that as an emergency bridge. Log in, confirm access, and then immediately reset the password through wp-admin or WP-CLI so WordPress stores it using the current hashing path. In other words: use MD5 to recover, not to stay recovered.
That distinction matters in real operations. The shortcut is useful during an outage, but leaving a legacy-style recovery state in place after the incident is avoidable technical debt.
Fix the process, not just the login
A surprising number of WordPress access incidents start outside WordPress itself: a shared admin password stored in chat, a vendor using a real human login for an integration, or a handover where nobody updated the recovery email. Once access is back, use the moment to remove the underlying fragility.
For scripts, reporting tools, or external services, use WordPress Application Passwords instead of sharing a main administrator password. They are built for programmatic access, can be named per tool, can be revoked individually, and are available over HTTPS by default. That gives agency teams and operations leads a much cleaner offboarding story when a tool changes or a vendor relationship ends.
A simple rule works well: one application password per integration, a descriptive name, and immediate revocation when the integration is retired. That is far easier to manage than tracing where a shared admin password ended up six months ago.
A practical recovery checklist for live sites
- Take a database backup or hosting snapshot before editing user records.
- Confirm you are on the correct environment before changing anything, especially if staging and production share similar domains or credentials.
- Change one thing at a time: email first, then password only if the normal reset path still fails.
- If you use WP-CLI on a troublesome site, try
--skip-pluginsand--skip-themesto reduce unrelated interference. - After access is restored, remove temporary credentials, document the final recovery path, and confirm who owns the account going forward.
Most WordPress admin recovery work is not especially complex. What makes it expensive is unclear ownership, rushed fixes, and temporary workarounds that become permanent. A calm recovery process saves more time than a clever trick.
If your team wants WordPress access, handovers, and vendor credentials to stop being brittle, Greg can help tighten the process without turning simple website operations into a heavyweight project.
Need help with WordPress operations?
Talk to Greg about making WordPress access and handovers less fragile.
Need help with this kind of work?
Talk to Greg about making WordPress access and handovers less fragile Get in touch with Greg.