WordPress white screen of death — how to debug without admin access

1. Problem

You open the site and get nothing. No error, no message, no styling, just a blank white rectangle where a page used to be. You try wp-admin. It is white too. There is no error to screenshot, no stack trace to paste into a forum, and no dashboard to log into because the dashboard is the thing that is broken.

Search "wordpress white screen of death fix" and the advice is the same everywhere: disable all your plugins, switch to a default theme, increase your memory limit, try all three, see what sticks. That works eventually, sometimes, but it treats a diagnosable event as an unsolvable mystery. A white screen is not a special category of failure. It is almost always an ordinary failure with its output turned off.

The real question is not "how do I clear the white screen." It is "what actually happened on that request, and where is the record of it." Most white screens trace back to a PHP fatal that never got shown to you, which is the same wp_php_fatals_total signal behind every other blank-page crash on a WordPress site. The rest are memory exhaustion or a redirect loop, both of which leave their own trail if you know where to look. This guide is about finding that trail when you have no admin panel to start from.

2. Impact

A white screen is worse than a normal error page because it gives you nothing to act on and, in the wp-admin case, takes away the tool you would normally use to fix it. The cost compounds the longer it stays a mystery.

• You lose your own way in. When wp-admin is white, the usual first move (deactivate the suspect plugin from the plugins screen) is unavailable. You are locked out of the exact interface built for recovering from this.
• Every visitor sees a dead site, not an error. A 500 page or a critical-error notice at least tells a visitor something went wrong and to try again later. A blank page looks like the domain expired or the browser failed to load, which reads as abandonment rather than a temporary fault.
• Random disabling destroys the evidence. Deactivating plugins one by one over SFTP, or wiping the theme, does eventually restore the page, but by the time it works you often cannot tell which change fixed it, so you cannot tell what actually broke, and it is free to break again the same way.
• The clock keeps running while you guess. Every minute spent trying theme A, then plugin B, then a cache purge, is a minute the site is down for search engines, ad campaigns, and anyone who bookmarked the front page. Blind troubleshooting is slow precisely because it is not informed by anything.

3. Why It’s Hard to Spot

The white screen exists because WordPress, by design, tries not to show visitors raw PHP errors. In production, WP_DEBUG_DISPLAY is off, so when PHP hits a fatal, nothing is printed to the browser at all. Depending on the host and the point of failure, you get a generic critical-error notice, or, if the fatal happens before WordPress can even render that notice, nothing at all: an empty response with a 200 or 500 status and zero bytes of explanation.

What makes this specific case worse than an ordinary fatal is that the failure can be in code that loads on every request, admin and front end alike, such as a must-use plugin, an early hook in a regular plugin, or the active theme's functions.php. If the fatal fires before WordPress finishes bootstrapping, it takes wp-admin down with it, because wp-admin loads the exact same plugins and the exact same theme functions file. There is no separate, safer admin runtime to fall back on.

A second version of the same trap is a redirect loop: something in the site (a forced HTTPS rule, a caching plugin, a broken siteurl value) sends the browser back and forth between two URLs until the browser gives up and shows a blank error, which looks identical to a fatal at a glance. And a third is memory exhaustion mid-render: PHP hits the memory ceiling partway through building the page, so some output may already have been sent before the process dies, leaving a page that is blank or truncated rather than a clean error.

None of these three show up in an uptime monitor as anything other than "page loaded, technically." A blank page with a 200 status code passes most uptime checks. The signal that would tell you a fatal actually fired, or that memory usage spiked right before the crash, exists only in a log file you may not have access to and would not think to check without a lead pointing you there.

4. Cause

A white screen is a symptom, not a cause. It is what a broken request looks like when its error output has nowhere to go. The wp_php_fatals_total signal is the anchor for the most common version of it, but three distinct underlying causes produce the same blank page:

