Skip to main content
WordPress TroubleshootingMay 24, 2026

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

Learn how to fix “There has been a critical error on this website” in WordPress using recovery mode, plugins, themes, logs, PHP, and safe rollback steps.

Category: WordPress Troubleshooting

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

Seeing “There has been a critical error on this website” can feel serious, but in most WordPress sites it usually means one PHP process failed badly enough that WordPress stopped loading the page. The cause is often a plugin conflict, theme issue, PHP version mismatch, memory limit, failed update, custom code error, or server-side fatal error.

This guide shows you how to restore access safely, find the real cause, and prevent the same critical error from coming back.

TL;DR: Fastest Safe Fix

To fix the WordPress critical error, first check your admin email for the WordPress recovery mode link. If that does not work, access your site files through hosting File Manager or SFTP, rename the plugins folder to disable plugins, then test the site. If it loads, rename the folder back and disable individual plugins one by one. If plugins are not the cause, switch to a default theme, enable private debug logging in wp-config.php, check wp-content/debug.log or your server error log, then fix the plugin, theme, PHP, memory, or custom code error named in the log.

What Does “There Has Been a Critical Error on This Website” Mean?

The message means WordPress detected a fatal PHP error and stopped the request instead of showing a blank white screen or exposing technical error details publicly. In simple terms, something loaded by WordPress failed: a plugin file, theme file, PHP function, class, memory-heavy process, incompatible PHP feature, or custom snippet.

A critical error can appear on the whole website, only inside wp-admin, only on one page, only during checkout, only after login, or only after updating a plugin or theme. That location matters because it usually points toward the cause.

Common causes include:

  • A plugin update with a PHP fatal error.
  • A theme or child theme function breaking the site.
  • Custom code added to functions.php or a code snippets plugin.
  • PHP version incompatibility after changing hosting settings.
  • Low WordPress or server PHP memory limit.
  • Missing plugin files after an incomplete update.
  • WooCommerce, page builder, security, cache, or backup plugin conflicts.
  • Corrupted WordPress core files after a failed update.

Before You Start: Do These Safety Checks First

The biggest mistake is making random changes before collecting the clue that identifies the failing file. If you still have access to your hosting panel, take a backup or snapshot before editing files. If your host offers automatic backups, note the latest clean restore point.

Quick safety checklist:

  • Do not delete plugins or themes immediately. Rename folders first.
  • Do not restore an old database on WooCommerce, LMS, booking, or membership sites unless you understand the data loss risk.
  • Write down what changed recently: plugin update, theme update, PHP version, migration, cache change, or custom code edit.
  • Check the site in a private browser window to avoid cached admin sessions.
  • Clear page cache only after collecting useful error logs.

If you have a log excerpt from your server, PHP, LiteSpeed, Apache, Nginx, or wp-content/debug.log, you can use the FyrePress Server Log Analyzer to classify the likely cause before changing more files.

Fix 1: Use the WordPress Recovery Mode Email

WordPress can send a recovery mode email to the site admin address when it detects a fatal error. This email usually includes a special link that lets you access the dashboard in recovery mode and disable the broken plugin or theme.

Steps:

  1. Open the inbox for the admin email set in WordPress.
  2. Look for a message about a technical issue on your site.
  3. Click the recovery mode link.
  4. Log in to WordPress.
  5. Deactivate the plugin or theme WordPress identifies.
  6. Update, replace, or roll back the broken component.
  7. Exit recovery mode after confirming the site works.

If you do not receive the email, check spam, confirm the admin email address, and remember that server mail delivery may fail on some hosts. Do not depend only on recovery mode. The next fixes work even when you cannot access wp-admin.

External reference: WordPress introduced Fatal Error Recovery Mode to help administrators access the backend after fatal errors. You can read the official Make WordPress explanation here: Fatal Error Recovery Mode in WordPress 5.2.

Fix 2: Disable Plugins Without Accessing wp-admin

Plugin conflicts are one of the most common reasons behind the WordPress critical error. If the dashboard is inaccessible, you can disable plugins from your hosting File Manager, SFTP, or SSH.

