WordPress critical error and white screen of death

How to diagnose and fix the WordPress critical error or white screen of death by enabling debug mode, deactivating plugins, increasing memory, checking custom code and restoring core files.

If your WordPress site shows a completely blank white page, or the message "There has been a critical error on this website",1 a PHP error has stopped the page from loading. The blank version is often called the "white screen of death".

Both have the same underlying cause. Since version 5.2, WordPress catches most of these errors and shows the "critical error" message instead of a blank page.2 Errors that happen before WordPress's error handling has loaded can still show a blank page.

The most common causes are a plugin or theme problem, running out of PHP memory, a mistake in custom code, damaged WordPress files, a faulty .htaccess file or a plugin that doesn't work with your server's PHP version. The fix depends on which one is responsible, so it's worth working through them in order.

Check for a recovery mode email

When the error is caused by a plugin or theme, WordPress emails the site administrator a special link to log in using "recovery mode".2 The subject is "[Your site name] Your Site is Experiencing a Technical Issue", and the email usually names the plugin or theme involved.3

Recovery mode pauses the faulty plugin or theme for you while you're logged in, so you can reach the dashboard. Visitors still see the error until you fix it. From the dashboard, deactivate the plugin or theme the email names (or update or replace it), then check the site. Because this doesn't involve editing any files, it's the safest place to start.

Check your inbox and spam folder. The email goes to the administration email address under Settings → General, which may not be the one you use day to day, and WordPress only sends one of these emails a day.4 If your host blocks WordPress from sending email, it may not have been sent at all. In that case, move on to the steps below, and once the site is working, see our guide to fixing WordPress email delivery so the next recovery email gets through.

Turn on debug logging

If recovery mode isn't available, WordPress's debug log is the fastest way to find the exact error.

Open wp-config.php (in your WordPress root folder) via SFTP or your hosting file manager. Download a copy first, since a typo in this file can itself cause a white screen, and the copy lets you put it straight back. Add these lines just above the comment that reads /* That's all, stop editing! */:5

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reload the page that was showing the error, then open wp-content/debug.log. It should contain a "fatal error" message with a file path and line number, which usually points straight at the plugin, theme or file responsible.

When you've finished, remove these lines (or set WP_DEBUG to false) and delete debug.log. The log can reveal details about your site and server, and on many servers files in wp-content can be viewed by anyone who knows the address.

Your host can also check the server's own PHP error log, which records errors even when WordPress can't.

Check plugins and your theme

Plugin and theme problems are the most common cause of this error. If it appeared straight after an update, our guide to recovering a site broken by an update covers rolling back safely. If your debug log points at a particular plugin or theme, start with that one.

If you can reach the dashboard (through recovery mode or otherwise), deactivate plugins under Plugins → Installed Plugins, then reactivate them one at a time, checking the site after each. Deactivating plugins switches their features off for visitors too, so do this at a quiet time or on a staging copy if you can.

If you're locked out of the dashboard, connect via SFTP or your hosting file manager, go to wp-content/plugins/ and rename plugin folders one at a time (for example, from plugin-name to plugin-name-disabled), checking the site after each. WordPress can't load a plugin whose folder has been renamed. Rename the folders back when you've finished, and check each plugin is active again under Plugins.

To test whether your theme is the cause, rename your active theme's folder inside wp-content/themes/. WordPress then switches to its default theme, if one is installed.6 This is a real theme change that visitors will see. When you've finished, rename the folder back, reactivate your theme under Appearance → Themes and check your menus and widgets are still in place.

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, a mistake in that code can take down the whole site. A missing semicolon, an unclosed bracket or a stray character is enough.

If your debug log mentions functions.php or a snippet, connect via SFTP and put back your copy of the file from before the change, or remove the code you added. If you used a code snippets plugin, renaming that plugin's folder in wp-content/plugins/ switches it off, along with all the snippets it runs. Many snippet plugins also have a safe mode, described in their documentation.

As a general rule, avoid editing theme files directly. Use a child theme or a snippets plugin for customisations, and always keep a copy of a file before changing it.

Check PHP memory

