WORDPRESS & PHP TROUBLESHOOTING

How to Fix the WordPress White Screen of Death

The WordPress White Screen of Death (WSOD) is a blank response where website content should appear. It can affect the entire public site, wp-admin, or only individual pages and actions. A PHP fatal error is a common cause, but a white page alone does not identify what failed.

You might see an entirely white page, an inaccessible dashboard, content disappearing after an update, or only certain admin screens failing. Modern WordPress may instead display “There has been a critical error on this website.” Both symptoms call for evidence-led troubleshooting rather than random configuration changes.

Quick answer: find the failing component before changing it

1. Preserve backups and record recent changes.
2. Check whether the frontend, dashboard, or one page fails.
3. Look for a Recovery Mode email and matching PHP/hosting logs.
4. Test the suspected plugin, theme, or configuration with a rollback plan.
5. Retest important features, then restrict temporary diagnostics.

Need Help With Your WordPress Website?

If you prefer professional assistance, Hostingcone offers support for eligible WordPress troubleshooting and website repair issues.

Get WordPress Support

What Causes the WordPress White Screen of Death?

PHP fatal errors, incompatible plugins, theme code errors, custom snippets, and memory exhaustion can stop rendering. PHP version mismatches, failed updates, missing application files, and server configuration problems can produce similar symptoms.

A blank page may return HTTP 500, or it may return another status with little or no content. Cache and proxy layers can obscure the original response. Record the actual failing URL and action; compare a logged-out request with the admin area without assuming a cached homepage proves the application is healthy.

The response by itself does not identify a faulty plugin, lost database, or hosting outage. Match recent changes with current logs and the scope of the failure. A browser rendering or JavaScript problem can also look blank even when the server returned content, so distinguish missing server output from content hidden in the browser.

Before You Troubleshoot

Protect the site and change one thing at a time

Live troubleshooting can temporarily disable forms, checkout, security features, and other functions. Preserve a rollback route and use staging for uncertain tests where practical. Restoring an older backup can overwrite newer content, orders, submissions, or configuration.

1. Back up website files and the database where possible; check existing backups are usable.
2. Record when the failure began and the exact affected request.
3. Identify recent plugin, theme, PHP, WordPress, or custom-code changes.
4. Determine whether the frontend, wp-admin, or both fail.
5. Check the site administration mailbox for a Recovery Mode email.
6. Record original settings, versions, and active components.
7. Use staging where practical.
8. Avoid multiple simultaneous changes.

Use authorized hosting, file, and administration access. If a fresh backup cannot be made, preserve available copies and involve the provider before risky recovery work. Keep credentials and backups outside public download locations. Backups aid recovery but do not guarantee that every recent change can be restored.

Enable WordPress Debug Logging Safely

With authorized file access, locate the wp-config.php used by the affected installation. Preserve its existing configuration. If temporary WordPress logging is appropriate, update existing definitions rather than adding duplicates. These illustrative settings belong before WordPress loads, normally before the configuration-ending “stop editing” comment:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

With the default content directory, WP_DEBUG_LOG set to true may write errors to wp-content/debug.log when WP_DEBUG is enabled and an error occurs. Customized installations can use another path. Match the timestamp and failing action; an old warning is not necessarily the current cause.

The log may not appear if permissions or hosting policy block writes, no relevant error occurs, or the failure happens before WordPress initializes logging. A syntax error in configuration, a PHP startup issue, or a failed service may be recorded only in PHP or hosting-level logs.

Look for recent fatal errors, uncaught exceptions, missing functions/files, and memory exhaustion. Note the component, file, and line, but read surrounding context: a plugin named in a trace may be calling another failing dependency. Avoid editing a random line merely because it appears in the stack trace.

Keep errors and diagnostic logs private

Do not display sensitive PHP errors publicly or paste raw logs and configuration files into public tools. Debug logs may contain paths, queries, customer data, or secrets. Restrict access using controls appropriate to the server, or an approved log path outside public serving locations.

After troubleshooting, restore the intended production debug settings and disable or restrict temporary logging. Handle collected logs under the site’s security and retention policy. WP_DEBUG_DISPLAY false controls WordPress debug display; it does not guarantee that every hosting-level startup error is hidden.

Use WordPress Recovery Mode

When WordPress detects certain fatal plugin or theme errors, it may send a Recovery Mode notification and link to the site’s administration email address. Check that mailbox and spam folder. Treat the recovery link as private, verify the expected domain, and do not forward it publicly.

