There has been a critical error on this website: how to fix the WordPress fatal error screen

Your site shows a near-blank page with one short sentence: "There has been a critical error on this website. Please check your site admin email inbox for instructions." The HTTP response is 500. Visitors see the same message you see. Sometimes a refresh recovers it for one request. More often the site is fully down until you intervene.

What this error actually means

The exact text comes from WP_Fatal_Error_Handler, a class WordPress has shipped since version 5.2. It catches five categories of PHP fatal errors during a request: E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR, and E_RECOVERABLE_ERROR. When it catches one, it stops the response, returns HTTP 500, and renders the critical error screen instead of whatever the visitor was supposed to see.

In plain language: a PHP file in WordPress core, in a plugin, or in your theme tried to run code that PHP refused to execute. The script died mid-request. WordPress could not produce HTML, so it showed the fallback message and asked you to check your email.

This screen replaced the older blank "white screen" behavior. Before WordPress 5.2, the same fatal would simply render nothing at all and you had to guess what happened. If you still see a fully blank page (no message, no headers, just white), the fatal error handler did not run, and you should follow the diagnosis steps in White Screen of Death in WordPress instead. The fixes overlap, but the diagnosis path is different.

Common causes, ordered by likelihood

After dozens of these on managed sites, the order is consistent:

1. A PHP fatal in a plugin. By far the most common. A plugin update introduced a bug, two plugins call the same function, or a plugin uses a PHP feature your server does not have. The fatal happens during plugin load (plugins_loaded), so the entire site goes down, not just the plugin's own pages.
2. A PHP version mismatch. A plugin or theme requires PHP 8.1 or higher, but the server is on PHP 7.4. Or the inverse: an old plugin uses a PHP 5 idiom that PHP 8.2 removed. WordPress itself recommends PHP 8.3 or greater per the official requirements page, and many plugins now require at least PHP 8.0.
3. A PHP fatal in the active theme. Less common than plugins, more common after a theme update or after manual edits to functions.php. Often a parse error from a missing semicolon or bracket.
4. The PHP memory limit was hit. WordPress trips a fatal when a script tries to allocate more memory than the server allows. This shows up in the debug log as Allowed memory size of N bytes exhausted.
5. The database connection died mid-request. If MySQL or MariaDB drops the connection partway through page load, some WordPress operations throw a recoverable fatal that the handler turns into the critical error screen. This is rarer and usually a symptom of host-side trouble rather than something in your site.

The diagnosis steps below tell you which one applies before you start changing files.

Step 1: Check the recovery email first

WordPress sends an email to the site admin address whenever the fatal error handler catches a fatal during a normal page load. The email contains a one-time link that loads the site in recovery mode, which is a special session where the offending plugin or theme is paused for you (the admin) only. Visitors still see the critical error, but you can log in to wp-admin and fix the problem from a working dashboard.

What to do:

1. Open the inbox of the address tied to your WordPress admin user. Check spam too. If the site uses a separate admin email constant (RECOVERY_MODE_EMAIL in wp-config.php), check that inbox instead.
2. Look for the subject "[your site name] Your Site is Experiencing a Technical Issue". That string comes straight from the WP_Recovery_Mode_Email_Service class. The body names which plugin or theme caused the fatal and includes a recovery link.
3. Click the recovery link. It logs you into wp-admin in recovery mode. WordPress has paused the broken extension for your session. Go to Plugins (or Appearance > Themes if it was a theme) and either deactivate the offender, update it to a version that fixes the bug, or replace it.
4. Log out. That ends recovery mode. WordPress will not auto-reactivate the extension you paused. You decide when it goes back on.

The recovery link is rate-limited. By default, recovery_mode_email_rate_limit is set to one day, which means a fresh email is only sent at most once every 24 hours. If you missed the email, you have to wait or trigger the fatal again from a clean state. The link itself stays valid for at least the same window.

You will know it worked when the site loads normally for visitors and the fatal error screen is gone. Confirm by opening the site in a private browser window.

No email arrived? Three reasons happen most often:

• Your hosting's outbound mail is broken and WordPress emails never deliver. This is its own problem and worth fixing separately. See why WordPress is not sending email.
• The admin email in Settings > General points to an inbox you no longer monitor.
• The fatal happens so early in the request lifecycle (before plugins load) that the handler can never run. In this case, jump straight to step 2.

Step 2: Read the debug log

If the recovery email was no help, turn on debug logging and let WordPress tell you exactly what broke and where.

Connect via SFTP or your hosting file manager and edit wp-config.php in the WordPress root. Find this block:

define('WP_DEBUG', false);

Replace it with the canonical safe debug configuration from the WordPress debug documentation:

// Enable debug mode
define('WP_DEBUG', true);
// Write errors to wp-content/debug.log instead of the screen
define('WP_DEBUG_LOG', true);
// Hide errors from visitors
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Save, then reload the broken page once. Open wp-content/debug.log (it is created on the first error). The last entries describe the fatal that triggered the critical error screen. A typical entry looks like:

