How to Fix the WordPress White Screen of Death

The WordPress White Screen of Death is a blank page that appears when WordPress cannot finish loading. You may see a completely white browser window, a generic 500 Internal Server Error, or the newer message that says, “There has been a critical error on this website.”
The cause is usually a PHP fatal error, a plugin or theme conflict, a memory limit problem, or a broken update. Since WordPress 5.2, many fatal errors also trigger Recovery Mode, which sends a special login link to the site administrator.
This guide explains how to bring a WordPress site back online, starting with the safest fixes and moving toward deeper debugging only when needed.
Quick Reference
| Problem | First place to check |
|---|---|
| Critical error message | WordPress Recovery Mode email |
| Blank frontend only | Active theme, cache, page builder, or template code |
| Blank admin area | Plugin conflict, admin hook, PHP fatal error |
| Blank site after update | Recently updated plugin, theme, or PHP version |
| Intermittent blank pages | PHP memory limit, server logs, object cache |
| No visible error | wp-content/debug.log or hosting PHP error log |
wp-config.php, or restoring core files.What Causes the WordPress White Screen of Death
WordPress is a PHP application. If PHP stops with a fatal error before WordPress can render the page, the browser may receive an empty response. In production, PHP errors are often hidden for security reasons, so the only visible symptom is a white page.
Common causes include:
- A plugin update that introduces a fatal PHP error
- A theme function or template that is incompatible with the current WordPress or PHP version
- A PHP memory limit that is too low for the site
- Broken or incomplete WordPress core files after an update
- Corrupted cache from a page cache, object cache, CDN, or browser
- Database errors that stop WordPress before the page loads
If the server returns a 500 status instead of a blank page, the root cause is often similar. See the 500 Internal Server Error guide
for the broader server-side checks.
Step 1: Check the Recovery Mode Email
Start with the site administrator email inbox. When WordPress detects a fatal error, it may send an email with the subject Your Site is Experiencing a Technical Issue.
Open that email and use the Recovery Mode link. WordPress will let you log in even when the public site is broken. It usually identifies the plugin or theme that caused the fatal error.
Once inside Recovery Mode, disable the broken plugin or switch away from the broken theme. Then reload the site in a private browser window to confirm that it works for normal visitors.
If you do not receive the email, check the spam folder and confirm that the site can send email. Many hosting panels also expose the PHP error log, which can show the same fatal error without needing the Recovery Mode email.
Step 2: Find Out What Part of the Site Is Broken
Before changing files, check the scope of the problem:
- Visit the homepage and a few internal pages.
- Open
/wp-admin/in a private browser window. - Try the login page at
/wp-login.php. - Check the same URL with a different browser or device.
- If you use a CDN or cache plugin, bypass the cache if possible.
If only one page is blank, the issue may be a page template, shortcode, block, or page builder widget. If the whole site and admin area are blank, start with plugins and the active theme.
Step 3: Disable Plugins Safely
Plugin conflicts are one of the most common causes of a blank WordPress site. If Recovery Mode names a specific plugin, disable that plugin first.
If you have SSH access and WP-CLI is installed, list active plugins:
wp plugin list --status=activeDisable a suspected plugin by its slug:
wp plugin deactivate plugin-slugIf you do not know which plugin failed, disable all plugins:
wp plugin deactivate --allReload the site. If it works, reactivate plugins one by one until the white screen returns. The last plugin you enabled is the likely cause.
If you do not have WP-CLI access, use your hosting file manager or SFTP. Go to the WordPress root directory and rename the plugin folder:
mv wp-content/plugins wp-content/plugins.disabledCreate a new empty plugins directory so WordPress has a normal path again:
mkdir wp-content/pluginsIf the site loads after that, move plugins back one at a time from plugins.disabled into plugins, testing after each move.
Step 4: Switch to a Default Theme
If plugins are not the cause, check the active theme. A broken functions.php file, template, or theme update can stop WordPress before it renders anything.
With WP-CLI, switch to a default theme such as Twenty Twenty-Five:
wp theme activate twentytwentyfiveIf that theme is not installed, list the available themes:
wp theme listWithout WP-CLI, use SFTP or the hosting file manager and rename the active theme directory:
mv wp-content/themes/active-theme wp-content/themes/active-theme.disabledWordPress will try to fall back to another installed theme. If no default theme is installed, upload one from a clean WordPress package or restore the theme from backup.
Step 5: Enable WordPress Debug Logging
If disabling plugins and switching themes does not fix the site, enable debug logging so WordPress records the actual PHP error.
Open wp-config.php in the WordPress root directory and add these lines above the line that says That's all, stop editing:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reload the broken page once, then check the debug log:
tail -n 50 wp-content/debug.logLook for PHP Fatal error, Allowed memory size exhausted, Call to undefined function, or a file path inside a plugin or theme. The file path usually tells you what to disable or update.
After you finish debugging, turn logging off again:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );Do not leave debug display enabled on a public site. PHP errors can expose paths, plugin names, and other implementation details.
Step 6: Increase the PHP Memory Limit
If the log shows Allowed memory size exhausted, increase the WordPress memory limit.
Add this line to wp-config.php above the stop-editing comment:
define( 'WP_MEMORY_LIMIT', '256M' );Some hosts also require raising the PHP memory_limit value in the hosting panel, php.ini, .user.ini, or .htaccess. If the host caps memory below what the site needs, contact support or reduce the load by disabling heavy plugins.
Memory errors often point to an underlying problem. If the site suddenly needs much more memory after a plugin update, treat the plugin as suspicious instead of only raising the limit.
Step 7: Check PHP Version and Recent Updates
A site can white-screen after a host changes PHP versions or after WordPress, a plugin, or a theme updates.
Check the PHP version from the command line:
php -vCheck the WordPress version:
wp core versionIf the white screen started right after switching PHP versions, change back to the previous supported version in your hosting panel and test again. Then update the incompatible plugin or theme before moving forward.
If the issue started after a WordPress core update, restore from a backup if needed. You can also reinstall WordPress core files without touching wp-content:
wp core download --force --skip-contentRun that only from the correct WordPress root directory, and only after you have a backup.
Step 8: Clear Cache Layers
Cache rarely causes a true PHP fatal error, but it can keep showing a blank page after the underlying problem has been fixed.
Clear each cache layer you use:
- WordPress cache plugin
- Object cache such as Redis or Memcached
- Hosting cache
- CDN cache
- Browser cache
If the admin area works, clear cache from the plugin or hosting dashboard. If the admin area is still broken, disable the cache plugin like any other plugin and purge cache from the hosting panel or CDN dashboard.
Step 9: Restore a Backup or Contact Hosting Support
If the site still shows a white screen after plugins, themes, debug logs, memory, PHP version, and cache checks, restore the last known working backup.
Before restoring, save a copy of the current site files and database. That gives you a way to recover recent uploads, orders, comments, or form submissions that happened after the backup date.
Contact hosting support when:
- The PHP error log points to server modules or permissions.
- The site fails before WordPress loads.
- You cannot access files or the database.
- A PHP version or memory limit is controlled by the host.
- Restoring a backup does not fix the issue.
Give support the exact URL, time the issue started, recent changes, and any fatal error from debug.log or the hosting error log.
FAQ
Why does WordPress show a critical error instead of a white screen?
Modern WordPress versions often catch fatal errors and show a critical error message. The cause is usually the same as a white screen, but Recovery Mode may give you a safer way to log in and disable the broken plugin or theme.
Can I fix the white screen without admin access?
Yes. Use WP-CLI, SFTP, or your hosting file manager to disable plugins, rename the active theme, enable debug logging, or restore a backup.
Will disabling plugins delete plugin data?
No. Deactivating or renaming a plugin normally stops the code from running but does not delete its database tables or settings. Deleting a plugin can remove data for some plugins, so disable first and delete only after you know what the plugin does.
Why is only one page blank?
One blank page usually points to a page template, shortcode, block, page builder widget, or custom code used only on that page. Enable debug logging and check the specific URL that fails.
Should I edit WordPress core files to fix WSOD?
No. Reinstall core files if they are corrupted, but do not manually edit WordPress core. Fix the plugin, theme, configuration, PHP version, or server setting that caused the failure.
Conclusion
The WordPress White Screen of Death is usually a fatal PHP error hidden behind a blank page. Start with Recovery Mode, then isolate plugins and themes, read the debug log, and only move to memory, PHP version, cache, or backup restores when the earlier checks do not bring the site back.
Tags
Linuxize Weekly Newsletter
A quick weekly roundup of new tutorials, news, and tips.
About the authors

Dejan Panovski
Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 800+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.
View author page