How to Fix the WordPress Critical Error and White Screen

Q: Is it safe to enable WP_DEBUG on a live site?

Yes, as long as WP_DEBUG_DISPLAY is false and errors go only to the log file. Turn it off again once you have found the problem and delete or protect debug.log.

Your site suddenly shows There has been a critical error on this website., or just a blank white page, and wp-admin may be gone too. That message is WordPress catching a PHP fatal error. This guide shows you how to find the exact error line in a few minutes and fix the WordPress critical error without making things worse on a live site.

Quick fix

In most cases a plugin, theme or PHP version change caused the fatal error. Do this first:

Check the site admin email inbox for a message titled “Your Site is Experiencing a Technical Issue”. It names the plugin or theme that failed and includes a recovery mode link that lets you log in with that extension paused.
If there is no email, turn on logging (not on-screen errors) in wp-config.php, above the line that says /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // never print errors to visitors
@ini_set( 'display_errors', 0 );

Reload the broken page, then open wp-content/debug.log and look for the last line starting with PHP Fatal error. The file path in that line tells you which plugin or theme is responsible.
Deactivate that plugin (rename its folder over SFTP or run wp plugin deactivate plugin-slug) and the site should come back.
Set WP_DEBUG back to false when you are done.

Common causes, most likely first

1. A plugin update or a new plugin

This is the usual suspect. A plugin calls a function that no longer exists, clashes with another plugin declaring the same class, or requires a newer PHP version than your server runs. If you cannot reach wp-admin, disable every plugin at once by renaming the folder:

cd /path/to/site/wp-content
mv plugins plugins.off
mkdir plugins
# site loads? then restore and rename plugins one by one
rm -r plugins && mv plugins.off plugins

With SSH and WP-CLI it is cleaner, because you can skip loading the broken code entirely:

wp plugin list --status=active --skip-plugins --skip-themes
wp plugin deactivate --all --skip-plugins --skip-themes
wp plugin activate woocommerce --skip-plugins --skip-themes  # re-enable one at a time

Once you visit the Plugins screen, WordPress marks any plugin it cannot find as deactivated, so note which ones were active before you start.

2. The theme, often `functions.php`

A missing semicolon or bracket added through the theme editor produces PHP Parse error: syntax error, unexpected ... and takes the whole site down. Open the file and line from the log, fix it, or revert to the last known good version. To rule the theme out entirely, switch to a default theme:

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

Without WP-CLI, rename the active theme’s folder in wp-content/themes/. WordPress falls back to a default theme if one is installed.

3. A PHP version upgrade

This is the one people miss, because nobody touched WordPress. Your host moves you from PHP 7.4 to 8.x, and code that only raised deprecation notices or warnings now throws fatal errors. Typical PHP 8 breakages in older themes and plugins:

Call to undefined function create_function() or each(): both were removed in PHP 8.0.
count(): Argument #1 ($value) must be of type Countable|array, null given: calling count() on null or a string is a TypeError in PHP 8.
Unsupported operand types: string + int: arithmetic on arrays or invalid types now throws.
Curly-brace string offsets like $str{0}, which are now a parse error.

The short-term fix is to switch the site back to the previous PHP version in your hosting panel. The real fix is to update or replace the offending code. A guarded version of the count() case looks like this:

$items = get_post_meta( $post_id, 'items', true );
$total = is_countable( $items ) ? count( $items ) : 0;

If you maintain your own code, my guide to modern PHP 8 features covers the typed, stricter style that avoids these errors.

4. PHP memory limit

The log shows Allowed memory size of 134217728 bytes exhausted. Raise the WordPress limit in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );     // front end
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // admin and heavy tasks

WordPress cannot raise memory above the server’s memory_limit in php.ini, so you may need to change that with your host. Treat a higher limit as a stopgap. If one request needs that much memory, a plugin is usually loading far more data than it should.

5. Corrupted core files or a failed update

An update interrupted by a timeout can leave a .maintenance file behind or core files half-written. Delete .maintenance from the site root, then replace core files without touching content:

wp core verify-checksums
wp core download --force --skip-content

Step-by-step diagnosis

Read the recovery email if WordPress sent one. It includes the error message and file.
Check the server’s PHP error log. On cPanel hosts this is often an error_log file in the site root or in /wp-admin/; on Nginx or PHP-FPM stacks look in your host’s log panel or under /var/log/. If PHP failed before WordPress loaded, only this log has the error.
Enable WP_DEBUG_LOG as shown above, reproduce the error, and read the last fatal entry: tail -n 50 wp-content/debug.log.
Map the file path to an extension. wp-content/plugins/foo/ means plugin foo; wp-content/themes/bar/ means the theme.
Isolate by deactivating that plugin or switching theme. If the path points to core in wp-includes, the cause is usually still an extension passing bad data, so check the stack trace below the error line.
Check the PHP version in your hosting panel or under Tools, Site Health, Info, Server (the CLI can run a different PHP binary from the web server), and compare with the plugin’s “Requires PHP” value.
Clean up. Turn debugging off and delete or protect debug.log, because by default it sits in a publicly reachable folder.

Why not WP_DEBUG_DISPLAY on production? It prints file paths, query fragments and sometimes data to every visitor and search crawler. Logging to a file gives you the same information privately. You can also point the log outside the web root by passing a path instead of true: define( 'WP_DEBUG_LOG', '/home/user/logs/wp-debug.log' );.

Prevention checklist

Use a staging site. Apply plugin, theme, core and PHP updates there first and click through the critical pages.
Keep the theme and custom plugins in version control so a broken functions.php is a git revert away. Disable the built-in file editor with define( 'DISALLOW_FILE_EDIT', true );.
Update in a sensible order: take a backup, update plugins and themes, then WordPress core, and change the PHP version last, one change at a time so you know what broke.
Check “Requires PHP” and “Tested up to” on each plugin before a PHP upgrade, and remove abandoned plugins.
Keep off-site backups you have actually tried restoring.
Monitor uptime so you find out before your visitors do. My WordPress security hardening checklist covers backups, file permissions and editor lockdown in more detail.

Key takeaways

The critical error message is WordPress catching a PHP fatal error. The real error is always in a log.
Use WP_DEBUG_LOG with WP_DEBUG_DISPLAY set to false; never show errors publicly on production.
The file path in the fatal error tells you which plugin or theme to disable.
Renaming the plugins folder or wp plugin deactivate --all --skip-plugins gets you back in when wp-admin is down.
PHP 8 upgrades turn old warnings into fatal errors, so test PHP changes on staging first.

Frequently asked questions

What causes “There has been a critical error on this website” in WordPress?

It appears when PHP hits a fatal error while WordPress is loading, most often from a plugin or theme update, a syntax error in functions.php, a PHP version upgrade, or running out of memory. The exact cause is written to debug.log or the server error log.

How do I fix a WordPress critical error without admin access?

Use the recovery mode link from the admin email, or connect over SFTP and rename wp-content/plugins to disable all plugins at once. With SSH you can run wp plugin deactivate --all --skip-plugins --skip-themes instead.

Is it safe to enable WP_DEBUG on a live site?

Yes, as long as WP_DEBUG_DISPLAY is false and errors go only to the log file. Turn it off again once you have found the problem and delete or protect debug.log.

I didn’t receive the recovery mode email. What now?

The email goes to the address in Settings, General, and many servers fail to send PHP mail, so it often never arrives. Go straight to the logs and disable the plugin or theme manually instead.

If your site is still down or the log points somewhere you are not comfortable editing, get in touch and I can track down the fatal error and get your WordPress site back online.

#Debugging
#PHP 8
#Troubleshooting
#WordPress
#WP-CLI