A WordPress white screen needs its failing layer identified before a repair is chosen. An empty response can involve PHP or an early exit; a page with HTML may instead be hidden by front-end code. We assess the affected URL, visitor condition and recent changes, then scope the correction and the checks needed to accept it.
Step 1 — Map where the blank appears
Record the affected URL and compare the homepage, a post and the administrator under the relevant visitor condition. Note whether the response is empty, contains HTML or redirects. These observations narrow the investigation; they do not by themselves prove that a particular plugin or theme caused it.
Step 2 — Turn on logging, not on-screen errors
Correlate the request time with existing server and PHP logs first. If additional logging is necessary, agree a controlled collection, keep errors off public screens and protect the log. Temporary debugging belongs in staging where possible; retain the previous configuration so it can be restored after diagnosis.
Step 3 — The plugins-folder test
If the evidence identifies a plugin, isolate that component with a recovery route. When the cause is unknown, broader isolation needs a staging copy or an agreed interruption, the active-plugin list and a restoration plan. Must-use plugins load separately. A page returning after a change is a useful clue, not the final explanation.
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
Before a theme test, confirm that a compatible fallback is installed and preserve the current configuration. Prefer a controlled copy for isolation. If changing the theme affects the symptom, inspect the relevant template or custom code before deciding the permanent correction.
Step 5 — Memory and a partial deployment
For memory exhaustion, identify the failing request and consumer before considering a different limit. For an interrupted deployment, compare trusted component files and preserve site data before replacing anything. Raising a ceiling or replacing files without matching evidence can leave the original fault unresolved.
Preserve first
Preserve the current state and a way back before editing. After diagnosis, restore temporary logging settings and confirm that collected logs are not publicly accessible. The official WordPress debugging guidance explains the relevant controls.
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.
What a white-screen repair should hand back
The initial brief needs the failing URL, when it started, recent changes, whether the administrator opens and the business route affected. A shop, booking flow or enquiry page needs its own acceptance check; a working homepage alone does not settle the incident.
Ask the proposal to separate diagnosis, correction and verification. The close-out should identify the cause supported by evidence, the change made, the conditions tested and any route still unverified. Response time and scope must be agreed for the actual case.
For the diagnostic detail, use our WordPress blank-page diagnostic guide. To request a WordPress white-screen repair assessment, send the public URL and the observations you already have. Keep passwords out of the request.
EVIDENCE-LED WORDPRESS RECOVERY
Turn a blank screen into an evidence-led diagnosis
In urgent website repair and WordPress recovery, the visible symptom may be far from the cause. The objective is to restore the affected journey without gambling with the rest of the site. 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.