Fix “There Has Been a Critical Error” in WordPress

If WordPress shows “There has been a critical error on this website,” the problem is usually a PHP fatal error from a plugin, theme, or custom code. The safest fix is to identify the last change, recover access with plugins/themes disabled, and then restore the specific component that broke the site.

Start with a backup if you can still access the files or database. If the site is down and you are short on time, a free diagnosis or Emergency Rescue is often the fastest way to get a senior engineer on it without guessing.

What this message usually means

This warning is WordPress’s generic way of saying “something fatal happened before the page could finish loading.” In practice, that usually means PHP stopped because of a plugin conflict, theme issue, bad custom code, a failed update, or a server-side problem such as memory limits or a missing PHP extension.

Unlike a plain “500” error, this message is often friendlier because WordPress may email the site admin a recovery link. But that message is also frustratingly vague: it does not tell you exactly which file or plugin is broken unless you check the logs.

Common symptoms you may see

The critical error can show up in a few different ways:

• The front end shows the critical error message instead of your site.
• The wp-admin area is inaccessible or only partially loads.
• You receive an email from WordPress with a recovery mode link.
• The site works in some places but breaks on specific pages or after a recent update.
• The error appears only for logged-in users, only on mobile, or only after a form submits.

If the problem started right after an update, this guide pairs well with WordPress Site Broke After an Update? Here's What Happened and How to Fix It.

The most likely causes

Most critical errors come from one of these issues:

• A plugin update introduced a PHP fatal error.
• A theme file or child theme override has a syntax problem.
• Custom code added to functions.php, a snippet plugin, or mu-plugins is failing.
• The site is running on a PHP version that is too old or too new for one of its components.
• WordPress ran out of memory during a request.
• A corrupted plugin or theme file is missing a required class, function, or dependency.
• The site has been modified by malware or an unauthorized change.

If you are also seeing other strange behavior, such as admin lockouts or redirects, review Locked Out of WordPress Admin: Why It Happens and How to Fix It and WordPress Site Hacked? Here's How to Clean It Up — Safely.

Step 1: Back up before you change anything

If the site still gives you file or hosting access, make a full backup of both files and database before testing fixes. That way, if you disable the wrong plugin or edit the wrong file, you can restore the site quickly.

If you do not know how to back up safely, ask your host for a one-click snapshot or use your existing backup system. And if you want to make sure your backup is actually restorable, read The Backup Test Most WordPress Sites Never Do.

Step 2: Use WordPress recovery mode if the email arrived

When WordPress detects a fatal error, it may send an email to the admin address with a special recovery link. If you have that email, open it and use the link to log in safely.

Recovery mode can help because it disables the broken plugin or theme only for your session, letting you get into wp-admin and fix the root cause without taking the whole site offline.

If the email never arrived, check spam, hosting mail logs, and the admin email configured in WordPress. If your site’s mail delivery is unreliable, that is a separate issue, but it can block recovery notices from reaching you.

Step 3: Disable plugins the safest way

Plugins are the most common cause, so test them first. If you can reach wp-admin, go to Plugins and deactivate the most recently updated or installed plugin first. Refresh the site after each change.

If you cannot access wp-admin, use one of these safer methods:

• Rename the plugins folder via SFTP or file manager, which disables all plugins at once.
• Rename one plugin folder at a time inside wp-content/plugins to isolate the bad one.
• Use recovery mode if WordPress provided the link.

Once the site loads again, reactivate plugins one by one. When the error returns, the last plugin activated is your likely culprit.

Step 4: Switch to a default theme

If disabling plugins does not solve it, the theme is next. A broken theme file, a bad child theme override, or custom code in the theme can trigger the critical error.

To test this, temporarily switch to a default WordPress theme such as Twenty Twenty-Four. If you cannot enter wp-admin, rename the active theme folder over SFTP so WordPress falls back to another installed theme.

