The WordPress White Screen of Death (WSOD) occurs when a serious PHP error stops WordPress from rendering a page. You might see a completely blank screen, a partially loaded page, or the message, “There has been a critical error on this website.”
Common causes include a faulty plugin, incompatible theme code, a PHP version change, exhausted memory, or an interrupted update. Before changing anything, note what happened immediately before the error and make a backup if your hosting tools still allow it. Then work through the checks below, starting with the least disruptive options.
1. Confirm Which Parts of the Site Are Affected
Open the homepage, several internal pages, and /wp-admin/ in a private browser window. This helps you determine whether the failure affects the entire site or only a specific request.
- If the front end is blank but the dashboard works, check the active theme, page templates, caching, and front-end plugins.
- If both the site and dashboard fail, investigate plugins, themes, PHP errors, memory limits, and recent WordPress updates.
- If only one post or page fails, inspect its shortcode, custom block, page-builder element, or template.
Test from another connection and clear relevant page caches if necessary. Caching can preserve an old error, but it usually does not resolve the PHP problem that produced it.
2. Try WordPress Recovery Mode
When WordPress detects a fatal error, it may send the site administrator an email with a Recovery Mode link. That link opens a temporary session where the reported plugin or theme can be paused without disabling every extension.
- Open the Recovery Mode link in the administrator email.
- Read the component name and error details rather than dismissing them immediately.
- Deactivate or update the named plugin, or switch away from the reported theme.
- Exit Recovery Mode and test the site in a normal browser session.
Recovery Mode provides access for troubleshooting; it is not itself a permanent repair. Before updating the component, confirm that its new version supports your WordPress and PHP versions. If no email arrives, continue with the file-access and logging methods below.
3. Enable Debug Logging Without Showing Errors Publicly
WordPress debug logging can identify the file and line that triggered the failure. Edit wp-config.php in the WordPress root directory and add these settings before the line that says “That’s all, stop editing!”
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Load the failing page once, then inspect wp-content/debug.log. Focus on the first fatal error in the relevant request. The message may identify a plugin directory, theme file, missing class, undefined function, memory exhaustion, or PHP syntax problem.
Do not display debug messages on a public production site. They can reveal file paths and other technical details. After troubleshooting, change WP_DEBUG back to false and remove or protect the log.
4. Isolate a Plugin Conflict
Plugins are a frequent cause of a white screen, particularly after an update or when two extensions provide incompatible code. If the dashboard is available, deactivate every plugin and reactivate them one at a time, testing the site after each activation.
When the dashboard is unavailable, use your host’s file manager or SFTP. Rename wp-content/plugins to a temporary name such as plugins-disabled. WordPress will treat the plugins as inactive. If the site returns, rename the directory to plugins and deactivate individual plugin folders one at a time until you identify the failure.
Start with the plugin that was installed, updated, or configured immediately before the outage. On a WooCommerce site, restore payment, checkout, and order-management functionality carefully and avoid leaving those components disabled longer than necessary. A staging copy is preferable when transactions are involved.
For preventive maintenance, review plugin security in WordPress and maintain a record of active extensions, versions, and license requirements.
5. Switch to a Default Theme
A theme can cause a fatal error through an outdated template, incompatible custom code, or an incomplete update. If you can access the dashboard, activate an installed default theme such as Twenty Twenty-Four.
If the dashboard remains unavailable, use phpMyAdmin only if you are comfortable editing the database. In the wp_options table, locate template and stylesheet, then set both values to the folder name of an installed default theme. Create a database backup before making this change.
If the site works with the default theme, inspect the original theme’s functions.php, child theme, custom snippets, and page-builder integrations. A visual builder may require additional troubleshooting; this guide to page builders for WordPress provides related background.
6. Check PHP Compatibility, Memory, and Syntax
A PHP failure can follow a hosting upgrade or occur when older code runs on a newer PHP release. Check the hosting panel’s PHP error log and confirm that WordPress core, the active theme, and installed plugins support the selected PHP version.
Do not use an obsolete PHP version as a long-term solution. A controlled rollback may restore access temporarily, but updating incompatible code is the safer repair.
Memory exhaustion may appear in the log as Allowed memory size exhausted. You can request a higher WordPress memory limit in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );Your host may enforce a lower server limit, so this setting is not guaranteed to increase available memory. High memory usage can also point to a plugin query, import, image process, or custom function that needs correction.
For custom PHP, review recently edited files for missing semicolons, unmatched braces, duplicate class declarations, and calls to functions removed or changed by an update. Use version control and staging where possible, along with the techniques described in this PHP development tools guide.
7. Repair a Failed Update or Corrupt Core Files
If the white screen began during a WordPress update, upload fresh copies of the wp-admin and wp-includes directories from the same WordPress version. Do not overwrite wp-content or wp-config.php.
Your host or managed WordPress provider may also have a restore point. Before restoring anything, confirm its date and scope. A full restore can remove newer orders, comments, user accounts, or other content. For a business or WooCommerce site, ask the host to preserve the current files and database before rolling back.
8. Know When to Get Help
Stop making changes on production if the site processes payments, contains important customer data, or has no recent backup. A developer can reproduce the problem on staging, inspect server logs, test PHP compatibility, and patch custom code without repeatedly changing the live site.
If you need hands-on assistance, hire a PHP developer for WordPress who can explain the cause, document the repair, and improve the deployment process. Support may include plugin debugging, custom PHP, API integrations, performance work, and WooCommerce recovery.
Frequently Asked Questions
Can clearing the cache fix the White Screen of Death?
Clearing the cache can remove a stale cached response, but it normally does not fix a fatal PHP error. Check the logs and test plugins, themes, and PHP configuration.
What if I cannot find the debug log?
Confirm that the constants were added to wp-config.php, reproduce the error once, and check wp-content/debug.log. Some hosts store PHP errors in a separate hosting-panel log.
Will disabling all plugins delete their settings?
Normally, deactivation does not delete plugin settings. Renaming the plugins directory temporarily deactivates extensions; it does not uninstall them.
Should I change the PHP version immediately?
First identify the failing code and check compatibility. A PHP rollback may restore access temporarily, but updating the incompatible plugin or theme is usually the better long-term approach.
Conclusion
Fixing the WordPress White Screen of Death means isolating the failure rather than changing several settings at once. Use Recovery Mode when available, read the debug log, test plugins and themes, check PHP and memory limits, and restore only from a verified backup. Once the site is stable, update the responsible component, test the change on staging, and document the repair.