If the debug log says "Allowed memory size ... exhausted", a plugin or process is using more memory than PHP allows. WordPress's WP_MEMORY_LIMIT setting lets you ask for more:7

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

Add it to wp-config.php (with a copy of the file saved first). It only works up to the limit your host allows, so if it makes no difference, ask your host whether they can raise the server's limit.

If this fixes the site, something is using a lot of memory, and it's worth finding out what rather than just raising the limit. The debug log usually gives a clue, and your host may be able to tell you whether your plan has enough resources for your site.

Check your PHP version

If the error appeared without any changes on your part, your host may have changed the PHP version on your server. Older plugins and themes can contain code that doesn't work with newer PHP versions, which causes fatal errors.

Check which PHP version is active in your hosting control panel, and ask your host whether it's changed recently. Switching back to the previous version can confirm whether that's the cause, but older PHP versions stop getting security fixes,8 so treat it as a short-term measure. The longer-term fix is to update or replace the plugins or themes that aren't compatible. Plugins that no longer get updates are the usual culprits, and our guide to dealing with closed or abandoned plugins covers replacing them.

Reset .htaccess

On Apache and LiteSpeed servers, a faulty .htaccess file (for example, one with invalid rules written by a plugin) can cause a blank screen or a 500 error. Connect via SFTP and rename .htaccess to .htaccess_old. Renaming keeps a copy of any custom rules. Then try loading the site.

If it recovers, create a fresh file by going to Settings → Permalinks and clicking Save Changes, then copy back any custom rules you still need from .htaccess_old one block at a time, checking the site after each. Our 500 error guide covers .htaccess problems in more detail.

Repair the database

A damaged database table can also cause a fatal error. Take a backup of your database before running a repair, since repairs on badly damaged tables can lose data. Then add this line to wp-config.php:7

define( 'WP_ALLOW_REPAIR', true );

Visit https://example.com/wp-admin/maint/repair.php (replacing example.com with your domain) and run the repair. Anyone can use this page without logging in while the setting is on,7 so remove the line from wp-config.php as soon as you've finished.

Reinstall WordPress core files

If nothing else has worked, WordPress's own files may be damaged or incomplete. Take a backup first, since reinstalling overwrites WordPress's core files. If you can reach the dashboard, go to Dashboard → Updates and click the Re-install version button.9 This replaces the core files without touching your themes, plugins and uploads in wp-content, or your wp-config.php file.

If you can't reach the dashboard, you can replace the core files by hand with a fresh copy of the same WordPress version, following WordPress's manual update process.10 Take great care not to overwrite or delete wp-content or wp-config.php. If you're not confident, this is a job for your host or a developer.

Still seeing a white screen or critical error?

If the error continues after these steps, my WordPress development service and emergency WordPress support can help find and fix the problem. Your hosting provider can also check the server's error logs, which often show the cause directly.


  1. class-wp-fatal-error-handler.php, WordPress source code on GitHub. ↩

  2. Fatal error recovery mode in 5.2, Make WordPress Core, 16 April 2019. ↩ ↩

  3. class-wp-recovery-mode-email-service.php, WordPress source code on GitHub. ↩

  4. class-wp-recovery-mode.php, WordPress source code on GitHub. ↩

  5. Debugging in WordPress, WordPress Advanced Administration Handbook. ↩

  6. theme.php (validate_current_theme), WordPress source code on GitHub. ↩

  7. wp-config.php, WordPress Advanced Administration Handbook. ↩ ↩ ↩

  8. Supported versions, PHP.net. ↩

  9. update-core.php, WordPress source code on GitHub. ↩

  10. Upgrading, WordPress Advanced Administration Handbook. ↩

Adam Greenough

Written by Adam Greenough

Freelance web developer with over 15 years of experience building and fixing WordPress sites. I work with businesses across the UK on everything from emergency support to full builds.

Need emergency WordPress support today?

If your site is down, hacked or throwing errors, send me the details and I will assess the problem quickly. Support starts from £50, you will get a fixed quote before any work begins, and if I cannot fix the issue, you will not pay.