A blank WordPress page is frustrating because it offers almost no clues. There may be no error message, no menu, and no obvious way to reach the dashboard. This is often called the WordPress white screen of death.
The phrase describes what you see, rather than a single fault. A blank response can come from failed PHP code, while an apparently blank page can also result from a display or loading problem. The right fix starts by telling those situations apart.
1. Confirm what “blank” means
Check the affected page in a private browser window. Try another device if one is available. Note whether the page is completely empty or whether a header, loading icon, or footer still appears.
Then open the homepage, another page, and the dashboard. Record which ones load. A blank product page with a working homepage gives you a narrower investigation than a completely unavailable website.
If you see an explicit critical error message, use my critical error recovery guide. If the browser reports that it cannot find the server, investigate hosting or domain access before changing plugins.
2. Preserve evidence before clearing everything
Write down the URL, time, and action that produced the blank page. Take a screenshot if the problem appears only sometimes. Include whether you were signed in.
For a form problem, record the steps without including private submitted details. For an editor problem, note which page or template you opened. These small details can save a long troubleshooting session.
Avoid changing multiple settings just to see what happens. If several changes are made at once, even a successful result may leave you unsure which change fixed it or what else was affected.
3. Create a backup through your host
You do not need a working WordPress dashboard to ask your host for a backup. Preserve the current files and database before deactivating components or restoring an older version.
Review recent restore points and what they contain. Some backups include both files and data; others cover only one part. Confirm the scope before relying on a restore.
For stores and membership sites, note any orders or signups since the last good backup. Recovery should protect those records. A clean-looking homepage is not a useful result if recent business data disappeared during the repair.
4. Determine whether the server returned an error
Ask your host or developer to inspect the response and PHP logs for a failing URL at the time you tested it. This helps distinguish failed execution from a page whose content is hidden or unfinished.
If the server reports a fatal error, follow the named file and error rather than guessing. If it returns page content successfully, investigate the page’s layout, browser errors, and loaded assets.
This distinction matters. A missing stylesheet, a faulty loading overlay, and exhausted PHP memory can all look like a blank page to a visitor, but they require different repairs.
5. Start with the most recent relevant change
Think back to the last working visit. Did you update a plugin, edit a template, change PHP, enable optimization, or add a snippet?
A targeted test is more useful than disabling everything immediately. If a new optimization setting coincided with the problem, reverse that setting first and repeat the same page request.
Keep a small change log during troubleshooting. Include the original setting, the new setting, and the result. If the test fails, restore the original state before moving to an unrelated possibility.
6. Test plugins on a staging copy
If a plugin is suspected, reproduce the issue on staging with a current copy of the website. Check whether the problem occurs with the plugin disabled and whether it returns when the plugin is active.
Some plugins require others to function. Preserve those dependencies during testing and record the setup. A failure caused by removing a required dependency does not prove that the original fault has been found.
On a live store, disabling checkout, shipping, or subscription components can interrupt customer activity. Use targeted recovery only when necessary, and plan a safe window for broader tests.
7. Check the theme and affected template
A blank page limited to one layout may involve its template, builder, or custom fields. Compare it with a working page that uses a different template.
On staging, test a default WordPress theme to help isolate theme-related code. Take care with sites that depend on theme-specific features; the test is for diagnosis, not a finished replacement design.
If a template was recently edited, compare it with the previous working version. Ask a developer to inspect the change. Deleting a template or reinstalling the whole theme can remove useful evidence and custom work.
8. Treat memory errors as evidence
If the log specifically reports exhausted memory, ask what task used it. A large import, expensive page builder operation, or faulty integration may need a different response from a simple hosting limit.
Your host can confirm the effective PHP memory limit and available resources. A developer can decide whether a temporary increase is appropriate and whether the workload needs repair.
Avoid raising limits repeatedly without checking the result. More memory might allow a request to finish, but the underlying inefficient or failing process could remain. Record whether the same task succeeds after the change.
9. Clear the relevant cache after the repair
Once a likely cause has been corrected, clear the affected page cache and any relevant CDN cache. Then test in a fresh browser session.
Do not assume every visitor sees the same version you see while logged in. Public page caching can make a successful administrator test misleading.
Repeat the check on the exact URL and action you recorded earlier. If the blank page returns only under certain conditions, capture those conditions rather than calling the problem resolved after one successful visit.
Check the important journeys
Test your main navigation, forms, login, and key business pages. If the issue affected an online store, use an appropriate test checkout without creating unintended customer charges.
Review both desktop and mobile views. Confirm that the repaired page contains the expected content and that links and buttons work. A white screen can disappear while a hidden layout or scripting problem remains.
Finally, disable temporary public debugging and have unnecessary logs removed or protected. Keep the useful incident notes so another person can understand the repair later.
Get help with a persistent blank page
Send a developer the affected URL, last known working time, recent changes, and a private error excerpt where available. That gives them something concrete to reproduce.
My website maintenance and fixes service covers WordPress troubleshooting and follow-up testing. You can also use the monthly maintenance checklist to make future changes easier to trace.
See the official WordPress troubleshooting guidance for additional recovery options.
