WordPress white screen of death: how to fix it

You load your WordPress site and get nothing. No error message, no broken layout, no partial content. Just a blank white page. This is the WordPress white screen of death (WSOD), and it is one of the most disorienting errors you can encounter because it gives you zero information about what went wrong.

The white screen is not actually a unique error. It is the visible result of a PHP fatal error that WordPress could not recover from, displayed in an environment where error output is suppressed. The fix depends on identifying the actual PHP error hiding behind the blank page.

Since WordPress 5.2, a related error has mostly replaced the classic white screen: “This site is experiencing technical difficulties” or “There has been a critical error on this website.” These messages appear when WordPress catches the fatal error before it causes a blank page. The causes and fixes are identical – the only difference is whether WordPress managed to display a message or not.

Why the screen is white#

PHP is configured by default to hide error messages from visitors. This is a security measure – error messages can reveal file paths, database credentials, and server configuration details that attackers can use. The relevant PHP settings are:

display_errors = Off

When display_errors is off and a PHP fatal error occurs, the browser receives no output at all. No HTML, no error message, nothing. The browser renders this as a blank white page.

WordPress has its own error display layer on top of PHP’s settings. Even if PHP’s display_errors is on, WordPress respects its own WP_DEBUG_DISPLAY constant. By default, both are off in production.

The white screen tells you that PHP crashed during execution but the crash happened silently. Your first step is always to make the error visible.

Step 1: Enable WordPress debugging#

The most direct way to see what is causing the white screen is to enable WordPress debugging. Edit wp-config.php (via SFTP or SSH) and add or modify these lines:

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

This configuration writes all PHP errors to wp-content/debug.log without displaying them to visitors. This is the safe approach for a live site.

If the site is not public (staging, development, or you are the only one accessing it), you can also enable display:

define('WP_DEBUG_DISPLAY', true);

Now reload the page. If the white screen was caused by a PHP fatal error, you will either see the error on screen or find it in the debug log. The error message tells you exactly which file and line number caused the crash, which narrows the problem to a specific plugin, theme, or core file.

For a deeper explanation of PHP error configuration and how the different error levels work, see How to display PHP errors and enable error reporting. For writing errors to a file instead of displaying them (the recommended approach for production), see PHP error logging: how to log errors to a file.

Step 2: Check the PHP error log#

If WP_DEBUG_LOG is enabled, check wp-content/debug.log :

tail -50 wp-content/debug.log

If WP_DEBUG was not enabled before the error occurred, the error may still be in the server’s PHP error log. The location depends on your hosting setup:

• On Hostney, per-site PHP error logs are at  ~/.logs/{your-domain}-php.error.log
• On cPanel hosting, check  ~/logs/error.log  or the Error Log section in cPanel
• On a VPS, check  /var/log/php-fpm/www-error.log  or wherever your PHP-FPM pool is configured to log

The error message will look something like:

PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 4096 bytes) in /home/user/public_html/wp-includes/class-wpdb.php on line 2056

or:

PHP Fatal error: Uncaught Error: Call to undefined function some_function() in /home/user/public_html/wp-content/plugins/some-plugin/main.php on line 142

The file path in the error message tells you whether the problem is in a plugin ( wp-content/plugins/ ), a theme ( wp-content/themes/ ), or WordPress core ( wp-includes/ or wp-admin/ ).

Cause 1: Plugin conflict or crash#

The most common cause of the white screen is a plugin. A plugin update introduced a bug, a plugin is incompatible with your PHP version, or two plugins conflict with each other.

How to confirm

The error log shows a file path inside wp-content/plugins/ . Or you recently updated a plugin and the white screen appeared immediately after.

How to fix

If you can access wp-admin, go to Plugins and deactivate the plugin mentioned in the error. If wp-admin also shows a white screen (which is common, since the plugin loads on every page), you need to deactivate it manually.

Via SFTP or SSH, rename the plugin’s directory:

cd wp-content/plugins/
mv problematic-plugin problematic-plugin-disabled

Reload the site. If the white screen is gone, you have confirmed the plugin is the cause. Either keep it deactivated, update it to a version that works, or find an alternative.

If you are not sure which plugin is the cause, rename the entire plugins directory:

mv plugins plugins-disabled

This deactivates all plugins at once. If the site loads, rename the directory back to plugins , then rename individual plugin directories one at a time to identify the culprit.

The nuclear option for plugin conflicts

If deactivating all plugins fixes the white screen but reactivating them one by one does not reproduce it, the problem is a conflict between two or more plugins that only occurs when they are active simultaneously. This is harder to debug. Reactivate plugins in small groups rather than one at a time, and test after each group.

Cause 2: Theme crash#

Less common than plugins but follows the same pattern. A theme update broke something, or the active theme is incompatible with the current PHP version.

How to confirm

The error log shows a file path inside wp-content/themes/ . Or you recently switched or updated themes.