• A PHP fatal with display off. This is the majority case. Something (a plugin update, a PHP version change, a bad edit) causes an uncaught error, and because WP_DEBUG_DISPLAY is off in production, the browser gets nothing instead of the fatal message. Signal: wp_php_fatals_total, often preceded by wp_php_warnings_total naming the symbol involved, and by wp_state_changes_total recording whatever update introduced it.
• Memory exhaustion mid-render. The request hits WP_MEMORY_LIMIT partway through building the page. Some templates have already emitted output when the process dies, so the result is a blank or partial page rather than a clean error screen. Signal: a climbing wp_request_peak_memory_mb on the affected route in the requests leading up to the crash.
• A redirect loop or a broken theme. The browser is bounced between URLs until it stops and shows a blank error, or the active theme's template hierarchy is broken badly enough that nothing renders even though PHP itself did not fatal. This case is quieter in the logs: no fatal line, but often a wp_state_changes_total entry around the time a theme, a caching plugin, or the site URL setting changed.

The Logystera WordPress plugin emits the fatal, the warnings before it, and the state change before that as separate signals on one timeline, which is what turns "the site is just white" into "this fatal, on this route, caused by this change."

5. Solution

5.1 Diagnose (logs first)

Do not start by disabling things at random. Start by getting a fatal to write itself down, because that single log line usually tells you exactly what to do next.

1. Enable logging. If you still have file access (SFTP, hosting file manager, or SSH) but no admin access, edit wp-config.php directly to turn on the log without turning on display.

// In wp-config.php, above the "stop editing" line
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // keep errors out of the browser, we only need the file

2. Reproduce once. Load the white page a single time so the fatal (if that is what this is) has a chance to write itself to the log. Then read it.

grep -nE "PHP Fatal error" /var/www/wp-content/debug.log | tail -n 20

# If that file is empty or missing, check the server-level log instead
grep -nE "PHP Fatal error" /var/log/php-fpm/error.log | tail -n 20

A hit here converts the mystery into an ordinary fatal-error investigation. A typical line looks like this:

[14-Jul-2026 03:12:47 UTC] PHP Fatal error: Uncaught Error: Call to undefined function acf_get_field() in /wp-content/themes/storefront-child/functions.php:41

This is the wp_php_fatals_total signal firing. Note that the file is the theme's functions.php, which loads on every request including wp-admin, which is exactly why both were white. From here, follow the fatal-error workflow to trace the missing function to whatever plugin stopped providing it.

3. If the log is clean, suspect memory or a loop. No fatal line after a reproduced request usually means one of the other two causes. Check peak memory on the route, and separately check whether the browser is actually looping rather than just failing once.

# Look for a memory ceiling being hit even without a fatal line
grep -nE "Allowed memory size" /var/www/wp-content/debug.log | tail -n 20

# Check for a redirect loop from the outside, independent of the browser
curl -sIL https://example.com/ | grep -E "^HTTP|^location" 

A repeating chain of 301/302 responses in that curl output confirms a redirect loop rather than a fatal. A climbing wp_request_peak_memory_mb on the same route across recent requests, with no fatal line, points at memory exhaustion, covered in depth in the memory-limit guide.

5.2 Root Causes

Match what you found in step 1 to its cause before changing anything.

• A PHP Fatal error line in the debug log, especially in a theme file or a must-use plugin, means an ordinary fatal that had nowhere to display. Cause: a removed function, a plugin update, or a PHP version change. Signal: wp_php_fatals_total, usually with wp_state_changes_total just before it.
• An empty debug log plus a rising Allowed memory size pattern on prior requests to the same route means memory exhaustion, not a code contract issue. Signal: wp_request_peak_memory_mb trending up before the blank page.
• A repeating 301/302 chain in curl -IL means a redirect loop, commonly from a forced-HTTPS rule fighting a stale siteurl, or a caching plugin serving a cached redirect. Often shows up as a wp_state_changes_total entry around the time the URL or caching setting changed.
• No fatal, no memory warning, no redirect loop, but still blank, points at a broken theme template hierarchy (a missing index.php, a corrupted template file). This is the rarest case and usually traces back to a bad theme edit or an incomplete file transfer.

