How to Fix “There Has Been a Critical Error on This Website” (WordPress)

You’re minding your business, you update a plugin (or add a snippet), and suddenly your site throws the dreaded message:

“There has been a critical error on this website. Please check your site admin email inbox for instructions.”

This is **WordPress telling you that a fatal PHP error (or a similarly “hard stop” issue) occurred and it can’t safely finish loading your site.

The good news: in most cases, this is fixable in minutes—and you can usually recover without rebuilding anything.

This guide walks you through a practical, real-world workflow to get your site back online quickly, identify the exact cause, and prevent it from happening again.

What the “critical error” message actually means

A “critical error” usually points to one of these root causes:

A plugin conflict (very common after updates)
A theme conflict (especially after updating a theme or page builder)
A custom code mistake (functions.php, a snippet plugin, custom plugin, mu-plugin)
A server/PHP mismatch (PHP version incompatibility, disabled PHP extensions, low memory)
A corrupted file (core files, plugin files, theme files)
A security issue (malware altering files, injecting code)

WordPress introduced fatal error protection / Recovery Mode so admins can still access wp-admin even when the site crashes. (Make WordPress)

Before you touch anything: quick safety rules

If your site is down and revenue matters (commerce, leads, bookings), follow these rules:

Stop updating things. Don’t update additional plugins/themes “hoping it fixes it.”
Don’t start deleting random files. You can make the problem worse.
If possible, take a backup before you change files. Even a quick host snapshot helps.
Write down what changed last (plugin update, theme update, PHP version change, new snippet, etc.). That clue often solves the whole thing.

Step 1: Check your admin email for the Recovery Mode message

When WordPress detects a fatal error, it typically emails the site admin email with:

The file/plugin/theme that triggered the error (sometimes)
A Recovery Mode link (time-limited) (Make WordPress)

What to do

Search your inbox for “WordPress” + “critical error”
Click the Recovery Mode link and log in
In wp-admin, WordPress may show a banner telling you what broke and offer to disable the failing plugin/theme

If you don’t get the email

This is extremely common. Reasons include:

Your site’s email deliverability is broken (no SMTP, DNS not set, etc.)
The admin email address is old or unreachable
The email went to spam
Your host blocks outbound mail

Tip: You can also manually try Recovery Mode by visiting:

https://yourdomain.com/wp-login.php?action=entered_recovery_mode

(This method is widely used when you can’t access the email.) (GoDaddy)

Step 2: Find the real error message (the “why”)

The critical error screen is vague on purpose. To fix it fast, you want the exact fatal error line, like:

“Call to undefined function…”
“Allowed memory size exhausted…”
“Cannot redeclare class…”
“Syntax error, unexpected…”

Option A (best): Enable WordPress debugging to write errors to a log

WordPress supports built-in debug constants in wp-config.php. (WordPress Developer Resources)

Add (or edit) these lines above the “That’s all, stop editing” line:

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

What this does:

Turns debug mode on
Writes errors to: wp-content/debug.log
Prevents errors from showing publicly on-screen

Then reload the broken page and open wp-content/debug.log. You’re looking for the newest PHP Fatal error entry.

✅ Important: Once fixed, set WP_DEBUG back to false (or remove the lines). Debug mode should not stay enabled on a live site.

Option B: Check your server error logs

Many hosts expose logs in:

Hosting dashboard
cPanel error log
/logs/
error_log file in your site’s directory

If you see a fatal error referencing a specific plugin file (example: /wp-content/plugins/plugin-name/...), you already know what to disable.

Step 3: Rule out a plugin conflict (most common cause)

If you can’t access wp-admin, this is the fastest “get the site back” technique.

Disable all plugins without wp-admin

Using cPanel File Manager or SFTP/FTP, rename:

/wp-content/plugins/ → /wp-content/plugins.OFF/

That instantly disables all plugins.

If the site loads again, a plugin caused the crash
Rename the folder back to plugins
Then re-enable plugins one by one inside wp-admin until the crash returns
The last plugin you enabled is your culprit

This “rename plugins folder” approach is also used in WP Fix It’s older walkthrough on the same error (still valid as a core method). (WP Fix It)

If you suspect one plugin specifically

You can disable only that plugin by renaming its folder, like:

/wp-content/plugins/problem-plugin/ → /wp-content/plugins/problem-plugin.OFF/

This is faster and less disruptive—especially for WooCommerce or membership sites.