How to fix

Via SFTP or SSH, rename the active theme’s directory:

cd wp-content/themes/
mv your-theme your-theme-disabled

WordPress will fall back to the latest default theme (Twenty Twenty-Five, Twenty Twenty-Four, etc.) if one is installed. If no default theme is installed, you will see a different error – but at least not the white screen.

Via the database, if renaming the theme directory does not help (or no default theme is installed):

wp option update template twentytwentyfive
wp option update stylesheet twentytwentyfive

Or via direct SQL:

UPDATE wp_options SET option_value = 'twentytwentyfive' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfive' WHERE option_name = 'stylesheet';

Cause 3: PHP memory exhaustion#

WordPress and its plugins consume PHP memory during execution. If the total exceeds the configured limit, PHP terminates the script with a fatal error. Depending on timing, this can produce a white screen or a partial page that cuts off mid-render.

How to confirm

The error log contains: Allowed memory size of X bytes exhausted

How to fix

Increase the PHP memory limit. In wp-config.php :

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

This tells WordPress to request 256 MB from PHP. However, this only works if PHP’s own memory_limit setting is equal to or higher than what WordPress requests. If PHP is configured with memory_limit = 128M , WordPress’s request for 256M is ignored.

On Hostney, the PHP memory limit is set at the platform level with a generous default that covers most WordPress sites. It is not user-configurable through PHP Manager. If your site needs more memory (WooCommerce stores with large product catalogs or sites running page builders sometimes do), contact support and they will adjust it for your account.

For a detailed walkthrough of PHP memory configuration including the difference between WordPress’s WP_MEMORY_LIMIT and PHP’s memory_limit , see WordPress 500 internal server error: what it means and how to fix it.

If increasing the memory limit fixes the white screen but the site keeps hitting the limit during normal operation, the real problem is a plugin or theme that is consuming too much memory. Use a profiling tool or check the error log to identify which component is using the most memory.

Cause 4: Corrupted WordPress core files#

Core files can become corrupted during failed auto-updates, interrupted file transfers, or (rarely) disk errors. If a critical core file is missing or corrupted, WordPress cannot load at all.

How to confirm

The error log references a file in wp-includes/ or wp-admin/ . Or wp-config.php is intact but the site shows a white screen before any plugins or themes load.

How to fix

Reinstall WordPress core files without touching your content:

wp core download --force --skip-content

This downloads a fresh copy of WordPress core files and overwrites the existing ones. The --skip-content flag ensures wp-content/ (your themes, plugins, and uploads) is not touched.

If WP-CLI is not available, download WordPress from wordpress.org, extract it, and upload everything except the wp-content directory and wp-config.php to your site via SFTP.

Cause 5: PHP version incompatibility#

WordPress itself supports PHP 7.4 through 8.3 (as of WordPress 6.7), but individual plugins and themes may not support the full range. A plugin written for PHP 7.4 may crash on PHP 8.2 due to deprecated features being removed. A theme using PHP 8.1 syntax will crash on PHP 7.4.

How to confirm

The error log shows errors related to PHP syntax or removed functions. Common examples:

• Uncaught TypeError: count(): Argument #1 must be of type Countable|array  (PHP 8.0+ enforces stricter type checking)
• Uncaught Error: Call to undefined function create_function()  ( create_function()  was removed in PHP 8.0)
• Uncaught Error: Call to undefined function each()  ( each()  was removed in PHP 8.0)

How to fix

If you recently changed the PHP version, change it back. On Hostney, switch the PHP version in Hosting > PHP Manager. On other hosts, check the PHP version selector in your control panel.

If you did not change the PHP version but a plugin update introduced code that is incompatible with your current version, deactivate the plugin (see Cause 1) and check the plugin’s changelog or support forum for PHP version requirements.

For a deeper look at PHP version compatibility and the risks of running outdated versions, see End-of-life PHP: the risks of running an unsupported version.

Cause 6: Corrupted .htaccess file (Apache only)#

On Apache servers, a malformed .htaccess file can cause a white screen by creating a redirect loop, a 500 error that PHP never sees, or an incorrect rewrite that sends requests to a non-existent file.

How to confirm

The error log is empty (because Apache rejects the request before PHP runs). This only applies to Apache – if your site runs on Nginx, skip this section. Hostney uses Nginx by default, which does not read .htaccess files, so this entire class of white screen causes does not apply.

How to fix

Rename .htaccess via SFTP:

mv .htaccess .htaccess-backup

Reload the site. If it works, go to Settings > Permalinks and click Save to regenerate a clean .htaccess file. Compare the new file with your backup to see what was different.

WordPress recovery mode#

Since WordPress 5.2, WordPress includes a recovery mode that catches fatal errors and sends a recovery link to the admin email address. Instead of a white screen, you see “This site is experiencing technical difficulties” or “There has been a critical error on this website.”

How recovery mode works

