WordPress White Screen of Death (WSOD): 12 checks that actually work

October 20, 2025 • February 3, 2026 • Read: 19 min • Views: 9

Was this helpful?

The White Screen of Death is WordPress’s way of saying “something exploded” while refusing to tell you where the shrapnel landed. Customers see a blank page. Your monitoring sees “200 OK”. Your on-call brain sees its own mortality.

This is the playbook I wish more teams ran: fast triage first, then disciplined checks that turn mystery into a single root cause you can fix and prevent.

Fast diagnosis playbook (first 10 minutes)

Speed matters, but guessing is slower than reading the right log once. The goal is to find the bottleneck: is the failure happening before PHP runs, inside PHP, or after PHP (database/cache/storage)?

Minute 0–2: confirm what “white” means

Check HTTP status and headers. A 500 with an empty body is different from a 200 that returns whitespace.
Compare homepage vs wp-admin. If wp-admin loads, it’s often theme/front-end plugin, not global runtime.
Bypass CDN and caches. If the origin is fine and the edge is blank, you’re debugging the wrong system.

Minute 2–5: read the error logs like a grown-up

Web server error log (Nginx/Apache) for upstream failures and timeouts.
PHP-FPM log / PHP error log for fatal errors, memory exhaustion, opcode cache issues.
Application-level fatal via WordPress debug log if you can enable it safely.

Minute 5–10: isolate plugins/themes without touching code

Disable all plugins (WP-CLI or rename directory) and retest.
Switch to a known-good default theme.
If it’s still white, stop blaming “a plugin” and look at PHP version mismatches, missing extensions, DB connectivity, disk, and memory.

One useful mental model: WSOD is rarely “WordPress is down.” It’s usually “PHP hit a fatal and output buffering produced nothing” or “the runtime can’t read/write required files and fails mid-flight.”

A few facts (and minor history) about WSOD

WSOD predates WordPress. The term was popularized in the PHP ecosystem when fatal errors were suppressed in production, leaving blank output.
WordPress used to fail silently by default. Early configurations often had display_errors off with no centralized logging, making WSOD effectively “normal.”
“The Recovery Mode” is relatively new. WordPress introduced a fatal error protection/recovery mode (5.2 era) that can email admins and let you disable a broken plugin/theme. It helps, but it’s not omniscient.
WSOD can be a 200 OK. Many failures happen after headers are sent or are handled in a way that returns an empty body with success status—so uptime checks lie.
OPcache made WSOD both better and worse. It improves performance, but stale bytecode after a deployment can keep executing old code even when files changed.
Modern PHP is stricter. Upgrading PHP versions can turn “warnings you ignored for years” into fatals due to removed functions or stricter typing.
Memory exhaustion is still a top cause. Particularly with page builders, big WooCommerce installs, and “helpful” security plugins that do expensive things on every request.
Storage failures often masquerade as WSOD. A full disk, read-only filesystem, or slow NFS can cause PHP sessions/uploads/cache writes to fail, resulting in blank pages.
CDNs can cache emptiness. If the origin briefly returns a blank 200, the edge may happily serve that blankness to everyone until expiry.

One quote that every WSOD incident quietly proves: Everything fails, all the time. — Werner Vogels

The 12 checks that actually work (with commands, outputs, decisions)

Each check below is a real task: a command you can run, what the output means, and the decision you make. Do these in order unless you already have a smoking gun.

Joke #1: WSOD is like a meeting with no agenda: everyone is present, nothing is happening, and somehow you’re still losing money.

Check 1) Confirm the failure mode with curl (status, headers, body size)

cr0x@server:~$ curl -sS -D- -o /tmp/body.html -w "\nstatus=%{http_code} size=%{size_download} time=%{time_total}\n" https://example.com/ | head -n 20
HTTP/2 200
date: Thu, 26 Dec 2025 14:21:09 GMT
content-type: text/html; charset=UTF-8
cache-control: max-age=0, must-revalidate
server: nginx

status=200 size=0 time=0.312

