A blank WordPress page is a symptom, not a diagnosis. A fatal PHP error is one possibility, but a proxy, server failure, incompatible update or other rendering problem can look similar. Record what happens before changing files or disabling components.
Key takeaways
- Capture the affected URL, time, device and recent changes.
- Check recovery email and private logs before trying fixes.
- Use staging or an authorised recovery process for changes that affect production.
Check the scope of the failure
Test the public page and, if available, the WordPress dashboard. Check another page, browser and network. Note the HTTP status and whether the failure affects all visitors or only one route. Check the hosting status page and recent deployments.
Look for a WordPress recovery email and review PHP, web-server and application logs around the failure time. Keep debug output private. If enabling WordPress debug logging, follow the official debugging guidance and turn it off after diagnosis.
Isolate likely changes safely
Compare the failure time with core, plugin, theme, PHP, configuration and deployment changes. Reproduce the issue on staging where possible. Test one suspected component at a time and record the result. Avoid renaming folders or switching themes on a live store without a backup, an outage plan and a way to restore the previous state.
If the dashboard and site are both unavailable, ask the host to check server health and access logs. If a recent update is confirmed as the cause, restore or roll back using a tested process, then verify the software compatibility before trying again. A rollback may not undo database changes, so check the vendor’s instructions.
Verify recovery
Test the affected page and nearby functions such as forms, login, checkout and mobile layout. Review logs for new errors and document the root cause, change and recovery point. If the site may have been compromised or data is missing, follow an incident response process rather than treating the screen alone as the problem.
For other WordPress faults, see the five-error troubleshooting guide. If production is down and the recovery path is unclear, use emergency WordPress repair support.
Common questions
Is a plugin conflict always responsible?
No. A plugin may be involved, but logs and a controlled test are needed to establish the cause.
Should I increase PHP memory immediately?
Not without evidence. A resource limit can be involved, but increasing it may only defer another issue or exceed the hosting plan.
Can I fix it by disabling every plugin?
That can disrupt site functions and does not identify the cause by itself. Test safely on staging or follow an approved incident process.