The WordPress White Screen of Death (WSOD) is exactly what it sounds like: your site loads a completely blank white page with no error message, no content, and no obvious indication of what went wrong. It's one of the most disorienting WordPress errors because it gives you nothing to work with. Here's how to diagnose and fix it systematically, starting with the fastest checks.
The WSOD is almost always a PHP error that WordPress is suppressing rather than displaying. The most common causes are: a plugin or theme with a PHP fatal error, a memory limit being exceeded, a file permissions issue, or a corrupted WordPress core file. The blank screen means PHP started executing but couldn't complete.
The reason there's no visible error message is that WordPress disables PHP error display in production by default, a sensible security measure that becomes frustrating when you're trying to diagnose a crash. Your first job is to get that error message surfaced somewhere you can read it.
Note whether the WSOD affects your entire site or only the admin area. A white screen on the front end but a working wp-admin usually points to a theme issue. A white screen only in wp-admin but a working front end points to a plugin that affects the dashboard. Both front end and back end blank is typically a plugin with a sitewide hook, a memory exhaustion, or a corrupted core file.
Connect to your site via FTP or your host's file manager and open wp-config.php. Find the line that reads define( 'WP_DEBUG', false ); and replace it with:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Setting WP_DEBUG_DISPLAY to false means errors are written to a log file rather than displayed publicly on the page, important if real visitors might see your site during diagnosis. Reload the site, then check /wp-content/debug.log for the actual error message. It will almost always name the exact file and line number causing the problem.
In addition to WordPress's own debug log, your hosting server maintains its own error log. In cPanel this is under Logs > Error Log. The server error log captures PHP fatal errors even when WordPress isn't able to write to its debug log, for example, if the error occurs before WordPress fully initialises.
Look for lines timestamped around when the WSOD started appearing. A typical entry will look like: PHP Fatal error: Call to undefined function in /wp-content/plugins/some-plugin/file.php on line 84. That tells you exactly what to fix.
Via FTP or file manager, navigate to /wp-content/plugins/ and rename the entire plugins folder to plugins_disabled. This deactivates all plugins at once without touching the database. Reload your site, if the white screen is gone, a plugin is the culprit.
Rename the folder back to plugins, then deactivate plugins one by one from your wp-admin dashboard to isolate the problem. Start with the most recently installed or updated plugin, that's the most likely candidate. If you can't access wp-admin because the white screen affects the backend too, use phpMyAdmin to deactivate plugins via the database: look for the active_plugins option in the wp_options table and set its value to a:0:{}.
Via FTP, rename your active theme folder in /wp-content/themes/. WordPress will fall back to a default theme (Twenty Twenty-Four or similar). If the site loads, your theme contains a PHP error. The most common location is functions.php, check that file first for syntax errors or calls to functions that require a plugin that may have been deactivated.
If you recently edited the theme's functions.php, a syntax error there (a missing semicolon or unclosed bracket) is the single most common cause of a WSOD after a code edit. You can switch to a different theme from wp-admin once the fallback is loaded, then fix the syntax error in your original theme.
Memory exhaustion causes a WSOD when PHP cannot complete execution due to hitting the memory ceiling. Add the following line to your wp-config.php above the line that reads "That's all, stop editing!":
define( 'WP_MEMORY_LIMIT', '256M' );
If memory was the cause, this resolves it immediately. You can also try setting this in .htaccess with php_value memory_limit 256M if your host allows PHP directives via .htaccess. If neither works, your hosting plan has a hard PHP memory cap that requires a plan upgrade or a support request to your host.
Download a fresh copy of WordPress from wordpress.org, extract the zip, and use FTP to overwrite your existing wp-admin and wp-includes folders. Do not overwrite wp-content or wp-config.php, these contain your content and site configuration and must not be replaced. Corrupted core files are a less common cause of the WSOD but they do occur after failed auto-updates or server-side file system issues.
Set WP_DEBUG back to false in wp-config.php once you've resolved the issue. Running debug mode in production exposes server file paths and code details in your debug log that can be useful to malicious scanners if that log is publicly accessible. Also check that /wp-content/debug.log is not readable via the web, add the following to your .htaccess to block direct access:
<Files debug.log>
Order allow,deny
Deny from all
</Files>
Finally, if a plugin caused the WSOD, check whether an update is available for it that fixes the issue, or find an alternative. Running known-broken plugins is an ongoing risk.
HostBible WordPress plans include daily backups so you can roll back to before the error in one click. LiteSpeed, staging, and support from people who know WordPress.
View Hosting Plans