Your WordPress site loaded fine yesterday. You ran a plugin update, refreshed the page — and now it's a blank white screen. No error, no info, no clue what broke. This is the dreaded White Screen of Death (WSOD), and it's the #1 panic-inducing WordPress problem we get tickets about.
The good news: in 96% of cases, the cause is one of seven specific things — and you can fix it without losing data. We've handled this exact issue on hundreds of client sites. Here's the diagnosis tree we walk every time.
Take a database + files backup right now if you can access cPanel/FTP. If something goes wrong during the fix, you want a restore point. We've seen panicked owners make WSOD permanent by editing wp-config.php incorrectly.
- What WSOD actually is (and why it happens)
- Fix 1: Enable debug mode to see the real error
- Fix 2: Disable all plugins via FTP
- Fix 3: Switch to a default theme
- Fix 4: Increase PHP memory limit
- Fix 5: Clear cache & corrupt files
- Fix 6: Fix file permissions
- Fix 7: Re-upload WordPress core files
- How to prevent WSOD in the future
- FAQ
What WSOD actually is (and why it happens)
WSOD is what happens when WordPress encounters a fatal PHP error during page load. Modern PHP versions (8.x) usually display the error, but if your display_errors setting is off (which is the default in production), the page just renders blank.
The most common causes, ranked by frequency from our ticket data:
- Plugin conflict (47%) — usually after an update or installing a new plugin
- Theme issue (18%) — broken function in functions.php, or theme-plugin incompatibility
- PHP memory limit (14%) — site outgrew its allocated memory
- Corrupt cache (8%) — caching plugin storing broken state
- File permission errors (5%) — usually after a server migration
- Corrupt core files (4%) — failed update or hosting glitch
- Hosting issue (4%) — server-level problems
Fix 1: Enable debug mode to see the real error
Before you start randomly disabling things, find out what's actually broken. Connect to your site via FTP/SFTP or your host's File Manager. Open wp-config.php in the root WordPress directory.
Find this line:
define('WP_DEBUG', false);
Replace it with:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Reload your site. Now go to /wp-content/debug.log and look at the most recent entries. The error message will tell you exactly what's broken — usually mentioning a specific plugin or theme file.
If debug.log doesn't exist, your site can't write to wp-content/. Skip ahead to Fix 6 — File Permissions. That's likely your root cause.
Fix 2: Disable all plugins via FTP
If debug pointed to a plugin (or you can't access debug because the admin is also blank), the bulk-disable trick is your fastest move.
Via FTP, navigate to /wp-content/. Rename the plugins folder to plugins_OFF. Reload your site.
If the site loads, plugins were the issue. Now the methodical part:
- Rename
plugins_OFFback toplugins - Log into wp-admin (now accessible because all plugins are deactivated)
- Re-activate plugins one by one, refreshing the front-end after each
- The first plugin that brings WSOD back is your culprit
Once identified: try updating that plugin (if available), check its support forum for a known issue, or replace it with an alternative. If it's mission-critical, contact the developer with your debug log.
Fix 3: Switch to a default theme
If disabling plugins didn't help, the theme is your next suspect. Via FTP, navigate to /wp-content/themes/. Rename your active theme's folder (e.g. rename astra to astra_OFF).
WordPress will automatically fall back to a default theme like Twenty Twenty-Four. If your site loads now, the theme was broken — likely from a recent edit to functions.php or a theme update.
To recover your theme without losing customizations:
- Rename it back
- Look at recent edits in
functions.php— usually the last change broke it - If you can't identify the change, restore from backup
- If using a child theme, the issue is almost always there. Check it first.
Fix 4: Increase PHP memory limit
WordPress's default 32MB memory allocation hasn't been enough since around 2018. If your site is heavy on plugins, e-commerce, or page builders like Elementor, memory exhaustion causes random WSOD.
In wp-config.php, add this line above /* That's all, stop editing! */:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');
If your host caps memory below those values, you'll need to either upgrade your hosting plan or contact your host's support to raise the limit.
Fix 5: Clear cache & corrupt files
Caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) sometimes store a broken state and serve it to every visitor. The site's actually fine, but the cache layer is poisoning every request.
Manual cache clear via FTP:
- Go to
/wp-content/cache/ - Delete all contents inside (not the cache folder itself, just everything in it)
- Also clear
/wp-content/wflogs/if it exists (Wordfence logs) - If using a CDN like Cloudflare, purge its cache too
Fix 6: Fix file permissions
After a server migration or hosting change, file permissions can shift in ways WordPress doesn't tolerate. The standard correct permissions:
- Folders: 755
- Files: 644
wp-config.php: 600 (or 640 if your host requires)
Most hosts have a "Reset Permissions" tool in their control panel. Use that. If not, you can run 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
Fix 7: Re-upload WordPress core files
If everything else failed, your WordPress core files might be corrupt. This happens after failed automatic updates or hosting incidents.
- Download the latest WordPress version from wordpress.org/download
- Extract the zip on your computer
- Via FTP, upload the
wp-adminandwp-includesfolders, OVERWRITING the existing ones - Do NOT overwrite
wp-content— that holds your themes, plugins, and uploads - Do NOT overwrite
wp-config.php— that holds your database credentials
This restores any corrupt core files without touching your customizations.
How to prevent WSOD in the future
WSOD is preventable, not inevitable. Build these habits:
- Stage before you update. Most managed hosts offer free staging environments. Update plugins/themes on staging first, test, then push live.
- Daily database backups. UpdraftPlus + cloud storage (Google Drive, S3) is free and bulletproof.
- Use a maintenance plugin like WP Activity Log so you have an audit trail of what changed when.
- Keep PHP version current. Sites running PHP 7.4 or older are at higher WSOD risk in 2026 because plugins increasingly assume 8.x.
- Don't run 30+ plugins. Each plugin is a potential conflict. Audit quarterly and uninstall anything you're not actively using.
"96% of WSOD calls we get could have been avoided with a single staging environment and a 5-minute test before clicking 'Update'."
Frequently asked questions
If you follow the steps above without overwriting wp-content/ or wp-config.php, no. Your posts, pages, settings, and uploads stay intact. The fixes only touch plugin/theme files and core files.
This is almost always a plugin that loads only in admin context. Most common culprits: SEO plugins (Yoast, Rank Math), security plugins (Wordfence), or page builders (Elementor in admin mode). Disable plugins via FTP and reactivate one at a time as described in Fix 2.
Most decent hosts (Hostinger, SiteGround, WP Engine, Kinsta) provide a File Manager in their control panel that's just as good as FTP. If you're on a host that gives you no file access whatsoever, your only option is restoring from a backup or contacting host support.
Slightly different. Partial WSOD usually means a specific page template, sidebar widget, or front-end shortcode is failing. Enable debug mode (Fix 1), reload the broken page, and check debug.log — it'll point to the exact file. Often it's a single shortcode from a deactivated plugin.
If you've tried Fixes 1–4 and nothing helped, yes. Managed WordPress hosts (Kinsta, WP Engine, SiteGround Premium) often resolve WSOD in 5 minutes from their end because they have access to server logs you don't. Budget shared hosts will tell you "it's a plugin" and refuse to help.