WordPress white-screen diagnosis

Trace the WordPress white screen to its source using the HTTP response and PHP logs

A white screen is not one error. The server may return 500, produce a zero-byte or truncated body with 200, affect only wp-admin, or a cache/CDN may serve stale empty output. The first step is to measure scope and the real HTTP response, not to disable plugins blindly.

Go to Steps Frequently Asked Questions

root@eka:~/diagnostics

curl -sS -D /tmp/headers.txt -o /tmp/body.html https://example.com/
sed -n '1,20p' /tmp/headers.txt
wc -c /tmp/body.html
tail -n 120 wp-content/debug.log
wp plugin status
wp theme status

STATUS200, 500 or redirect

BYTESIs the body actually empty?

SCOPEWhole site, wp-admin or one URL

LOG TIMESame window as the request

Topic-specific framework

Distinguish a white screen from a critical error, cached output and frontend failure

A browser may appear blank even when HTML exists or JavaScript/CSS hides the content. Measuring status, headers and body size with `curl` confirms whether the server truly returned an empty response. Then compare WordPress debug.log with PHP-FPM, Apache, Nginx or LiteSpeed logs in the same time window.

Scope test

Whole site or one area?

Test homepage, a single post, wp-login.php, wp-admin and REST API separately. If only one template or endpoint fails, disabling everything is unnecessary.

Response test

HTTP status and body size

A 500, a zero-byte 200, a truncated 200 and a redirect loop point to different causes. Save headers and the actual body.

Server evidence

WordPress and PHP logs

If failure occurs before WordPress starts, debug.log may remain empty. PHP-FPM pool, Apache error_log, Nginx error.log or LiteSpeed stderr then become decisive.

Terminal and verification

Inspect the real HTTP output and log timing, not only the browser view

Capture headers and body separately

This reveals status, Content-Type, redirects and whether the body is truly empty. Comparing CDN and origin requests can expose caching differences.

curl -sS -D /tmp/wp-headers.txt -o /tmp/wp-body.html https://example.com/
sed -n '1,25p' /tmp/wp-headers.txt
wc -c /tmp/wp-body.html
head -c 300 /tmp/wp-body.html

Compare scope by URL

Differences among frontend, login, admin and REST may point to theme templates, admin plugins or rewrites. View status codes together.

for u in / /wp-login.php /wp-admin/ /wp-json/; do
  curl -sS -o /dev/null -w "$u %{http_code} %{size_download}\n" "https://example.com$u"
done

Enable safe debug logging

Enable WordPress logging without displaying errors. Reproduce the screen once and read the latest lines. If no file is written, check wp-content permissions and the PHP error log.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

List recent changes and active components

A timeline of deployments, plugin/theme updates, PHP changes or cache rules accelerates diagnosis.

wp core version
php -v
wp plugin list --status=active --fields=name,status,version,update
wp theme list --status=active --fields=name,status,version,update
find wp-content -type f -mmin -180 | head -80

Implementation order

Narrow the white screen from scope to root cause

Pair file and database backups

Before repair, capture wp-content, wp-config.php and the database as one timestamped set. Plan around live orders or form submissions.

Determine the white-screen scope

Compare homepage, a content URL, wp-login.php, wp-admin and wp-json using a private window and another network. If only one user or device is affected, investigate browser/cache layers.

Save status and body as evidence

Do not treat a 500 and an empty 200 as the same. Record Content-Type, Content-Length, redirect chain, body size and initial HTML bytes.

Find logs from the same time window

Reproduce once, then immediately inspect WordPress, PHP and web-server logs. Review `Fatal error`, `Uncaught`, `memory`, `permission denied` and `upstream sent` entries in context.

Isolate the logged component selectively

If the path names a plugin or theme, disable only it or roll back to the last working version. If logs are absent, use WP-CLI skip flags and controlled comparisons.

Clear and compare cache, opcode and CDN layers

After the app is fixed, stale empty output may remain in object/page cache, OPcache or CDN. Clear layers in order and compare origin with public URL again.

Verify functionality and absence of new log entries

Test login, admin, forms, AJAX/REST, cron, email and payments in addition to the homepage. Confirm no new fatal error or warning storm appears.

Error dictionary

Distinguish the technical meanings of blank output

HTTP 500 + empty body

Usually a PHP fatal error, web-server rule, permission problem or upstream crash. Prioritize PHP-FPM/Apache/Nginx logs for the request timestamp.

HTTP 200 + zero or tiny body

Code may exit early, clear output buffers, return incorrectly from a custom endpoint or cache an empty response.

HTML exists but the screen is white

Possible causes include CSS visibility, an overlay, JavaScript failure, missing assets or a browser extension. Inspect source, Console and Network.

Only wp-admin is white

Admin-only hooks, role-dependent code, admin AJAX or different memory use may be involved. A working frontend does not prove the whole site is healthy.

Risks

Practices to avoid

Diagnosing only by browser appearance without measuring HTTP status
Deleting or renaming plugin/theme directories without a backup
Enabling PHP display_errors on production and exposing file paths
Misjudging the fix because caches were not compared
Disabling everything at once and losing the failing component

Checklist

Prove before completion

Status codes for frontend, wp-admin, login and REST are recorded
Response body size and initial HTML were inspected
WordPress and PHP/web-server logs from the same timestamp were compared
The failing component was isolated based on evidence
Origin, cache/CDN and private-window results agree
Login, forms, AJAX/REST, cron and email were re-tested

Frequently asked questions

Clear answers about the WordPress white screen

What is the most common cause of a WordPress white screen?

Plugin/theme PHP fatal errors and memory exhaustion are common, but empty 200 responses, cache, permissions, web-server or frontend issues also occur. Status and logs are required.

Can WP-CLI work during a white screen?

Often yes. If bootstrap hits the same fatal error, some commands may work with `--skip-plugins` and `--skip-themes`; mu-plugins may still load and require separate inspection.

Does an empty debug.log mean there is no error?

No. The failure may occur before WordPress, logging may lack permission or PHP may use another target. Check PHP-FPM, Apache, Nginx/LiteSpeed and hosting-panel logs.

Does renaming the plugins folder fix a white screen?

It may restore access if a plugin is responsible, but disables all plugins and does not prove the root cause. Target the logged plugin first whenever possible.

Is the site healthy if it returns HTTP 200?

No. A 200 response may contain zero bytes, truncated HTML or an application error page. Inspect body, functionality and logs.

Internal SEO topic cluster

Continue to the right topic after this guide

Category hubWordPress Technical Guides

Before interventionWordPress Backup and Restore

Main knowledge centerAll Technical Guides

Technical sources

Verify with official documentation

WordPress Developer Handbook — Common WordPress errors WordPress Developer Handbook — Debugging in WordPress WordPress Developer Handbook — Editing wp-config.php WP-CLI — wp plugin deactivate WP-CLI — wp core verify-checksums

EKA SUNUCU TEKNİK BİLGİ MERKEZİ

Base your decision on technical evidence, not assumptions.

Contact Eka Software and Information Systems for installation, server, script and technical support services.

Custom Server Services

Standard Servers