You accidentally delete your WordPress admin account. Or a plugin breaks WordPress and locks you out of the admin. Or you forget the password, the reset email never arrives, and the hosting email account is also inaccessible. Or a hacker changes admin credentials. A WordPress site lockout is one of the most stressful WordPress problems because the solution requires accessing the site through alternative means — the database, FTP, or the hosting control panel — rather than the browser login form that is no longer accessible. This fits into the wider topic we cover in our WordPress Errors Complete Guide.
WordPress Site Lockout — Regaining Access Through Multiple Paths
A WordPress site lockout can be resolved through several different access paths depending on what access is available. Knowing which paths exist prevents unnecessary panic — there is always a way back in if at least one of the following access methods is available: web hosting control panel (cPanel, Plesk), FTP or SFTP access, or database access (phpMyAdmin). Direct WordPress admin access is not required for any of these recovery methods.
Before attempting recovery, identify which access methods are available: check whether cPanel login (separate from WordPress) is possible — the hosting account password is typically different from the WordPress admin password and stored with the hosting provider, not in WordPress. Check whether FTP credentials are saved in a local FTP client like FileZilla — these are often stored from the initial site setup. Check whether the database password is saved — some hosting providers display it in the cPanel MySQL section. The fastest recovery path depends entirely on which access is available, so identifying available access before starting prevents wasted time on recovery methods that require access that is not available. Our guide on diagnosing WordPress site down events covers the hosting access paths that also apply when the WordPress site lockout is combined with a site availability issue.
The WP CLI recovery approach applies to VPS and dedicated servers with SSH access: wp user update admin_user --user_pass="NewSecurePassword!" — this directly updates the password for the specified user without accessing the WordPress admin or requiring email verification. wp user create new_admin [email protected] --role=administrator --user_pass="SecurePassword!" creates a new administrator account. WP CLI bypasses all WordPress authentication and acts directly on the database, making it the fastest lockout recovery method on servers where SSH access is available. According to the WP-CLI documentation, all user management commands including password reset and role assignment work on any WordPress installation accessible via SSH, making it the preferred recovery tool for WordPress site lockout scenarios on servers with shell access.
Resetting WordPress Password Via phpMyAdmin
When WP CLI is not available, the WordPress site lockout can be resolved by directly updating the password hash in the WordPress database through phpMyAdmin — the database management interface available in cPanel on most shared hosting accounts.
Access phpMyAdmin for WordPress site lockout recovery: cPanel → Databases → phpMyAdmin from the left sidebar (the database name is in wp-config.php as DB_NAME). Navigate to wp_users table → click the Edit icon for the admin account → find the user_pass field → change the Function dropdown from “No change” to “MD5” → enter a new password in the Value field → click Go. WordPress actually uses a more secure password hashing algorithm than MD5, but entering a new password with MD5 selected will still work as a temporary reset — WordPress automatically upgrades the hash format to its more secure scheme on the next login. After logging in with the MD5-set password, change it immediately from the WordPress Profile page to re-engage WordPress’s stronger password hashing.
If the WordPress site lockout is from a lost admin email rather than forgotten password, update the user_email field in wp_users to an email address that is currently accessible. Navigate to phpMyAdmin → wp_users → find the admin account → Edit → change the user_email field → Go. Then use the standard WordPress password reset with the updated email address — the reset link will now arrive at the newly set email. For WordPress site lockout where an attacker changed both the password and email, change both fields back simultaneously in phpMyAdmin and also check wp_usermeta for the session_tokens meta_key — deleting these rows invalidates all active sessions, logging out the attacker before the password change takes effect. Our guide on fixing WordPress session expired errors covers the security key rotation that should follow any lockout caused by unauthorized access, ensuring the attacker’s session is fully invalidated even if they somehow have a valid session token.
Creating a New Admin Account via FTP and functions.php
When database access is unavailable but FTP is — a WordPress site lockout can be resolved by temporarily adding PHP code to the active theme’s functions.php that creates a new administrator account when WordPress next loads.
Connect via FTP → navigate to /wp-content/themes/active-theme/ → download functions.php → add this code at the very end of the file:
function create_emergency_admin() {
if (!username_exists('emergency_admin')) {
$user_id = wp_create_user('emergency_admin', 'TempPass123!', '[email protected]');
$user = new WP_User($user_id);
$user->set_role('administrator');
}
}
add_action('init', 'create_emergency_admin');Upload the modified functions.php — the key step in this WordPress site lockout recovery — back to the server → visit any page on the WordPress site (this triggers WordPress to load and execute the code) → log in with the emergency credentials emergency_admin / TempPass123! → immediately remove the code from functions.php and re-upload → the emergency account remains active but the code that created it is gone. Create a permanent new admin account, update or delete the emergency account, and secure the original admin account. This FTP-based recovery from a WordPress site lockout works even when the WordPress admin is completely inaccessible, as long as FTP access to the theme files is available. Change the temporary password immediately after login — the hardcoded password in a file is a security risk during the window between writing it and removing the code.
Plugin and Theme Lockout Recovery
A plugin-caused WordPress site lockout that introduced a PHP fatal error can be resolved without database or complex FTP procedures — simply renaming the problematic plugin’s folder via FTP or file manager deactivates it, restoring admin access.
Deactivate the problem plugin via FTP to end a WordPress site lockout: connect to the server → navigate to /wp-content/plugins/ → rename the folder of the problematic plugin from “plugin-name” to “plugin-name-disabled” → reload the WordPress admin → if the admin now loads, that plugin was causing the fatal error → rename the folder back to reactivate it and investigate the error before reactivating through the WordPress admin. If the problem is a theme rather than a plugin, rename the active theme folder — WordPress will fall back to a default theme (Twenty Twenty-Four or any available default theme), restoring admin access while the broken theme is investigated. This folder-rename approach is the fastest recovery from a plugin/theme-caused WordPress site lockout because it requires only FTP access and does not require any database changes or understanding of PHP error details.
For WordPress site lockout specifically on managed WordPress hosting where FTP is restricted and phpMyAdmin is not directly accessible, hosting providers typically offer emergency recovery tools through their control panel: Kinsta provides phpMyAdmin access and WP CLI via the MyKinsta dashboard; WP Engine provides phpMyAdmin and a recovery mode for white screen situations; SiteGround provides phpMyAdmin through the hosting control panel. Contact the hosting provider’s support with a clear description of the lockout situation — most managed WordPress hosts have documented emergency recovery procedures and can restore admin access within minutes through their platform tools without requiring direct database or FTP access. Reviews from the WordPress support community confirm that the phpMyAdmin password hash update and the FTP functions.php emergency account creation together resolve the vast majority of WordPress site lockout scenarios across all hosting types and lockout causes. Our guide on WordPress malware removal covers the post-lockout security audit that should follow any WordPress site lockout caused by a hacked account — once access is restored, checking for backdoors and unauthorized changes is essential before returning the site to normal operation.
Preventing future WordPress site lockout situations requires several proactive measures. Store all WordPress credentials (admin username, password, FTP credentials, hosting login, database name and password) in a team password manager (1Password, Bitwarden, LastPass for Teams) — any team member with vault access can retrieve credentials without depending on any single person’s memory. Enable two-factor authentication on all administrator accounts with backup codes stored separately from the authenticator device — our guide on WordPress two factor authentication covers the complete setup that prevents unauthorized admin account takeover while backup codes prevent lockout if the 2FA device is lost. Keep at least two active administrator accounts on any WordPress site — if one account is compromised or locked out, the second provides access to investigate and fix the first. This redundant admin account policy is the simplest single measure that prevents the majority of WordPress site lockout scenarios from becoming genuine emergencies requiring database-level recovery.
Emergency access documentation — a brief document stored securely in the team password manager or printed and stored physically — lists all recovery paths available for the specific hosting environment. For each WordPress site under management, document: the hosting provider and cPanel login URL, the database name and MySQL user credentials, the FTP server address and credentials, the emergency WP CLI commands for common recovery scenarios, and the specific recovery tools available from the hosting provider. This documentation is most valuable when it is needed under stress — having the correct phpMyAdmin URL, database name, and wp_users table structure documented means the recovery can proceed immediately without spending time discovering these details during a WordPress site lockout incident. Update the emergency access document whenever hosting credentials change, when the WordPress installation moves to a new server, or when new recovery options become available through the hosting provider.
The Health Check & Troubleshooting plugin (free, from the WordPress.org directory) provides a built-in safe mode that can help recover from plugin-caused WordPress site lockout scenarios without FTP access — when activated, the plugin creates a special login URL that loads WordPress with all plugins disabled and a default theme active for that session only, allowing the admin to load and deactivate the problematic plugin through the normal interface. Access the safe mode login URL by appending ?troubleshoot=1 to the WordPress login URL — if this parameter is recognised by the installed plugin, it loads the admin in safe mode. This requires the plugin to have been installed before the lockout occurred; it cannot be installed during a lockout. Install and activate Health Check & Troubleshooting proactively on all managed WordPress sites as a preventive measure that makes future plugin-related WordPress site lockout recovery significantly easier without requiring database or FTP access.
WordPress’s built-in recovery mode email addresses a specific type of WordPress site lockout: when WordPress detects a fatal PHP error during login, it automatically sends a recovery mode email to the admin email address containing a special login link that bypasses the fatal error. Click the link in the recovery mode email → WordPress loads the admin with the problematic plugin or theme deactivated → find and deactivate the plugin causing the fatal error → the site restores to normal operation. This recovery mode feature (introduced in WordPress 5.2) works without any FTP or database access, making it the most accessible recovery method when the fatal error is PHP-based and the admin email is accessible. The recovery mode link is single-use and expires after 30 minutes — use it promptly after receiving the email. If the recovery mode email does not arrive (email delivery issues, the error occurs during a background process rather than a user login attempt), proceed with the FTP plugin deactivation method described above.
Multisite network administrators face a unique WordPress site lockout variant: losing Super Admin access while regular site admin access on subsites remains intact. A regular site administrator cannot grant Super Admin privileges through the normal user interface — only existing Super Admins can promote other users to Super Admin. Recovery requires direct database access: phpMyAdmin → wp_sitemeta → search for meta_key = ‘site_admins’ → edit the value → the serialised array contains the usernames with Super Admin rights → add the recovery username to the array. The serialisation format requires careful editing: s:8:"username" where the number matches the character count of the username exactly. Alternatively, WP CLI handles this cleanly: wp super-admin add username — this adds Super Admin status to any existing WordPress user without any serialisation editing risk. On multisite networks, keeping at least two Super Admin accounts active at all times is even more important than on single sites, because the recovery options for a sole Super Admin WordPress site lockout are more complex than for standard single-site administrator account recovery.
