A WordPress white screen of death is a blank page where the site, dashboard, or a particular feature should appear. The blank screen is a symptom. It can result from a server-side failure, empty output, a browser script problem, hidden content, or a cached response.
To fix it, first determine what the browser actually received. Record the affected request, inspect its status and content, and compare the result with the matching server or browser error. Then isolate the responsible component on a protected copy, apply a supported correction, and verify the original task in a normal visitor session.
This approach avoids treating every blank page as a reason to disable all plugins, increase memory, or restore an old database. Those actions can be useful in the right circumstances, but they should follow evidence.
First define what is blank
Start with the exact URL and action. Is the entire public website blank, only the homepage, the dashboard, the block editor, or a popup inside an otherwise working page? Does the page become blank immediately, or after you click something?
Record whether the browser displays a white canvas, an error page, a loading indicator, or a page with navigation but no main content. These observations lead to different tests. A missing template section is not the same condition as an empty server response.
Try a normal visitor session and an authenticated session if access remains available. Record the differences instead of assuming one is authoritative. Administrators may bypass cache and see scripts or permissions that visitors do not.
Check another browser or device to establish scope, but do not treat one successful comparison as a fix. A browser extension, cached asset, or session condition may explain the difference. Preserve the failing conditions long enough to investigate them.
Capture a useful incident note
Include the first observed time with time zone, affected URL, user role, browser, recent changes, and what should have appeared. Add whether other pages work and whether the dashboard can save a draft.
If an error appears briefly before the page turns blank, capture it safely. Remove private account details and tokens from screenshots. Keep one controlled example that another authorized person can reproduce.
A good note might describe “the editor opens for new posts but turns blank when opening the services page containing the booking block.” That is much more useful than “WordPress is down,” because it identifies a repeatable feature and a comparison.
Understand the main categories of blank-page failure
| Evidence | Possible category | Productive next step |
|---|---|---|
| Empty or truncated response with a server error | PHP, server, or upstream failure | Match request time to protected server logs |
| HTML exists but visible content is missing | Theme, template, CSS, or script behavior | Inspect page structure and browser errors |
| Editor fails while public pages work | Editor assets, REST requests, permissions, or block code | Inspect the failing editor request |
| Only cached visitors see a blank page | Stored response or generated asset issue | Compare origin and cache through supported controls |
| One browser fails | Local cache, extension, or session condition | Compare a clean browser context |
| Error follows a code edit | Syntax or runtime issue | Review the exact change and matching error |
These categories overlap. A JavaScript failure may follow an unsuccessful server request. A cache can preserve a response generated during a PHP failure. Work from the actual response toward the cause.
Preserve the site before changing components
Confirm a current backup of files and database and preserve the present state if recent business data matters. The WordPress file-backup documentation explains the application-file side of recovery; database records require their own coverage.
Do not restore yesterday’s database merely because today’s page is blank. A plugin file or template error may be repairable without replacing new orders, leads, and accounts.
Record the installed versions and the last changes. Include automatic updates, host runtime changes, optimization settings, theme edits, and external integrations. A blank page can begin without anyone manually editing WordPress that day.
Use staging for broad isolation and code changes. Protect the copy from public access and prevent it from sending customer messages or making production transactions. A copied application can inherit working credentials and scheduled actions.
Inspect the response before guessing at the cause
The browser’s network panel shows requests and responses. Open it before reproducing the failure, then identify the main document request or the feature request associated with the blank area.
Record the request URL, response status, time, and whether a response body arrived. The WordPress browser-debugging guide explains access to browser diagnostic tools.
A status code is evidence, not a complete diagnosis. A 500 response suggests the server could not complete the request normally. A 502 or 504 may involve an upstream service or timeout. A 200 response can still contain empty or incorrect content.
Google’s HTTP and network error reference describes response categories from a crawler perspective. For troubleshooting, connect the observed status with the host’s actual request logs rather than using the code alone to identify a plugin.
Is the HTML empty or merely invisible?
If the response contains substantial page markup, inspect whether the expected content exists in the document. A CSS rule can hide an element, a template can omit the content region, or a script can replace it with an empty state.
Avoid editing random CSS to make something appear before understanding the page structure. A hidden element may be an intentional access-control presentation, a loading state, or a component waiting for data. Making it visible does not necessarily restore its function or permissions.
If the HTML is empty or ends abruptly, compare the server logs at that time. A fatal error can stop output before a full page is produced. The server may suppress the visible error, which is appropriate for visitors but means you need protected diagnostics.
Distinguish the main document from background requests
Modern WordPress interfaces often load a page shell and then request data through REST or AJAX. The main document may return successfully while a background request fails.
Click the failing request and inspect a sanitized response. A login page returned where JSON was expected can point toward authentication or redirect behavior. A permission response needs a different investigation from a PHP error. A blocked request may involve a firewall rule or browser policy.
Keep sensitive request data private. Network exports can contain cookies, authorization headers, form fields, and personal details. Share the minimum evidence needed through an approved support channel.
Match server errors to the actual failed request
Ask the host for the PHP or application error associated with the URL and timestamp. Include the time zone and environment. An unrelated warning from another hour is not evidence for the blank page you are investigating.
The WordPress debugging handbook describes debugging controls. Prefer a protected staging environment and private logs. Do not display stack traces or configuration details to public visitors.
A blank WordPress debug log does not prove there was no failure. The request may fail before WordPress initializes, logging may point elsewhere, or the relevant error may be in web-server or PHP process logs.
A file named in a stack trace is an investigative lead. It may be the component that failed, a caller, or the place where another component’s invalid data surfaced. Compare it with the recent change and a controlled reproduction.
Read the error category
A syntax error after a file edit suggests reviewing that exact edit. An undefined function can indicate a missing dependency, wrong load order, or incompatible version. A memory-exhaustion message calls for examining the request’s workload and limits. A permission error points toward access or ownership.
Do not combine those categories into one universal “increase memory” fix. The smallest useful correction depends on what failed. Preserve the error message and avoid adding unrelated changes during the comparison.
If a host provides a request identifier, keep it in the incident note. It can help correlate a browser request with application and infrastructure logs without retaining sensitive payloads.
Follow the path that matches your affected area
The public site is blank but the dashboard works
Start with the affected public URL, theme template, recent design changes, cache behavior, and relevant front-end scripts. Test another representative public page and compare logged-in and logged-out responses.
If only one template is affected, inspect the content and blocks used by that template. A page builder or custom block may load code that other pages never execute. Removing every plugin can erase that context and make the comparison less useful.
On staging, test a suitable unmodified theme or a supported template fallback. Record what changes. If content appears under another theme, investigate the active theme integration without assuming the entire database is damaged.
Check whether an optimization feature changed script or stylesheet delivery. Compare the feature separately rather than permanently disabling all performance controls without identifying the interaction.
wp-admin is blank but public pages appear normal
Public pages may be cached. Test an uncached dynamic request before concluding that the application’s public side is healthy.
Identify the exact administrative screen. A blank plugin settings page, an empty editor, and a dashboard that never loads can involve different code. Record whether login succeeds and whether a simpler admin page remains usable.
A legitimate WordPress Recovery Mode email can help when a fatal error is detected. Treat its link as sensitive access information. A recovery session is a diagnostic route, not proof that ordinary users can now use the site.
If no recovery email arrives, use hosting support and logs. Missing email does not establish that recovery is impossible. The mail subsystem or early failure may prevent the expected message.
The block editor is blank
Open the browser console and network panel while reproducing the editor problem. Check whether the failure occurs for all content or one post with particular blocks.
Compare a new empty draft with the affected content on staging. If only one block triggers the failure, record its plugin and version. Preserve the original content before attempting block removal or conversion.
Inspect failed REST requests and authentication behavior. Do not disable all security controls just because an editor request is blocked. Identify the specific route and use a narrow supported correction after reviewing why it was denied.
A developer may also need to inspect custom editor scripts, theme editor support, and the component’s compatibility requirements. An editor-only failure can have a different repair from a public theme failure.
Only one visitor or browser sees the problem
Compare a clean browser context, then investigate local cache, extensions, cookies, and network conditions. A clean comparison is a diagnostic step, not a reason to tell every customer to clear everything indefinitely.
If the problem affects a class of users, record the shared condition. Examples include a user role, membership state, language, device width, or consent choice. Those details can reveal a conditional code path that a maintainer’s account never exercises.
Avoid collecting unnecessary personal data to investigate a session issue. A controlled test account with the same relevant role is usually more appropriate than asking a customer to share their password or entire browser profile.
Isolate plugins and themes without losing the test
Use a protected copy and define the smallest setup that still performs the failing action. Keep required dependencies active. A test that removes the feature entirely cannot establish that the feature is repaired.
Record the starting theme, child theme, ordinary plugins, custom snippets, and host-managed components. Then change one relevant variable and repeat the same action with the same inputs.
If a minimum configuration works, add components back systematically. Confirm the suspected interaction by removing and restoring it. For intermittent failures, repeat attempts and compare timestamps instead of accepting one lucky success.
The WooCommerce conflict-testing guide describes staged isolation and additional layers such as must-use plugins and drop-ins. Those layers can remain active when ordinary plugins are disabled, so record what your test actually excluded.
Include custom code and dependency order
A child theme’s functions, a snippet manager, and a custom integration can execute on every request or only on selected screens. Add them to the test inventory rather than treating the ordinary Plugins screen as a complete list of application behavior.
A dependent extension may fail when its base component is absent. Preserve the dependency order during testing and read the vendor’s requirements. An undefined function after disabling a dependency is not necessarily evidence of the original incident.
Do not delete custom code to see whether something changes. Preserve the exact file and use a reviewed reversible change on staging. If the code controls access, pricing, or order processing, understand those responsibilities before disabling it live.
Avoid a misleading theme comparison
Switching to a default theme can identify a theme-related path, but it can also remove the templates and features required to reproduce the issue. If the affected page depends on a commercial theme’s builder, explain that limitation in the test record.
Compare the parent theme and child theme where appropriate. Custom templates and functions in the child theme can differ from the vendor’s supported package. Preserve customization before replacing or updating files.
Once a theme-related cause is narrowed, test a supported update or correction. A permanent switch to a different theme is a redesign and migration decision, not merely a diagnostic toggle.
Review recent PHP and hosting changes
A host can change the PHP runtime, extensions, process configuration, or server rules independently of WordPress’s dashboard. Ask about changes near the first failure time.
Use the actual web runtime, not only the version reported by a command-line shell. Different execution contexts can use different PHP versions and settings. A command that works over SSH does not prove that the browser request has the same environment.
Check the component’s requirements and the PHP supported-versions page before choosing a runtime change. Avoid freezing an obsolete version indefinitely as a workaround. A temporary compatibility rollback needs an owner and a plan for the supported combination.
If a required extension is missing, have the host enable the appropriate supported module rather than downloading arbitrary binaries. Retest the original request and review the error log after the environment correction.
Handle memory errors specifically
A memory-exhaustion error identifies a request that exceeded its available memory; it does not explain why the request used that memory. A large import, runaway loop, expensive query result, or incompatible component can require different corrections.
Ask the host which limit applied and whether the plan can support a reviewed change. WordPress constants do not override every server-level restriction. The configuration reference explains relevant settings and warns that increasing memory can conceal underlying problems.
On staging, compare the workload and affected components. If the failure occurs only with one unusually large document or import batch, test the supported batch or content approach. Do not simply copy an enormous memory value into every site.
Record the final limit and rationale if a capacity change is appropriate. Verify that the request completes and that concurrent customer requests remain healthy. Making one job succeed by exhausting the rest of the account is not a useful overall result.
Check caches and generated assets deliberately
A cache may preserve an empty response after the original failure has ended. Generated CSS or JavaScript can also remain inconsistent with the installed plugin version.
Identify browser, WordPress, hosting, CDN, and object-cache layers separately. Use supported controls to regenerate assets or invalidate the relevant response. A private browser window does not bypass every server-side cache.
Compare the origin through the host’s approved method, then the public cached URL. If the origin is healthy and the cached response is blank, correct the cache rule or stale object rather than restoring the database.
If disabling an optimization component resolves the issue, isolate its specific feature on staging. Script delay, combination, unused-CSS generation, and page caching affect different parts of the request. A specific supported exception is easier to maintain than permanently turning off every feature.
Do not manually remove arbitrary cache directories or host-managed drop-ins. Ownership, rebuild behavior, and shared services differ. The must-use plugin documentation helps explain why some host components are not controlled like ordinary plugins.
Recover after an interrupted update or code edit
If the blank page appeared immediately after an edit, preserve the current file and compare the exact change. A syntax correction or targeted reversal may recover the application without affecting stored business records.
For an interrupted update, confirm whether files are incomplete and whether database migrations ran. Follow the vendor’s supported reinstall or recovery procedure using legitimate packages. Do not combine files from several versions and assume the result represents a valid release.
The official WordPress upgrade guide describes core-update procedures. It does not authorize replacing site-specific configuration or uploads with generic package contents.
An experienced administrator can use core checksum verification for supported core files. Its scope does not include every plugin, theme, upload, or database record. Interpret differences before choosing replacement.
If dashboard access is unavailable
Use legitimate recovery access or hosting support. If evidence points to one ordinary plugin, an authorized administrator may isolate it through a reversible folder change after preserving the installation and understanding the business impact.
Avoid renaming the entire plugins directory on an active store as the first generic step. Payment, shipping, access, and security features can disappear together. Coordinate any broad live isolation and record the original activation state.
Restoring a directory name does not guarantee the component is active again. After access returns, compare the intended plugin state, dependencies, and settings. Verify the original task in a normal session rather than stopping at a successful login.
Decide whether a restore is the right scope
A restore can be appropriate when files or data are damaged beyond a narrower supported repair. Choose the recovery point and scope deliberately: files, database, or a coordinated full site.
A file-only restore can preserve newer database records, but the restored code must be compatible with the current schema. A database restore can remove changes after the recovery point. Neither is a universal answer to a white screen.
For a store, preserve current records and compare external payments and fulfillment activity. WooCommerce’s subscription restore documentation explains why previously processed scheduled actions can become dangerous after rollback.
If compromise is suspected, restoration also requires investigation of the entry point and persistence. A site that loads from an old backup is not automatically clean. Preserve evidence and review access before reopening sensitive functions.
Verify recovery through the original user journey
Start with the precise action that produced the blank page. Use the same relevant role, content, inputs, and browser conditions. Then check a few neighboring functions that the repair could affect.
For an editor failure, open the affected content, make a controlled change on staging, save it, and inspect the public rendering. A working editor shell does not prove that the content can be saved correctly.
For a service site, test the contact or booking journey and confirm the receiving system. For a store, check product selection, cart updates, the relevant checkout path, order state, and notifications through controlled test facilities.
Use an ordinary visitor session after any troubleshooting mode ends. Check both current origin output and the intended cached experience. Review the matching logs, remove temporary debug settings, and identify any delayed task still awaiting observation.
Check access boundaries after a visibility fix
If the repair changed theme output, CSS, membership code, or security rules, test a user who should be allowed and one who should be denied. Visible content is not the only acceptance condition.
A broad rule that makes an editor work may also expose an endpoint more widely than intended. A template change that restores a page may accidentally display protected information. Review the actual responsibility of the changed component.
Do not use real customer accounts for convenience when controlled test accounts can represent the needed roles. Remove temporary accounts and private diagnostic exports after review.
Prepare an evidence-based support handoff
A useful support report includes the affected URL and action, expected output, observed response status, browser error if relevant, matching server error, and exact versions. State whether each observation came from production or staging.
Add the minimum reproduction sequence and the comparisons already performed. If another theme or a reduced plugin set changes the result, describe the actual configuration and any limitations. Do not simply write “all plugins checked” when host-managed code remained active.
Keep a short timeline of actions and outcomes. Multiple contractors making overlapping changes can erase the evidence. One coordinator should maintain the record and identify who owns the next test.
Share logs through the appropriate private channel. Remove passwords, tokens, personal data, and unrelated requests. A short relevant extract is usually more useful than a large unfiltered archive.
Illustrative diagnosis examples
The following scenarios are fictional teaching examples. They do not represent performed tests or customer results.
A template hides the main content
The homepage returns substantial HTML with a successful status, while the visible content area is blank. The administrator compares another template and inspects the document structure on staging.
The investigation focuses on a recent template customization rather than database restoration. After a reviewed correction, acceptance includes the affected page, mobile layout, navigation, and any conditional content. The diagnosis follows the received markup instead of the screen color alone.
The editor shell loads but a request fails
A post editor opens with an empty working area. The network panel shows that a required request does not return the expected data. A controlled comparison identifies a security rule affecting the route.
The responsible administrator reviews the rule and makes a narrow supported change. The team verifies editor loading, saving, public rendering, and permission boundaries. It does not permanently disable the entire security layer to remove one symptom.
A code edit prevents output
The site turns blank immediately after a custom file change. A matching server error identifies a syntax problem. The administrator preserves the file and reverses the exact edit through authorized access.
After recovery, the intended change is developed and checked on staging. The incident leads to a safer editing process rather than a permanent refusal to update the website. No database rollback is required for a file-level syntax correction.
Use a compact comparison record instead of repeated guesses
Give each attempt a name and record the relevant conditions. The record does not need to be elaborate, but it should make the comparison intelligible to someone who was not present.
| Field | What to record |
|---|---|
| Request | URL or administrative action, with private tokens removed |
| Session | Visitor, administrator, or controlled test role |
| Environment | Production, staging, or local copy |
| Response | Status, approximate content behavior, and relevant request identifier |
| Change | One component, setting, or code revision |
| Result | Whether the original task completed |
| Limitation | External service blocked, cache difference, or untested delayed action |
Use actual observations in the rows you create. Do not fill a report with assumed successes because an automated tool returned a green indicator. A response monitor and a customer journey answer different questions.
Compare representative content deliberately
When only one page fails, create a safe comparison on staging. Start with a copy of the affected content and preserve the original. Remove or substitute one relevant block or data element at a time while keeping the rest of the layout unchanged.
This can help distinguish a template-wide issue from a particular component or input. A page containing a large embedded document, an unusual shortcode, or an external data block may exercise code that other pages do not. The comparison should preserve the feature long enough to identify what changes the result.
Do not save experimental content changes over a live sales page merely to see whether the screen returns. Work on a protected copy or a clearly controlled draft. Keep a record of which content revision the final repair was tested against so an older staging page does not accidentally replace newer copy.
If the page depends on a third-party embed, check the external service separately through its official status or documentation. A blocked or unavailable embed should not automatically be diagnosed as damaged WordPress data. Record whether the rest of the page can render independently and whether the integration handles failure gracefully.
Check response content without exposing it
Support may ask whether the response is empty, HTML, JSON, or a login redirect. You can often answer that category without sharing the entire body. A small sanitized excerpt or a description of the content type may be enough.
If private content appears in a response unexpectedly, treat that as part of the incident. Stop posting screenshots publicly and involve the responsible administrator. Troubleshooting should not make sensitive information more widely available than the original application intended.
A useful diagnostic record retains the evidence necessary to explain the failure and removes unnecessary payloads afterward. Avoid keeping complete customer requests indefinitely in a shared troubleshooting folder.
Separate immediate recovery from the permanent correction
A targeted rollback or temporary exclusion may restore access while the vendor investigates. Record that state explicitly. Include the temporary measure, its business effect, the responsible person, and the condition for replacing it.
For example, disabling one visual feature can be an acceptable short-term choice if the essential customer journey remains available. Disabling an access-control component has a different consequence and requires a different recovery decision. The decision should follow the component’s responsibility, not how easy its toggle is to reach.
When the permanent correction is available, repeat the original reproduction on staging before removing the workaround. Then deploy the supported change and run the normal production acceptance checks. A vendor release note is useful context, but the site’s own combination still needs verification.
Keep the incident’s minimal reproduction as a regression test description. It does not need to become a large automated test suite to be useful. A maintainer who knows which page, role, and action previously failed can check that path after relevant updates and recognize the symptom early.
Avoid these common shortcuts
Do not increase memory without a matching memory error and workload review. Do not delete every plugin because the screen is empty. Do not paste an entire replacement configuration from a tutorial over the site’s actual settings.
Avoid displaying debug output publicly. It can reveal paths and sensitive application details. Also avoid leaving a diagnostic plugin installed indefinitely when its compatibility and maintenance status have not been reviewed.
Do not assume a cache purge fixed the cause. A fresh response can look healthy until the failing request runs again. Identify whether the cache stored a transient failure or whether an underlying component still generates it.
Finally, do not close the incident after seeing the homepage once. The affected task, permissions, receiving systems, and relevant delayed work should determine the acceptance checks.
Leave the next maintainer a clear starting point
Save the final reproduction steps, repaired component version, and relevant configuration exception with the site record. Include the reason for the change and any vendor reference so another maintainer can distinguish an intentional exception from an accidental setting.
Record which response and workflow were checked after deployment. If the issue was intermittent, identify the next meaningful observation period and who will review it. Keep sensitive request payloads out of this record and retain only the evidence needed to explain the result. This gives the next update cycle a practical regression check and prevents the team from repeating broad isolation simply because the original investigator is unavailable.
Frequently asked questions
Is a white screen always a PHP fatal error?
No. A server-side fatal error is one possibility, but a blank screen can also result from empty output, scripts, styles, templates, or cached content. Inspect the actual response and relevant logs before choosing the repair.
Why does only one page go blank?
That page may use a different template, block, shortcode, data set, or conditional integration. Compare it with a working page and preserve its specific reproduction conditions. A site-wide reset can remove the clue you need.
Should I turn on visible debugging?
Prefer protected logging and staging. Public error output can expose sensitive details and disrupt visitors. Follow the official debugging documentation and remove temporary diagnostics after collecting the matching evidence.
Can a browser extension cause the problem?
Yes, a browser-specific condition can affect rendering or requests. Compare a clean browser context and record the result. If several users share a role or workflow, investigate that shared condition rather than assuming every report is a local browser issue.
What if wp-admin is also blank?
Check for legitimate Recovery Mode access and ask the host for matching server errors. Authorized file access may support a targeted reversible isolation step. Preserve the current site and understand the component’s responsibilities before changing it globally.
Does a successful HTTP status mean the page is healthy?
No. A response can have a successful status while containing empty, incorrect, or unusable content. Validate the actual user task as well as the response status.
Will restoring a backup remove the white screen?
It may, if the recovery set addresses the actual cause and is compatible with the environment. It can also restore the same problem or overwrite newer data. Choose restoration based on evidence, recovery scope, and a plan for recent business activity.
How can I prevent another blank-page incident?
Use protected testing for significant changes, keep recoverable backups, track versions and custom code, and maintain a short acceptance test for critical workflows. Ensure someone monitors errors and can access hosting when the dashboard is unavailable.
Check the final public response again after temporary tools are removed and the intended cache is rebuilt. This last comparison confirms that the observed recovery does not depend on the administrator’s diagnostic session.
Get help when a blank page interrupts business
A blank page becomes easier to diagnose when you preserve the failing request and identify whether the problem is in the server response, browser behavior, or a specific application component.
Web Expert Solutions provides WordPress troubleshooting, critical-error repair, and plugin and theme support. If a blank page affects your dashboard, customer forms, or store, share the affected action, recent changes, and available access so the investigation can focus on a supported repair and verified recovery.
