White screen: how to debug a site that says nothing

First thing to do: check the log, not the browser

Site down, white screen, no error message. The fastest check isn't reloading the page: it's opening the PHP error log, which in most cases already contains the line you need, even if nothing appears on screen.

On Ubuntu 24.04 with Nginx and PHP-FPM the command is:

sudo tail -n 50 /var/log/php8.3-fpm.log

(the filename changes with your installed PHP version: on PHP 8.1 it's /var/log/php8.1-fpm.log). If the package doesn't have an active dedicated log, the default path for the PHP-FPM error_log directive is "Path to error log file", with default value #INSTALL_PREFIX#/log/php-fpm.log, as documented in the official PHP manual. On a cPanel instance check instead /usr/local/cpanel/logs/error_log or, for the individual domain, the "Errors" section in the panel (cPanel → Metrics → Errors). On Plesk the file is under /var/www/vhosts/system/<domain>/logs/error_log.

On these shared systems, if you see nothing there either, the problem might be upstream: we'll explain that later.

What the error means

A white screen is almost always a PHP fatal error: the engine stopped before generating any output, and by default production PHP has display_errors disabled, so it prints nothing. The visitor sees blank, you see blank, but somewhere a log is writing the cause.

Enabling logs without exposing them to visitors

If the site is WordPress and you can reach wp-config.php via FTP, SSH or file manager, add these lines before 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 );

With this configuration, the code inserted in wp-config.php will log all errors, warnings and notices to a file called debug.log in the wp-content directory, whilst hiding them so they don't break page generation, as per the official WordPress developer documentation. The file ends up in wp-content/debug.log within your site's filesystem; if you want to move it outside the document root (recommended, because that path is public and predictable) you can replace true with an absolute path: you can set it to a valid file path to save it elsewhere.

Warning: a debug.log file left active in production is a security issue, not just a housekeeping one. Anyone scanning WordPress sites knows that the debug log file is created with a well-known filename, debug.log, and it's usually in the publicly accessible /wp-content/ directory, and an attacker can download it to read paths, partial credentials or SQL queries. Disable WP_DEBUG as soon as you're done.

Reload the page showing white, then:

tail -n 50 wp-content/debug.log

The line that matters is the one starting with PHP Fatal error: followed by the name of the missing function or class and, in brackets, the file and exact line where the error occurred. That's the line telling you whether the cause is a plugin, the theme or the core.

Most common causes, in order

1. An updated or incompatible plugin. This is the most common cause. In the log you'll see the path inside wp-content/plugins/<plugin-name>/.

2. The theme, or a child theme with code in functions.php. The path in the log will be under wp-content/themes/.

3. PHP memory limit exhausted. The log reports "Allowed memory size of ... bytes exhausted".

4. PHP version incompatible with a plugin or the core, typical right after a PHP upgrade by your provider.

5. Corrupted core files or incomplete loading (interrupted FTP upload, automatic update failed halfway).

How to isolate the cause when you can't even access the panel

If wp-admin is white too, you can't disable plugins from the interface. Two options, depending on what you have available.

From filesystem (FTP/SSH). Rename the plugins folder:

mv wp-content/plugins wp-content/plugins-disabled
mkdir wp-content/plugins

WordPress no longer finds the active plugins and considers them all disabled without deleting anything; the page becomes visible if the cause was there. Then you rename the original folder back and move the disabled plugins inside, one at a time, reloading the site after each move, until it goes white again: the one you just moved is the culprit. Same principle for the theme: rename wp-content/themes/<theme-name> to something else, WordPress automatically falls back to a default theme if it finds one installed (e.g. Twenty Twenty-Four).

From database, if you don't have FTP access but have phpMyAdmin or a command-line client:

mysql -u <user> -p <database_name> -e "UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';"

This command empties the list of active plugins without touching the files: it's equivalent to disabling them all from the panel. From there you can reactivate them one by one from wp-admin, or act on the active_plugins row again to manually reinsert them.

If the white screen appears after an update

If the site was working and broke right after an update (plugin, theme, PHP, or WordPress automatic update), the log will almost always tell you the name of the function that no longer exists or expects a different parameter: that's the typical symptom of a PHP version change breaking old code, or a plugin requiring a newer minimum WordPress version than what's installed. Before disabling everything, check the PHP version in use (php -v from SSH, or the Tools → Site Health page in WordPress) and compare it with what the plugin or theme requires in its changelog.

When the problem isn't yours

If the PHP log shows no application error but the site remains white or times out, the suspicion shifts to the layer below: PHP-FPM not responding, resource limits on your hosting plan (memory, processes), or a problem on the provider's node. In this case open a ticket with your host including: the exact time (with timezone) when the white screen occurred, the URL of the affected page, the output of tail from the PHP-FPM log and, if available, the ticket ID or domain ID from the panel. Without these details support starts from scratch and response time increases.

How to verify it's fixed

After the fix, reload the page that showed white and check that the log doesn't record new error lines at the same point. Finally disable WP_DEBUG and, if you moved it, remove the external log file: leaving it active in production only fills the disk and exposes information that shouldn't be public.