The WordPress white screen of death
A completely blank page with no error and no HTML. PHP stopped mid-request and the message went to a log you have not read yet.
(a blank white page, no text at all)
The screen is blank because display_errors is off, not because there is nothing to say. Switch on WP_DEBUG_LOG, reload the page once, and read wp-content/debug.log - the last entry names the file and line that stopped.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| A fatal PHP error in a plugin or theme | The log entry starts with "PHP Fatal error" and names a file under wp-content. That path is the answer. | Deactivate the named plugin or switch theme. If the file belongs to a theme, switching to a default theme restores the site while you look at it. |
| The memory limit was reached | The log says "Allowed memory size … exhausted". A blank page and an out-of-memory kill look identical from the browser. | Raise the limit enough to load the page, then find what needed the memory. The limit is a symptom, not the cause. |
| Only wp-admin is white | The front end renders and the dashboard does not, or the reverse. That asymmetry points at admin-only code. | The fatal is in an admin-only path. Rename the plugins directory over SFTP to get back in, then reactivate one at a time. |
| OPcache is serving a stale compiled file | The site was fine, a file was edited, and now it is blank - and the error names a line that no longer exists in the file. | Flush OPcache. Editing PHP in place without a flush leaves the compiled version and the source disagreeing. |
| A syntax error in a file you just edited | php -l on the file you touched last reports the error without needing WordPress at all. | Fix the syntax or restore the previous copy. A stray brace in wp-config.php or functions.php takes down every page at once. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Turn the message back on
Log rather than display: you want the detail without publishing a stack trace to visitors.
wp config set WP_DEBUG true --raw wp config set WP_DEBUG_LOG true --raw wp config set WP_DEBUG_DISPLAY false --raw
Reload the blank page once, then read the log
The last entry is yours. Everything above it may be old noise.
tail -n 30 wp-content/debug.log
If it named a plugin, take that plugin out of the request
Deactivating by name is enough; you do not need to delete anything.
wp plugin deactivate the-named-plugin
If you cannot reach wp-admin at all, disable plugins from the filesystem
Renaming the directory makes WordPress find no plugins, which is enough to get the dashboard back.
mv wp-content/plugins wp-content/plugins.off
Turn debugging back off when you are done
A debug log left on grows without limit and records paths you would rather not publish.
wp config set WP_DEBUG false --raw
What the platform takes off the list.
The white screen is a configuration accident rather than a WordPress feature: PHP is told not to display errors and nothing is told to log them. Here the log is on and writable from the first request, so a fatal error is a line you can read rather than an empty page. Cloning the site before an update means the plugin that fatals does it on a copy nobody is visiting.
Questions, answered.
Why is the page blank instead of showing the error?
The front end is fine but wp-admin is white. Why only there?
I fixed the file but the page is still blank.
Can I find the culprit without any command-line access?
If that was not it.
These fail in ways that look similar from the browser.