WordPress critical error and white screen of death

If your WordPress site is showing a completely blank white page, or displaying the message "There has been a critical error on your website," a fatal PHP error has stopped the page from rendering. This is sometimes called the "white screen of death" (WSOD).

The blank white screen and the critical error message are caused by the same thing. The difference is that newer versions of WordPress (5.2 and above) catch fatal errors and display the critical error message instead of a blank page. Older versions, or errors that occur before WordPress can load its error handling, show nothing at all.

The most common causes are a plugin or theme conflict, PHP memory exhaustion, a syntax error in custom code, corrupted core files, a bad .htaccess file or a PHP version incompatibility. The fix depends on which of these is responsible, so it's worth working through each possibility in order.

Check for a recovery mode email

Since WordPress 5.2, fatal errors trigger an automatic email to the site administrator with a special recovery mode link. The email subject is typically "Your Site is Experiencing a Technical Issue."

Recovery mode lets you log into a sandboxed version of the WordPress dashboard where you can deactivate the plugin or theme causing the problem without affecting what front-end visitors see. This is the safest first step because it requires no file editing.

Check your inbox and spam folder for the recovery mode email. Keep in mind that the email is sent to the admin email address configured under Settings → General, which may not be the same as your personal email. If your hosting environment restricts the PHP mail() function, the email may not have been sent at all. In that case, move on to the manual steps below.

Enable debug mode

If recovery mode isn't available, enabling WordPress debug mode is the fastest way to find out exactly what's causing the error. Debug mode tells WordPress to log PHP errors to a file instead of failing silently.

Open your wp-config.php file (in the root of your WordPress installation) via FTP, SFTP or your hosting file manager. Add the following lines just above the comment that reads /* That's all, stop editing! */:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Reload the page that was showing the error, then open wp-content/debug.log. The log will contain a fatal error message referencing a specific file path and line number. This usually points directly to the plugin, theme or core file responsible.

Once you've identified the error, disable debug mode by removing these lines or setting WP_DEBUG to false. Leaving debug mode enabled on a live site is a security risk, as the log file can expose information about your server configuration.

Deactivate plugins and switch themes

Plugin and theme conflicts are the most common cause of the critical error and white screen. If your debug log points to a specific plugin or theme file, start by deactivating that one. If you're not sure which is responsible, you'll need to test them individually.

If you can access the WordPress dashboard (through recovery mode or otherwise), go to Plugins → Installed Plugins and deactivate all plugins. If the site recovers, reactivate them one at a time, checking the site after each one to identify the conflict.

If you're locked out of the dashboard, connect via FTP or your hosting file manager and navigate to wp-content/plugins/. Rename each plugin folder one at a time (for example, change plugin-name to plugin-name-disabled) and check whether the site recovers after each one.

To test whether a theme is the cause, rename your active theme's folder inside wp-content/themes/. WordPress will fall back to a default theme if one is installed. If the site loads with a default theme, the problem is in your theme.

Check custom code

If you recently edited your theme's functions.php file, added a code snippet from a tutorial or used a code snippets plugin to add custom functionality, a syntax error in that code can take down the entire site. A missing semicolon, an unclosed bracket or a stray character is all it takes to cause a fatal error.

If your debug log references functions.php or a custom snippet file, connect via FTP and either revert the change you made or remove the code entirely. If you used a code snippets plugin, renaming that plugin's folder in wp-content/plugins/ will deactivate it and the snippets it manages.

As a general rule, avoid editing theme files directly. Use a child theme for customisations, and always keep a copy of the original file before making changes.

Increase the PHP memory limit

If the debug log shows a "memory exhausted" or "allowed memory size" error, a plugin or process is using more memory than PHP has been allocated. You can increase the limit by adding the following line to wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

If the site loads after this change, the immediate problem is solved, but it's worth investigating which plugin or process is consuming so much memory. Check your debug log for clues, and consider whether your hosting plan provides enough resources for the plugins you're running. You may also need to contact your hosting provider to increase the PHP memory allocation at the server level, as the wp-config.php setting only works up to the limit your host permits.

Check your PHP version

If the error appeared without any recent changes on your part, your hosting provider may have upgraded the PHP version running on your server. Older plugins and themes can contain code that is incompatible with newer versions of PHP, which causes fatal errors.

Check your hosting control panel to see which PHP version is currently active. If it was recently changed, try switching back to the previous version temporarily to confirm whether that's the cause. Then update or replace any plugins or themes that aren't compatible with the newer PHP version, as running an outdated version of PHP long-term is a security risk.

Reset .htaccess

A corrupted .htaccess file can cause a white screen, particularly if a plugin wrote invalid rules to it. Connect via FTP and rename .htaccess to .htaccess_old, then try loading the site. If it recovers, regenerate the file by going to Settings → Permalinks and clicking Save Changes.

If your server runs Nginx rather than Apache, there is no .htaccess file and this step doesn't apply.

Repair the database

A corrupted database table can cause a fatal error if WordPress can't read essential data on page load. Add the following line to wp-config.php:

define('WP_ALLOW_REPAIR', true);

Then visit https://example.com/wp-admin/maint/repair.php (replacing example.com with your domain) and run the repair. This page does not require you to be logged in, which is why the feature is disabled by default. Remove the line from wp-config.php as soon as you're finished.

Restore core files

If none of the above has resolved the issue, WordPress core files may be corrupted or incomplete. If you can access the dashboard, go to Dashboard → Updates and click Re-install now. This replaces core files without touching your wp-content folder or wp-config.php.

If you can't access the dashboard, download a fresh copy of WordPress from wordpress.org, extract it and upload the files via FTP. Do not overwrite wp-content or wp-config.php, as these contain your site's content and configuration.

Still seeing a white screen or critical error?

If the error persists after working through these steps, my emergency WordPress support service can help diagnose and resolve the problem.