What it means: A 200 with size=0 is classic WSOD behavior: request succeeded at HTTP level, but generated no body (or got truncated).

Decision: Treat this as an application/runtime failure, not “the web server is down.” Move to logs and PHP-FPM.

Check 2) Bypass CDN / edge caching to prove origin behavior

cr0x@server:~$ curl -sS -H "Cache-Control: no-cache" -H "Pragma: no-cache" -D- -o /dev/null https://example.com/
HTTP/2 200
date: Thu, 26 Dec 2025 14:21:31 GMT
content-type: text/html; charset=UTF-8
cf-cache-status: HIT
server: cloudflare

What it means: The edge is serving cached content (maybe cached blankness). Your “no-cache” request didn’t force origin.

Decision: Test origin directly by hitting the origin IP/host header or internal LB address. If origin is fine, purge edge cache; if origin is broken, stop looking at CDN.

Check 3) Look at web server errors first (Nginx example)

cr0x@server:~$ sudo tail -n 80 /var/log/nginx/error.log
2025/12/26 14:20:58 [error] 23144#23144: *9181 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect() in /var/www/html/wp-content/plugins/legacy-db/legacy.php:41" while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

What it means: This is gold: a fatal error inside a plugin calling a removed function. PHP never produced a valid response.

Decision: Disable that plugin immediately. Then plan a code fix or replacement. Also check why this made it to production (more on that later).

Check 4) Check PHP-FPM service health and recent crashes

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running) since Thu 2025-12-26 14:00:01 UTC; 21min ago
   Main PID: 1109 (php-fpm8.2)
      Tasks: 19 (limit: 18962)
     Memory: 214.5M
        CPU: 1min 42.110s
     CGroup: /system.slice/php8.2-fpm.service
             ├─1109 "php-fpm: master process (/etc/php/8.2/fpm/php-fpm.conf)"
             └─1132 "php-fpm: pool www"

What it means: PHP-FPM is up. That does not mean it’s healthy; it just means it’s alive. You still need to inspect logs for worker crashes, max children, slow requests.

Decision: If PHP-FPM is down or flapping, fix that first (config, memory, segmentation faults, package issues). If it’s up, proceed to logs.

Check 5) Read PHP-FPM log for fatal patterns (memory, timeouts, segfaults)

cr0x@server:~$ sudo tail -n 120 /var/log/php8.2-fpm.log
[26-Dec-2025 14:20:58] WARNING: [pool www] child 1733 said into stderr: "PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 2345"
[26-Dec-2025 14:21:03] WARNING: [pool www] child 1735 exited on signal 11 (SIGSEGV) after 2.412340 seconds from start
[26-Dec-2025 14:21:03] NOTICE: [pool www] child 1741 started

What it means: Two separate problems can exist: memory exhaustion (usually deterministic per request) and segfaults (often extension bugs, OPcache, or corrupted memory). Either can yield WSOD.

Decision: For memory exhaustion: identify the offending request/plugin/theme; raise limits only after you know why. For segfaults: check extensions (Redis, Imagick), OPcache, PHP version; consider rolling back or disabling the extension.

Check 6) Enable WordPress debug logging safely (not display_errors)

In production, you want logs, not public error output. Edit wp-config.php and log to file. Then reproduce the request once.

cr0x@server:~$ sudo -u www-data sed -n '1,120p' /var/www/html/wp-config.php | tail -n 20
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Change (temporarily) to:

cr0x@server:~$ sudo -u www-data perl -0777 -pe 's/define\(\x27WP_DEBUG\x27,\s*false\);/define(\x27WP_DEBUG\x27, true);/; s/define\(\x27WP_DEBUG_LOG\x27,\s*false\);/define(\x27WP_DEBUG_LOG\x27, true);/; s/define\(\x27WP_DEBUG_DISPLAY\x27,\s*false\);/define(\x27WP_DEBUG_DISPLAY\x27, false);/' -i /var/www/html/wp-config.php

Then hit the site and read:

