What the white screen actually means
A blank white page means WordPress hit an error so serious it stopped before it could draw anything. The usual culprits are a plugin conflict, a broken theme, a PHP version mismatch, a memory limit being exceeded, or a bad update that left files half-changed.
Good news first: the white screen rarely means your content is gone. Your posts, pages, and orders normally sit safely in the database while PHP refuses to run. The job is to find the line of code that is failing — not to start deleting things in a panic.
Since WordPress 5.2, “fatal error protection” often kicks in and emails the site admin address a special recovery-mode link that lets you log in and disable the offending plugin or theme. Before anything else, check the admin inbox — WordPress may have already told you exactly what broke.
Step 1 — Stop, and write down what changed
The single most useful piece of information is what happened right before the screen went blank. A plugin update? A theme change? A PHP version bump from the host? A new plugin install? Nine times out of ten the cause is the last change made, so resist the urge to “try a few more updates” — that only adds new variables.
Step 2 — Turn on debugging to read the real error
A blank screen hides the actual error message; debugging reveals it. Following the official Debugging in WordPress guide, set define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); in wp-config.php. WordPress then writes the error to wp-content/debug.log instead of swallowing it.
The log usually names the exact file and line that failed — often a specific plugin or theme file. That one message turns guesswork into a targeted fix. Turn debug display off again once you are done, so visitors never see raw errors.
Step 3 — Isolate the cause
With or without the log, the goal is to find which component is breaking the site. Work through the likely causes in order of likelihood, and change only one thing at a time so you know what fixed it.
- Plugins: if you can reach the dashboard, deactivate plugins one by one. If you cannot, rename the
wp-content/pluginsfolder via SFTP or the host file manager to disable them all, then re-enable individually. - Theme: switch to a default theme (such as a Twenty Twenty-something theme) to rule out the active theme. Renaming the theme folder forces WordPress back to a default.
- Memory: if the log mentions “allowed memory size exhausted,” raise the limit with
define( 'WP_MEMORY_LIMIT', '256M' );— but treat a memory error as a symptom of a heavy plugin, not just a number to crank up. - PHP version: a host PHP upgrade can break an old plugin or theme overnight. Check whether PHP changed, and roll back the version while you update the offending code.
Step 4 — Restore if recovery gets risky
If the cause is unclear and the site is business-critical, restoring a known-good backup is often the fastest safe path back online. Restore first to get customers a working site, then investigate the cause on a staging copy where mistakes are harmless. This is exactly why off-site backups and a staging environment — the backbone of any WordPress care plan — are worth paying for before you need them.
How to stop it happening again
Most white-screen incidents are preventable. Test updates on staging before they touch the live site, keep frequent off-site backups, retire abandoned plugins (start with a plugin audit), and make sure hosting PHP changes are planned rather than sprung on the live site. That is the difference between a five-minute non-event and a lost afternoon — and it is the whole point of a WordPress maintenance routine.
Quick diagnosis: symptom → likely cause → first move
Match what you are seeing to the most common cause, then start with the matching first move.
| What you see | Most likely cause | First move |
|---|---|---|
| Whole site blank after a plugin update | Plugin conflict or fatal error in that plugin. | Disable plugins (folder rename if locked out), re-enable one by one. |
| Only the front end blank, admin works | Theme error. | Switch to a default theme. |
| Blank after a host change | PHP version mismatch. | Check and roll back the PHP version; update the code. |
| Log says “memory size exhausted” | Memory limit hit, often by a heavy plugin. | Raise WP_MEMORY_LIMIT, then find the heavy plugin. |
| Recovery-mode email in your inbox | WordPress already caught the fatal error. | Use the recovery link to log in and disable the culprit. |
Mistakes that turn a 5-minute fix into a crisis
- Panic-clicking more updates or installs, which adds new variables and buries the real cause.
- Editing core or theme files live with no backup, so a typo makes things worse.
- Cranking the memory limit sky-high instead of finding the plugin eating the memory.
- Ignoring the recovery-mode email WordPress sent to the admin address.
- Restoring an old backup without first noting what changed, so the same break returns.
How we handle a white screen on a managed site
When a managed site goes white, the priority order is simple: get the customer a working site, then find the root cause somewhere safe. Restoring from a recent backup buys breathing room; diagnosing on staging means we never experiment on the live site while customers are trying to use it.
- Get the site back up from backup first, investigate second.
- Reproduce and fix the fatal error on staging, never on live.
- Once fixed, re-test the customer paths — forms, checkout, login — before calling it done.
- Record what caused it so the same plugin or PHP combination does not bite twice.
Frequently asked questions.
Can the white screen be fixed without losing content?
Almost always, yes. The white screen is a PHP execution failure, not a data loss — your posts, pages, and orders normally remain in the database. The key is to diagnose calmly rather than deleting or overwriting things while you guess.
Should I restore a backup immediately?
If the site is business-critical and the cause is unclear, restoring a recent known-good backup is often the fastest way back online. Restore to recover, then investigate the cause on a staging copy so you do not just reintroduce the same break.
How do I see the real error behind a blank page?
Enable WordPress debugging by setting WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php. WordPress then logs the failing file and line to wp-content/debug.log, per the official Debugging in WordPress guide. Turn debug display back off once you are done.
What is WordPress recovery mode?
Since WordPress 5.2, fatal error protection can detect a crashing plugin or theme, pause it, and email the admin a recovery-mode link to log in and fix it safely. Check the admin inbox before doing anything drastic.
Research sources.
This guide was checked against current platform and search documentation before publication.