Use a valid recovery link to enter the dashboard when available. Recovery Mode can pause the implicated extension for the recovery session so the administrator can investigate the reported error. This is not the same as permanently deactivating it for every visitor; the public site may still fail until the underlying problem is addressed.

Record the reported component and error, preserve backups, then review compatibility or use a controlled deactivation, update, or rollback as appropriate. Test normal access outside the recovery session before deciding the site is restored. Exit recovery after the corrective work and verify essential features.

Emails are not guaranteed for every failure. Delivery problems, early bootstrap failures, unavailable services, or the failure type can prevent useful notifications. Recovery Mode does not repair missing files, every server issue, or every kind of fatal error. If the link is unavailable, use authorized hosting logs and file access.

Disable Plugins Without wp-admin Access

Method A — WordPress dashboard

If the dashboard works, record the active plugin list and deactivate the recently changed or log-identified plugin individually. Retest the same failing action. Reactivate verified components deliberately; a dependency conflict may involve more than one plugin.

Method B — cPanel File Manager or SFTP

Use authorized cPanel File Manager if supplied, or SFTP rather than unencrypted FTP. Verify the actual installation and plugin directory; the standard location is wp-content/plugins, but it can be customized. Prefer a targeted temporary rename of the suspected plugin’s folder when the evidence identifies it.

If the cause is unclear, an approved temporary rename of the ordinary plugins directory can test whether those plugins are involved. Record the original name and active list. This can disable essential features, so use staging or a controlled production window and retest the original request.

Restore the original directory name after the test and isolate components carefully using dashboard controls when available. Renaming is not always a persistent deactivation: restoring the folder can load previously active plugins again, while visiting wp-admin with files missing can change activation state. Preserve the active list and plan each reactivation.

Must-use plugins and drop-ins such as object-cache.php load separately and are not disabled by renaming the ordinary plugins directory. Hosting-managed components may be required. Ask the provider before changing them; do not delete all plugins or assume a directory rename tests every extension.

Method C — WP-CLI

WP-CLI can inspect or deactivate plugins for administrators with authorized shell access in the correct installation. Availability varies by host. Appropriate skip options can avoid loading ordinary plugins/themes during some commands, but must-use plugins and earlier bootstrap failures may still interfere. Confirm the path and dependencies before running any operation.

Check for Theme Conflicts

Theme PHP errors, an incompatible update, functions.php changes, and child-theme customizations can stop requests. A child theme may depend on a parent version or functionality supplied by an extension. Correlate the latest change with matching fatal-error logs.

Where appropriate, test another installed, compatible default theme in staging or during an approved production test. Record the original parent/child relationship and configuration first. Retest the failing URL, dashboard, and important theme-dependent features.

Switching themes can change appearance, widgets, menus, templates, and functionality. Do not permanently delete the active theme as an initial fix or rely on an unknown automatic fallback. Preserve custom code and use a reviewed rollback or compatible release after identifying the cause.

Investigate PHP Memory Exhaustion

A current log entry such as “Allowed memory size of … bytes exhausted” is evidence that a PHP request reached its effective memory limit. Review the component and operation involved: large queries, imports, builder work, or faulty code can consume unusually high memory.

Illustrative WordPress configuration only — 256M is an example, not a universal recommendation:

define( 'WP_MEMORY_LIMIT', '256M' );

Update an existing definition rather than duplicating it, and place it before WordPress loads. WP_MEMORY_LIMIT requests a WordPress allowance; hosting-level PHP limits or policy may override or restrict it. The effective web PHP runtime and available capacity matter. WordPress can use a separate administrative memory allowance in some contexts.

Ask the host about the supported limit and investigate the consuming operation before raising it. Increasing memory alone will not correct incompatible code, a missing file, or every WSOD issue. Repeatedly raising limits can conceal inefficient behavior without resolving the cause.

Check PHP Version Compatibility

Compare the web application’s PHP version with the supported requirements of WordPress core, each relevant plugin and theme, and custom PHP code. An upgrade can expose removed functions, incompatible signatures, or extension requirements. Deprecation warnings alone do not necessarily explain a fatal failure.

The command-line PHP version can differ from the web/PHP-FPM runtime. Check the failing application’s effective version, handler, and installed extensions through the provider’s supported controls. Do not assume a successful CLI command proves the web process has the same environment.

Test a supported compatible configuration in staging and document a rollback route before changing production. Shared and managed hosts may restrict available versions or handlers. Avoid arbitrary downgrades to unsupported PHP releases; involve the provider or software vendor when compatibility cannot be established.

