WordPress White Screen of Death: Fixes in Order (Tested)

A WordPress white screen almost always means PHP hit a fatal error and stopped before the page was built, and the fix is to find which plugin, theme or setting caused it and switch that one thing off. Since WordPress 5.2, most of these crashes show “There has been a critical error on this website” instead of a blank page, but a truly blank page still happens. To see exactly what each failure looks like today, I broke a local WordPress 7.1.2 site four different ways (plus one config variant) and recorded what visitors, the admin and the error log showed.

Below are the fixes in the order I use them, least risky first.

What is the WordPress white screen of death?

The WordPress white screen of death is a page that loads with nothing on it, or with only a short error notice, because PHP crashed partway through building it. The server usually returns HTTP 500. Your content is not lost; the crash is in code.

What you actually see depends on your WordPress version and settings. Before WordPress 5.2, a fatal error on a live site usually meant a blank white page and a locked dashboard. The 5.2 release added fatal error protection: WordPress catches the crash, shows a message, and emails the admin a “recovery mode” link for logging in with the broken plugin or theme paused. In WordPress 7.1.2’s source, the handler shows one of three messages:

• “There has been a critical error on this website.” The plain version visitors see on the front end.
• “There has been a critical error on this website. Please check your site admin email inbox for instructions.” Shown on wp-admin and the login page, even when no email was actually sent.
• “There has been a critical error on this website, putting it in recovery mode.” Shown to someone already in recovery mode when a new error is caught.

So “there has been a critical error on this website” is the modern WordPress white screen of death. Same cause, friendlier page.

What causes a WordPress white screen of death?

A PHP fatal error causes it: code that cannot continue, such as a call to a function that does not exist, a syntax error, or running out of memory. WordPress’s handler covers five PHP error types (E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR and E_RECOVERABLE_ERROR). Warnings and notices do not blank a page on their own.

Cause	What you see	Where to look	Fix
Plugin fatal error, often after an update	“Critical error” message; recovery email if the admin or login page crashed	Recovery email, wp-content/debug.log, Plugins screen in recovery mode	Deactivate it in recovery mode, or rename its folder
Theme error, such as a typo in functions.php	“Critical error” message on the front end and in wp-admin	debug.log shows a “Parse error” with file and line	Undo the edit, restore the file, or switch theme
PHP memory exhausted	Can be a truly blank page, even on current WordPress	debug.log: “Allowed memory size of … bytes exhausted”	Raise WP_MEMORY_LIMIT or the host’s PHP limit
Must-use plugin or custom code in mu-plugins	Generic “critical error”, no email, no recovery mode	debug.log, the wp-content/mu-plugins folder	Rename or remove the file over SFTP
Error handler disabled in wp-config	Blank page with zero bytes	WP_DISABLE_FATAL_ERROR_HANDLER in wp-config.php	Remove that line on live sites
Hacked or injected code	Blank or broken pages, unknown files, admin users you did not add	Recently changed files, users list	Clean the site; see below

I left out .htaccess and file permission problems: my test server does not read .htaccess, and I only list what I could reproduce.

How do you fix the WordPress white screen of death?

Work down this list and stop at the first step that brings the site back. Take a backup or download a copy of any file before you edit it.

1. Rule out your own browser and cache

Open the site in a private window and on your phone’s mobile data. If it loads there, clear your caching plugin or your host’s cache. If the WordPress white screen shows everywhere, move on.

2. Check the admin email inbox

If the crash hit wp-admin or the login page, WordPress sends an email titled “[Your site name] Your Site is Experiencing a Technical Issue” to the site’s admin email address. In my test it named the exact plugin and the error message with its line number, and included a recovery mode link that, per the email, expires in one day. That one email often tells you everything. If nothing arrived, visit /wp-admin/ yourself to trigger it, then check spam.

3. Turn on the debug log

If there is no email, the debug log is the fastest way to a name. Add these lines to wp-config.php above the “stop editing” line:

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

Reload the broken page, then open wp-content/debug.log. The WordPress debugging handbook says that is where the log goes by default, and that debug tools are not meant to stay on live sites. PHP’s own manual says error display “should never be used on production systems”. Read the last “Fatal error” or “Parse error” line: the path in it, such as /plugins/plugin-name/ or /themes/theme-name/, points at the culprit. Turn the three lines off again when you are done.

4. Deactivate the plugin that crashed

In client work, plugins cause most of the WordPress white screen cases I see, usually one that was just updated. There are three ways to switch it off.

