Fix the WordPress critical error and white screen of death calmly: back up, read the logs, find the cause by elimination, then handle database, 500, memory, maintenance mode, 404 and login errors.
A WordPress critical error or white screen of death almost always comes from a short list of causes: a faulty plugin or theme, a PHP memory or version problem, a damaged file, or a database or server fault. Fix it in order: back up, read the error and the logs, then switch things off one at a time until the site returns. The fixes below come from the official WordPress and WooCommerce documentation as of October 2026.
In short
Rushing makes an outage worse, so follow the same order every time.
The message reads "There has been a critical error on this website". WordPress's common errors page lists plugin conflicts, theme compatibility issues, an incompatible PHP version, the memory limit and corrupted files as the usual causes.
Recovery mode has existed since WordPress 5.2. When WordPress detects a fatal PHP error during a regular page load (not in cron or background tasks), visitors see the error screen and the administrator receives an email with a login link. The faulty plugin or theme is paused just for your admin session, so you can deactivate it under Plugins or Appearance > Themes, then choose Exit Recovery Mode.
If the email does not arrive, check that the Administration Email Address in Settings > General is read by someone, and look in spam. WordPress warns that the message may be filtered if the error happens before your email plugin loads. Use the file method below.
The common errors page says both PHP errors and database errors can show as a white screen, though in some cases WordPress shows the critical error message instead. The fixes are the same.
If you can reach the admin screens, deactivate all plugins, then reactivate them one by one. If not, use SFTP or your host's file manager, after a backup.
To test one suspect, rename only its folder, for example hello-dolly to hello-dolly-1, as the recovery mode documentation does. Renaming deletes nothing.
If plugins are not the cause, activate a default theme under Appearance > Themes. Without admin access, rename the active theme's folder in wp-content/themes. WordPress then switches to a fallback theme, the latest core default theme that exists (reference), so check that one is installed. If the site returns, check the theme's latest update and any code you added to it.
WordPress's debugging documentation gives these settings. Copy wp-config.php first, then add the lines before the comment "That's all, stop editing":
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_LOG writes messages to debug.log in the content directory, usually wp-content/debug.log, and only works while WP_DEBUG is true. WP_DEBUG_DISPLAY set to false keeps messages out of the page. The documentation says WP_DEBUG is not recommended on live sites, so prefer staging. Site Health flags both displayed errors and a possibly public log file, because debug output can contain sensitive information.
In the log, the newest "Fatal error" line has a path under wp-content/plugins/ or wp-content/themes/ that names the culprit. WooCommerce also keeps a fatal-errors file under WooCommerce > Status > Logs, which does not include web server errors such as timeouts.
Afterwards restore your copy of wp-config.php, or set WP_DEBUG to false and remove the other lines, then delete debug.log.
The common errors page says this is usually caused by wp-config.php: check the database name, username, password and host. Otherwise the cause may be your host: a database over its quota or a server that is down. If a log points to a damaged table, the wp-config documentation describes an automatic repair setting. Back up the database first:
define( 'WP_ALLOW_REPAIR', true );Enable it only if needed and remove it once solved: while it is on, a visitor does not need to be logged in to use the repair script at /wp-admin/maint/repair.php.
The common errors page names a corrupted .htaccess file as the most likely cause. Over SFTP, rename .htaccess to .htaccess_old (it is hidden, so show hidden files) and reload. If that works, open Settings > Permalinks and save: WordPress writes a fresh file, or shows the rules to paste if it cannot, as the Permalinks documentation explains. If the error stays, deactivate plugins, switch theme, raise the memory limit and, last, re-upload wp-admin and wp-includes from a fresh WordPress download, never wp-content or wp-config.php. Nginx has no .htaccess: ask your host for the error log.
"Allowed memory size exhausted" means WordPress lacked memory for the task. WooCommerce's memory limit guide says to add this line to wp-config.php (copy it first) above the "That's all, stop editing" comment, and recommends 256 MB:
define( 'WP_MEMORY_LIMIT', '256M' );If it has no effect, your host may enforce a maximum, so ask the host or set memory_limit in php.ini. WooCommerce > Status shows the WP memory limit in its system status report. If memory runs out again soon, suspect a plugin.
During an update WordPress places a .maintenance file in the folder that holds wp-admin. If the update is interrupted, visitors keep seeing "Briefly unavailable for scheduled maintenance". Wait a few minutes, then delete .maintenance over SFTP and check Dashboard > Updates, because the FAQ says the upgrade should run again in case it failed.
If the home page loads but posts return 404, open Settings > Permalinks: visiting the screen flushes the rewrite rules, and saving shows either "Permalink structure updated" or the rules to paste into .htaccess. The migration guide says to reconfigure permalinks when the moved site goes live and to check the WordPress Address and Site Address. On Apache, also ask whether mod_rewrite is enabled. See moving a WordPress site to a new host.
If the login page reloads after correct details, the Logging In guide says, in order: clear cookies for your site, check wp-config.php for correct WP_HOME and WP_SITEURL, check the siteurl and home values in the options table, and rename the plugins folder. To force the right address (copy wp-config.php first), it shows:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Replace example.com. These lines override the database values without changing them. For "cookies are blocked", the guide says to exclude wp-login.php from page caching.
Mixed content is an HTTPS page that loads images, scripts or stylesheets over HTTP; most browsers block active content such as scripts. Find the culprits in your browser's developer tools, check that the WordPress Address (URL) and Site Address (URL) in Settings > General start with https://, and replace old http:// links in the database. The migration guide warns that a plain search and replace can break serialised data and that the guid column must not change, so back up and use a plugin or WP-CLI's wp search-replace with --dry-run first.
Ask when the database error continues after you confirmed the wp-config.php details, when 500 errors continue after you renamed .htaccess and plugins, when the memory limit will not change, when you cannot read the error log, or when you suspect a hack (see the WordPress security checklist). Send the exact error text, the time and time zone, what changed and what you tried, plus the WooCommerce system status report (Get system report, then Copy for support) if you can reach it. If a plugin or theme bought on DevMarket is the cause, check the support period on its listing.
They share causes. The critical error is the message WordPress shows, with a recovery email, when it catches the error.
Check the Administration Email Address and spam, then rename the plugins folder as shown above.
No. It deactivates the plugins and keeps their settings; you reactivate them by hand.
No. WordPress does not recommend debugging on live sites, and Site Health flags it.
Once the site is back, update with the routine in how to update WordPress and WooCommerce safely and schedule the tasks from the WordPress maintenance checklist. You can also browse licensed WordPress plugins, each listing showing its support period and update policy.
Choose a WordPress theme by testing, not by demo. Compare block and classic themes, sources, speed, accessibility, RTL support, WooCommerce, builder lock-in and licence terms on a staging copy.
9 min read
Use this WordPress maintenance checklist to plan weekly, monthly and yearly tasks: updates, backups, users, plugins, security, speed, PHP, domain and SSL, plus Site Health and WooCommerce checks.
9 min read
Learn how to back up WordPress: what a complete backup contains, host, plugin and manual methods, where to store copies, how often to run them for blogs and stores, and how to restore and test.
9 min read
Every item on DevMarket has a human-reviewed release, an instant licence key and clear update and support terms.