If the site comes back after the theme switch, compare recent theme changes, especially custom template files, functions.php, and any code added by a page builder or snippets plugin.

Step 5: Check the error logs for the exact file

Once the site is accessible enough to investigate, check the PHP error log and WordPress debug log. These logs usually point to the exact file and line number that failed.

On many hosts, you can find logs in the hosting control panel. If not, you can temporarily enable debugging by adding or adjusting these settings in wp-config.php:

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

After reproducing the problem, review wp-content/debug.log. Look for the first fatal error, not just the last line. The log often names the plugin, theme file, or function causing the crash.

Step 6: Check PHP version and memory

A site can break if the host changes PHP versions or if a plugin requires a version your site is not ready for. Likewise, low memory can cause fatal errors during plugin loading or complex page rendering.

Ask your host which PHP version is active and compare it with your theme and plugins. If the error started after a hosting-side change, this is a strong clue.

You can also increase the WordPress memory limit in wp-config.php, but treat that as a diagnostic step, not the final fix:

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

If raising memory makes the error disappear, you still need to find out why the site needs so much memory. That may point to a slow query, an oversized page builder layout, or a plugin looping through too much data.

Step 7: Reinstall the broken component

If the logs point to a specific plugin or theme, reinstall it from a clean source. Corrupted files can cause fatal errors even when the version itself is fine.

Only replace code from trusted sources. Avoid downloading “fixed” copies from random sites, and never install nulled plugins or themes just to get the site back online. If you are unsure whether code has been tampered with, treat it as a security issue as well as a stability issue.

Step 8: Rule out malware or tampering

If the error appeared with no recent change, or if plugin and theme tests do not make sense, consider malware or unauthorized file edits. A malicious change can cause fatal errors by injecting broken code into core files, plugins, themes, or mu-plugins.

Look for unexpected admin users, unfamiliar files in wp-content, recently modified PHP files, and redirects or spam content elsewhere on the site. If the evidence points that way, move carefully and do not overwrite suspicious files until you have copied them for analysis.

For a deeper cleanup path, use WordPress Site Hacked? Here's How to Clean It Up — Safely.

What not to do

When the site is down, it is tempting to make random changes until something works. That usually makes recovery slower. Avoid these common mistakes:

• Deleting plugins or themes before taking a backup.
• Editing multiple files at once without keeping notes.
• Changing PHP versions repeatedly without checking logs.
• Turning on debug display publicly on a live site.
• Replacing core files from untrusted downloads.

How to prevent this error from coming back

Once the site is fixed, a little prevention goes a long way:

• Update plugins, themes, and WordPress in a controlled way, one change at a time.
• Keep a tested backup and know how to restore it.
• Avoid piling custom code into theme files when a small mu-plugin or snippets system is better documented.
• Remove inactive plugins and old themes you no longer use.
• Check compatibility before changing PHP versions.
• Monitor uptime and error logs so you catch failures early.

If update-related outages are common for your site, a managed maintenance process can prevent a lot of emergency work. Mend’s Care Plan covers updates, backups, security, and uptime monitoring so issues are caught before visitors do.

When to call a professional

Call for help if the site is live, you do not have a safe backup, the error returns after plugin and theme testing, or the logs point to code you do not understand. You should also escalate if the site is revenue-critical and every minute offline matters.

This is exactly the kind of issue Mend handles every day. A senior engineer can trace the fatal error, fix it on a backup-first workflow, and send you a plain-English report of what broke and what changed. If you need that, start with a free diagnosis or go straight to Emergency Rescue if the site is down now.

If you prefer to connect the site securely without sharing passwords, use Connect your site securely through the free Mend Connect plugin.

Quick recap

The “There has been a critical error on this website” message usually means a fatal PHP problem, not a mysterious WordPress failure. The fastest safe path is: back up, use recovery mode if available, disable plugins, test the theme, check logs, and confirm whether PHP, memory, or malware is involved.

If you want a second set of eyes before making changes, Mend can diagnose it and take it from there.