Diagnose a WordPress white screen without blindly disabling production components or destroying evidence.
A blank WordPress response may hide a PHP fatal error, exhausted resource, broken template, incompatible extension, failed update, cache artifact, or output problem. Preserve the failing request and recent-change evidence before attempting broad fixes.
Classify the blank response
Record the exact URL, time, login state, device, status code, response size, whether page source contains markup, and whether admin, API, cron, or other templates work. Compare an uncached request when authorized. “White screen” is a visual symptom; the server and logs may report something more specific.
Collect evidence before changing files
- Application, PHP, web-server, host, and security logs near the event
- Recent core, plugin, theme, PHP, deployment, and configuration changes
- Disk, memory, process, database, and file-permission health
- Affected and unaffected routes, roles, and cache states
- Known-good backup or release and exact rollback unit
- Maintenance files, failed jobs, and incomplete update indicators
Use the symptom to choose the next layer
| Observation | Likely layer | Next safe check |
|---|---|---|
| HTTP 500 and fatal log | PHP or code execution | Trace message and changed component |
| HTTP 200 with empty body | Template, output, cache | Compare theme and generated response |
| Only one route or role | Template, data, permission | Reproduce in staging with same state |
Isolate the failure reversibly
- Capture logs and response evidence.
- Check platform health and storage.
- Revert the last controlled change when evidence supports it.
- Use staging or host-supported methods to isolate a component.
- Retest the exact route and related workflows.
- Remove temporary debugging and document the root cause.
Avoid destructive guessing
- Renaming all plugins without recording state
- Turning on public error display that exposes paths or secrets
- Editing production code through an untrusted snippet
- Restoring an old database over newer orders or content
Close the incident with prevention
Record the initiating change, error, affected scope, diagnostic evidence, repair, data impact, validation, temporary access used, and prevention action. Add a staging test, compatibility check, resource alert, or rollback improvement that would detect the same class earlier.
Continue with the next decision
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- WordPress debugging documentation Official guidance for WordPress debug configuration, logs, scripts, queries, and safe troubleshooting.