A white screen means PHP hit a fatal error and WordPress, politely, chose to show visitors nothing rather than the error itself. The fix is almost never dramatic — it’s usually one plugin, one theme, or one update that landed sideways. Before anything else, check your email: since WordPress 5.2, a fatal often triggers Recovery Mode, which sends the admin a login link that skips the broken code entirely. If that email is sitting there, use it and deactivate the flagged plugin — you may be done in five minutes. If not, you’ll need SFTP or SSH access to the site, and it helps to be comfortable reading your error logs.

Turn on WP_DEBUG the safe way

WordPress ships with error display off, which is why you’re looking at a blank page instead of a clue. Open wp-config.php and, above the line that says “That’s all, stop editing,” add:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

That third line matters: it writes errors to a private log instead of printing them on the page where visitors (and attackers) can read paths and version numbers.

Read the fatal error

Reload the broken page once, then open wp-content/debug.log:

tail -20 wp-content/debug.log

You want the line that starts with PHP Fatal error. Read the file path at the end of it — that’s your suspect. A path containing wp-content/plugins/some-plugin/ points at that plugin; a path in wp-content/themes/ points at the theme; “Allowed memory size exhausted” means PHP ran out of memory, which is a hosting-settings conversation rather than a broken-code one.

Deactivate plugins without the admin

If the fatal named a plugin — or if the log is unclear — turn plugins off from outside. With WP-CLI:

wp plugin deactivate --all --skip-plugins --skip-themes

No shell access? Same result over SFTP: rename wp-content/plugins to wp-content/plugins-off. WordPress can’t find the plugins, so it quietly deactivates all of them. If the site comes back, you’ve confirmed the problem lives in a plugin. Rename the folder back before the next step — the plugins stay deactivated until you turn them on.

Halve your way to the culprit

Reactivating one at a time works, but halving is faster. Turn on half your plugins, load the site. Still fine? The problem is in the other half. Broke again? It’s in the half you just enabled. Deactivate all, enable half of the guilty half, and repeat. Twenty plugins takes about five rounds — like finding the dead bulb in a string of holiday lights, except the string tells you which end to check. When you land on the culprit, leave it off and check the plugin’s support forum; a fixed version is often already out.

Fall back to a default theme if needed

If plugins came up clean, test the theme. Activate a stock one:

wp theme activate twentytwentyfive

Over SFTP, renaming your active theme’s folder forces WordPress to fall back to a default theme, as long as one is installed. Site renders on the default theme? Your theme has the fatal — the debug log will name the exact file and line, which is what you hand to whoever maintains it.

Verify, then turn debug back off

Click around like a visitor: front page, an interior page, the login, a form if you have one. Then put wp-config.php back the way it was:

define( 'WP_DEBUG', false );

Delete wp-content/debug.log too — it’s served publicly on many hosts. You’re verified when the site renders logged-out in a private browser window, the admin loads, and the log stays quiet on a fresh reload. If the culprit was a plugin you actually need, update it before reactivating, and if the site is down and you’re not sure this is the problem, start wider with what to do when your website goes down.