WordPress Critical Error Screen

Learn what causes it, and how to fix it.

Published September 2, 2026.

Most articles on this error tell you to deactivate every plugin and switch themes until the screen goes away. That works eventually, but it is guessing. WordPress already recorded exactly what broke and where. Read that first.

What The Screen Means

“There has been a critical error on this website” is WordPress’s fatal error handler, added in 5.2. A PHP fatal error stopped the request before the page could render. Instead of a blank white page or a raw PHP error, WordPress catches it, writes it to the PHP error log, emails the site admin, and shows this generic message.

The screen itself tells you nothing about the cause. The error log does.

Check Error Log First

On a good host you can view the PHP error log from the hosting dashboard. Kinsta, WP Engine, and Cloudways all expose it; cPanel hosts usually have an “Errors” tool or an error_log file next to the site files. The error that triggered the screen will be in there, most likely at or near the top if the log is sorted newest first.

  1. Log in to your host and open the error log
  2. Look for lines containing PHP Fatal error or PHP Parse error
  3. Read the file path and line number on that line. If the path contains /wp-content/plugins/some-plugin/, that plugin is the cause. If it contains /wp-content/themes/your-theme/, the theme is

A fatal error line looks like this:

PHP Fatal error: Uncaught Error: Call to undefined function wc_get_order() in /www/site/public/wp-content/plugins/example-addon/includes/orders.php:42

Below it you will usually see a stack trace: a numbered list of the functions that were running when the error happened, from the most recent call back to the start of the request. You rarely need to read the whole thing. The first line names the file and line that failed, and the first plugin or theme path in the trace names the code responsible.

If the host does not expose a log, turn on WordPress debug logging in wp-config.php and reload the page once:

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

The error is written to wp-content/debug.log. Turn WP_DEBUG back off when you are done.

Check Admin Email

When the handler catches a fatal error, WordPress emails the address set in Settings > General with the subject “Your Site is Experiencing a Technical Issue.” The email names the plugin or theme it believes is responsible and includes a link that opens the dashboard in recovery mode, where that plugin or theme is paused for your session only.

Most of the time this email is a second notice of the same thing the log already told you. It is worth opening for two reasons:

  • It names the offending plugin or theme without you having to read a trace
  • The recovery mode link gets you into the dashboard when the error has also taken down wp-admin

The link expires after one day by default, and WordPress rate-limits the email to one per day, so if you miss it you may not get another right away. If no email arrives, the site may not be able to send mail at all, or the error happened early enough in the request that the handler never ran. Either way, the log is still there.

Repair The Source

Once the log or email has named the file, fix the thing that changed. In practice this error almost always follows a plugin update, a theme deploy, or a manual code edit.

Theme or custom code: if the error points at a file you or your team deployed, fix the syntax or logic error locally and redeploy. A missing semicolon, a call to a function from a plugin that is no longer active, or PHP syntax the server’s PHP version does not support are the usual suspects.

Plugin update: if the error points at a plugin that was just updated, roll it back.

  1. Find the previous version. For plugins on WordPress.org, open the plugin page, click Advanced, and download the prior version from the dropdown at the bottom
  2. Over SFTP, replace the folder in wp-content/plugins/ with the previous version
  3. If you do not have SFTP access, use the recovery mode link to reach the dashboard, delete the broken plugin, then upload the previous version through Plugins > Add New > Upload

With WP-CLI the rollback is one command:

wp plugin install example-addon --version=2.4.1 --force

Plugin conflict or PHP version: if nothing was updated, check whether the host changed the PHP version. Older plugins fail on PHP 8.x with errors like Uncaught TypeError or Call to undefined function create_function(). Rolling PHP back buys time; the real fix is replacing the plugin.

After the fix, reload the site. If it loads and you entered recovery mode, click Exit Recovery Mode in the admin bar.

If You Cannot Read The Log

Only after the above: rename wp-content/plugins to wp-content/plugins-off over SFTP. If the site loads, rename it back, then rename individual plugin folders one at a time until you find the one that breaks it. This is the method most guides lead with. It works, but it is slower than reading one line from a log.