Opening your site gives you a blank white page, with no useful error message. First check whether the dashboard and other pages still open. That small comparison helps you choose between a page-specific problem and a failure affecting the whole installation.
Work through the matching checks below. Keep a usable backup before changing files, and make one change at a time so you can tell what restored access.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Quick diagnosis
| What still works? | Likely investigation | First action |
|---|---|---|
| Dashboard and other posts | One template, block or shortcode | Compare the affected page with a working page |
| Nothing dynamic opens | Shared PHP failure or server problem | Check recovery email and PHP logs |
| HTML loads, but content stays hidden | Browser styling or script issue | Inspect the document response and console |
| Only a cached homepage opens | Cached page may conceal a PHP failure | Test the dashboard and another dynamic page |
Check more than one page
- Open the affected URL in a private browser window.
- Open another post and
/wp-admin/on the same site. - Write down which pages are blank and the approximate time.
- If you are comfortable using browser tools, open Developer Tools → Network, reload and select the main document. Record its status and whether the response contains HTML.
Example: an empty response with status 500 sends you toward PHP and server logs. A response containing the expected text sends you toward styling or scripts. A 200 status alone does not prove the page is healthy.
Open another public page and the dashboard, then compare the result in a second browser or private window. If one page alone is blank, note its template and any recently added block or shortcode. If every dynamic page is affected, look at shared components and the server logs.
A browser’s Network panel can show the document response and HTTP status. An empty body with a 500 status suggests a server-side failure. A normal HTML response with content that is hidden or never rendered calls for a browser-side inspection instead.
A cached homepage may continue loading during a PHP problem. It is useful to test a page that requires WordPress to run, rather than declaring the whole installation healthy because one cached page opens.
Use the last change as a starting point
Think about what happened immediately before the blank screen: a plugin update, a theme change, a PHP-version switch, or a code edit. Keep the original file or package and the error time before making another change.
If custom code was just saved, restoring the known-good version of that file is often the most direct recovery. A PHP syntax error needs that code examined; clearing caches cannot make invalid PHP valid.
For a recent plugin change, compare on staging where possible. Temporarily pausing a suspected component can help identify the failing path, but it also removes that component’s features. Forms, checkout, and memberships need their own functional checks once access returns.
Check for recovery information
- Check the administrator email inbox and spam folder.
- Confirm the recovery message identifies your domain.
- Open its private recovery link and note the named plugin or theme.
- If access returns in recovery mode, investigate that component; test the public site outside that session after the repair.
WordPress may send the site administrator a recovery-mode email for certain fatal errors. The message can identify the affected component and provide a way into the dashboard. Check the configured administrator inbox and spam folder.
Not every blank page produces that email. WordPress may fail before its recovery handler runs, or delivery may be unavailable. The absence of a message does not establish that the problem is harmless.
If the dashboard is also blank, your hosting panel or SFTP access remains independent of WordPress. A host can inspect the PHP error log and help restore a specific file or component without rebuilding the site.
Get a log entry for the failed request
Useful support request: “The public page and dashboard became blank after [change]. I reproduced it at [time and timezone]. Please check the matching PHP fatal error and whether the request reached WordPress.” Replace the brackets with your observations; send credentials only through your provider’s approved recovery process.
Reproduce the failure once and record the exact time. Match that request with the server’s PHP log. An undefined function, syntax error, missing file, or memory exhaustion gives you a much clearer direction than the blank screen itself.
If temporary WordPress debugging is needed, keep errors out of the public response and protect the resulting log. It can contain server paths and private data. A developer or host can configure logging, collect the relevant entry, and turn off unnecessary diagnostics afterward.
The file named in an error is where the failure was reported, not always where it began. Include the surrounding stack trace when sending a private support request, and describe the action that produced it.
When PHP is not the cause
If the response contains the expected HTML, inspect the page’s visible elements and browser console. A styling change may hide the content, or a script-dependent feature may never finish loading. Compare with the last working template and optimization settings.
Once the actual repair is made, purge any cached blank response for the affected URL and view it as a visitor. Repeatedly clearing every cache before identifying the fault can consume time without changing the failing code.
Confirm the repaired page and its features
Open the original page, the dashboard, and a few representative pages. Test the feature that was changed, then check that no fresh PHP error appears. If restoring a backup was necessary, note whether any recent content still needs to be recovered.
Our critical error guide and memory exhaustion guide cover specific log messages. For the general investigation, see WordPress’s common error reference and plugin and theme troubleshooting lesson.
Before calling it fixed
- The original failing URL opens as a visitor.
- The dashboard opens outside recovery mode.
- The changed feature still works, including any form or checkout.
- The same fatal error does not reappear in the matching log.
For the technical checks, use the official WordPress error guide. If logging is needed, follow the official debugging guidance and keep error details off public pages.