Diagnose a blank page by separating a PHP fatal error, a failed theme template, cache output and a missing response body.
Recognize the symptoms before changing settings
The same visible error can originate in different layers. Your first objective is to identify whether the failure is specific to a route, a user action, a hosting component or a recent change. Do not treat a browser message as a complete diagnosis.
- A public page is fully white or nearly empty, sometimes with HTTP 200.
- The administrator screen may load while the public theme fails, or both may be blank.
- A recent update or custom PHP edit precedes the problem.
Record the original URL, time of failure, browser or HTTP error and the last change that occurred before the issue began. These observations make later comparisons reliable, especially when caching or multiple servers are involved.
Before you change anything
If the site is taking payments or sending messages, confirm whether an operation may have already completed before resubmitting it. Make one isolated change at a time, then test the original failure again.
Diagnosis: find the layer that actually failed
Work through these plausible causes in evidence-first order. More than one can coexist, but fixing the first confirmed cause is safer than making several speculative adjustments.
Common underlying causes
- Fatal PHP error with public display suppressed.
- A template produces no output or stops before rendering.
- Cached empty output at the CDN or page cache.
- Theme/plugin incompatibility, not necessarily memory exhaustion.
Three checks that narrow the problem
- Inspect the Network tab for HTTP status, response length and response headers.
- Compare a logged-in session, private browsing and a cache-bypassed test.
- Check the first fatal error at the matching request time.
The relevant response, request log and configuration source together provide better evidence than a generic error screenshot. If you cannot access logs, gather the failing URL and timestamp and request the corresponding records from your hosting provider.
How to interpret conflicting results
If the first check points toward fatal php error with public display suppressed, focus on reproducing that condition without changing unrelated settings. A quick improvement after a targeted test is useful evidence but not yet proof that the root cause is removed.
If your second check suggests a template produces no output or stops before rendering, collect the corresponding service or application log and compare what happens immediately before and after the failed request. This prevents mistaking correlation for cause.
If neither case fits, consider theme/plugin incompatibility, not necessarily memory exhaustion. Work from the outside in: DNS and connection, web server and proxy, PHP/WordPress runtime, then the affected plugin, theme or data. When a check gives inconclusive results, record that uncertainty instead of labelling it a confirmed fix.
Step-by-Step Troubleshooting
Choose the safest method for your access level. Use the Beginner tab for recovery and the Advanced tab for log-based diagnosis and targeted fixes.
Use WordPress Recovery Mode when available
Check the administrator email for a Recovery Mode link and disable the extension named in its diagnostic message. Preserve the error message before taking action.
Disable only the most likely extension
If Recovery Mode is unavailable, rename the just-changed plugin directory through SFTP, then load one affected page. If the issue started with a theme change, switch to a known working theme through the dashboard or staging restore rather than deleting the theme.
Compare cached and uncached output
Purge the specific page from any server or CDN cache only after noting whether the origin returns valid HTML. If only cached visitors see a blank page, investigate cache generation or edge rules.
Use a private error log to locate the real crash
Temporarily enable logging without public display. Place these constants before the WordPress stop-editing marker; adjust existing definitions instead of duplicating them.
define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );Check PHP and theme compatibility
Identify the PHP version and fatal-error file/line number. Compare the failing function with the documented requirements of that plugin or theme before modifying core files.
Prove the repair and restore safe settings
Reload one public page, one admin page and one uncached page. Restore debug constants and keep the original version of the changed file.
How to verify the repair
Do not call a problem solved solely because one browser reload succeeds. Retest the exact workflow that failed, then include a normal public request and one administrator action. Keep the site cache and authenticated/anonymous behavior in mind.
- The page returns expected HTML for anonymous and logged-in users.
- No matching fatal-error message recurs after several fresh requests.
Complete the checklist below as you test. The progress indicator belongs to this article and is intended as a reading aid, not a guarantee of server health.
Solution Checklist
If it still fails: rollback and escalation
If the symptom remains, stop repeating the same changes. Save the newest error evidence and compare it with the pre-change state; the unchanged behavior is a useful clue that the current hypothesis was wrong.
- Restore the plugin directory name or original edited file.
- Re-enable the prior theme or restore the working snapshot if the change did not help.
When escalating to your provider or developer, send the time, affected URL, relevant status/log excerpt, environment version and the specific changes already tried. Remove passwords, session cookies, personal information and secret keys from the report.
How to prevent the error from returning
- Test PHP upgrades and theme updates on staging.
- Maintain access to error logs and recovery-email delivery.
After a successful fix, make a brief incident note: symptom, root cause, effective change, verification test and rollback instructions. This is much more useful than keeping a list of unverified tweaks.
Further reading: official documentation
This guide explains diagnostic choices rather than guaranteeing that one setting will work on every host. Verify the actual software versions, hosting environment and provider restrictions before applying examples.