• Recovery mode: click the link in the email, log in, go to Plugins and click Deactivate on the plugin marked “paused”. The pause only applies to the browser you clicked the link in, so visitors still see the error until you deactivate it.
• Rename the folder: in your host’s file manager or over SFTP, rename wp-content/plugins/plugin-name to plugin-name.off. WordPress deactivates it on its own. If you cannot tell which plugin it is, rename the whole plugins folder, check the site, then rename it back and switch plugins on one at a time.
• WP-CLI: wp plugin deactivate plugin-name --skip-plugins, or wp plugin deactivate --all --skip-plugins to switch everything off. The --skip-plugins flag stops the broken plugin loading while WP-CLI runs.

Update or replace it before switching it back on.

5. Fix or switch the theme

If the log points at your theme, the most common cause is a hand edit to functions.php. Undo the change or put back the copy you saved. If you cannot, rename the theme’s folder over SFTP, then open Appearance > Themes: WordPress switches to its default theme, Twenty Twenty-Five on 7.1, when the active theme is missing and the default is installed. With WP-CLI, wp theme activate twentytwentyfive --skip-themes should do the same job: the --skip-themes flag stops the broken theme loading while the command runs (I did not run this one in my test).

6. Raise the memory limit if the log says memory

If debug.log says “Allowed memory size of 41943040 bytes exhausted”, the site hit WordPress’s 40 MB single-site default (64 MB on multisite). Adding define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php fixed it in my test. If that line changes nothing, your host’s PHP limit is the ceiling. My guide to increasing the WordPress memory limit covers every method and why the wp-config line sometimes fails.

7. Restore a backup or reinstall core files

If nothing above names a cause, restore the last backup from before the problem started, or reinstall WordPress core from Dashboard > Updates. Core files rarely break on their own, so this is for an interrupted update or files you cannot account for.

8. Check for a hack

A blank site with no plugin, theme or memory cause, especially alongside admin users or files you did not add, can be malicious code. Restoring alone leaves the hole open. My guide to fixing a hacked WordPress site walks through cleanup, or you can hand it to a WordPress malware removal service.

What I saw when I broke a WordPress site on purpose

I ran these tests on 2026-10-14 on a local WordPress 7.1.2 site with PHP 8.2.12, the Twenty Twenty-Five theme, SQLite instead of MySQL, and seven active plugins, including UpdraftPlus 1.26.8. I served it with PHP’s built-in web server, turned display_errors off as a live host would, and captured outgoing email to a file. I backed up wp-config.php, the theme’s functions.php and the database first, and restored all three exactly afterwards (checksums matched).

What I broke	Front end	wp-admin	Email	What fixed it
Plugin calling a function that does not exist	HTTP 500, “critical error” message	HTTP 500, “check your site admin email inbox”	Sent on the first wp-admin visit, not on the front-end visit	Deactivate in recovery mode; separately, renaming the folder
Syntax error in the theme’s functions.php	HTTP 500, “critical error” message	HTTP 500, “check your site admin email inbox”	None: the one-per-day limit was already used	Restoring the original file
Memory: host limit 32M, so WordPress ran at its 40M default	HTTP 500, blank, 0 bytes	HTTP 500, blank, 0 bytes	None	WP_MEMORY_LIMIT set to 256M
Fatal error in a must-use plugin	HTTP 500, “critical error” message	HTTP 500, same plain message	None	Removing the file
Same, with WP_DISABLE_FATAL_ERROR_HANDLER on	HTTP 500, blank, 0 bytes	Not tested	None	Removing the file

Memory crashes can still give you a real WordPress white screen. The log showed memory running out inside UpdraftPlus, then again inside WordPress’s translation code while it built the error page, so the visitor got an empty response. If you get a WordPress blank page rather than the critical error message, think memory first.

The plugin in the memory error was not the cause. UpdraftPlus was simply loading when the 40 MB ran out. Deactivating it would have hidden the problem, not fixed it.

Must-use plugins get no protection. WordPress loads the mu-plugins folder before it starts recovery mode, so a crash there sent no email and gave even the admin the plain message. WP-CLI with --skip-plugins crashed as well, and the WP-CLI docs confirm that mu-plugins are still loaded with that flag. Hosts and agencies often put code there, so check that folder when the usual steps find nothing.

Why didn’t I get the recovery mode email?

