A completely blank page — the “white screen of death” — means PHP failed and error output is switched off, so the browser receives nothing. The error still exists in a log. This is the sequence to find it without exposing anything to visitors.
Step 1 — Map where the blank appears
Load three things: the front page, a single post, and /wp-admin/. The pattern tells you a lot. A blank front end with a working admin points at the theme or a front-end plugin. Everything blank, including admin, points at a global fault — memory, a must-use plugin, PHP or a corrupted core file.
Step 2 — Turn on logging, not on-screen errors
Add to wp-config.php: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);. Reload the blank page, then read /wp-content/debug.log or the server’s PHP error log. You are looking for the last fatal error or an “Allowed memory size exhausted” line. Displaying errors publicly would expose file paths, so keep display off.
Step 3 — The plugins-folder test
Over SFTP or the hosting file manager, rename /wp-content/plugins to plugins_off and reload. If the page returns, a plugin is responsible: rename the folder back and re-enable plugins one at a time until the blank screen reappears. That identifies the exact plugin instead of just clearing the symptom.
Is your website affected right now?
Send the URL and the symptom you can see. Jordi Ensenyat reviews the case personally and defines the scope and quote before anything is changed. This form never asks for passwords.
Step 4 — Default theme test
If plugins are clear, rename the active theme’s folder in /wp-content/themes so WordPress falls back to a default theme. A blank screen that clears here is a theme problem — often a recent edit to functions.php or a template that calls a function removed in a newer PHP version.
Step 5 — Memory and a partial deployment
If the log points at memory, raise it with define('WP_MEMORY_LIMIT', '256M'); and confirm the host allows it. A blank screen that started right after an upload or migration can also mean incomplete files — compare file counts, or reinstall WordPress core over itself (it overwrites core files without touching your content) once a backup exists.
Preserve first
Back up the current state before editing. Keep every change reversible, and undo the debug constants when you finish so a log file does not sit exposed on a public site.
When to escalate
Call a specialist if the admin is also blank and there is no backup, if the site is a store, or if the blank screen appears alongside redirects or unfamiliar files. Sending the URL, what changed just before, and whether the admin loads is enough to assess it without any credentials.
EVIDENCE-LED WORDPRESS RECOVERY
Turn a blank screen into an evidence-led diagnosis
In WordPress malware cleanup and reinfection prevention, the visible symptom may be far from the cause. The objective is to remove malicious persistence, close evidenced entry points and verify the behaviour that triggered the alert. A completely white page often means that error output is hidden while PHP execution has failed. Publicly enabling debug messages can expose paths and sensitive details, so evidence should be captured privately through logs or a controlled environment.
What we verify
- The complete journey, not only the screen where the error appears
- External dependencies, logs and evidence before configuration changes
- PHP and WordPress logs for fatal errors or memory exhaustion
- Whether the blank screen affects every route, admin or one action
- Theme, plugin, cache and deployment changes near the failure
- The original route plus representative pages after recovery
What a verified outcome means
Close-out documents the cause found, the change applied and the tests performed. The result must be observable and repeatable—not a feeling that it “seems to work”.
BEFORE THE ASSESSMENT
Common questions about this WordPress incident
How do you verify that the problem is genuinely resolved?+
The affected journey is reproduced, its dependencies are checked and post-change evidence is recorded.
Is the WordPress white screen the same as a critical error?+
They can share a PHP cause, but the visible behaviour differs. Logs are needed to determine whether the failure is memory, code, cache or deployment related.
Should I enable WP_DEBUG on the live website?+
Debug logging can help, but displaying errors publicly is unsafe. Diagnostic output should be written to a protected log and disabled after use.
Can clearing the cache solve a white screen?+
Sometimes cache is involved, but clearing it without evidence can erase useful signals. The failing layer should be identified first.