The white screen has a status code. Read that first.
A white screen is not an absence of information. It is information that has been suppressed, deliberately, by a production setting, and the first job is to find out which of several quite different failures produced it.
The fastest discriminator is the one nobody looks at, because a browser does not show it.
curl -sS -o /tmp/body -w 'code %{http_code} bytes %{size_download}\n' https://example.com/Two numbers, and between them they narrow the field immediately.
| Code | Bytes | What you are looking at |
|---|---|---|
| 500 | 0 or small | PHP died. There is a fatal error in a log somewhere. |
| 200 | 0 | PHP ran, produced nothing, and exited cleanly. Usually a die() or an output buffer discarded. |
| 200 | Thousands | Not a white screen at all. The HTML is there and the rendering failed. |
| 502 or 504 | Varies | The application never answered the proxy. Different problem entirely. |
The third row catches people out and is worth ruling out in the first minute. A page that returns a full document while showing nothing is a stylesheet that failed to load, a script that threw before rendering, or a layout collapsed by a CSS file that returned an error page instead of CSS. Look at /tmp/body. If there is markup in it, stop reading PHP logs and open the browser's network panel.
Where the log is, in the order to look
There are four candidate locations and they are not equivalent.
The web server's error log. The most reliable, because it is written by the process that noticed the failure. On a shared account it is usually exposed in the panel under a name like error log, and it is frequently truncated to the last few hundred lines.
PHP's own error log. Wherever the error_log setting points. On many shared hosts that setting is empty, and the default behaviour writes a file called error_log into the directory of the script that failed, which means the useful file may be sitting in the plugin's own folder.
find /home/client/public_html -name 'error_log' -newermt '-2 days' -lsWordPress's debug log, which only exists if somebody enabled it, and which is the one you control.
The host's panel, which sometimes aggregates all of the above and sometimes shows a fourth thing nobody can locate on disk.
Check the first two before changing any configuration. Turning on debugging to reproduce a failure you could have read about is a detour, and on a live site it is a detour with a risk attached.
Turning logging on without showing it to the world
Three constants, and the third is the one that matters on a client site.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/client/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG_DISPLAY false keeps the errors out of the page. Without it, enabling debugging on a live site prints file paths, database details and stack traces to every visitor, which is worse than the blank page you were trying to fix.
Giving WP_DEBUG_LOG an explicit path rather than true matters too. The default location is inside the uploads-adjacent content directory and is served by the web server, so anyone who guesses the filename can read your error log. Put it outside the document root.
The email you probably never received
Since the introduction of fatal error protection, WordPress does something useful when a plugin or theme causes a fatal error: it shows a generic difficulties message instead of a blank page, and it emails the site's administration address with a link that logs you into a recovery mode with the offending extension paused.
Two reasons that never helps in practice on client sites. The administration email is frequently an address nobody reads, or one at the domain whose mail is broken for the same reason the site is. And the mechanism only catches errors raised inside a plugin or theme; a fatal in core, or one that occurs before the protection is loaded, still produces a plain blank page.
When you take over a site, check that address and change it to one of yours. It costs ten seconds and it is the difference between a link in your inbox and an afternoon with a file manager.
wp option get admin_emailThe three causes, ranked by how often they turn out to be it
A fatal error in a plugin or theme after an update. A call to a function that no longer exists, a class renamed, a file removed. The log names the file and the line, which is the whole diagnosis. Where the log is unavailable, disabling plugins in bulk and re-enabling them is the crude version, and the useful refinement is to halve the set rather than walk it one at a time.
wp plugin deactivate --all
wp plugin activate plugin-a plugin-b plugin-cMemory exhaustion. Distinctive because the log says so explicitly, naming the number of bytes and the file that asked for the last allocation. That file is usually innocent; it is the one that happened to be running when the budget ran out.
A PHP version change. The host moved the account, or somebody clicked the version selector, and code written for an older interpreter now raises a fatal. This one is easy to miss because nobody at your end deployed anything, so the timeline suggests the site broke on its own.
Why nothing external caught it
The 500 case is at least detectable by any status check. The 200 case is not, and it is the more common one on a site behind a caching layer or a proxy that turns an empty upstream response into a well-formed empty page.
A monitor asserting only on the status code reports a perfectly healthy site while every visitor sees nothing. The assertion that catches it is a string that must be present in the body, chosen from something the page can only contain when it has actually rendered: what a 200 proves, and what it does not.
Adding that one assertion per client site is a few minutes of work each and it converts this entire category from "the client phones you" to "you already know". Which is the difference the retainer is actually paying for: what a maintenance plan is bought for, as opposed to what is on its task list.
