WordPress white screen of death: read the error first

In short

Check the site admin email inbox: WordPress sends a link there that opens the dashboard despite the error.
Without that email, turn on the debug log in wp-config.php and reload the broken page.
Read the PHP Fatal error line in wp-content/debug.log: the file path names the plugin or theme at fault.
Switch off that one component, by renaming its folder or with WP-CLI.
If the message mentions memory or the PHP version, the fix belongs in the site configuration or with your host.
Once the site is back, turn the log off and delete debug.log.

"Critical error" or white screen: the same failure

A blank page is almost always a PHP fatal error: a file on the site asked for something impossible, and execution stopped before anything was displayed. Since WordPress 5.2, WordPress catches these errors: instead of a blank page it shows "There has been a critical error on this website." and emails the site admin address.

The page stays completely white in a few cases: an older WordPress version, an error that happens before that safety net loads, the WP_DISABLE_FATAL_ERROR_HANDLER constant set to true, or a caching plugin serving a blank page it stored during the failure. The method below works for all of them.

Three moves can wait until you have read the error: reinstalling WordPress, deleting plugins, restoring an old backup. Each can wipe settings or recent data, while the error message usually tells you exactly which component to switch off, with nothing lost.

The shortcut: recovery mode

When WordPress catches the error, it emails the site admin address a message titled "[Site name] Your Site is Experiencing a Technical Issue". It names the plugin or theme at fault and contains a link that opens the dashboard in recovery mode.

In this mode, the faulty component is paused for you alone: your visitors still see the error.
From Plugins or Appearance > Themes, deactivate the component named in the email, then click "Exit Recovery Mode" in the admin bar.
The link stays valid for 24 hours, and WordPress sends at most one such email a day. If it does not arrive, check the spam folder, then move on to the next method.

Read the error: the debug log

Connect to the site over SFTP or through your host’s file manager, open wp-config.php at the root, and replace the line define( 'WP_DEBUG', false ); with these four lines:

wp-config.php

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

They go above the /* That's all, stop editing! Happy publishing. */ line. Reload the broken page, then open wp-content/debug.log. Setting WP_DEBUG_DISPLAY to false keeps the messages in the file and off the page your visitors see.

If debug.log stays empty or does not appear, PHP logged the error itself: look for an error_log file at the site root or in wp-admin, or for the error logs section of your hosting control panel.

What the message says, and the fix that goes with it

A fatal error fits on one line: the error type, its description, then in followed by the full file path and the line number. The path is the most useful part: wp-content/plugins/name/ points to a plugin, wp-content/themes/name/ to a theme.

The message contains	What it means	The fix
`Call to undefined function` or `Class "…" not found`, in `wp-content/plugins/plugin-name/`	The plugin calls code that is missing: an incomplete update, a plugin it depends on switched off, or a PHP version it does not support.	Deactivate that plugin, then reinstall or update it.
`Allowed memory size of 268435456 bytes exhausted`	The script went over the memory PHP allows, here 268,435,456 bytes, or 256 MB.	Raise `WP_MEMORY_LIMIT` in `wp-config.php`, within the limit your host sets, then find out what uses that much.
`PHP Parse error: syntax error, unexpected`, in `functions.php on line 42`	A syntax mistake in a file, very often after a manual edit in the theme file editor.	Fix the line shown, or put the previous version of the file back.
`Uncaught TypeError` or `Uncaught ArgumentCountError`, after a PHP version change	A component written for an older PHP version, which the current version refuses to run.	Update the component. As a stopgap, switch back to the previous PHP version in your host’s panel while you replace it.
`Maximum execution time of 30 seconds exceeded`	A task ran longer than PHP allows (`max_execution_time`).	Identify the task (import, backup, image generation) and have the limit raised with your host if the task is legitimate.

wp-config.php, to raise the memory WordPress may use

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

Switch off the faulty component without the dashboard

Over SFTP or with the file manager

Rename the folder of the plugin named in the message, for example wp-content/plugins/plugin-name to plugin-name.off. WordPress no longer finds the plugin and stops loading it; its settings stay stored in the database, and WordPress deactivates it the next time the Plugins screen is opened.

For a theme, renaming its folder in wp-content/themes brings the dashboard back, but visitors see a blank page while no theme is active. Open Appearance > Themes straight away: WordPress notices the active theme is broken and reverts to an installed default theme.

With WP-CLI

Terminal, at the site root (the theme you activate must appear in wp theme list)

wp plugin list --status=active
wp plugin deactivate plugin-name
wp theme list
wp theme activate twentytwentyfive

The first command records which plugins are active, which is worth having before any bulk deactivation. If WP-CLI itself stops on the error, add --skip-plugins --skip-themes to the command so it starts without loading plugins or the theme. Plugins in wp-content/mu-plugins still load; if the error comes from one of them, rename its file.

When the message names no component, wp plugin deactivate --all switches every plugin off. If the site comes back, reactivate them one at a time, reloading the site in between: the last one reactivated before the error returns is the culprit.

Once the site is back

Set define( 'WP_DEBUG', false ); again and remove WP_DEBUG_LOG from wp-config.php.
Delete wp-content/debug.log: sitting in a web-accessible folder, anyone can read it, and it contains server paths.
Update or replace the component at fault, after reading its changelog.
Clear your caching plugin’s cache, and your host’s cache if it has one.
For next time: test updates on a copy of the site before applying them live.

A website whose updates are our job

With Serenity by Simafri, we create your professional website, host it, secure it and keep it up to date. You write to us, we take care of everything. Domain name and professional email included.

Discover Serenity by Simafri

Frequently asked questions

Why does my WordPress site say "There has been a critical error on this website"?

Because a PHP fatal error occurred, most often in a plugin or a theme. WordPress catches it, shows this message and emails the site admin address with a link to recovery mode. The debug log gives the details of the error and the file at fault.

I did not get the recovery mode email. What now?

Check the spam folder and the administration email address set under Settings > General. Without the email, turn on the debug log in wp-config.php, read the error in wp-content/debug.log, then switch off the faulty component by renaming its folder over SFTP.

Does renaming a plugin folder lose its settings?

Plugin settings are stored in the database, not in the plugin folder, so they stay. A renamed plugin shows as deactivated; restore its original folder name and reactivate it from the Plugins screen to get it back with its settings.

Why is only the dashboard showing a white screen?

The failing component may only load in the dashboard, or the dashboard needs more memory. WordPress applies WP_MAX_MEMORY_LIMIT to admin screens and WP_MEMORY_LIMIT to the public site. The debug log works the same way in both cases: load the failing admin page, then read debug.log.

WordPress white screen of death: read the error before you change anything