The WordPress white screen of death, and how to get out of it
No error message, no content, just white. It is the least informative failure WordPress produces, and it has a small number of causes that can be worked through in a fixed order.
The short answer
A blank white page means PHP stopped executing and produced no output, usually from a fatal error with display disabled, an exhausted memory limit, or a broken theme. Enable debug logging in wp-config.php, reload once, and read wp-content/debug.log. If wp-admin also shows white, the cause is a plugin or memory; if only the front end is white, suspect the theme first.
Why the screen is blank rather than showing an error
PHP fatal errors normally print a message. On production sites, display_errors is switched off so that visitors do not see file paths and version numbers, which is correct security practice. The result is that PHP dies silently and the server returns a page with nothing in it.
So the white screen is not a distinct kind of failure. It is a fatal error with the message suppressed. The message still exists; you just have to go and find it.
Narrow it down before you start
Check whether wp-admin loads. This one test splits the problem in half and takes ten seconds.
- Front end white, admin loads: the theme or a front-end-only plugin is the likely cause
- Both white: a plugin, a memory limit, or a core problem
- Admin white, front end fine: an admin-side plugin, often a page builder or SEO plugin
- Only one page white: a plugin used only on that page, or a shortcode or block calling missing code
Turn the error message back on
Edit wp-config.php and enable WP_DEBUG and WP_DEBUG_LOG while keeping WP_DEBUG_DISPLAY false. Reload the failing page exactly once, then read wp-content/debug.log. The last lines identify the file and line where execution stopped.
Reload only once. Every reload appends more entries, and on a busy site the log grows quickly enough to make the relevant lines hard to isolate.
Work through the causes
Plugin conflict
Rename wp-content/plugins to plugins-off via SFTP or your host's file manager. WordPress deactivates everything because it can no longer find the files. If the white screen clears, rename the folder back and then rename individual plugin folders one at a time until the failure returns. The last one you renamed is the cause.
This is destructive to plugin settings in only the rarest cases, because deactivation by file removal does not delete plugin data from the database. Settings are almost always intact when you reactivate.
Memory exhaustion
If the log mentions allowed memory size exhausted, raise WP_MEMORY_LIMIT in wp-config.php to 256M and reload. If the site returns, do not stop there. Something is consuming an unreasonable amount of memory and the limit increase has only bought you room. Common culprits are backup plugins running during page loads, image-processing plugins working on very large uploads, and plugins running unbounded database queries.
Theme error
If only the front end is white, switch theme. Without admin access, rename your active theme's folder in wp-content/themes. WordPress falls back to a default theme if one is present, which is a good reason to keep a default theme installed on every site rather than deleting them for tidiness.
The most common theme cause is a child theme calling a function the parent removed in an update, followed by a functions.php edit made directly on production without testing.
A failed update mid-flight
If the white screen began during an update, files may be partially written. Replace wp-admin and wp-includes with fresh copies from a matching WordPress release. Leave wp-content and wp-config.php alone. If the update was a plugin, delete the plugin folder and reinstall it cleanly rather than updating over the damaged files.
Watch for the .maintenance file
A failed core update can leave a file named .maintenance in the WordPress root, which keeps the site in maintenance mode indefinitely. Deleting that file restores the site immediately, and it is worth checking early because it is a thirty-second fix that looks like a serious outage.
If you need the site up right now
Restore the most recent backup. On a client site during business hours, restoring first and diagnosing second is almost always the right call, because every minute spent debugging on production is a minute the client is offline. Reproduce the fault afterwards on a staging copy.
Preventing the next one
Nearly every white screen an agency encounters traces back to a change: an update, an edit, or a host-side version bump. The preventable ones share a pattern, which is that the change was applied without a restore point and without verification afterwards.
- Automatic restore point before every update, on every site
- Post-update verification that the page still returns HTTP 200 and renders
- Visual comparison against a stored reference so silent layout breakage is caught
- Automatic rollback when verification fails
- A default theme kept installed on every site as a fallback
- PHP version tracked across the portfolio so host upgrades are not a surprise
Related questions
That pattern points at the theme or a plugin that only runs on the front end. Rename the active theme folder to force a fallback, and if that clears it, the theme is the cause. A recent functions.php edit is the most common single reason.
Yes. A PHP version change, a reduced memory limit, a disabled PHP extension a plugin depends on, or an exhausted process limit all produce blank pages. If nothing changed on the site itself, ask your host what changed on theirs.
Usually not. It is far more often a plugin, theme or memory problem. That said, a compromised site can produce blank pages if injected code has a syntax error. If the error log points at a file you do not recognise, or at core files that should not have been modified, treat it as a possible compromise.
Uptime monitoring that checks for actual page content rather than only an HTTP status code will catch it, because a white screen frequently still returns HTTP 200. If your monitoring only checks status codes, a completely blank site can look healthy indefinitely.
Related reading
Safe WordPress updates
How preflight checks, visual comparison and automatic rollback stop this happening again.
See how it worksBackups and restore
Restore-tested backups so the copy you rely on is proven before you need it.
Read moreWordPress maintenance guide
The full maintenance routine that prevents most emergency recoveries.
Read the guideCatch blank pages before your client does
Content-aware uptime checks across every site you manage, plus visual comparison on every update.
Free during early access. No credit card required.