2026年11月12日
2026年11月12日
Can’t Access WordPress Admin After an Update? How to Find and Fix It
This article is a localized edition of the Japanese original. Read the Japanese original
When the WordPress admin (/wp-admin/) stops opening after you update WordPress, a plugin or a theme, the cause is usually a bug in the updated plugin or theme, an update that was interrupted, or a PHP version mismatch. This article shows how to narrow down the cause from the message on the screen and fix it step by step.
Before you start, back up your site files and database. If your host provides automatic backups, check whether you can restore to a point before the update, so you have a fallback if these steps don't solve the problem. Run the WP-CLI commands over SSH in the directory where WordPress is installed.
Identify the cause from the message on screen
| What you see | Likely cause | Section to read |
|---|---|---|
| "There has been a critical error on this website." | A fatal PHP error in a plugin or theme | Recovery mode, debug log |
| A completely white screen (nothing displayed) | A fatal PHP error (on a server where error display is turned off) | Debug log |
| "Briefly unavailable for scheduled maintenance." | An update stopped partway and left .maintenance behind |
Delete .maintenance |
| "Database Update Required" | The database update after a core update has not run | Update the database |
| You keep getting sent back to the login screen, or you get a 403 / 404 | Cookies, .htaccess, or security plugin settings |
Check .htaccess |
1. Check for the recovery mode email
Since WordPress 5.2, when a plugin or theme causes a fatal PHP error, WordPress emails the administrator address (the Administration Email Address under "Settings → General" with the error details and a link to enter "recovery mode". The email begins with text explaining that WordPress has a built-in feature that detects when a plugin or theme causes a fatal error on your site.
- Open the link in the email and log in
- The admin shows which plugin or theme was paused as the cause, along with its error
- Deactivate the plugin responsible, or switch themes
- Leave recovery mode with "Exit Recovery Mode" in the admin bar
During recovery mode, the faulty plugin or theme is paused only in the browser that opened the link. Visitors still see the error, so deactivate or otherwise fix the problem before you exit.
The link in the email expires. If the email doesn't arrive, check your spam folder or use the method in the next section to find the cause. If you add the RECOVERY_MODE_EMAIL constant to wp-config.php, the email is sent to that address instead of the administrator email.
<?php
// Add to wp-config.php above the "That's all, stop editing!" line
define( 'RECOVERY_MODE_EMAIL', 'admin@example.com' );
2. Read the error in the debug log
If no email arrives, or you see a white screen, write the error to a log and read it. Change WP_DEBUG in wp-config.php as follows (if define( 'WP_DEBUG', false ); is already there, replace that line).
<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // write to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // don't show errors on screen
@ini_set( 'display_errors', 0 );
Save the file, reload the admin, and then check wp-content/debug.log.
tail -n 30 wp-content/debug.log
The PHP Fatal error line shows the path of the file where the error occurred. If the path contains wp-content/plugins/plugin-name/, that plugin is the likely cause; if it contains wp-content/themes/theme-name/, that theme is.
debug.log is created in a location that can be read from the web. When you're done, set WP_DEBUG back to false and delete debug.log. The same errors may also appear in the server's PHP error log (its location depends on the server; on shared hosting you can often view it from the control panel).
3. Delete .maintenance (if the maintenance message won’t go away)
During an update, WordPress creates a file called .maintenance in the installation directory and deletes it when the update finishes. If the update stops partway, the file is left behind and the maintenance message keeps appearing.
ls -la .maintenance
rm .maintenance
Because the file name starts with a dot, FTP clients may not show it unless you enable hidden files. After deleting it, rerun the interrupted update from "Dashboard → Updates". A plugin whose update stopped partway may have missing files.
4. Disable plugins to isolate the cause
To disable plugins while you can't reach the admin, use WP-CLI or rename files.
# If you know the culprit: deactivate just that plugin
wp plugin deactivate plugin-slug
# If you don't: deactivate everything for now
wp plugin deactivate --all
If WP-CLI itself fails with an error, run it without loading plugins and themes.
wp plugin list --skip-plugins --skip-themes
wp plugin deactivate --all --skip-plugins --skip-themes
If you can't use WP-CLI, rename the plugin's folder inside wp-content/plugins/ with FTP or your host's file manager (for example example-plugin → example-plugin.off). WordPress can no longer find that plugin's files and stops loading it. If you don't know which plugin is the cause, rename the whole wp-content/plugins folder to disable every plugin.
Once you can reach the admin, reactivate plugins one at a time to see which one brings the error back. For the plugin responsible, check the author's support forum for reports of the same problem, and keep it deactivated until a fix is released or roll back to the previous version.
5. Switch themes to test
If disabling plugins doesn't help, the theme may be the cause. If a default WordPress theme (such as Twenty Twenty-Five) is installed, switch to it.
wp theme list
wp theme activate twentytwentyfive
If you can't use WP-CLI, open the database's wp_options table in phpMyAdmin or a similar tool (adjust the name if your table prefix isn't wp_), and change the option_value of the two rows whose option_name is template and stylesheet to the folder name of an installed default theme (for example twentytwentyfive). Note the original values first. If no default theme is installed, download one from WordPress.org and upload it to wp-content/themes/ first.
6. Check the PHP version
A fatal error can also happen when an updated plugin or theme needs a newer PHP version than your server runs. If the debug log shows a syntax error or a call to a function that doesn't exist (Call to undefined function), check the PHP version.
php -v
wp cli info
The command-line php and the PHP used by the web server can be different versions. Check the web server's version in your hosting control panel. The PHP version a plugin requires is listed as "Requires PHP" on its WordPress.org plugin page. As of November 2026, WordPress.org recommends PHP 8.3 or later.
7. Update the database
If "Database Update Required" appears after a core update, click the button on that screen or open /wp-admin/upgrade.php to run the update. With WP-CLI, use this command:
wp core update-db
If the screen keeps coming back, the core file update may have only partly completed. Reinstall the core files as described in the next section.
8. Verify and reinstall core files
When an automatic or manual core update stops partway, files in wp-admin or wp-includes can end up missing or out of date. WP-CLI can check whether they match the official files.
# Check the current version
wp core version
# Compare against the official checksums (lists mismatched or missing files)
wp core verify-checksums
If there are mismatches, download the core files for the same version again and overwrite them. With --skip-content, wp-content (themes, plugins and uploads) is left untouched.
wp core download --version=$(wp core version) --skip-content --force
If you can't use WP-CLI, download the ZIP for the same version from WordPress.org and replace the wp-admin and wp-includes folders entirely. Do not overwrite the wp-content folder or wp-config.php.
9. Check .htaccess
If you get a 404 or 403 after logging in, or only the admin won't open, check .htaccess. Security plugins sometimes add rules that restrict access to /wp-admin/.
First make a copy of the current .htaccess, then reduce it to the standard WordPress rules and test. The standard rules are shown below (if WordPress is installed in a subdirectory, the paths in RewriteBase and the last line change).
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
cp .htaccess .htaccess.bak
If the standard rules fix the problem, restore your copy and remove the added rules one at a time to find the culprit. Once you can reach the admin, go to "Settings → Permalinks" and click "Save Changes" without changing anything; WordPress rewrites its own section.
If you keep getting sent back to the login screen, clear your browser cookies and try again, then check that the site URLs in wp-config.php or the database (siteurl and home) match the actual URL.
wp option get siteurl
wp option get home
After the problem is fixed
- Set
WP_DEBUGback tofalseand deletewp-content/debug.log - Rename any folders back to their original names and reactivate plugins that were deactivated. Keep the faulty plugin deactivated until a fix is released
- To prepare for the next update, decide how you will take a backup beforehand and how you will test on a staging site first
Related articles
- How to enable WordPress debug mode
- How to disable plugins when you can't log in to the admin
- How to update WordPress safely
Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)