White Screen After a Plugin or Theme Update

Record the old and attempted versions and whether the updater reported completion. Review dependencies, PHP requirements, missing extension files, and incomplete filesystem writes. An interrupted transfer or failed extraction can look different from a fully installed release with incompatible code.

When appropriate, use a reviewed rollback to a known-good, supported version or a verified backup. Check whether the update changed database structures or stored configuration; rolling back files alone may not reverse those changes. Preserve evidence and test the recovery path rather than blindly reinstalling.

A restore can overwrite newer changes

Database or whole-site restoration may replace recent content, orders, submissions, and settings. Agree on what will be restored and how newer data will be handled. Keep the original files and backup outside public download locations.

After correction, test the original failing page and essential forms, checkout, and administration tasks. A working homepage may be cached. Resume updates only after the compatibility or installation issue is understood.

White Screen After WordPress Core Updates

An interrupted core update can leave missing files or mixed versions. Major upgrades can also expose incompatible plugins, themes, or PHP code. Record the intended WordPress version and update result; check Dashboard → Updates when accessible and compare the relevant logs.

An update-related maintenance notice is a separate symptom from a PHP blank screen. A leftover indicator may hide the next error, and removing it does not repair an incomplete update. Confirm no updater is active before considering any indicator removal. Follow the guide to fixing WordPress stuck in maintenance mode safely.

Verify backups, the exact version, storage, ownership/permissions, and supported recovery process before reinstalling or replacing core files. Preserve wp-config.php and site content. Do not copy arbitrary core releases over production or delete directories blindly; request assistance if the installation is inconsistent.

White Screen After Website Migration

A destination can use a different PHP version, lack an extension or custom dependency, reject a server directive, or apply different ownership and permissions. An incomplete file transfer can leave required code missing even when the database import succeeded.

DNS determines which server a hostname reaches; it does not by itself identify a PHP fatal error. A database connection failure has its own credential, endpoint, and service checks. Confirm the intended installation is serving traffic, then use the actual response and logs to distinguish these problems.

Check WordPress database connection errors after migration

Review Hostingcone Website Migration scope and purchase steps

The published service is $149 one-time and applies to one standard WordPress website migration. Work beyond the listed scope may require approval and additional charges. Review the current service page for the existing Buy Now workflow, access needs, and limitations.

Check Server Logs and Configuration

Review PHP error logs, web-server error logs, and the hosting control panel’s relevant Errors interface where available. Match the timestamp and failing URL, allowing for server time-zone differences. Review recent configuration changes, disk/account storage limits, and resource exhaustion.

Shared or managed-hosting customers should ask the provider for logs or service checks unavailable in their account. cPanel feature names and log coverage vary; a limited Errors view may omit PHP-FPM or upstream details. Use the controls actually supplied rather than assuming every plan has cPanel.

Authorized VPS administrators can review the actual PHP-FPM status/logs, service configuration, and system resource evidence under their operating procedures. Service names and paths vary. Do not restart shared infrastructure or change global configuration without authority; a restart can interrupt clients and obscure evidence.

Troubleshoot WordPress 500 Internal Server Error

Provide the domain, time, failing action, recent changes, and redacted log excerpts to the responsible provider. Never expose secrets or raw customer data. A failure before WordPress loads may require hosting-level correction instead of a plugin change.

Why Only One Page Is Blank

A shortcode, page-specific plugin, custom code block, theme template, or content-dependent PHP path may run only on that request. Compare a working page with the failing page and identify which components each loads. A single failing page does not automatically mean its content was deleted.

Elementor-specific checks

Review recent widget, template, addon, and Elementor-version changes. Compare frontend rendering, the editor, and other pages using the same template. Check the matching PHP logs and, where the server returns content but the browser remains blank, the browser console and network requests for client-side failures.

Use a backed-up staging copy to isolate the implicated widget or addon when possible. Verify compatibility between Elementor, its relevant addons, the theme, and PHP. Avoid resetting global styles or deleting shared templates as a diagnostic shortcut; those actions can change many unrelated pages.

Retest the exact URL, query/action, and relevant user state. Browser or hosting caches can retain an old response, but clearing a cache does not repair the underlying fatal error. Clear only the relevant cache through approved controls after correcting the cause.

How to Prevent Future White Screen Errors