Step 4: Rule out a theme conflict

If plugins weren’t the issue, the theme (or child theme) may be throwing the fatal error.

Switch to a default theme without wp-admin

Rename your active theme folder:

/wp-content/themes/your-theme/ → /wp-content/themes/your-theme.OFF/

WordPress will fall back to an installed default theme (like Twenty Twenty-Four).

If the site loads, the theme or a child theme file caused the crash
Common culprits: functions.php, custom includes, page builder integrations

Step 5: Undo the last change (rollback)

If you know the crash started immediately after:

a plugin update
a theme update
adding a code snippet

…then the cleanest solution is to roll back the change.

Roll back a plugin/theme

Options include:

Restore from backup (fastest, if you have one)
Upload a known-good version of the plugin/theme via SFTP/File Manager
Use a rollback tool (if you can reach wp-admin)

WP Fix It’s earlier post recommends rollback tools and manual replacement methods. (WP Fix It)

Step 6: Fix memory limit and resource issues

A surprising number of “critical errors” are actually memory exhaustion or resource limits.

Look for errors like:

“Allowed memory size exhausted…”
“Out of memory…”
“Maximum execution time exceeded…”

Increase WordPress memory (wp-config.php)

Add:

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

Then check with your host whether the server’s PHP memory limit is also set appropriately.

Step 7: Check PHP version compatibility (especially after host changes)

Hosts sometimes upgrade PHP automatically. A plugin/theme that worked yesterday might break today if it’s not compatible with your PHP version.

A typical symptom is a fatal error that references:

deprecated functions
typed properties / syntax issues
missing PHP extensions

If you recently changed hosts, enabled a “performance stack,” or upgraded PHP, this is a big suspect.

WP Fix It offers a dedicated PHP compatibility service if you’d rather not wrestle with version mismatches across plugins/themes. (WP Fix It)

Step 8: Repair `.htaccess` (quick test)

While .htaccess issues more commonly show up as 500 errors, it’s worth a quick check because it’s easy and reversible:

Rename .htaccess → .htaccess.OFF
Try loading the site
If it works, go to Settings → Permalinks → Save to regenerate rules

If you’re specifically hitting a 500 error path, WP Fix It also has a walkthrough:
WordPress 500 Internal Server Error – FIXED FAST (WP Fix It)

Step 9: Reinstall WordPress core files (when errors look “core-ish”)

Sometimes a critical error is caused by:

corrupted core files
incomplete updates
a hacked/modified core file

A safe approach is:

Replace /wp-admin/ and /wp-includes/ with fresh copies from the same WordPress version
Do not delete your wp-content folder
Keep your wp-config.php intact

This mirrors standard “core refresh” guidance found across hosting and WordPress support workflows. (Liquid Web)

Step 10: Consider malware if the crash makes no sense

If you didn’t update anything and the site “just broke,” especially with:

weird admin behavior
unexpected redirects
injected scripts
new unknown admin users
file timestamps changing

…you should treat it as potentially compromised.

WP Fix It’s infection removal service is here:
Remove WordPress Malware and Infections (WP Fix It)

And if you want proactive defense, the Guard Dog security page is here:
Guard Dog Security (WP Fix It)

Common “critical error” scenarios (and the quickest fix)

1) Plugin update broke the site

Fast fix: rename the plugin folder to disable it, then roll back/update later.

2) Theme or child theme error in functions.php

Fast fix: rename active theme folder, then fix code in staging.

3) Code snippet typo

Fast fix: disable the snippet plugin (or remove the bad snippet file) and reload.

4) Memory exhausted after importing products/posts

Fast fix: increase memory, reduce heavy processes, check hosting limits.

5) Recovery mode doesn’t work

Fast fix: use file access (SFTP/File Manager) and disable the offending plugin/theme directly.

Prevention: how to avoid critical errors going forward

If you want fewer “surprise downtime” moments, adopt these habits:

Use staging for updates (especially WooCommerce, page builders, and major theme changes)
Update in batches (don’t update 25 plugins at once)
Keep reliable backups (and test restores)
Avoid duplicate plugins (multiple caching plugins, multiple SEO plugins, etc.)
Track changes (even a simple “site log” note helps)
Keep PHP current and plugins updated—but do it safely

If you want ongoing stability, WP Fix It’s care plan option is here:
WordPress Care Plans (WP Fix It)