cr0x@server:~$ sudo tail -n 80 /var/www/html/wp-content/debug.log
[26-Dec-2025 14:22:15 UTC] PHP Fatal error:  Uncaught TypeError: strpos(): Argument #1 ($haystack) must be of type string, null given in /var/www/html/wp-content/themes/custom/functions.php:912
Stack trace:
#0 /var/www/html/wp-content/themes/custom/functions.php(912): strpos()
#1 /var/www/html/wp-includes/class-wp-hook.php(324): theme_filter()

What it means: Theme code is crashing. That can blank the front end while wp-admin still works.

Decision: Switch theme now; fix theme after service is restored. Revert debug settings after you’ve captured the error (or keep logging, but rotate).

Check 7) Disable all plugins using WP-CLI (fast, reversible)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp plugin list --status=active
+---------------------+--------+-----------+---------+
| name                | status | update    | version |
+---------------------+--------+-----------+---------+
| redis-cache         | active | none      | 2.5.2   |
| legacy-db           | active | available | 1.3.1   |
| woo-commerce        | active | none      | 8.5.0   |
+---------------------+--------+-----------+---------+
cr0x@server:~$ sudo -u www-data wp plugin deactivate --all
Plugin 'redis-cache' deactivated.
Plugin 'legacy-db' deactivated.
Plugin 'woo-commerce' deactivated.
Success: Deactivated 3 of 3 plugins.

What it means: You’ve removed the biggest variable: plugin code. If WSOD disappears, re-enable one by one (binary search if there are many).

Decision: If disabling plugins fixes it: re-enable until it breaks; then patch/replace the culprit. If not fixed: look at theme/runtime/DB/storage.

Check 8) Switch to a default theme without the admin UI

If the front end is down but you can’t get into wp-admin, switching themes via CLI is clean.

cr0x@server:~$ sudo -u www-data wp theme list
+----------------+----------+-----------+---------+
| name           | status   | update    | version |
+----------------+----------+-----------+---------+
| twentytwentyfour | inactive | none      | 1.2     |
| custom         | active   | none      | 3.8     |
+----------------+----------+-----------+---------+
cr0x@server:~$ sudo -u www-data wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

What it means: You’ve replaced the execution path that renders most pages. WSODs frequently live in functions.php or a theme’s mucky “utility” file.

Decision: If this restores the site, keep the default theme active while you fix the custom theme. Your brand team will survive.

Check 9) Verify PHP version, loaded modules, and missing extensions

cr0x@server:~$ php -v
PHP 8.2.12 (cli) (built: Nov  8 2025 10:12:34) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.12, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.12, Copyright (c), by Zend Technologies
cr0x@server:~$ php -m | egrep -i 'mysqli|pdo_mysql|imagick|redis|opcache'
mysqli
PDO
pdo_mysql
redis
Zend OPcache

What it means: The basics are present. If you’re missing mysqli or pdo_mysql, WordPress can fail hard. If imagick is absent, some plugins/theme code might fatal if it assumes it exists.

Decision: If a required extension is missing, install it or change the plugin/theme that assumes it. Also: ensure PHP-FPM and CLI versions match; mismatches create “works in CLI, breaks on web” nonsense.

Check 10) Confirm memory limits at PHP and WordPress layers

cr0x@server:~$ php -r 'echo "memory_limit=".ini_get("memory_limit").PHP_EOL;'
memory_limit=256M
cr0x@server:~$ grep -R "WP_MEMORY_LIMIT" -n /var/www/html/wp-config.php
42:define('WP_MEMORY_LIMIT', '128M');
43:define('WP_MAX_MEMORY_LIMIT', '256M');

What it means: WordPress may cap memory lower than PHP’s global setting. Admin requests use WP_MAX_MEMORY_LIMIT; front end uses WP_MEMORY_LIMIT. A WSOD that only affects wp-admin can be the inverse.

Decision: If you’re hitting memory fatals, temporarily raise WP_MEMORY_LIMIT to match PHP, but do not stop there. Find the heavy query, runaway loop, or plugin doing unbounded work. Bigger memory is not a fix; it’s a bandage.

Check 11) Validate database connectivity and look for “too many connections”

