WordPress white screen: diagnose and restore access
- Word press
- September 2, 2025
Table of contents
A WordPress white screen is a symptom, not a diagnosis. It means the browser is not displaying the expected content. Before reinstalling anything, establish whether the request returns a server error, an empty response or a page whose content is present but hidden.
The useful sequence is to establish the scope, find the error associated with the request and recover access through a targeted change. A blank page alone does not justify database repairs or a higher memory limit.
Establish which parts of the site are blank
Open the homepage, an internal page and the administrator login address. Repeat the checks in a logged-out session. Record differences by user, page and device, and whether the problem followed an update, code change or hosting intervention.
| Observation | Initial investigation |
|---|---|
| Public pages and administrator access both fail | PHP logs, web service and globally loaded components |
| Dashboard works but public pages are blank | Theme, templates and frontend code paths |
| Only one page is blank | That page’s content, blocks or specific feature |
| Failure affects only some users | Cache, session and role-dependent behaviour |
| Expected HTML exists but is invisible | Browser-side CSS and JavaScript |
Use these findings to choose a test, rather than treating them as confirmed causes. A redirect loop or rejected password belongs to a different diagnostic path from an empty document response.
Inspect the HTTP response before changing WordPress
Open the browser’s Network panel, reload the page and select the main document request. Record its status and response body. A 500 calls for server-side investigation; a 200 with an empty body does not establish that the application completed successfully.
If the expected content is present in the HTML, inspect the elements and JavaScript errors. If a cache supplied the response, compare it with a controlled request to the application using the host’s tools. Adding an arbitrary query parameter is not proof that every cache has been bypassed.
For example, a CSS rule hiding the main container can make the page look empty without any PHP failure. Conversely, a cached homepage may remain visible while uncached requests fail. Separate these situations before deciding what to change.
Find the log entry for the failed request
Start with the PHP logs available through the hosting panel. Reproduce the problem once, note the time and locate the matching error. Check the log’s timezone before correlating events with browser observations.
WordPress debugging may help when additional evidence is needed. It requires authorised file access and care with existing configuration. The official debugging documentation distinguishes enabling debug mode, recording errors and displaying them. Prefer staging; keep technical error details out of public responses and protect log files.
An empty WordPress log is not proof that no error occurred. Confirm that logging can write to its destination and investigate whether the failure happens before WordPress loads. Once you have a message, use the PHP error and memory diagnosis guide to interpret it.
Recover administrator access when a plugin fails
Check for an administrative email with recovery-mode instructions. Delivery is not guaranteed: it depends on the error and the mail system. Do not share recovery links publicly.
If the evidence identifies an ordinary plugin and the dashboard cannot load, preserve backups and logs before temporarily renaming that specific plugin directory through SFTP or the host’s file manager. Record its original name and establish which dependent functions will stop working.
This prevents ordinary loading; it is not an uninstall procedure. It does not automatically cover must-use plugins, drop-ins or Multisite arrangements. If the theme is involved, avoid renaming directories without a fallback plan. Prepare a compatible alternative theme and establish how it should be activated.
The goal is a controlled recovery step whose consequences are understood. A site that loads after an entire set of components is removed still needs a more focused diagnosis.
Treat restored visibility as evidence
If disabling the suspected component restores the page, reproduce the failure on staging and identify the specific condition. The missing component may provide a necessary booking form, search feature or private area.
In a hypothetical example, disabling a search plugin makes the website visible again, but search itself is absent. That establishes that its execution path participates in the failure. The plugin, dependency or affected data still needs attention before the feature can be restored.
If the incident followed an incomplete update, inspect file consistency using the failed WordPress update guide. When the available evidence is inconclusive, preserve the state and involve the host before replacing broad sections of the installation.
Confirm recovery beyond the homepage
Repeat the original request and inspect the HTTP status, content and new log entries. Test login, saving content, forms and affected functions as both a visitor and administrator. Include pages that are not served from cache.
Return debugging settings to their appropriate production state and handle collected logs so that they are not publicly accessible. Record the confirmed cause and any functions still suspended.
If a WordPress white screen prevents access, I can review the site’s responses and error logs to identify a targeted recovery step and verify its effect on the functions you need.