Maintain verified backups and a recovery plan. Test substantial changes in staging, keep WordPress/plugins/themes compatible, and review PHP requirements before upgrades. Avoid unmaintained extensions and document meaningful code, version, and configuration changes.

Monitor website availability, inspect logs after major changes, and keep adequate hosting resources for the workload. Confirm updates complete and preserve a clear route for escalating hosting or software issues. Monitoring helps identify failures; it does not prevent every outage.

Explore WordPress Maintenance for ongoing upkeep

Review Website Care for recurring maintenance and support

These practices reduce avoidable failures and improve recovery readiness. They do not eliminate all future errors, guarantee uninterrupted service, or promise that every lost change can be recovered.

When to Contact WordPress Support

Seek assistance when the site is inaccessible, Recovery Mode is unavailable, PHP fatal errors persist, targeted tests have not helped, or an update/migration caused a failure you cannot safely diagnose. Get help if you lack authorized file access or the necessary server logs.

Hostingcone’s published WordPress Troubleshooting service is $79 one-time: diagnosis and up to 1 hour of troubleshooting for one WordPress website. Additional work requires approval and may incur additional charges. Included time is not a guarantee that every error will be repaired.

Get WordPress Support and review the existing Buy Now workflow

Website Repair starts at $99. Final pricing depends on complexity, urgency, and the amount of work required. Its existing Request Service workflow allows the issue and scope to be reviewed before work begins.

Review Website Repair scope and request assistance

WordPress Maintenance and Website Care cover ongoing upkeep according to the purchased service or plan. Customer cooperation and secure access may be needed; third-party software, vendors, and hosting environments can affect results. No repair time or outcome is guaranteed.

Share the affected domain, timing, recent changes, attempted checks, and redacted evidence through the appropriate support channel. State which backups are available. Use the provider’s secure credential-sharing method if access is required rather than sending passwords in an ordinary message.

Frequently Asked Questions

What is the WordPress White Screen of Death?

It is a blank page where WordPress output should appear. It can affect the frontend, dashboard, or one request. Modern WordPress may show a critical-error notice instead. The symptom needs logs and context to identify the cause.

What causes a blank white page in WordPress?

PHP fatal errors, plugin/theme incompatibilities, memory exhaustion, custom code, failed updates, missing files, and server problems can contribute. A blank browser display can also involve client-side rendering; inspect the response and matching evidence.

How do I fix a WordPress white screen without wp-admin?

Check any Recovery Mode email, then use authorized hosting logs and File Manager or SFTP for a targeted investigation. Preserve backups and original settings. A controlled plugin test may help, but server-level failures may require the host.

Can a WordPress plugin cause a blank screen?

Yes. Incompatible code, missing dependencies, or resource-intensive operations can fail a request. Match logs and recent changes, then test the suspected plugin safely. Renaming ordinary plugin folders does not disable must-use plugins or separate drop-ins.

Can PHP memory exhaustion cause a white screen?

Yes, when a request exceeds its effective limit. Look for a matching exhaustion message. A suitable limit adjustment may help where permitted, but it does not repair faulty code or every white-screen issue. 256M is only an illustrative value.

What does “There has been a critical error on this website” mean?

WordPress detected a serious application failure, often a PHP fatal error. The notice is not a complete diagnosis. Review any recovery notification and matching PHP/hosting logs to identify the failing component.

How does WordPress Recovery Mode work?

For certain detected fatal extension errors, WordPress may email a private recovery link. It can pause the implicated extension for the recovery session so an administrator can investigate. It does not guarantee email delivery or automatically repair the public site.

Why is only one WordPress page blank?

That request may load a particular shortcode, widget, template, addon, or content-dependent code path. Compare working and failing pages, recent changes, response details, and logs before changing shared settings.

Can Elementor cause a white screen?

Elementor, an addon, a widget, or a template interaction can be involved, as can PHP limits or unrelated server faults. Check compatibility and the specific failing request. Do not reset global styles or delete templates without evidence and a rollback plan.

Will troubleshooting the White Screen of Death delete my content?

A targeted diagnostic step does not inherently require deleting content. Restores, replacements, or careless file/database changes can overwrite data. Preserve verified backups and agree on recovery scope before corrective operations.

Need Help Fixing a Blank WordPress Website?

If your WordPress website is displaying a blank page or critical error, Hostingcone offers WordPress troubleshooting and website repair services to help investigate supported problems.

Explore more solutions in our WordPress Troubleshooting Hub, including guides for database errors, failed updates, and website migrations.