WordPress can blank out when DB calls fail mid-render, especially if errors are suppressed and the theme doesn’t handle nulls.

cr0x@server:~$ mysql -h 127.0.0.1 -u wpuser -p -e "SELECT 1;"
Enter password:
1
1
cr0x@server:~$ mysql -h 127.0.0.1 -u root -p -e "SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';"
Enter password:
Threads_connected	148
max_connections	150

What it means: You’re flirting with the connection ceiling. When the site spikes, PHP workers queue up, and DB rejects connections. Depending on error handling, you may get WSOD.

Decision: Short-term: reduce concurrency (PHP-FPM pm.max_children), or raise DB max_connections if the host can handle it. Long-term: optimize queries, add caching correctly, and stop running “slow analytics” in the request path.

Check 12) Storage sanity: disk full, inode exhaustion, permissions, and read-only mounts

Storage problems are the quiet assassins of PHP apps: sessions can’t write, cache can’t update, uploads fail, and code paths do weird things when file operations return false.

cr0x@server:~$ df -h /var/www /tmp
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  160M 100% /
tmpfs           1.0G  1.0G     0 100% /tmp
cr0x@server:~$ df -i /
Filesystem     Inodes IUsed  IFree IUse% Mounted on
/dev/vda1     262144 262144     0  100% /
cr0x@server:~$ mount | grep ' on / '
/dev/vda1 on / type ext4 (ro,relatime,errors=remount-ro)

What it means: Triple whammy: disk full, inodes exhausted, and the filesystem remounted read-only. WordPress is not going to gracefully handle this; it will simply fail to write critical files and can present as WSOD.

Decision: Restore write capability and free space first. Delete logs, clear temp directories, rotate properly, and investigate why the filesystem flipped read-only (underlying disk errors, kernel issues). Don’t waste time reinstalling plugins while your disk is on fire.

Bonus check) OPcache: when deployments “succeed” but code doesn’t change

This one is so common in production that it deserves a slot even if it makes the list “12 plus a bonus.” If you can only have twelve checks, replace whichever you do least.

cr0x@server:~$ php -r 'echo "opcache.enable=".ini_get("opcache.enable").PHP_EOL; echo "opcache.validate_timestamps=".ini_get("opcache.validate_timestamps").PHP_EOL; echo "opcache.revalidate_freq=".ini_get("opcache.revalidate_freq").PHP_EOL;'
opcache.enable=1
opcache.validate_timestamps=0
opcache.revalidate_freq=2

What it means: With timestamp validation off, PHP may never notice code changes until FPM restarts. That can keep a broken version running even after you “fixed it.”

Decision: In immutable deployment models, this can be acceptable if you restart PHP-FPM on deploy. If you don’t, enable validation or add an explicit reload step. Operational consistency beats cleverness.

Joke #2: “It works on my laptop” is adorable. Production does not do adorable.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption (the PHP upgrade “should be fine”)

A mid-sized company ran a content-heavy WordPress site behind an Nginx reverse proxy. They also ran a separate marketing microsite farm. On a quiet Tuesday, they upgraded the base image for all PHP services, moving from PHP 7.4 to PHP 8.2. It was planned, approved, and “tested.”

The wrong assumption was simple: if the staging homepage loads, production will load. Their staging environment had a different plugin set—because licensing. The legacy plugin that handled an old database integration wasn’t installed in staging, and nobody noticed because it “wasn’t supposed to matter anymore.” It mattered.

Production started returning a blank 200 for the homepage. Monitoring stayed green because their health check hit /robots.txt, which was static. Support tickets arrived. The on-call engineer saw the 200 and initially blamed the CDN. Ten minutes disappeared in cache purges and redeploys.

The fix was quick once they looked at Nginx errors: a fatal from a removed PHP function. They disabled the plugin via WP-CLI, restored service, and later replaced it with a supported integration.

The prevention was less glamorous: their “staging parity” policy now required the same plugin list (even if configured differently), and upgrades required a synthetic transaction that hit dynamic WordPress endpoints, not static files.

