Critical Error in WordPress: Fix It Fast Without Losing Data

The "There has been a critical error on this website" message means PHP crashed hard enough that WordPress couldn't finish loading — it's the modern replacement for the old White Screen of Death. The fix almost always comes down to one of four culprits: a broken plugin, a broken theme, a PHP version mismatch, or a memory limit your server can no longer meet. Work through the steps below from safest to most invasive and you'll have the site back up without touching the database or losing any content.

What You're Seeing — and What It Means

WordPress 5.2 introduced a built-in fatal-error handler. When PHP throws an unrecoverable exception, instead of a blank screen you now get a short message in the browser and, critically, an automatic email to the admin address on file. That email contains the actual error message and the file that caused it. Check your inbox first — it saves you from guessing.

The front end of your site is down. Depending on where PHP crashed, your wp-admin may also be inaccessible, or it may still load with a banner warning at the top. Either way, real visitors are seeing the error right now, so speed matters.

Before You Touch Anything: Take a Backup

If your host provides server-level snapshots (cPanel, Kinsta, WP Engine, etc.), create one now. If you have a backup plugin and can still reach wp-admin, run a manual backup. The steps below are non-destructive, but the five minutes spent on a backup removes all risk.

Step 1 — Read the Recovery Email

WordPress sends the email to the address in Settings → General → Administration Email Address. Open it. It will name the exact PHP file that crashed and include the error type (most commonly Fatal error, Parse error, or Call to undefined function). The file path tells you which plugin or theme owns the broken code — look for /wp-content/plugins/plugin-name/ or /wp-content/themes/theme-name/ in the path.

If the email never arrived, check your spam folder, then move to Step 2 and enable debug logging manually.

Step 2 — Use WordPress's Built-In Recovery Mode

The recovery email also contains a unique recovery-mode link. Click it. This logs you into wp-admin with the broken plugin or theme temporarily paused, so you can deactivate it properly without needing FTP. This is the fastest safe path when the email arrived and the link still works (links expire after one hour by default).

Inside recovery mode, go to Plugins, find the plugin flagged in the email, and click Deactivate. Reload the front end. If the site loads, you've found the culprit — skip to the "After You Fix It" section below.

Step 3 — Enable Debug Logging via wp-config.php

If recovery mode isn't available, you need to see the raw PHP error. Add these three lines to wp-config.php (via your host's file manager or FTP) above the line that reads /* That's all, stop editing! */:

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

Setting WP_DEBUG_DISPLAY to false keeps errors out of the browser (away from visitors) and writes them to /wp-content/debug.log instead. Reload the broken page, then open that file. The last entry is almost always the crash that took the site down.

The log entry will look something like:

[14-Jun-2025 09:22:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function some_plugin_function() in /home/user/public_html/wp-content/plugins/some-plugin/some-file.php:142

That file path tells you exactly which plugin to target. Once you've identified the cause, remove those three debug lines from wp-config.php — never leave WP_DEBUG on in production.

Step 4 — Deactivate Plugins via the Database or File Rename

If wp-admin is completely inaccessible, you have two reliable options.

Option A: Rename the Plugin Folder (FTP or File Manager)

Navigate to /wp-content/plugins/ and rename the specific plugin's folder — for example, change some-plugin to some-plugin-DISABLED. WordPress will detect the folder is missing and auto-deactivate that plugin the next time it loads. Reload your site. If it comes back, you've confirmed the culprit.

If the debug log pointed at a theme file instead, rename the active theme's folder inside /wp-content/themes/. WordPress will fall back to its default bundled theme (Twenty Twenty-Four or similar), which at minimum lets you back into wp-admin to fix things properly.

Option B: Deactivate All Plugins via the Database

Use phpMyAdmin (available in most cPanel hosts) or your host's database tool. Open the wp_options table, find the row where option_name is active_plugins, and set its option_value to a:0:{}. That serialized value means "zero active plugins." Save and reload your site. If it comes back, reactivate plugins one at a time from wp-admin to find the bad one.

Note: Your table prefix may not be wp_ — check your wp-config.php for the $table_prefix value.

Step 5 — Check Your PHP Version

A surprisingly common trigger: your host silently upgraded PHP (or you changed it yourself) and a plugin or theme hasn't been updated to support the new version. In wp-admin under Tools → Site Health → Info → Server you can see the current PHP version. Cross-reference it with the plugin's "Tested up to" listing on wordpress.org, or look for a minimum PHP version in its readme.

If a version mismatch is the culprit, you have two options: roll back PHP in your hosting control panel (most hosts allow this), or update the plugin/theme to a version that supports your current PHP. Rolling back PHP is the faster emergency fix; updating the software is the correct long-term answer.

Step 6 — Raise the PHP Memory Limit

A second common cause the debug log will flag with Fatal error: Allowed memory size of X bytes exhausted. WordPress defaults to 40 MB; most sites need at least 256 MB. Add this to wp-config.php above the stop-editing line:

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

If that alone doesn't work, you may also need to raise the server-level memory limit in your host's PHP settings or via a .htaccess directive (php_value memory_limit 256M). Some managed hosts restrict this — contact their support if the setting doesn't stick.

After You Fix It: Don't Just Walk Away

Once the site is back up, do three things:

1. Remove debug lines from wp-config.php if you added them.
2. Update or replace the offending plugin/theme. If a newer version of the plugin is available, update it and test before reactivating. If there's no fix available, find an alternative — a plugin that crashes your site is a liability.
3. Check for other outdated software. Go to Dashboard → Updates and clear the queue. One vulnerable or incompatible plugin often signals others are overdue.

How to Prevent This From Happening Again

Most critical errors are caused by updates — a plugin update that introduced a bug, or a PHP upgrade the plugin wasn't ready for. A few habits eliminate the majority of these incidents:

• Stage before you update. Run updates on a staging copy first. Many hosts provide one-click staging environments.
• Update one thing at a time. Batch updates make it impossible to know which change broke the site.
• Keep automated backups running daily. If a crash does happen, you want a recent restore point that predates it.
• Monitor uptime. You shouldn't be finding out about a critical error from a customer — an uptime monitor alerts you within a minute or two.

These are exactly the things covered under a managed maintenance plan. Mend's Care Plan handles managed updates, daily backups, security scanning, and uptime monitoring for $99/month — so a bad plugin update gets caught on staging rather than taken live.

When to Call a Professional

You should hand this off if:

• The debug log points to a core WordPress file (not a plugin or theme) — this can indicate a hacked or corrupted installation.
• You've deactivated everything and the error persists, which suggests a problem at the server or WordPress core level.
• The site runs WooCommerce or another revenue-critical application and every minute of downtime has a real cost.
• You're uncomfortable with FTP, phpMyAdmin, or editing wp-config.php.

If any of those apply, request a free Mend diagnosis — it triages the problem, tells you what broke and why, and quotes a flat price before any work begins. Most critical-error fixes land in the Quick Fix ($129) tier, and same-day turnaround is standard. If the site is completely down and revenue is at stake, the Emergency Rescue ($499) gets a senior engineer on it immediately.

For a deeper look at what's happening inside the PHP error itself, the guide at There Has Been a Critical Error: What It Means and How to Fix It goes into more detail on reading specific error types. And if your site came back up but now runs noticeably slower, it's worth reading WordPress Slow to Load? Diagnose It in the Right Order — a memory-limit increase sometimes masks a deeper performance problem.