The WordPress White Screen of Death (WSOD) is one of the most frustrating errors you will encounter. Your site loads a blank white page with no error message, no admin access, and no obvious cause. This checklist walks you through every troubleshooting step in logical order, from quick wins to deep server diagnostics.
Understanding the White Screen of Death
The WSOD typically indicates a PHP fatal error that prevents WordPress from rendering any output. The error might originate from a plugin conflict, theme issue, memory exhaustion, or corrupted core files. Because PHP error display is often disabled in production, you see nothing but white.
Before you start, determine the scope. Does the white screen affect only the admin area, only the front end, or both? Does it happen on all pages or specific ones? This narrows your focus.
Enable Debug Logging First
Your first action is making errors visible. Edit wp-config.php via FTP, SFTP, or your hosting file manager. Find the line that says define('WP_DEBUG', false); or add these lines just before /* That's all, stop editing! */:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);
This writes errors to wp-content/debug.log without displaying them publicly. Reload the white screen page, then check the log file. The error message usually points directly to the cause.
If you cannot access files, skip to the server-level checks.
Check PHP Memory and Execution Limits
Memory exhaustion is a common cause. Increase the PHP memory limit by adding this line to wp-config.php before the debug settings:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');
If your host enforces a lower limit via php.ini or server configuration, contact support to raise it. Many shared hosts default to 128M, which is insufficient for sites with multiple plugins or page builders.
Check your current limit with a temporary PHP info file. Create info.php in your site root:
<?php phpinfo(); ?>
Visit yoursite.com/info.php in a browser, search for memory_limit, note the value, then delete the file immediately for security.
Deactivate All Plugins
Plugin conflicts cause the majority of WSOD incidents. If you can access wp-admin, deactivate all plugins from the Plugins screen. If the white screen blocks admin access, use the file system.
Via FTP or file manager, navigate to wp-content/plugins/. Rename the plugins folder to plugins-disabled. This deactivates every plugin instantly. Refresh your site. If it loads, the issue is plugin-related.
Rename the folder back to plugins, then rename each individual plugin folder one at a time, testing after each. When the site breaks, you have found the culprit. Leave that plugin disabled and investigate updates or alternatives.
If you use WP-CLI, SSH in and run:
wp plugin deactivate --all
Then reactivate one by one:
wp plugin activate plugin-name
Switch to a Default Theme
Theme functions can trigger fatal errors just like plugins. If deactivating plugins did not resolve the white screen, switch themes. From wp-admin (if accessible), activate a default WordPress theme like Twenty Twenty-Four.
From the file system, rename your active theme folder inside wp-content/themes/. WordPress will fall back to the most recent default theme. If your site loads, the theme is at fault. Check for theme updates, restore a backup, or contact the theme developer.
With WP-CLI:
wp theme activate twentytwentyfour
Increase PHP Max Execution Time
Scripts that run too long can time out and produce a blank page. Edit .htaccess (if using Apache) and add:
php_value max_execution_time 300
Or in php.ini (if you have access):
max_execution_time = 300
Restart your web server if you modified php.ini. For Nginx with PHP-FPM, adjust the request_terminate_timeout directive in your pool configuration.
Check for Corrupted Core Files
WordPress core file corruption is rare but possible after a failed update or server issue. Download a fresh copy of WordPress from the official site (matching your installed version) and replace wp-admin and wp-includes directories via FTP. Do not touch wp-content or wp-config.php.
With WP-CLI, verify and repair core files:
wp core verify-checksums
wp core download --skip-content --force
The --force flag overwrites existing files without removing your content or configuration.
Review Web Server Error Logs
WordPress-level logs show PHP errors, but web server logs capture timeouts, permission issues, and resource limits. In cPanel, visit "Errors" under the Metrics section. Look for 500 or 503 errors coinciding with your white screen incidents.
On a VPS or dedicated server, check:
- Apache:
/var/log/apache2/error.logor/var/log/httpd/error_log - Nginx:
/var/log/nginx/error.log
Search for "segmentation fault," "Allowed memory size exhausted," or "Maximum execution time exceeded." These indicate resource or configuration problems at the server level.
Verify File and Directory Permissions
Incorrect permissions can prevent PHP from reading files or writing to the database. Standard WordPress permissions are:
- Directories:
755 - Files:
644 wp-config.php:600or640
Reset permissions recursively via SSH:
find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
chmod 600 /path/to/wordpress/wp-config.php
Replace /path/to/wordpress/ with your actual document root. In cPanel File Manager, select folders, click Permissions, and adjust as needed.
Check Database Connectivity
A lost database connection often produces a "Error establishing a database connection" message, but in some configurations it can yield a blank page. Verify credentials in wp-config.php:
define('DB_NAME', 'database_name');
define('DB_USER', 'database_user');
define('DB_PASSWORD', 'password');
define('DB_HOST', 'localhost');
Test the connection manually. Create db-test.php in your site root:
<?php
$conn = mysqli_connect('localhost', 'database_user', 'password', 'database_name');
if ($conn) {
echo 'Database connection successful';
} else {
echo 'Connection failed: ' . mysqli_connect_error();
}
?>
Visit yoursite.com/db-test.php, note the result, then delete the file. If the connection fails, check that the database server is running and credentials are correct in your hosting control panel.
Repair the WordPress Database
Corrupted tables can cause unpredictable behavior. Add this line to wp-config.php:
define('WP_ALLOW_REPAIR', true);
Visit yoursite.com/wp-admin/maint/repair.php in your browser. Click "Repair Database" or "Repair and Optimize Database." When finished, remove the WP_ALLOW_REPAIR line immediately because the repair page is publicly accessible.
With WP-CLI:
wp db repair
wp db optimize
Review Recently Changed Files
If the white screen appeared after a recent edit, code change, or FTP upload, revert that change. Check your FTP client logs or hosting file manager activity log if available. Restore the previous version of the modified file from a backup.
For sites under version control, roll back the last commit:
git log --oneline -5
git checkout HEAD~1 path/to/file.php
Clear Caching Layers
Aggressive caching can serve a stale white screen even after you fix the underlying issue. Clear:
- WordPress object cache: Delete files in
wp-content/cache/or flush Redis/Memcached. - Plugin caches: Purge WP Rocket, W3 Total Cache, or WP Super Cache.
- CDN cache: Purge Cloudflare, StackPath, or your CDN provider.
- Opcode cache: Restart PHP-FPM or run
opcache_reset()from a temporary PHP script. - Browser cache: Hard refresh with Ctrl+Shift+R or Cmd+Shift+R.
With WP-CLI:
wp cache flush
For Cloudflare:
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"purge_everything":true}'
Check .htaccess for Syntax Errors
A malformed .htaccess file produces 500 errors and sometimes blank pages. Rename .htaccess to .htaccess-backup and test your site. If it loads, regenerate permalinks from Settings > Permalinks in wp-admin to create a clean .htaccess.
If you made manual edits, review them for typos or incompatible directives. Common mistakes include missing RewriteEngine On or unescaped special characters in rewrite rules.
Verify PHP Version Compatibility
Running an outdated or too-new PHP version can break plugins and themes. WordPress core supports PHP 7.4 and above, but many plugins still require specific versions. Check your current PHP version in cPanel under "Select PHP Version" or via command line:
php -v
If you recently upgraded PHP and the white screen started immediately after, switch back to the previous version temporarily, then update plugins and themes before retrying.
Restore from Backup
If none of the above resolves the issue, restore a working backup. Most hosts provide automated daily backups via cPanel or Plesk. Download a backup from before the white screen appeared and restore the public_html directory and database.
With a manual backup:
- Extract the backup archive to your local machine.
- Upload files via FTP, overwriting the broken installation.
- Import the database via phpMyAdmin or command line:
mysql -u database_user -p database_name < backup.sql
Always test a restore on a staging site first if possible.
Contact Your Host for Server-Level Issues
If you have exhausted file-level and application-level checks, the issue may originate from the server. Contact your hosting support and provide:
- The exact URL showing the white screen
- Contents of
wp-content/debug.log - Relevant lines from web server error logs
- Steps you have already taken
They can check for resource limits (CPU, I/O, memory), mod_security blocks, PHP worker exhaustion, or misconfigured server software that you cannot access.
Conclusion
The WordPress White Screen of Death is almost always solvable with a methodical approach. Start by enabling debug logging to identify the error, then work through plugin conflicts, theme issues, memory limits, and server configuration. Most cases resolve within the first few checklist items. For persistent issues, server logs and hosting support are your next resource. Keep backups current and test changes in staging to minimize downtime.