Your site was fine yesterday. Today it’s a blank white page — no error, no menu, sometimes not even the admin login. The white screen of death (WSOD) looks terrifying precisely because it tells you nothing. The good news: in most cases it’s one of five causes, and you can walk through them in order.
First: can you reach /wp-admin?
Try yoursite.com/wp-admin. If the dashboard loads while the front end is blank, your problem is almost certainly a theme or plugin — skip to step 2. If admin is blank too, start at step 1.
Step 1 — Check your email for recovery mode
Since WordPress 5.2, a fatal error usually triggers an email to the site admin address titled “Your Site is Experiencing a Technical Issue.” It contains a special recovery-mode link that lets you log in with the broken component paused, and names the exact plugin or theme at fault. This email solves half of all WSOD cases on its own — check spam too.
Step 2 — Rule out a plugin conflict
If you can reach admin: deactivate all plugins, check the site, then reactivate one by one until it breaks again. If you can’t reach admin, rename the plugins folder via FTP or your hosting file manager (wp-content/plugins → plugins-off) — WordPress silently deactivates everything. Site back? Rename the folder back and disable plugins individually inside it. The culprit is usually whatever updated most recently.
Step 3 — Fall back to a default theme
Rename your active theme’s folder inside wp-content/themes. WordPress falls back to a default theme if one is installed. If the site comes back, the white screen lives in your theme — often a PHP syntax error in functions.php from a recent edit.
Step 4 — Raise the PHP memory limit
Exhausted memory is a classic silent killer. Add to wp-config.php, above the “stop editing” line:
define('WP_MEMORY_LIMIT', '256M');
If your host caps memory at the server level, this line won’t be enough — ask them to raise it.
Step 5 — Turn on debug mode and read the actual error
Still blank? Make WordPress tell you what’s wrong. In wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Then reload the broken page and read wp-content/debug.log. The last “PHP Fatal error” line names the file and line number responsible — which is the difference between guessing and fixing. Turn WP_DEBUG off again when done.
Before you change anything: back up
Every step above is reversible except the ones done carelessly. Take a full backup (files + database) before editing wp-config.php or renaming folders, especially on a live business site. It’s the rule we never break on client sites, including the boring cases.
When to hand it over
If debug.log points at core files, the database, or a hacked file you don’t recognize — or the site is down while orders are coming in — the cost of an hour of expert help is usually smaller than the cost of experimenting on production. That’s the exact scenario our WordPress support & bug fix service exists for: describe the symptom, we take a backup, diagnose, and quote before touching anything. Send us the symptoms — including what changed right before the screen went white.