When a PHP fatal error occurs, WordPress catches it using PHP’s register_shutdown_function() . If the error is in a plugin or theme, WordPress:

1. Identifies which plugin or theme caused the fatal error
2. Sends an email to the site admin with a special recovery URL
3. Displays the “technical difficulties” message to visitors

The recovery URL contains a token that is valid for a limited time. When you click it, WordPress loads in a special mode where the offending plugin or theme is paused. You can then deactivate it, update it, or investigate the problem from the admin dashboard.

When recovery mode does not work

Recovery mode fails when:

• The admin email is wrong. If the email address in Settings > General is outdated, you never receive the recovery link.
• Email delivery is broken. If the server cannot send email (no SMTP configured, DNS issues, email server blocked), the recovery link never arrives.
• The error is in WordPress core. Recovery mode only catches errors in plugins and themes. A core file error produces the classic white screen.
• The error happens before WordPress loads. If  wp-config.php  itself has a syntax error, WordPress never reaches the recovery mode handler.

In all of these cases, fall back to the manual SFTP/SSH methods described in the causes above.

Accessing recovery mode without the email

If the recovery email did not arrive but you know the error is in a plugin, you can bypass recovery mode entirely by renaming the plugin directory via SFTP. This is faster than waiting for email anyway.

If you need to check what email address WordPress is configured to use:

wp option get admin_email

Or via SQL:

SELECT option_value FROM wp_options WHERE option_name = 'admin_email';

White screen on wp-admin only#

Sometimes the front-end loads but wp-admin shows a white screen (or vice versa). This narrows the cause significantly.

wp-admin white screen, front-end works: The error is in a plugin or theme component that only loads in the admin dashboard. Common causes: a plugin’s admin page has a PHP error, a theme’s functions.php registers an admin hook that crashes, or a dashboard widget plugin is broken.

Front-end white screen, wp-admin works: The error is in the theme’s template files. The admin dashboard uses its own templates and does not load the active theme’s front-end code. Switching to a default theme from wp-admin (Appearance > Themes) will fix it immediately.

Both white screen: The error is in code that loads everywhere – wp-config.php , a must-use plugin, or a core file.

White screen after a WordPress update#

If the white screen appeared immediately after a WordPress core update, the update may have been interrupted and left core files in an inconsistent state.

# Check WordPress version
wp core version

# Verify core file integrity
wp core verify-checksums

verify-checksums compares your core files against the checksums for your WordPress version. If any files are modified or missing, it will tell you which ones. Fix the issue with:

wp core download --force --skip-content

Preventing future white screens#

The white screen itself is just a symptom. The underlying causes – plugin crashes, memory exhaustion, PHP version conflicts – can be minimized with a few practices:

Keep WP_DEBUG_LOG enabled permanently. There is no performance cost. Errors are written to a file that you can check when something goes wrong. Without it, you are debugging blind.

Update plugins on a staging site first. The most common white screen trigger is a plugin update that introduces a fatal error. If you test updates on a staging copy of your site before applying them to production, you catch these before they affect visitors.

Monitor PHP memory usage. If your site regularly uses 80%+ of its memory limit, it is one heavy page load away from a white screen. Increase the limit proactively rather than waiting for the crash.

Keep at least one default theme installed. If your active theme crashes, WordPress can fall back to a default theme. If no default theme is installed, the fallback fails and the white screen has no automatic recovery path.

How Hostney handles this#

Several aspects of Hostney’s architecture make white screen diagnosis and recovery faster.

Per-site PHP error logs. Each site has its own isolated error log, so you are not searching through a shared log file to find your errors. The error log path is always ~/.logs/{your-domain}-php.error.log , and you can access it via SSH or the control panel.

PHP version switching without downtime. If a PHP version change caused the white screen, switching back takes effect immediately through Hosting > PHP Manager – no waiting for a support ticket. The change applies to your site’s container without affecting anything else on the server.

Container isolation. Each site runs in its own PHP container. A white screen on one site does not affect other sites on the same account or server. If a plugin causes PHP to crash and loop, only that container is affected – and it auto-restarts within seconds.

Generous default memory. The platform sets a generous PHP memory limit by default. If your site needs more, support can adjust it for your account without any downtime.

Summary#

The WordPress white screen of death means PHP crashed but error display was suppressed. The fix is always the same sequence: enable debugging to see the actual error, identify whether the cause is a plugin, theme, core file, memory limit, or PHP version issue, then apply the appropriate fix.

The recovery mode introduced in WordPress 5.2 catches many of these cases automatically, but it only works for plugin and theme errors and requires a functional admin email. For everything else, SFTP or SSH access to rename directories and read error logs is the reliable path.

Start with the error log. The answer is almost always there. If the error log is empty, check the web server error log (Nginx or Apache). If both are empty, the error is happening before PHP executes, which points to .htaccess (Apache), a server misconfiguration, or a completely missing index.php. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.