Mini-story 2: The optimization that backfired (object cache without guardrails)

An enterprise team had a WordPress site that spiked during press releases. Someone proposed Redis object caching to reduce database load. Good instinct. They rolled it out quickly, celebrated a drop in DB CPU, and moved on to the next fire.

Weeks later, a plugin update introduced a subtle bug: it cached a large PHP object graph under a key that varied by user-agent and some query parameters. Cache keys exploded. Redis memory filled, eviction got aggressive, and latency climbed. Under load, PHP requests started timing out waiting on Redis calls.

From the outside, the site looked like WSOD: pages were blank or half-rendered. Internally, Nginx showed upstream timeouts. PHP-FPM had many active workers stuck. The database was fine, which misled the team because “we solved DB.” They had not solved the request path; they had just moved the bottleneck to a new box.

The rollback was to disable object caching immediately (rename the drop-in file), then reintroduce it with constraints: sane TTLs, memory caps, key discipline, and a rule that caching bugs are production outages, not “performance issues.”

The lesson: caching is a sharp tool. If you wave it around in a crowded room, someone bleeds.

Mini-story 3: The boring but correct practice that saved the day (logs, rotation, and a canary)

A financial services team ran WordPress for a knowledge base. Nothing fancy, lots of compliance. Their practices were not exciting: centralized logs, strict log rotation, a deployment checklist, and a canary host that received traffic from internal users first.

One day, a theme update introduced a fatal error on a rarely used page template. The canary host started logging a fatal immediately. Because logs were centralized, the on-call didn’t need SSH heroics; they saw the exact stack trace in a dashboard and rolled back the theme package.

External users never saw WSOD. The change was reverted before the public rollout stage. No drama, no war room, no “maybe it’s DNS.”

This is the part people hate: the correct solution was not a clever command. It was dull process and observability. Dull is a feature when you’re responsible for uptime.

Common mistakes: symptom → root cause → fix

1) Blank page only on the homepage

Symptom: / is white; /wp-admin works.
Root cause: Theme template crash, front-end-only plugin hook, or a fatal in a shortcode used on the homepage.
Fix: Switch theme via WP-CLI; disable front-end plugins; check debug log for stack trace; reintroduce changes one at a time.

2) White screen after plugin update

Symptom: Site blanks immediately after updating one plugin.
Root cause: Fatal due to PHP version incompatibility, missing extension, or bad autoloader/class redeclaration.
Fix: Disable the plugin via WP-CLI; verify PHP version; rollback plugin; test update in parity staging.

3) White screen only for logged-in users

Symptom: Anonymous users see the site; admins see WSOD.
Root cause: Admin-only plugins, dashboard widgets, or memory limit differences (WP_MAX_MEMORY_LIMIT).
Fix: Increase admin memory temporarily; disable admin plugins; check PHP-FPM logs for memory exhaustion; profile slow admin pages.

4) White screen intermittently under load

Symptom: Works sometimes; blanks during spikes.
Root cause: PHP-FPM worker exhaustion, upstream timeouts, DB connection limits, Redis latency, or slow storage.
Fix: Check Nginx upstream timeouts, PHP-FPM pm.max_children, DB Threads_connected, Redis latency. Reduce concurrency or optimize slow path.

5) WSOD started “after we cleaned up caches”

Symptom: Clearing cache seems to trigger the blank pages.
Root cause: Cache plugin writes to disk/tmp, but disk is full or filesystem is read-only; or permissions are wrong on wp-content.
Fix: Check disk/inodes, mount flags, ownership on wp-content; fix storage first, then rebuild caches.

6) WSOD after enabling “security hardening”

Symptom: Site goes blank after enabling a WAF rule, hardening plugin, or file permissions change.
Root cause: Blocking admin-ajax/admin-post, blocking REST endpoints, or preventing PHP from reading theme/plugin files.
Fix: Review WAF logs; revert permissions to a known-good baseline; ensure PHP user can read code and write uploads/cache where needed.

Checklists / step-by-step plan (restore service, then prevent)

Phase 1: Restore service (priority: user impact)