[07-Apr-2026 09:14:22 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/plugins/some-plugin/render.php on line 87

Three things in that line tell you almost everything:

• PHP Fatal error: Uncaught Error: Call to undefined function get_field() means a plugin called a function that does not exist. Usually because Advanced Custom Fields (or another helper plugin) was deactivated.
• /wp-content/plugins/some-plugin/render.php is the source file. The folder name (some-plugin) is the plugin to suspect.
• line 87 is the exact location to look at if you want to inspect.

A parse error looks slightly different. Anything that starts with Parse error: syntax error, unexpected ... is a malformed PHP file, almost always from a manual edit. See syntax error, unexpected: how to fix a PHP parse error in WordPress for the focused fix.

You will know debug logging worked when wp-content/debug.log exists and contains a PHP Fatal error line dated to your most recent failed page load. Set WP_DEBUG back to false once you have your answer. Live sites should never run with debug on.

Step 3: Apply the targeted fix

Now that you know which file and which extension caused the fatal, the fix lines up with the cause:

Plugin fatal

If the log points at /wp-content/plugins/some-plugin/, deactivate that plugin. From wp-admin go to Plugins and click Deactivate. If you cannot reach wp-admin, deactivate via SFTP: rename the plugin's folder, for example from some-plugin to some-plugin.off. WordPress can no longer find it and treats it as deactivated.

Reload the site. You will know it worked when the site renders normally and the debug log stops growing. Then choose one of three follow-ups:

• Update the plugin if a newer version exists that fixes the bug.
• Replace it with an alternative that does not depend on a missing helper.
• Contact the plugin author with the exact debug log line, especially for paid plugins where you have a support entitlement.

Theme fatal

If the log points at /wp-content/themes/yourtheme/, force WordPress to fall back to a default theme. Via SFTP, rename the active theme's folder (yourtheme to yourtheme.off). If a default theme like Twenty Twenty-Four exists in wp-content/themes/, WordPress switches to it automatically. If no other theme is present, download Twenty Twenty-Four from wordpress.org/themes and upload it before renaming the broken one.

You will know it worked when the site loads with the default theme's design. Then either repair the original theme (often a single bad edit in functions.php) or move to a theme that is actively maintained.

PHP version mismatch

If the log mentions things like Cannot use ... as ..., Unsupported declare, or any PHP error tied to a language feature, the PHP version on the server does not match what the plugin or theme expects. Check your hosting control panel for Select PHP Version or its equivalent. WordPress recommends PHP 8.3 or greater, and most modern plugins now require at least PHP 8.0. If you just upgraded PHP and the site broke, downgrade temporarily to confirm. If you are still on PHP 7.x, upgrade.

You will know it worked when the site loads after the version change and the same fatal does not reappear in the debug log. Be aware that flipping PHP versions can expose other compatibility problems, so only do this on a staging copy first if you have one.

Memory exhaustion

If the debug log says Allowed memory size of N bytes exhausted, the script ran out of memory rather than logically crashing. The targeted fix is documented in detail in allowed memory size exhausted in WordPress. The short version: raise WP_MEMORY_LIMIT in wp-config.php, or raise the underlying PHP memory_limit if your host blocks the WordPress override.

You will know it worked when the same page loads to completion and the memory line stops appearing in the debug log.

Database connection lost

If the log says something like MySQL server has gone away, the connection between PHP and the database died mid-request. Sometimes this is a one-off. If it is consistent, it is a host-side problem, not a site problem, and the fix is on your hosting account. See error establishing a database connection in WordPress for the diagnostic path.

When to escalate

If none of the above resolves it, or if you would rather not change files yourself, hand the problem to your host or a WordPress specialist with this checklist already prepared. Every minute they save on collecting context is a minute closer to your site being back.

Collect before you ask:

• The exact error message you see in the browser, copied verbatim.
• The HTTP status code (open the browser's Network tab and reload; the failing request will show 500).
• The PHP version your site runs (visible in your hosting panel under PHP settings).
• The WordPress version (from the recovery email if you got one, or from wp-includes/version.php).
• The full last 30 lines of wp-content/debug.log after triggering the fatal once.
• A list of what you tried, in order, and what changed each time.
• Any change you made in the 24 hours before the site broke: a plugin update, a PHP upgrade, a custom code edit, a theme switch.

A good host or specialist can usually resolve a critical error in under an hour with that bundle. Without it, the same job takes three.

How to prevent the next critical error

You cannot eliminate fatals, but you can keep them rare and survivable:

• Test plugin and theme updates on a staging copy first. Most managed hosts include staging. If yours does not, even a simple local copy is enough to catch the obvious fatals before they reach production.
• Take a backup before every update. Then restoring takes 60 seconds. Without one, restoring takes hours. If you do not have a backup strategy yet, see WordPress backup strategy.
• Keep the admin email on an inbox you actually read. The recovery email is your fastest path back in, and it is worth nothing if it lands somewhere you do not check.
• Stay within one major PHP version of what your plugins require. A plugin written for PHP 7.4 will break on PHP 8.3 in ways that look like random fatals.
• Run no more plugins than you need. Each one is a potential source of the next fatal, and the average WordPress site has many it does not actively use.

For a broader prevention approach covering file permissions, DISALLOW_FILE_EDIT, and update automation, see the WordPress security hardening checklist.