WordPress White Screen of Death: Causes, Quick Fixes & Safe Mode
The WordPress White Screen of Death (WSOD) is a blank, unresponsive page that replaces your website when a fatal PHP error crashes WordPress before it can finish loading. It has no error message, no clue, just white. The good news: it’s almost always caused by a plugin conflict, memory exhaustion, or a broken theme file. Every one of those has a fix.
WordPress powers 42.2% of all websites globally and holds 59.6% of the CMS market. That scale means millions of site owners have faced this exact screen. This guide covers every common cause, provides the correct fixes in the right order, and explains how to prevent it from happening again.
Table of Contents
Key Takeaways
- The WSOD is almost always caused by PHP memory exhaustion, a bad plugin update, or a theme error.
- Since WordPress 5.2, most fatal errors show a ‘critical error’ message and trigger a Recovery Mode email instead of a pure blank screen.
- 91% of 2025 WordPress vulnerabilities came from plugins, making plugin conflicts the leading WSOD trigger.
- WordPress Safe Mode (via the Health Check plugin, 300,000+ installs) lets you troubleshoot without affecting live visitors.
- You can fix most WSOD cases in under 15 minutes without touching your database.
What Does the WordPress White Screen of Death Look Like in 2026?
Most people expect a completely blank page. Since WordPress 5.2 (released May 2019), that’s no longer the default outcome for most fatal errors. WordPress now catches PHP fatal errors through its own error handler and shows ‘There has been a critical error on this website’ instead of a pure blank.
What changed with WordPress 5.2:
- WordPress detects fatal PHP errors and intercepts them before the browser renders a blank page.
- The admin email receives a ‘Your Site is Experiencing a Technical Issue’ message with a one-time Recovery Mode login link.
- Front-end visitors see a generic error message rather than white space.
When a true blank white screen still appears:
Three situations still produce a genuine white screen in 2026.
- The error happens before WordPress’s error handler has loaded. PHP crashes too early for WordPress to catch it.
- The server returns a 500 Internal Server Error at the Apache or Nginx level.
- PHP runs out of memory before WordPress can initialize its error-handling code.
In our experience, memory exhaustion is the scenario most likely to produce a true blank screen in 2026, because PHP terminates the process before WordPress gets a chance to run its fatal error handler. A ‘critical error’ message on screen, by contrast, usually means WordPress caught the error, which narrows your troubleshooting path considerably.
10 Common Causes of the WordPress White Screen of Death
Plugin issues account for the vast majority of WSOD cases. In 2025, 91% of WordPress vulnerabilities were found in plugins and just 9% in themes, with WordPress core recording only 6 vulnerabilities all year. Understanding the full list of causes helps you fix the right thing first.
Cause 1: PHP Memory Exhaustion
This is the single most common cause of a true blank white screen. The default PHP memory limit on shared hosting is commonly 32MB or 64MB, far below WordPress’s recommended 256MB. When a plugin or theme process hits the ceiling, PHP stops dead. You may see ‘Fatal error: Allowed memory size of X bytes exhausted’ in your error log, or nothing at all.
Cause 2: Plugin Conflicts or a Bad Plugin Update
A plugin update that introduces a PHP syntax error or an incompatibility with another plugin can bring the entire site down. The average WordPress site runs 12-15 plugins, and US sites average 21. The more plugins you run, the higher the chance that a bad update creates a conflict.
Cause 3: Theme Conflicts or a functions.php Syntax Error
A missing semicolon, unclosed bracket, or a bad function call in your active theme’s functions.php crashes the front end. If only the front end is blank but wp-admin works, this is the first place to check. Child themes are not immune. A broken parent theme function will still crash a child theme that calls it.
Cause 4: Corrupted .htaccess File
Apache reads .htaccess before WordPress loads. A syntax error in this file, often left by a badly configured plugin like a security or caching tool, causes Apache to return a 500 error before WordPress ever starts. The blank screen comes from the server, not WordPress.
Cause 5: Corrupted WordPress Core Files
An interrupted update, a failed FTP transfer, or a disk write error can leave core files partially overwritten. WordPress then tries to load incomplete or mismatched PHP files. Re-uploading fresh core files fixes this without touching your database or content.
Cause 6: Database Errors
A corrupt table, a full database, or lost database credentials produces the ‘Error Establishing a Database Connection’ screen rather than a pure white screen. But some database states cause WordPress to load partially and then hang, which can appear as a white screen on specific pages.
Cause 7: File Permission Issues
After a server migration or a manual file transfer, permissions often go wrong. WordPress needs files set to 644 and directories set to 755. If PHP cannot read a required file due to permissions, it fails silently on some server configurations.
Cause 8: Stuck Maintenance Mode
Every WordPress update drops a .maintenance file in the root directory for the duration of the update. If the update is interrupted, that file stays behind. WordPress then shows a ‘Briefly unavailable for scheduled maintenance’ page. On some setups and caching configurations, this can render as a blank or broken page.
Cause 9: Malware Infection
Malware can blank out index.php files, inject PHP code that breaks execution, or add output before the HTML tag, which breaks WordPress’s header processing. If none of the standard fixes work, a malware scan is worth running.
Cause 10: Caching Issues
A stale cache can serve a blank HTML file to visitors even after you’ve fixed the underlying problem. More rarely, a corrupted page cache file that contains partial PHP output causes a blank response. Always purge your cache as a final step after any WSOD fix.
How to Fix the WordPress White Screen of Death: Step-by-Step
Work through these steps in order. Each step is designed to either fix the problem or give you more information to narrow down the cause. Don’t skip straight to step 6 if you haven’t tried steps 1-5. The earlier steps are faster and less disruptive.
Step 1: Determine the scope of the problem.
Visit both the front end of your site and your WP-Admin URL (yoursite.com/wp-admin). If wp-admin loads normally, the problem is in your active theme or a front-end-only plugin. If both are blank, you’re dealing with a PHP-level or server-level crash.
Step 2: Increase the PHP memory limit.
Add this line to wp-config.php, above the line that says /* That’s all, stop editing! */:
define(‘WP_MEMORY_LIMIT’, ‘256M’);
Alternatively, add this to your .htaccess file:
php_value memory_limit 256M
If this fixes the site, you’ve confirmed memory exhaustion. Then find which plugin or theme was the memory hog.
Step 3: Enable WP_DEBUG to read the actual error.
Add these three lines to wp-config.php:
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
Setting WP_DEBUG_DISPLAY to false keeps errors out of the public-facing page. Check /wp-content/debug.log for the exact fatal error message and the file path where it occurred.
Step 4: Check your Recovery Mode email.
Look in the inbox of your WordPress admin email address for a message with the subject ‘Your Site is Experiencing a Technical Issue.’ It contains a one-time link. Click it to log in to the wp-admin in Recovery Mode, where the faulty component is paused for your session only. Visitors see the live site or a generic error message while you fix the issue.
Step 5: Use the Health Check Troubleshooting plugin.
If you have the Health Check & Troubleshooting plugin installed (or can install it via FTP), go to Tools > Site Health > Troubleshoot tab and activate Troubleshooting Mode. This disables all plugins and switches to the default theme for your browser session only. Other visitors are unaffected. Re-enable plugins one by one to find the conflict.
Step 6: Disable all plugins via FTP.
If you cannot access wp-admin, connect via FTP or your host’s file manager. Rename the /wp-content/plugins/ folder to /wp-content/plugins_disabled/. WordPress will deactivate all plugins. If the site loads, rename the folder back to plugins and then re-enable plugins one at a time from wp-admin to find the bad one.
Step 7: Switch to a default theme via FTP.
Inside /wp-content/themes/, rename your active theme’s folder (for example, rename ‘mytheme’ to ‘mytheme_old’). WordPress will fall back to the most recently installed default theme, such as Twenty Twenty-Four. If the site loads, the problem is in your theme’s code.
Step 8: Fix or regenerate the .htaccess file.
Via FTP, rename .htaccess to .htaccess_old. Then log in to wp-admin, go to Settings > Permalinks, and click Save Changes. WordPress will write a fresh .htaccess file. If the site loads after renaming the old file, a corrupted .htaccess file was the cause.
Step 9: Remove a stuck maintenance file.
Check your WordPress root directory for a file named .maintenance. If it exists and no update is currently running, delete it. The maintenance screen will disappear immediately.
Step 10: Re-upload WordPress core files.
Download a fresh copy of WordPress from wordpress.org/download. Unzip it. Upload everything except the wp-content folder and wp-config.php to your server, overwriting existing files. This replaces any corrupted core files without touching your content or settings.
Step 11: Check and correct file permissions.
Via FTP or SSH, set files to 644 and directories to 755. Many hosts provide a ‘Reset Permissions’ tool in their control panel. Via SSH:
find /path/to/wordpress -type f -exec chmod 644 {} \;
find /path/to/wordpress -type d -exec chmod 755 {} \;
After each step, purge your cache and reload the site before moving to the next step.
WordPress Recovery Mode Explained
Recovery Mode is a core WordPress feature that has shipped with every version since WordPress 5.2 (May 2019). It runs automatically. You do not need a plugin to activate it.
‘WordPress Safe Mode’ is a common term used online, but it is not a built-in core feature. What people are referring to is the Troubleshooting Mode inside the Health Check & Troubleshooting plugin, which has 300,000+ active installs. This distinction matters when you’re searching for help at 2 am.
How Troubleshooting Mode works:
When you activate Troubleshooting Mode from Tools > Site Health > Troubleshoot, WordPress sets a cookie in your browser. For your session only, all plugins are disabled and the default theme is active. Every other visitor to your site sees the normal live site. Nothing changes server-side.
You then re-enable plugins one by one within the Troubleshooting tab. When the problem comes back, you’ve found the conflicting plugin. You can also switch themes inside Troubleshooting Mode to isolate a theme conflict without touching the database or any files.
How to Prevent the White Screen of Death
Prevention is faster than recovery. The WSOD is almost always triggered by an update, whether a plugin update, a theme update, or a WordPress core update. A consistent update process eliminates the majority of risk.
In our experience auditing client WordPress sites, bulk-updating all plugins at once is the single most common mistake that leads to a WSOD. Running updates one at a time, with a site check between each one, catches conflicts before they compound.
A prevention framework that works:
- Use a staging environment. Test every plugin and theme update on a staging site before pushing to production. Most managed WordPress hosts (WP Engine, Kinsta, Flywheel) include one-click staging. For shared hosting, use a plugin like WP Staging.
- Back up before every update. UpdraftPlus (free tier) or a host-level daily backup gives you a one-click restore point. A backup from before the update is the fastest recovery path of all.
- Update one plugin at a time. After each update, load your front end and WP-admin before updating the next plugin. This isolates a problem immediately.
- Monitor uptime actively. A free tool like UptimeRobot checks your site every 5 minutes and sends an alert if it goes blank. Without monitoring, a WSOD can go unnoticed for hours.
- Keep PHP on a supported version. PHP 8.2+ is recommended for WordPress 6.x. Outdated PHP versions have known bugs and are more likely to behave unpredictably with modern plugins.
- Keep WordPress core updated. WordPress core had only 6 vulnerabilities in 2025. Keeping core current is the lowest-effort, highest-value maintenance task you can do.
Frequently Asked Questions
Why is only my WordPress admin blank, but the front end loads fine?
An admin-only blank screen points to a wp-admin-specific plugin (like a dashboard widget plugin or a security plugin with admin hooks) or a user-role conflict. Enable WP_DEBUG, check /wp-content/debug.log for the exact error, then disable plugins one at a time from the wp-admin Plugins page or via Troubleshooting Mode. In 2025 alone, 11,334 new WordPress ecosystem vulnerabilities were discovered, a 42% year-over-year increase, so a recently updated security plugin is a common culprit.
Can I fix the white screen of death without FTP access?
Yes, in many cases. If you can reach your WP-Admin, use the Health Check Troubleshooting Mode or check your Recovery Mode email. If your host provides a file manager in cPanel or Plesk, you can rename plugin folders and edit wp-config.php without an FTP client. As a last resort, contact your host’s support. Many hosts can restore from a backup or restart PHP for you.
How do I know if the white screen is caused by memory?
Enable WP_DEBUG and check debug.log for a line that reads ‘Fatal error: Allowed memory size of X bytes exhausted.’ Alternatively, add define(‘WP_MEMORY_LIMIT’, ‘256M’); to wp-config.php and reload the site. If it loads, memory was the cause. The default limit on shared hosting is commonly 32MB or 64MB, far below WordPress’s recommended 256MB.
Will fixing the WSOD delete my content or posts?
No. The fixes in this guide, including disabling plugins via FTP, renaming your theme folder, regenerating .htaccess, and re-uploading core files, do not touch your database or your wp-content/uploads folder. Your posts, pages, images, and settings remain intact. Always take a backup first as a precaution, but content loss from a WSOD fix is not a realistic risk if you follow the steps correctly.
What if the site shows ‘There has been a critical error’ instead of a blank screen?
That message means WordPress 5.2+’s error handler caught the fatal error before it could produce a blank screen. Check your admin email for the Recovery Mode link, which was sent at the same time. Click the link, log in to wp-admin in Recovery Mode, and deactivate the plugin or theme listed in the error notice. This is the fastest path to recovery in most cases, because WordPress has already identified the broken component for you.
Conclusion
The WordPress White Screen of Death sounds catastrophic, but it follows a short list of predictable causes. PHP memory exhaustion, a bad plugin update, and a theme syntax error account for the vast majority of cases. Since WordPress 5.2, a true blank screen is less common because WordPress now catches most fatal errors itself and sends you a Recovery Mode email with a direct fix path.
Work through the diagnostic steps in order. Enable WP_DEBUG first. Check your Recovery Mode email before touching any files. Use the Health Check Troubleshooting plugin to isolate plugin conflicts without taking the live site down. Reserve FTP-based fixes for situations where wp-admin is completely unreachable.
For the long term, a staging environment, single-plugin update discipline, and uptime monitoring will prevent most WSOD incidents before they reach production. The sites that never go blank aren’t lucky. They have a consistent update process.


