WordPress White Screen of Death

What this error means & how to recognize it

• The WordPress front end, administration dashboard, or both show a completely blank white page without an error message.
• The failure may affect the entire site or only a specific dashboard screen, template, shortcode, block, or URL.
• The blank page may appear immediately after installing or updating a plugin or theme.
• The problem may start after the hosting provider changes the site's PHP version.
• Affected requests remain blank until the plugin, theme, memory issue, compatibility problem, or damaged file causing the PHP failure is addressed.

Root causes, ordered by likelihood

1. A plugin PHP fatal error — the most likely cause when the problem begins after a plugin installation or update, or when only plugin-related pages fail.
2. An active-theme error — a problem in the theme or its functions.php can affect many pages or the entire site.
3. Exhausted PHP memory — a request may exceed the configured memory_limit; the log commonly reports Allowed memory size exhausted.
4. PHP version incompatibility — a plugin or theme may contain code that does not work with the PHP version currently used by the host.
5. Corrupted WordPress core files — an interrupted or incomplete update can damage core files, although this is less likely when the failure clearly follows a plugin or theme change.

How to fix it

1. Protect the site and identify the failed request

If your hosting tools provide backups, make one before editing files. Note whether the blank page affects the front end, dashboard, or only a particular URL. You will need access to SFTP or the hosting panel's file manager and permission to edit wp-config.php.

2. Enable debug logging without exposing errors to visitors

Open wp-config.php and add or update these settings so each constant appears only once:

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

Keep WP_DEBUG_DISPLAY set to false on a live site. Reload the exact URL that shows the white screen, then inspect wp-content/debug.log. Look for the fatal error, the file path, and the line number. If the WordPress log is not created or does not contain the event, ask the host to check the account's PHP error log.

3. Disable the plugin identified by the log

If the error names a plugin, use SFTP or the hosting file manager to open wp-content/plugins/. Rename the relevant plugin folder by adding a suffix such as -disabled. Renaming prevents WordPress from loading the plugin while preserving its files and settings.

Reload the failed URL. If it works, the plugin is the immediate cause. Check for a compatible update or contact the plugin developer if no suitable update exists for the site's WordPress and PHP versions. Do not leave an incompatible or outdated plugin active merely because renaming its folder restored the site.

4. Test the active theme

If the log points to the active theme, or disabling the identified plugin does not help, rename that theme's folder in wp-content/themes/. WordPress should fall back to an available default theme.

If the site recovers, inspect the file and line reported in the log, with particular attention to functions.php. If no usable fallback theme is installed, restore the original folder name after testing and contact the theme provider or host before making further changes.

5. Resolve a memory-exhaustion error

If the log reports Allowed memory size exhausted, the failed request exceeded the configured PHP memory limit. Follow the site's hosting or WordPress administration procedure for raising the limit safely, and investigate whether a plugin, theme, or specific request is consuming excessive memory.

After making an authorized configuration change, reload the same URL and confirm that the identical fatal error is no longer being logged. Raising the limit may only mask an inefficient or incompatible component, so continue investigating if the error returns.

6. Check PHP-version compatibility

If the white screen began after a PHP version change, compare the timing with the plugin or theme named in the log. Temporarily disabling that extension can help confirm the relationship.

Ask the host whether a temporary PHP-version rollback is available while the plugin or theme is updated, replaced, or corrected. Treat a rollback as a diagnostic or temporary measure, not a permanent compatibility fix.

7. Restore core files only when the evidence supports it

If no plugin, theme, PHP, or memory change explains the failure and the log does not identify an extension, damaged WordPress core files are possible. Re-upload matching WordPress core files from a fresh official WordPress download through SFTP.

Do not overwrite wp-content or wp-config.php. If you cannot reliably distinguish core files from site content and configuration, stop and ask the host or a WordPress professional for help.

8. Verify the recovery and clean up

Reload the exact front-end URL or administration screen that was blank. Test related pages using the same plugin, theme, shortcode, or block. Review wp-content/debug.log and confirm that the same fatal error is not recurring.

Once the cause is confirmed, disable temporary debugging changes or ensure that any retained log is protected from public access.

Prevention & how to verify the fix

• Back up the site before updating WordPress, plugins, themes, or the hosting PHP version.
• Update plugins and themes one at a time so the change associated with a failure is identifiable.
• Test major WordPress, PHP, theme, and plugin changes on a staging copy before applying them to production.
• Keep WP_DEBUG_DISPLAY disabled on live sites and restrict access to any debug log.
• Monitor available PHP memory and investigate components that repeatedly approach the configured limit.
• After each fix, reload the exact failed URL and review the log for a recurrence of the same fatal error.

Frequently asked questions