Critical Error on WordPress: Fast Fixes That Actually Help

If WordPress shows “There has been a critical error on this website,” it usually means a plugin, theme, or custom code has triggered a fatal PHP error. The fastest safe approach is to back up first, then isolate the last change, recover access if needed, and read the recovery email or debug log to find the exact fault.

The good news is that this message is a symptom, not a diagnosis. In many cases you can fix it by disabling one plugin, switching themes, or restoring a small file change without touching content or the database.

What this error usually looks like

You may see the message on the front end, in wp-admin, or both. Sometimes WordPress also sends an email to the site admin address with the phrase “Your Site is Experiencing a Technical Issue” and a special recovery link.

Common signs include:

• The homepage loads the critical error message instead of your site.
• The dashboard is inaccessible or only partially loads.
• The error appears right after updating a plugin, theme, or WordPress core.
• The site works for some logged-in users but not visitors, or vice versa.
• You get a white screen, a 500 error, or a critical error on only one part of the site.

The most likely causes

This message is generated when WordPress catches a fatal PHP error. That fatal error is usually caused by one of a handful of issues:

• A broken plugin update or plugin conflict.
• A theme problem, especially in custom or child theme code.
• PHP version mismatch after a hosting change or server upgrade.
• Memory exhaustion on a heavy page, plugin, or import.
• Bad custom code in functions.php, a snippets plugin, or mu-plugins.
• Corrupted core files after a failed update or file transfer.
• Less commonly, malware or file tampering if the site was compromised.

If you want a broader decision tree for fatal errors, the related critical error fix guide is worth keeping open while you work.

Do this first: back up before changing anything

Before you deactivate plugins, rename folders, or edit files, make a full backup of both files and database. If you already have a known-good backup, confirm it can be restored. If you do not, make one now if the site is still accessible enough to do so.

A backup matters because the fastest fix often involves reversing the last change, and you do not want to make that guess without a safety net. If you need a backup process you can trust long-term, see our backup and restore test guide.

Step 1: Check the recovery email from WordPress

WordPress often sends an email to the site admin address when it detects a fatal error. That email may include the plugin, theme, or file responsible, plus a special “recovery mode” link that lets you log in safely and disable the faulty component.

Open that email first if you received it. If the recovery link works, use it to get back into the dashboard and then deactivate the suspected plugin or switch themes. This is the safest path because it avoids manual file changes.

If no email arrived, check spam, make sure your admin address is correct, and verify that your host can send mail reliably. Host email delivery varies, so no email does not mean no clue.

Step 2: Disable plugins the safest way

If you cannot access wp-admin, the usual safe move is to disable all plugins by renaming the plugins folder over SFTP or in your host file manager. WordPress will treat them as inactive when the folder name changes.

1. Connect by SFTP or use your host’s file manager.
2. Go to wp-content.
3. Rename the plugins folder to something like plugins-disabled.
4. Reload the site.

If the site loads after that, the problem is almost certainly one plugin or a plugin conflict. Rename the folder back to plugins, then disable plugins one by one from the dashboard until you find the culprit.

If you need a structured way to undo a recent bad update without admin access, the guide on what to do when WordPress breaks after an update walks through that sequence in more detail.

Step 3: Switch to a default theme

If disabling plugins does not help, the theme may be causing the fatal error. The cleanest test is to switch to a default WordPress theme such as Twenty Twenty-Four.

If you can get into wp-admin through recovery mode, change the active theme there. If you cannot, rename the active theme folder in wp-content/themes so WordPress cannot load it. WordPress should fall back to a default theme if one is installed.

If the site recovers after the theme switch, inspect any recent edits to functions.php, template files, or custom snippets. A small syntax mistake can bring down the whole site.

Step 4: Check the exact error in the debug log

The critical error message is intentionally generic. The real answer is usually in the PHP error log or the WordPress debug log. If you can safely enable logging, do it in a way that records errors without displaying them to visitors.

In wp-config.php, you can typically set debug logging like this:

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

After refreshing the broken page, check wp-content/debug.log for the fatal error line. Look for the file path, plugin slug, theme name, or function mentioned in the stack trace.

If you want help interpreting those lines, use the debug log reading guide to separate the real cause from the noise.

Step 5: Increase memory if the error points that way

Some fatal errors are caused by memory exhaustion rather than a broken plugin. That is more common on shared hosting, WooCommerce sites, page builders, or imports.

If the log mentions “allowed memory size exhausted,” you can try increasing PHP memory in wp-config.php. The exact limit depends on your host and plan, so start conservatively and do not assume unlimited memory is available.

That said, memory bumps are a temporary fix, not the root cause. If a plugin needs much more memory than the site normally has, the real fix is often to optimize the plugin, adjust the task, or replace the code path causing the spike.

Step 6: Verify PHP version compatibility

A site can run fine for months and then fail after the host changes PHP versions. Older plugins and themes may break on newer PHP releases, while outdated servers may not support code a modern plugin expects.

Check your hosting panel for the active PHP version and compare it with the requirements of your theme and key plugins. If the error began right after a PHP upgrade, try rolling back one version temporarily to confirm compatibility.

Use this as a test, not a permanent solution. Once you know the version is the trigger, update or replace the incompatible code.

Step 7: Look for custom code and must-use plugins

Not every critical error comes from a normal plugin. Custom snippets, mu-plugins, and modified theme files can cause the same crash and are easy to overlook because they are not in the usual plugins list.

Check for:

• functions.php edits made recently.
• Snippet plugins with new code.
• Files in wp-content/mu-plugins.
• Child theme overrides added during a design change.

To isolate custom code, revert the latest edit first. If you are not sure what changed, compare the current files with a known-good backup or deploy snapshot.

Step 8: Rule out file corruption or malware

If the error appeared without a clear update or code change, or if you see unknown admin users, strange redirects, or files you did not add, treat the site as potentially compromised. Malware can trigger fatal errors by modifying core files or loading malicious code early.

Start by checking core WordPress files against a clean install and scanning the site files for obvious foreign PHP in unusual locations. Do not delete random files if you are unsure what they do. On a live site, careless cleanup can make recovery harder.

If you suspect compromise, follow the safe cleanup approach in our WordPress hacked cleanup guide.

How to prevent this from happening again

Most critical errors are preventable with boring but effective maintenance:

• Keep a tested backup routine in place.
• Update plugins and themes one at a time, not all at once.
• Use a staging site for major theme, PHP, or builder changes.
• Prefer well-maintained plugins with clear compatibility notes.
• Review custom code before pushing it live.
• Monitor PHP errors so you catch warnings before they become fatal.

If updates are where your site most often breaks, read how to safely update WordPress plugins, themes, and core for a better rollout process.

When to call a professional

If you have a backup but not the time to investigate, a senior engineer can usually isolate the fault much faster than trial-and-error. That is especially true when the error involves custom code, a complicated page builder, WooCommerce, multisite, or a server setting you do not control.

You should also get help if the recovery email never arrives, the site crashes again after every fix, or you are worried the issue is tied to malware or a failed update chain. Mend can diagnose the problem on a backup-first workflow, give you a plain-English report of the root cause, and fix it fast in most cases the same day. Start with a free Diagnosis, or go straight to Emergency Rescue if the site is down and you need help now.

If you want ongoing protection after the fix, a Care Plan can take updates, backups, security, and uptime monitoring off your plate.

Bottom line: the “There has been a critical error on this website” message is almost always a fatal PHP problem, and the real fix is to identify what changed last. Start with a backup, use the recovery email if you have it, disable plugins, test the theme, and read the log before making bigger changes.