Disable all plugins temporarily

  1. Open your hosting File Manager or connect with SFTP.
  2. Go to your WordPress installation folder.
  3. Open wp-content.
  4. Rename the plugins folder to plugins-disabled.
  5. Reload the website.

If the site starts working, one plugin is likely the cause. Rename plugins-disabled back to plugins. Then open the plugins folder and rename individual plugin folders one by one until you find the plugin that breaks the site.

Example:

wp-content/plugins
wp-content/plugins-disabled

This does not delete your plugins. It only prevents WordPress from loading them. After you find the broken plugin, check whether it has a safe update, compatibility notice, rollback option, or known conflict with your PHP or WordPress version.

Related FyrePress guide: WordPress Plugin Compatibility Checklist.

Fix 3: Switch to a Default WordPress Theme

If disabling plugins does not fix the critical error, the active theme may be the problem. This is especially likely after editing functions.php, updating a premium theme, changing a child theme, or adding custom PHP snippets.

If you can access wp-admin:

  1. Go to Appearance → Themes.
  2. Activate a default WordPress theme.
  3. Reload the broken page.

If you cannot access wp-admin:

  1. Open File Manager or SFTP.
  2. Go to wp-content/themes.
  3. Rename your active theme folder.
  4. Reload the site.

If WordPress has another default theme available, it may fall back to that theme. If the site works after switching themes, the issue is probably inside the theme, child theme, template override, or theme-related custom code.

For custom theme edits, avoid editing a live production theme directly. Test theme changes on staging first. FyrePress has a related guide on creating a WordPress staging site before updates.

Fix 4: Enable WordPress Debug Logging

If the cause is not obvious, enable private debug logging. This helps WordPress write PHP errors to a log file instead of displaying them publicly to visitors.

Open wp-config.php and add or update these lines before the comment that says That's all, stop editing!:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Then reload the broken page once. After that, check:

  • wp-content/debug.log
  • Your hosting PHP error log
  • Apache, Nginx, LiteSpeed, or PHP-FPM logs
  • WooCommerce logs if the error happens during checkout or scheduled actions

Look for the first fatal error near the time of the failed request. The file path often reveals the cause.

Example log clue:

PHP Fatal error: Uncaught Error: Call to undefined function example_function()
in /wp-content/plugins/example-plugin/includes/class-loader.php on line 58

In this example, the file path points to example-plugin, so that plugin should be disabled, updated, rolled back, or replaced.

External reference: WordPress provides official debugging constants including WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY. Read the official documentation here: Debugging in WordPress.

FyrePress tool: Use the wp-config Builder to generate reviewable debug, memory, SSL, update, and hardening constants safely.

Fix 5: Increase the WordPress Memory Limit

Some critical errors happen because WordPress runs out of memory during an update, import, image process, WooCommerce action, backup, page builder edit, or admin request.

Add these constants to wp-config.php before the final stop-editing line:

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

If the server PHP memory limit is lower than the WordPress value, this may not work. In that case, raise PHP memory from your hosting control panel, php.ini, .user.ini, or by contacting your host.

Related FyrePress guide: How to Fix “Allowed Memory Size Exhausted” in WordPress.

Important: increasing memory can restore access, but it does not always fix the root cause. If one plugin keeps consuming 512M or more, investigate the plugin, query, import, scheduled task, or custom code instead of raising limits forever.

Fix 6: Check PHP Version Compatibility

A critical error may appear after switching PHP versions. For example, an old plugin may fail on a newer PHP version, or a modern plugin may fail on an outdated PHP version. This often happens after hosting migrations, WordPress updates, control panel changes, or automatic PHP upgrades.

What to check:

  • Which PHP version was active before the error?
  • Was PHP changed recently?
  • Do the active theme and plugins support the current PHP version?
  • Does the error log mention deprecated functions, missing classes, type errors, or syntax errors?

If the site broke immediately after a PHP change, temporarily switch back to the previous PHP version from your hosting panel. Treat this as a recovery step, not a permanent fix. After the site is online, update or replace the incompatible plugin, theme, or custom code.

Related FyrePress guide: WordPress PHP Requirements Explained.

Fix 7: Reinstall WordPress Core Files

