WordPress White Screen of Death: A Recovery Order That Avoids Making It Worse

Original Mosfetti guides and articles: computer repair, website repair and maintenance, WordPress help, hosting, migrations, DNS and business email, electronics projects, and Mosfetti technical updates. Authored by the editorial team.
Forum rules
Articles only. Post original, accurate technical content. No generic SEO filler, fake stats, or fabricated reviews. Authors may create and edit their own topics here.
Post Reply
Gensys
Parts Sorter
Posts: 25
Joined: Fri Jul 03, 2026 12:03 am

WordPress White Screen of Death: A Recovery Order That Avoids Making It Worse

Post by Gensys »

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
  1. Note the exact URL that fails (front page only? wp-admin? every page?).
  2. 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.
  3. Confirm backups exist (hosting snapshot, plugin backup, or offsite copy). If you have no backup, avoid destructive database imports until you make one.
  4. Reproduce once in a private/incognito window to rule out a broken cached HTML shell in your browser.
What a white screen usually is

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);
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:
  • 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.
Special case: [font=monospace]wp-content/mu-plugins[/font] loads always—check that folder if normal plugins were not the cause.

Step 3 — Theme fallback

If plugins are not the cause:
  1. Note the active theme folder under [font=monospace]wp-content/themes/[/font].
  2. 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]).
Or via WP-CLI if available:

Code: Select all

wp theme activate twentytwentyfour
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:

Code: Select all

define('WP_MEMORY_LIMIT', '256M');
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
  • 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.
Step 6 — Core files (only after plugins/theme)

If logs point to missing core files:
  1. Download a fresh WordPress zip matching your version (Dashboard often shows version in DB option [font=monospace]db_version[/font] / readme).
  2. 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].
  3. Do not overwrite [font=monospace]wp-content[/font] blindly.
Step 7 — Database last

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.
After recovery
  1. Update WordPress, theme, and plugins from a staging copy when possible.
  2. Remove unused plugins.
  3. Re-enable debug off.
  4. Confirm cron, forms, and checkout (if WooCommerce) on a staging URL first for major shops.
How this ties to hosting

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.
Top
Post Reply

Return to “Articles & Guides”