Usually because the crash only happened on the front end. WordPress sends the email only when the fatal error hits what it calls a protected endpoint: wp-admin, the login page, or certain admin Ajax actions. In my test, loading the home page sent nothing, and the first wp-admin visit sent the email straight away. Other reasons, all from WordPress core:

• One email per day. The rate limit defaults to one day. In my test, the theme error caught less than two minutes after the plugin error sent no second email.
• Wrong address. It goes to the admin email in Settings > General, unless a RECOVERY_MODE_EMAIL constant in wp-config.php names another address.
• The site cannot send mail. Many hosts block or junk WordPress’s default mail. An SMTP plugin fixes that for next time.
• The error is not from a plugin or theme. Must-use plugins and multisite networks do not get the email path, and my memory test sent no email either.
• The handler is switched off. WP_DISABLE_FATAL_ERROR_HANDLER set to true turns the whole feature off. The wp-config handbook describes it as a development setting, used so that WP_DEBUG_DISPLAY can print errors. If you find it on a live site, remove it.

The link also works only once: opening it a second time showed a normal login form.

How do you stop it happening again?

A WordPress white screen usually follows a change: a plugin update, a theme edit or a PHP upgrade by your host. Three habits prevent most of them:

• Test updates on a staging copy first, and update one plugin at a time on the live site so you know which one broke it.
• Keep automatic off-site backups, and test a restore once.
• Never edit functions.php in the theme editor on a live site. Use a child theme and edit over SFTP so you can undo it.

The same habits are most of what securing a WordPress site involves. If you would rather hand them off, tested updates, backups and uptime checks are what my WordPress maintenance service covers, and my breakdown of WordPress maintenance costs shows what that should cost.

Frequently asked questions

How do I fix the white screen of death in WordPress?

Check the admin email for a recovery link first. If there is none, turn on WP_DEBUG_LOG, reload the page and read wp-content/debug.log to find the file that crashed. Then deactivate that plugin by renaming its folder, restore the theme file you edited, or raise the memory limit if the log mentions memory. Restore a backup only if nothing else names a cause.

Can the WordPress white screen of death be fixed?

Yes, almost always, and usually without losing content, because the crash is in code rather than in your posts or database. Once you know which plugin, theme file or setting caused it, switching that off restores the site. In my tests, every failure was fixed by one change: deactivating a plugin, restoring or removing a file, or raising the memory limit.

What usually triggers a WordPress white screen?

A PHP fatal error that stops WordPress before it can finish the page. The usual sources are a plugin update with a bug or a PHP version clash, a syntax error in the theme’s functions.php, PHP running out of memory, or custom code in the mu-plugins folder.

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

It is the message WordPress 5.2 and later shows instead of a blank page when a fatal PHP error happens. It means the same thing as the WordPress white screen of death. If the error came from a plugin or theme and hit wp-admin or the login page, WordPress also emails the admin address a recovery mode link that lets you log in and deactivate it.

How do I fix a WordPress white screen without dashboard access?

Use your host’s file manager or SFTP. Rename the folder of the plugin named in debug.log, or rename the whole plugins folder to switch everything off at once. For a theme error, restore the edited file or rename the theme’s folder. With SSH, WP-CLI commands run with the skip-plugins or skip-themes flags do the same job.

Sources

• Fatal Error Recovery Mode in 5.2, Make WordPress Core, make.wordpress.org, retrieved 2026-10-14.
• Debugging in WordPress, Advanced Administration Handbook, WordPress.org, developer.wordpress.org, retrieved 2026-10-14.
• Editing wp-config.php, Fatal Error Handler section, WordPress.org, developer.wordpress.org, retrieved 2026-10-14.
• is_protected_endpoint() and recovery_mode_email_rate_limit, WordPress Code Reference, developer.wordpress.org and developer.wordpress.org, retrieved 2026-10-14.
• WordPress core 7.1.2 source: class-wp-fatal-error-handler.php, class-wp-recovery-mode.php, class-wp-recovery-mode-email-service.php, load.php, wp-settings.php, theme.php, default-constants.php, read 2026-10-14.
• WP-CLI global parameters (Config), WP-CLI Handbook, make.wordpress.org, and wp plugin deactivate, developer.wordpress.org, retrieved 2026-10-14.
• Runtime Configuration (display_errors, log_errors), PHP Manual, php.net, retrieved 2026-10-14.
• Tests on a local WordPress 7.1.2 install with PHP 8.2.12 and UpdraftPlus 1.26.8, by Mohammad Humza, 2026-10-14.