Diagnosing and Fixing the WordPress White Screen of Death

Recognizable condition

The WordPress White Screen of Death (WSOD) appears when a visitor (or admin) loads any page and sees a completely blank screen with no HTML, CSS, or error messages. The site may still respond with HTTP 200, but the output is empty.

Short cause/diagnostic table

Possible cause	Typical clue
PHP memory limit exhausted	Error log contains “Allowed memory size exhausted”.
Theme or plugin conflict	WSOD started after a recent update, activation, or install.
Corrupted core files	Missing or altered files in wp-admin/ or wp-includes/; file permission warnings.
Database connection failure	Error log shows “Error establishing a database connection” or MySQL is unreachable.

Ordered checks

1. Check PHP error logs

   Location depends on your host; common paths are /wp-content/debug.log (if WP_DEBUG_LOG is enabled) or the server’s PHP error log (e.g., /var/log/php7.4-fpm.log).

   Permissions: read access to the log file (usually the web‑user or via SSH).

   Command (Linux):

   # Replace /path/to/site with your WordPress root
   sudo grep -i "Allowed memory size" /path/to/site/wp-content/debug.log
   sudo grep -i "database connection" /path/to/site/wp-content/debug.log
   

   Expected check: If you see a memory‑exhausted message, proceed to the memory fix. If you see a database error, go to the database check. If the log is empty or shows only notices, continue to the next step.

   Risk: None; reading logs is safe.

2. Temporarily increase PHP memory limit

   Edit wp-config.php in the WordPress root.

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

   Place the line above the comment that says “/* That's all, stop editing! Happy publishing. */”.

   Permissions: file write access for the web‑user or via FTP/SSH.

   Expected check: Reload the site. If it loads, the memory limit was the cause. If it remains blank, revert the change (or keep it if you need higher memory) and move on.

   Limitation: Some hosts enforce a hard ceiling; increasing via wp-config may have no effect. Verify with phpinfo() after the change.

   Risk: Minimal; only a configuration change.

3. Rename the plugins folder

   Via FTP, SFTP, or SSH, rename wp-content/plugins to wp-content/plugins-disabled.

   Permissions: write access to wp-content.

   Expected check: Reload the site. If it loads, a plugin is causing WSOD.

   Next step to isolate: Rename the folder back to plugins, then rename each plugin sub‑folder inside it one by one (e.g., akismet to akismet-disabled), reloading after each rename until the offending plugin is found.

   Risk: Site may lose functionality while plugins are disabled; perform on a staging copy if possible.

4. Rename the active theme folder

   If plugins are not the issue, rename the current theme’s folder inside wp-content/themes (e.g., twentytwentyfour to twentytwentyfour-disabled). WordPress will fall back to the latest default theme.

   Permissions: write access to wp-content/themes.

   Expected check: Reload the site. If it loads, the theme caused WSOD.

   Risk: Temporary loss of custom styling; revert after testing.

5. Verify core file integrity

   Download a fresh copy of WordPress matching your version from wordpress.org. Extract and replace the wp-admin/ and wp-includes/ directories (do not overwrite wp-content or wp-config.php).

   Permissions: read access to the archive, write access to wp-admin and wp-includes.

   Expected check: After replacement, reload the site. If it loads, corrupted core files were the cause.

   Risk: Overwriting files incorrectly can break the site; always back up first.

6. Test database connection

   Create a simple PHP script named dbtest.php in the WordPress root:

   <?php
   $host = DB_HOST;
   $user = DB_USER;
   $pass = DB_PASSWORD;
   $db   = DB_NAME;
   $conn = new mysqli($host, $user, $pass, $db);
   if ($conn->connect_error) {
       die('Connection failed: ' . $conn->connect_error);
   }
   echo 'Connected successfully';
   ?>
   

   Access http://yourdomain.com/dbtest.php in a browser.

   Permissions: ability to create and execute a PHP file.

   Expected check: If you see “Connected successfully”, the database is reachable. If you see an error, verify credentials in wp-config.php and ensure the MySQL server is running.

   Risk: Exposes database credentials if left publicly accessible; delete the script after testing.

Fixes tied to findings

• Memory limit exhausted – Increase WP_MEMORY_LIMIT in wp-config.php (as shown) or ask your host to raise the PHP memory limit.
• Plugin conflict – Deactivate the problematic plugin, check for updates, or contact the plugin author. Consider an alternative if the plugin is abandoned.
• Theme conflict – Switch to a default theme temporarily, then either update the theme, patch the problematic code, or use a child theme with overrides.
• Corrupted core files – Replace wp-admin/ and wp-includes/ with fresh copies; ensure file permissions are 755 for directories and 644 for files.
• Database connection failure – Correct DB_NAME, DB_USER, DB_PASSWORD, or DB_HOST in wp-config.php. If the MySQL server is down, restart it or contact your hosting provider.

Escalation criteria

If after completing all six checks the site still shows a blank screen:

• Enable WP_DEBUG (define('WP_DEBUG', true);) and WP_DEBUG_LOG to capture any hidden fatal errors, then review the log.
• Check server‑level logs (e.g., Apache error_log or Nginx error.log) for 500 errors or PHP‑FPM crashes.
• Consider a deeper issue such as a corrupted .htaccess file, incompatible PHP version, or server‑side security module (mod_security, Suhosin) blocking execution.
• At this point, open a ticket with your hosting provider or engage a developer who can inspect server configuration and run a full site health report via WP‑CLI (wp site health).

Practical verification after any fix: Clear any caching layers (browser, plugin, CDN) and load the site in an incognito window to ensure the change truly resolved the WSOD.