The “white screen of death” (WSOD) is a WordPress page that loads completely blank — no error, no content. Behind it is almost always a PHP fatal error that’s hidden because error display is off (correctly, on a production site). The fix is to find that error. On a VPS you have the logs, so this usually takes minutes.

Recent WordPress versions often show “There has been a critical error on this website” instead of a blank page, and email the admin a recovery link. Same cause, same fixes — see also WordPress critical error.

Step 1: read the error log

Check the PHP-FPM and web server logs first; the error is usually already there:

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/php8.3-fpm.log
sudo journalctl -u php8.3-fpm -n 50 --no-pager

Look for lines with PHP Fatal error, for example:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /var/www/example.com/wp-content/plugins/old-plugin/old-plugin.php:42
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

The file path tells you which plugin or theme is responsible.

Step 2: enable WordPress debug logging

If the logs don’t show it, turn on WordPress’s own debug log in wp-config.php (above the “That’s all, stop editing!” line):

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

Reload the broken page, then:

tail -n 30 /var/www/example.com/wp-content/debug.log

WP_DEBUG_DISPLAY false keeps errors out of the page for visitors. Turn debugging off when you’re done — debug.log is publicly downloadable by default unless you block it. See WordPress debug mode.

Step 3: disable plugins

A plugin is the cause in most cases — often right after an update. Disable all of them with WP-CLI:

cd /var/www/example.com
sudo -u www-data wp plugin deactivate --all

If wp-cli itself fails because of the fatal error, skip plugins while running it:

sudo -u www-data wp plugin deactivate --all --skip-plugins --skip-themes

Or rename the plugins directory:

mv wp-content/plugins wp-content/plugins.off

If the site comes back, reactivate plugins one at a time to find the culprit:

sudo -u www-data wp plugin activate woocommerce

When you’ve found it, check for an update, roll back to the previous version (wp plugin install plugin-name --version=1.2.3 --force), or replace it.

Step 4: switch the theme

If plugins aren’t the issue, try a default theme:

sudo -u www-data wp theme install twentytwentyfive --activate

A fatal error in the theme’s functions.php — often from a code snippet pasted into it — is a classic WSOD cause.

Step 5: memory limit

Allowed memory size … exhausted means PHP hit its memory limit. Raise WordPress’s limit in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );   // admin area

WordPress can’t exceed PHP’s own memory_limit, so raise that too in /etc/php/8.3/fpm/php.ini and restart PHP-FPM. More in WordPress memory limit.

If memory keeps running out, a plugin is probably doing something expensive; raising limits hides the problem rather than fixing it.

Step 6: PHP version incompatibility

After upgrading PHP (for example from 7.4 to 8.x), old plugins and themes may use removed functions (create_function, each) or trigger new type errors. The log shows which file. Update the plugin, or replace abandoned ones. See WordPress PHP 8 compatibility.

Step 7: a failed update

An interrupted core update can leave a half-updated site, often with a .maintenance file in the root (“Briefly unavailable for scheduled maintenance”):

rm /var/www/example.com/.maintenance
sudo -u www-data wp core update --force
sudo -u www-data wp core verify-checksums

Step 8: only some pages are blank

  • Only wp-admin is blank → usually a plugin that loads only in the admin; same steps as above.
  • Only one page → a shortcode or block from a specific plugin, or a template file in the theme.
  • Blank after login → caching plugin or object cache serving a broken page: wp cache flush and clear the page cache directory.

Step 9: file permissions and ownership

After restoring files or copying them as root, PHP may not be able to read them:

sudo chown -R www-data:www-data /var/www/example.com

See WordPress file permissions.

Recovery mode

When WordPress detects a fatal error caused by a plugin or theme, it emails the admin a recovery mode link that logs you in with the faulty extension paused. Check the admin email inbox (and spam folder). This needs working outgoing email — see WordPress SMTP.

Prevent the next one

  • Test updates on a staging copy first — see WordPress staging site.
  • Keep daily backups so you can roll back quickly.
  • Remove plugins you don’t use.
  • Monitor the site with Uptime Kuma using a keyword check, which catches blank pages that still return HTTP 200.

With SSH access, none of these fixes requires waiting for a hosting provider’s support. Every WordPress VPS includes root access and full log visibility.

  • WordPress
  • Troubleshooting
  • PHP