Confirm WSOD mode with curl (status, size, response time).
Bypass caches/CDN and test origin.
Read web server and PHP-FPM logs for fatal errors and timeouts.
Disable all plugins (WP-CLI). Re-test.
Switch to a default theme. Re-test.
Check disk/inodes and mount state (full/read-only kills WordPress fast).
Check DB connectivity and connection saturation.
Rollback last change (plugin/theme/PHP version) if the cause is not obvious within 30 minutes.

Phase 2: Identify the exact root cause (priority: don’t repeat)

Capture the first fatal stack trace (WordPress debug log or PHP error log).
Reproduce in a controlled environment with the same plugin/theme set and PHP version.
Pinpoint the triggering request: homepage, shortcode, cron, admin-ajax, REST route.
Fix the bug or replace the component; add a regression test (even a cheap synthetic curl that checks non-empty HTML).
Decide whether to adjust memory/timeouts—only after code path is understood.

Phase 3: Prevention (priority: future you gets to sleep)

Parity staging: same plugin list, same PHP version, same caching layers.
Centralized logs: Nginx/Apache + PHP-FPM + WordPress debug log (rotated).
Deploy discipline: restart PHP-FPM when OPcache timestamp validation is off; avoid “partial deploys.”
Real health checks: hit dynamic endpoints and validate response body size, not just status code.
Storage monitoring: alert on disk %, inode %, and read-only remount events.

FAQ

1) Why do I get a white screen with HTTP 200?

Because the request completes at the HTTP layer, but PHP produces no output—often due to a fatal error, buffering, or output being cut off. Logs tell the truth.

2) Should I turn on `display_errors` in production?

No. Log errors instead. Public error output is an info leak and can break responses further. Enable WP_DEBUG_LOG and keep WP_DEBUG_DISPLAY false.

3) What’s the fastest way to rule out plugins?

WP-CLI: wp plugin deactivate --all. If you don’t have WP-CLI, rename wp-content/plugins to something else and retest.

4) Can a theme really cause WSOD?

Yes. Themes run PHP. A fatal in functions.php or a template part can blank the site just as effectively as a plugin.

5) Why does WSOD happen only sometimes?

Intermittent WSOD usually means resource contention: PHP-FPM workers exhausted, DB connections maxed, cache latency, or storage stalls. Look for timeouts and saturation metrics, not just fatals.

6) What if wp-admin is also white?

That points to a global issue: a must-use plugin, a core file mismatch, PHP extension crash, database failure, or storage/permissions. Start with logs, then disable plugins/themes from the filesystem or database.

7) How do I switch the theme if WP-CLI isn’t available?

Edit the database options template and stylesheet to a default theme. Or restore WP-CLI; it’s safer than manual SQL when you’re stressed.

8) Could OPcache cause WSOD?

Indirectly, yes: stale bytecode can keep executing broken code after you “fixed” files. If you deploy without restarting PHP-FPM and OPcache timestamp validation is off, you’re gambling.

9) Is increasing memory limit a valid fix?

As a temporary mitigation, sometimes. As a final fix, rarely. If a request suddenly needs double the memory, something changed: a plugin update, a query, an infinite loop, or a payload growth.

10) How do I stop the CDN from caching the blank page?

Purge the affected paths and ensure your origin doesn’t return empty 200s during failures. Configure edge caching rules to respect error statuses, and consider a synthetic check that validates non-empty HTML.

Next steps (practical, not inspirational)

Do this the next time WSOD hits:

Run curl and confirm status, size, and whether you’re looking at edge cache or origin.
Read Nginx/Apache error logs and PHP-FPM logs before changing anything else.
Disable plugins, switch theme, and re-test—fast isolation beats slow reasoning.
Check disk/inodes and mount state. Storage failures waste hours because they look “application-y.”
Once restored, write down the single root cause, the triggering change, and the guardrail you’re adding.

If you only add one guardrail: make your health check fetch a dynamic WordPress page and fail if the body is empty. WSOD loves hiding behind “200 OK.” Don’t let it.