How to Fix the WordPress White Screen of Death

A completely blank WordPress page usually means PHP stopped before WordPress could display a useful error. Start with the most recent change. If the white screen appeared after installing or updating a plugin, changing themes, editing PHP, or upgrading WordPress, reverse that change first.

Before modifying files, settings, or the database, confirm that you have a recent backup or create one through your hosting control panel.

Check what is actually blank

Open both the homepage and /wp-admin/ in a private browser window.

• If only one page is blank, check that page’s template, shortcode, blocks, and page-builder content.
• If the frontend works but /wp-admin/ is blank, an admin-only plugin hook or PHP error may be responsible.
• If every page is blank, start with the PHP error log and active plugins.

Clear server, CDN, page, and browser caches after each fix. A cached blank response can make the site appear broken after PHP starts working again.

Record the PHP error without showing it to visitors

WordPress can write PHP errors to a log while hiding them from visitors. Open wp-config.php through SFTP or your host’s file manager and add these lines above /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reload the blank page once, then check this file:

wp-content/debug.log

Look at the newest fatal error. Its file path often identifies the responsible plugin, theme, or custom code. For example, a path containing wp-content/plugins/example-plugin/ points to that plugin.

WordPress explains these settings in its debugging guide. Debug logs can contain filesystem paths, query details, email addresses, or other sensitive information. On some server configurations, debug.log may be publicly accessible, so protect it from web access or remove it promptly after collecting the details you need.

When troubleshooting is complete, restore the previous settings or set WP_DEBUG to false. Delete debug.log after saving only the error details needed for a support request.

If WordPress does not create the file, check the PHP error log in your hosting panel or ask your host for the fatal error recorded at the time of the blank request.

Disable plugins when the dashboard is unavailable

Plugin conflicts are among the causes covered in the official WordPress common-errors documentation.

If the dashboard still loads, go to Plugins > Installed Plugins, deactivate the plugin changed most recently, and reload the broken page. If you are not sure which plugin caused the problem, deactivate all nonessential plugins, then reactivate them one at a time until the white screen returns.

If the dashboard is blank, connect through SFTP or your host’s file manager. Record the exact original directory name, including capitalization, before renaming:

wp-content/plugins

Rename it temporarily to a unique name such as:

wp-content/plugins-disabled

This prevents standard plugins in that directory from loading. Reload the site.

If the site returns, the failure is likely in a standard plugin, but do not assume every plugin has been cleanly deactivated. To isolate the problem without loading them all at once:

1. Keep the renamed directory as a temporary backup.
2. Create a new empty directory named exactly plugins.
3. Move plugin directories from plugins-disabled into plugins one at a time.
4. Reload the site after each move.

When the white screen returns, move the last plugin directory back out of plugins. Leave that plugin disabled while you restore a known-good version, install a compatible release, or send the fatal-error details to its vendor.

After recovery, return all directories to their exact original names. Incorrect names can prevent plugins from being recognized or can change their stored paths.

Renaming the main plugins directory does not disable must-use plugins in wp-content/mu-plugins. If the error points there, contact the developer or hosting provider responsible for that code.

Test the active theme

If disabling plugins does not help, test the theme. This is particularly relevant when the white screen started after a theme update or an edit to functions.php.

When the dashboard is accessible, go to Appearance > Themes and temporarily activate another known-good theme. Prefer a current default WordPress theme.

If the dashboard is blank, first confirm that another valid theme is installed in wp-content/themes. Record the active theme directory’s exact name, including capitalization, and then rename only that directory through SFTP or your host’s file manager.

WordPress may switch to an installed fallback theme, but this depends on a valid alternative being available. If no fallback theme is installed, upload a current default WordPress theme before renaming the active theme directory.

If the site loads with the fallback theme, inspect the original theme’s PHP error, restore its previous version, or repair the file identified in the log. Restore the original directory name exactly before retesting or reactivating it.

For a custom theme, compare and roll back recent changes rather than reinstalling it and overwriting modifications.

Use the fatal error to choose the next fix

Allowed memory size exhausted

The request reached its PHP memory limit. Raising the limit may restore access temporarily, but it does not identify why memory use increased.

Ask your host to confirm the effective PHP memory limit and review the process causing the exhaustion. If the error follows a specific plugin activation or resource-heavy task, keep that component disabled until its requirements are understood.

Parse error or syntax error

The log should identify a PHP file and an approximate line number. Restore the file from a working backup or undo the latest code edit. Check nearby lines for missing semicolons, brackets, or quotation marks.

Avoid editing PHP through the WordPress theme or plugin editor during recovery. SFTP gives you a clearer rollback path if another edit fails.

Undefined function, class, or method

This can indicate incompatible code, an incomplete update, or a missing dependency. Reinstall or roll back the affected plugin or theme from a trusted package.

Do not edit vendor code merely to suppress the error. The next update will overwrite the change, and the underlying incompatibility will remain.

Check for an interrupted update

If the blank screen appeared during an update, inspect the WordPress root directory for a .maintenance file. A stuck maintenance file normally displays a maintenance message rather than a pure white screen, but it is worth checking after an interrupted update.

Delete .maintenance only after confirming that no update is still running. Then verify that the affected plugin, theme, or WordPress core files are complete. Restore the pre-update backup if files are missing or the update cannot be completed safely.

Optional WP-CLI method for SSH users

If you already use SSH and WP-CLI on this site, you can disable standard plugins without renaming directories:

wp plugin deactivate --all --skip-plugins

The --skip-plugins parameter prevents plugin code from loading while WP-CLI updates the activation state. See the official wp plugin deactivate command documentation.

Reload the site after running the command. If it works, reactivate plugins one at a time from the dashboard, or with WP-CLI if the dashboard is still unavailable:

wp plugin activate plugin-directory-name

Keep the plugin that brings back the white screen disabled while you restore a working version or contact its vendor.

Contact the host when WordPress cannot log the failure

Contact your hosting provider when:

• The PHP or web-server error log is unavailable.
• The blank page remains after disabling standard plugins and testing a valid fallback theme.
• PHP workers are crashing or requests are being terminated by server limits.
• File ownership or permissions prevent WordPress from reading required files.
• The failure started after a PHP version or server configuration change.

Provide the affected URL, approximate failure time, newest fatal error, and the changes made immediately before the problem started. Do not send passwords, database credentials, or the complete contents of wp-config.php.