If plugins, themes, memory, and PHP version are not the problem, WordPress core files may be incomplete or corrupted after a failed update. This is less common than plugin conflicts, but it can happen.

If wp-admin works:

  1. Go to Dashboard → Updates.
  2. Click Re-install for the current WordPress version.
  3. Clear cache and test the site.

If wp-admin does not work:

You can manually replace WordPress core files, but be careful. Do not overwrite wp-config.php or the wp-content folder.

  1. Download a fresh copy of WordPress from WordPress.org.
  2. Extract the files locally.
  3. Upload fresh core folders and files except wp-content and wp-config.php.
  4. Reload the site and check logs again.

If you are not comfortable replacing files manually, ask your host or developer to do this step. A wrong upload can overwrite custom content.

Best Fix Method by User Type

The right recovery path depends on your access level and how important the live database is.

For beginners

Start with recovery mode email. If that fails, use hosting support and ask them to check the PHP error log. Share the exact time the error happened and what was updated recently.

For site owners with hosting File Manager

Rename the plugins folder first, then test. If that fixes the site, restore the folder name and isolate the broken plugin. This is the safest practical method when wp-admin is down.

For developers

Enable private debug logging, reproduce the failure once, inspect the first fatal error, then fix the exact plugin, theme, hook, autoloader, PHP compatibility issue, or missing file shown in the trace.

For WooCommerce and membership sites

Avoid full database restores unless absolutely necessary. Orders, payments, subscriptions, user registrations, and bookings may have changed after the backup was created. Prefer targeted plugin/theme fixes first.

How to Prevent WordPress Critical Errors Next Time

Most critical errors are preventable with a safer update and testing workflow. WordPress sites break less often when updates are staged, backups are verified, plugin compatibility is checked, and debug logs are reviewed after major changes.

Prevention checklist:

  • Create a staging site before major updates.
  • Keep a full file and database backup before plugin, theme, PHP, or WordPress updates.
  • Update plugins and themes one group at a time, not everything blindly.
  • Test checkout, forms, login, search, admin editing, and mobile layout after updates.
  • Keep PHP on a supported version that your plugins and theme support.
  • Remove abandoned plugins and old themes.
  • Do not edit live functions.php without staging or SFTP access.
  • Keep debug display disabled on production.
  • Monitor error logs after updates.

For a safer update workflow, read How to Safely Update WordPress Without Breaking Your Site.

Final Recommendation

The fastest safe way to fix “There has been a critical error on this website” is to avoid guessing. Check recovery mode first, then disable plugins safely, test the active theme, enable private debug logs, and follow the fatal error path. In most cases, the log will name the plugin, theme, file, or PHP issue responsible.

After the site is back online, do not stop at “it works now.” Update or replace the broken component, test on staging, document the fix, and keep a rollback plan ready before the next update.

Frequently Asked Questions

What causes “There has been a critical error on this website” in WordPress?

The most common causes are plugin conflicts, theme errors, custom PHP code mistakes, PHP version incompatibility, low memory limits, failed updates, or corrupted WordPress files.

Can I fix the WordPress critical error without wp-admin access?

Yes. You can use hosting File Manager, SFTP, or SSH to rename the plugins folder, switch themes, edit wp-config.php, enable debug logging, and check error logs without accessing the WordPress dashboard.

Where is the WordPress critical error log?

If debug logging is enabled, WordPress can write errors to wp-content/debug.log. Your hosting account may also have PHP error logs, Apache logs, Nginx logs, LiteSpeed logs, or WooCommerce logs depending on the site and server setup.

Will disabling plugins delete my plugin settings?

No. Renaming the plugins folder or an individual plugin folder only stops WordPress from loading it. It does not delete the plugin files or database settings.

Should I restore a backup to fix a critical error?

Restore a backup only when targeted fixes fail or the site is seriously damaged. For WooCommerce, membership, booking, and LMS sites, be careful because restoring an old database can overwrite new orders, users, payments, or submissions.

How do I prevent this error after future updates?

Use a staging site, take full backups, update plugins and themes carefully, check PHP compatibility, avoid abandoned plugins, and review error logs after major updates.