5.3 Fix

If you have no admin access, the fix has to happen at the file or database level first. Once you can reach wp-admin again, apply the actual fix for whichever cause you identified.

Regain access with no admin panel. If the fatal traces to one plugin, rename its folder over SFTP so WordPress treats it as deactivated. If the fatal traces to the active theme's functions.php, switch the active theme directly in the database, since you cannot use the Appearance screen.

# Deactivate the one suspect plugin, not everything
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.off

# With WP-CLI, if it is available, this is safer and more precise
wp plugin deactivate some-plugin
wp theme activate twentytwentyfour

# Without WP-CLI, switching the theme means editing the option directly
wp db query "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet');"

Fix the underlying fatal. Once you are back in, this is an ordinary fatal-error fix: update or roll back the plugin that removed the function the theme called, or update the theme to match the plugin's current API. Renaming the folder restored access, it did not fix anything. Follow the fatal-error guide for the contract-break workflow, or the causal-chain guide if an update is the trigger.

Fix the memory case. Raising WP_MEMORY_LIMIT buys headroom but does not address why the route is consuming that much memory in the first place. Find and bound the query or loop driving wp_request_peak_memory_mb up; see the memory-limit guide for the full workflow.

Fix the redirect loop. Confirm the site's actual URL in the database matches what the server expects, purge any page or object cache that might be serving a stale redirect, and check the forced-HTTPS rule in .htaccess or the server config is not fighting a plugin doing the same thing.

wp option get siteurl
wp option get home
wp cache flush

5.4 Verify

The page loading once is not proof. Confirm the underlying signal actually stopped, on both the front end and wp-admin.

# Confirm no new fatals since the fix
grep -nE "PHP Fatal error" /var/www/wp-content/debug.log \
  | awk -F']' '$1 > "[14-Jul-2026 04:00:00 UTC"'

# Confirm both the front end and wp-admin return real pages, not blanks
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-admin/

In the metric, wp_php_fatals_total should stay flat across every route that was previously white, not just the one you tested manually. If the original cause was memory, watch wp_request_peak_memory_mb on the same route for a full traffic cycle rather than a single reload, since a memory ceiling that was hit under load may not reproduce on a quiet manual request.

6. How to Catch This Early

A white screen feels unsolvable because it withholds the one thing you need: what actually happened. Once you can see the fatal, it stops being a mystery and becomes a normal fix.

This issue surfaces as wp_php_fatals_total.

Nothing in default WordPress alerts on this. There is no notification that a request came back blank, no record that survives past whatever short retention your host keeps on its error log, and no distinction in an uptime check between a real page and an empty 200 response. The plugin folder you renamed to fix the immediate outage removed the evidence of which plugin caused it at the same time it restored the page.

Reading the fatal from the logs and counting it as a signal is what replaces the guesswork. A fatal that starts firing on a specific route, right after a plugin update lands as wp_state_changes_total, is visible the moment it happens rather than the moment someone reports the site is down. The same applies to memory: a wp_request_peak_memory_mb trend climbing toward the ceiling on one route is a warning you can act on hours before that route goes blank for every visitor.

7. Related Silent Failures

• wp_php_fatals_total spike: the ordinary fatal-error case, worth reading in full once you have a log line to work with. See the fatal-error guide.
• wp_php_warnings_total spike: warnings naming a symbol in the seconds before a fatal, often the fastest way to identify which function or class went missing.
• wp_request_peak_memory_mb climbing: the precursor to a memory-exhaustion white screen, worth watching per route rather than site-wide. See the memory-limit guide.
• wp_state_changes_total after an auto-update: the most common trigger for a fatal or a broken redirect setting that "appeared out of nowhere."
• Tracing an update to the fatal it caused: for the case where a white screen followed shortly after a plugin or core update, the full trigger-to-crash chain is covered in the causal-chain guide.