A blank page is a symptom, not a diagnosis. It can come from PHP failure, a rendering problem, a cached response or other causes. Start by finding which part of the site is affected.
Check public pages and admin separately
Open the homepage, a known post and wp-admin in a private browser window. Note which requests fail and whether a message appears. Check the hosting status panel and any recent update notification.
Record the last known working time and changes since then. If a critical-error email provides a recovery link, use it only when it is an expected message for your site. Never publish the link or send it to an untrusted party.
Keep hosting access available and preserve a backup of the current state where practical. Do not replace the database to diagnose a single blank page.
Reverse the smallest identified change
If admin works, investigate a recently changed plugin or theme through staging or a scoped troubleshooting session. Reproduce the same URL or action after each change.
If admin is unavailable, ask the host to inspect the PHP error log and temporarily disable the specifically identified component through its supported recovery process. A reversible folder rename can disable a plugin, but the exact path and restoration need to be understood. Beginners should ask the host rather than rename every folder.
Keep a note of original names and active components. Disabling a plugin that handles forms or checkout can change public behavior even when the page begins loading again.
Read evidence from protected logs
The host can often identify a fatal error and the responsible file without exposing diagnostics publicly. Give it the URL and timestamp. A memory-limit message and a missing-function message need different remedies.
For developers, WordPress documents WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY. Use protected logging on staging; avoid displaying errors to visitors or leaving a publicly downloadable log containing paths and personal data. Follow the debugging documentation rather than adding conflicting definitions to wp-config.php.
Increasing a limit is appropriate only when the evidence supports it and the host permits it. It is not a universal cure for a blank page.
Restore only when necessary
If recovery requires a backup, choose a known-good point and account for newer posts, orders and submissions. Restoring files alone and restoring the database are different operations; the host should explain which is required.
Reinstalling core or replacing files needs a verified package and a controlled procedure. Do not delete wp-content, uploads or wp-config.php as a speculative fix.
After recovery, test public pages, admin and critical flows. Update or replace the faulty component through a supported path, then repeat the original failing action. Preserve the error details so a recurring issue can be traced.
Sources & verification
Sources checked September 28, 2026. Documented behavior is distinct from hands-on testing.