How to Fix the WordPress White Screen of Death

A blank page with no message is what PHP produces when it stops on a fatal error and has been told not to print errors. That is the WordPress white screen of death: the code died, and the one line that says why went to a log file, or nowhere. WordPress now catches most fatal errors and shows a "critical error" notice in their place, so a truly empty page tends to mean the failure happened somewhere that safety net does not reach.

The fix is always the same two moves. First make the error visible. Then remove suspects in order, starting with the ones that are most likely and cheapest to undo: plugins, the theme, server limits, and last the core files.

See how much of the site is blank

The pattern narrows the search, so check it before opening any file. Load the site in a private window so a cached copy cannot mislead you, and open the browser developer tools on the Network tab to read the status code of the page request.

What you see	Most likely cause
Front end blank, /wp-admin/ loads	The active theme, or a plugin that only runs on the front end
Dashboard blank, front end loads	A plugin's admin code, or the memory limit on a heavy admin screen
Everything blank, status 500	A fatal error early in loading: a plugin, a must-use plugin, a drop-in or wp-config.php
Blank page, status 200	A template that outputs nothing, or a cache serving an empty page
One page or one action only	Memory or a timeout on that task, such as an import or a large image

Write down what changed last as well: a plugin update, an edit to functions.php, a PHP version switch by the host. The most recent change is the first suspect.

Make PHP tell you what failed

Before you change anything, download a copy of wp-config.php and the wp-content folder over SFTP, and export the database from the hosting panel if you can reach it. You are about to rename folders on a broken site, and a copy costs a few minutes.

Then open wp-config.php and add these lines above the require_once line that loads wp-settings.php. If a WP_DEBUG line already exists, change it. Do not add a second one.

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

Reload the blank page once, then open wp-content/debug.log and read the last lines for "PHP Fatal error" or "PHP Parse error". The message ends with a file path and a line number, and the folder in that path (wp-content/plugins/some-plugin/, wp-content/themes/your-theme/) names the culprit. Our guide to reading a fatal error and its stack trace goes through such a line piece by piece.

If no log file appears, the error happens before WordPress gets far enough to write one. The usual reasons are a syntax error in wp-config.php itself, or a web server user that cannot write to wp-content. Read the PHP error log in your hosting control panel in that case. The official page on debugging in WordPress lists every related constant. When you are finished, set WP_DEBUG back to false and delete the log, because anyone who guesses its address can read it.

Switch plugins off without the dashboard

If the log names a plugin, deal with that one. If it names nothing useful, take every plugin out of the picture at once.

Over SFTP or the host's file manager

Rename wp-content/plugins to plugins-off and reload the site. WordPress cannot find the plugin files, so it loads without them. If the page comes back, a plugin is the cause. Now open /wp-admin/plugins.php once, so WordPress notices the missing files and marks every plugin as deactivated. Rename the folder back to plugins. The plugins reappear in the list, all inactive. Activate them one at a time and reload the site after each until the blank page returns. The last one you switched on is the cause.

With WP-CLI

Over SSH the same test takes two commands. The --skip-plugins and --skip-themes flags matter: without them WP-CLI loads the broken code and dies with the same fatal error.

wp plugin list --status=active --field=name --skip-plugins --skip-themes
wp plugin deactivate --all --skip-plugins --skip-themes

The first line prints the plugins that are active now, so save its output. Then bring them back one at a time with wp plugin activate followed by the plugin's name, reloading the site after each.

Two kinds of code are untouched by either method: must-use plugins in wp-content/mu-plugins, and drop-in files such as object-cache.php and advanced-cache.php that sit directly inside wp-content. They load on every request. If the site is still blank with all plugins off, move those files out one at a time.

Rule out the theme

A theme breaks a site the same way a plugin does, most often after someone edits functions.php and leaves out a bracket or a semicolon. If you edited a theme file just before the screen went white, restore that file from your copy and you are done.

Otherwise switch to a default theme. With WP-CLI, list what is installed and activate one:

wp theme list --skip-plugins --skip-themes
wp theme activate twentytwentyfive --skip-plugins --skip-themes

Without SSH, first make sure a default theme such as Twenty Twenty-Five is present in wp-content/themes, and upload one if the folder holds only your own theme. Then rename the active theme's folder and open Appearance > Themes. WordPress sees that the active theme is missing and reverts to the default. If the site works with the default theme, the fault is in your theme or its child theme. Menus and widget areas may need to be assigned again when you switch back.

Check memory, the PHP version and other server causes

With plugins and the theme cleared and the page still empty, look at the server.

• Memory. A log line that reads "Allowed memory size of ... bytes exhausted" means a request ran out of memory. Adding define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php often brings the page back, but read what the memory limit error is telling you before you leave it there.
• PHP version. Hosts retire old PHP versions and move accounts to newer ones, and code written for an old version can fail to parse on a new one. Check the current version in the hosting panel. Switching back one version is a fair emergency measure until the code is updated or replaced.
• Timeouts. If the page stays white for a long time before it gives up, a script is hitting max_execution_time. The log will say "Maximum execution time" and name the file.
• A cached blank page. If you fixed the error and still see white, purge the page cache and the CDN, then test in a private window.

Replace damaged core files

Core files break after an update that stopped half way, a disk that filled up, or an attack that altered them. WP-CLI compares every core file with the official checksums:

wp core verify-checksums

If it reports files that do not verify, reinstall the same version over the top. This replaces wp-admin, wp-includes and the PHP files in the site root, and leaves wp-content and wp-config.php alone. Add --locale if the site runs a translated build.

wp core download --version=$(wp core version) --skip-content --force

Without SSH, download the matching version from the WordPress release archive, unzip it, and upload wp-admin, wp-includes and the loose root files over the existing ones. Do not upload the wp-content folder from the zip. If core files were altered and no update had failed, or you find PHP files in core folders that the checksum report does not recognize, treat the site as possibly compromised and have it checked before you call the job finished.

When the WordPress white screen of death needs a developer

The log plus the plugin and theme tests solve most blank screens, and a careful site owner can do all of that. Hand it over when the log points into a custom plugin or a customized theme that nobody on your team wrote, when the same error returns after every update, when checksums fail and you cannot explain why, or when the site takes orders and every hour of guessing has a cost. Our WordPress maintenance team works from the same log you just switched on, so keep it. If the broken code is an old customization, rebuilding it as a properly structured plugin stops the next update from causing the same outage.

Frequently asked questions

Why is my site blank only for visitors who are not logged in?

Logged-out visitors are usually served from a page cache, and logged-in users are not. A cache that stored an empty response keeps serving it after the real error is gone. Purge the page cache and the CDN. If the blank page returns, look at caching and script optimization plugins, which treat guests differently.

Can I fix the white screen without SFTP or SSH access?

Often, yes. Most hosting control panels include a file manager that can rename folders and edit wp-config.php, and that is all the plugin and theme tests need. With no panel access either, ask the host's support to rename the plugins folder and send you the PHP error log.

Will renaming the plugins folder delete my plugin settings?

No. Plugin settings live in the database, and deactivating a plugin does not remove them. Only deleting a plugin from the Plugins screen can remove its data.

Is it safe to leave WP_DEBUG switched on?

Not on a live site. With WP_DEBUG_DISPLAY off, visitors do not see errors, but debug.log keeps growing and may be readable from the web. Switch it off when the diagnosis is done.