WordPress White Screen of Death: A Recovery Order That Avoids Making It Worse
Posted: Thu Aug 06, 2026 9:40 pm
A blank white page (HTTP 200 or 500 with empty body) usually means PHP fatal error, exhausted memory, or a broken plugin/theme load—not “WordPress deleted itself.” This guide gives a recovery order: evidence first, then safe toggles, then targeted fixes, so you do not randomly overwrite a working database.
Before you change anything
Clue — Likely cause
White page after plugin install/update — Plugin PHP fatal / incompatibility
White page after theme switch — Theme functions.php fatal
wp-admin works, frontend white — Theme, page builder, or cache plugin conflict
Both white — Autoload plugin, must-use plugin, memory limit, core corruption
500 in network tab — Server/PHP error (see logs)
200 with empty body — Error display off; still a PHP failure underneath
Step 1 — Turn on controlled debugging (temporarily)
Via FTP/SFTP or file manager, open [font=monospace]wp-config.php[/font] above the line that says “That’s all, stop editing!” and ensure:
Reload once, then read [font=monospace]wp-content/debug.log[/font].
Turn display off in production ([font=monospace]WP_DEBUG_DISPLAY[/font] false) so errors are not shown to visitors. Remove or set [font=monospace]WP_DEBUG[/font] back to false after recovery.
Step 2 — Bypass plugins without deleting them
Rename:
[font=monospace]wp-content/plugins[/font] → [font=monospace]wp-content/plugins.disabled[/font]
Reload:
Step 3 — Theme fallback
If plugins are not the cause:
If you have no default theme uploaded, install one before switching.
Step 4 — Memory and limits
In [font=monospace]wp-config.php[/font] you may add:
Also check hosting PHP memory limit. If logs show [font=monospace]Allowed memory size exhausted[/font], raise limits properly in the host panel rather than stacking random plugins.
Step 5 — [font=monospace].htaccess[/font] and cache residue
If logs point to missing core files:
Only if logs/DB connectivity errors say so:
Many white screens appear right after PHP version changes (e.g. 8.0 → 8.2) or memory cuts on shared plans. If the log names a deprecated function in an abandoned plugin, the fix is replace/remove the plugin—not “increase PHP forever.”
Conclusion
Treat the white screen as a logged PHP failure. Disable plugins by rename, fall back the theme, then repair core. Guessing with random reinstalls risks configuration loss; logs and ordered isolation fix most cases without drama.
Before you change anything
- Note the exact URL that fails (front page only? wp-admin? every page?).
- Check hosting error logs (panel log viewer, [font=monospace]error_log[/font], or PHP-FPM log). A single fatal line beats an hour of guesswork.
- Confirm backups exist (hosting snapshot, plugin backup, or offsite copy). If you have no backup, avoid destructive database imports until you make one.
- Reproduce once in a private/incognito window to rule out a broken cached HTML shell in your browser.
Clue — Likely cause
White page after plugin install/update — Plugin PHP fatal / incompatibility
White page after theme switch — Theme functions.php fatal
wp-admin works, frontend white — Theme, page builder, or cache plugin conflict
Both white — Autoload plugin, must-use plugin, memory limit, core corruption
500 in network tab — Server/PHP error (see logs)
200 with empty body — Error display off; still a PHP failure underneath
Step 1 — Turn on controlled debugging (temporarily)
Via FTP/SFTP or file manager, open [font=monospace]wp-config.php[/font] above the line that says “That’s all, stop editing!” and ensure:
Code: Select all
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Turn display off in production ([font=monospace]WP_DEBUG_DISPLAY[/font] false) so errors are not shown to visitors. Remove or set [font=monospace]WP_DEBUG[/font] back to false after recovery.
Step 2 — Bypass plugins without deleting them
Rename:
[font=monospace]wp-content/plugins[/font] → [font=monospace]wp-content/plugins.disabled[/font]
Reload:
- If the site returns, a plugin is involved. Recreate [font=monospace]plugins[/font], then rename plugin folders one at a time (or restore half at a time) until it breaks again.
- Do not leave production without security plugins longer than needed.
Step 3 — Theme fallback
If plugins are not the cause:
- Note the active theme folder under [font=monospace]wp-content/themes/[/font].
- Using database access (phpMyAdmin or CLI), in [font=monospace]wp_options[/font] (prefix may differ):
- [font=monospace]template[/font] and [font=monospace]stylesheet[/font] → set both to a default theme that exists on disk (e.g. [font=monospace]twentytwentyfour[/font]).
Code: Select all
wp theme activate twentytwentyfour
Step 4 — Memory and limits
In [font=monospace]wp-config.php[/font] you may add:
Code: Select all
define('WP_MEMORY_LIMIT', '256M');
Step 5 — [font=monospace].htaccess[/font] and cache residue
- Temporarily move [font=monospace].htaccess[/font] aside and load the site (WordPress can regenerate permalinks later under Settings → Permalinks).
- Purge object/page cache plugins after the site loads again; delete [font=monospace]wp-content/cache[/font] contents only if you know the cache plugin’s layout.
- CDN: purge CDN cache once origin is fixed or you will keep seeing the old blank page.
If logs point to missing core files:
- Download a fresh WordPress zip matching your version (Dashboard often shows version in DB option [font=monospace]db_version[/font] / readme).
- Upload fresh [font=monospace]wp-admin[/font] and [font=monospace]wp-includes[/font], and root [font=monospace]*.php[/font] except do not overwrite [font=monospace]wp-config.php[/font].
- Do not overwrite [font=monospace]wp-content[/font] blindly.
Only if logs/DB connectivity errors say so:
- Verify DB name/user/host/password in [font=monospace]wp-config.php[/font].
- Check table prefix.
- Look for disk full on the database host.
- Avoid “repair all tables” as a first step on huge InnoDB databases without a backup.
- Update WordPress, theme, and plugins from a staging copy when possible.
- Remove unused plugins.
- Re-enable debug off.
- Confirm cron, forms, and checkout (if WooCommerce) on a staging URL first for major shops.
Many white screens appear right after PHP version changes (e.g. 8.0 → 8.2) or memory cuts on shared plans. If the log names a deprecated function in an abandoned plugin, the fix is replace/remove the plugin—not “increase PHP forever.”
Conclusion
Treat the white screen as a logged PHP failure. Disable plugins by rename, fall back the theme, then repair core. Guessing with random reinstalls risks configuration loss; logs and ordered isolation fix most cases without drama.