There Has Been a Critical Error on This Website: How to Fix

"There has been a critical error on this website" means PHP hit a fatal error and WordPress stopped before it could finish the page. On WP Aligned hosting the server, the database and the PHP service are almost always fine when you see it. The cause is code inside the site, usually a plugin or theme that was just updated, or an older plugin that can't run on the PHP version the site just moved to. The fix is to find that plugin in error_log, roll it back or deactivate it to get the site up, then fix it properly.

This guide is the process we follow when our monitoring catches a site showing this page.

What "there has been a critical error on this website" looks like

You'll usually see some of these together:

• Visitors get a plain page with the text There has been a critical error on this website. and a link, Learn more about troubleshooting WordPress.
• Sometimes the theme's header loads and the page stops partway down, with the same message at the bottom. That means the fatal happened while a block, widget or footer was rendering.
• The page usually returns HTTP status 500. If it stops partway through, the status can still be 200, so a check that only looks at the status code can miss it.
• wp-login.php and often wp-admin still load. The fatal only fires on the code paths that load the broken plugin, so the front end can be down while the login page works.
• The site's admin email gets a message from WordPress with the subject Your Site is Experiencing a Technical Issue. It names the plugin or theme that failed and includes a link to recovery mode.

Why it happens: the usual causes

In every case we traced this month, the fatal came from a plugin, and it showed up right after something changed:

The PHP version case catches agencies off guard, because nothing in WordPress changed. Two kinds of PHP 8 errors cause most of it:

• Removed functions. create_function() was removed in PHP 8.0. A plugin that still calls it fails on every request, with Call to undefined function create_function().
• Stricter type checks. PHP 7.4 logged a warning when a plugin passed the wrong type to a built-in function (for example, a string or null where it expects an array). PHP 8 throws a TypeError instead, which is a fatal. You'll see lines like in_array(): Argument #2 ($haystack) must be of type array, null given.

Why the site went down days after the change

On our hosting, LiteSpeed Cache serves saved copies of pages to visitors without running PHP. If a plugin starts failing, cached pages keep loading normally until they expire or the cache is purged. One site this month started throwing fatals right after a PHP change but kept loading for visitors for about three days, then went down overnight. Cached pages expiring is the most likely explanation.

It works the other way too. LiteSpeed can cache the error page itself, so a site can keep showing the critical error after you've fixed the cause. Purge the cache after every fix in this guide.

Step 1: Note what changed

Before you open any logs, write down what happened in the hour before the site broke:

• Plugin, theme or WordPress core updates, whether you ran them, a maintenance tool did, or WordPress auto-updated.
• A PHP version change on the domain. Check Software > MultiPHP Manager in cPanel. See How to change the PHP version per domain or subdomain in cPanel.
• A new plugin, or a settings change in one.

The folders' modification times show what was updated and when.

In cPanel (no command line):

1. Open Files > File Manager and go to the site's wp-content/plugins/ folder.
2. Click the Last Modified column header to sort by date. Do the same in wp-content/themes/.

Over SSH (optional): run this from the site's document root:

ls -lt --time-style=+'%Y-%m-%d %H:%M' wp-content/plugins wp-content/themes | head -20

A cluster of folders all modified within a few minutes of the outage is a strong lead.

Step 2: Find the fatal error in error_log

PHP writes the exact error to the site's error_log file. On our hosting that's error_log in the site's document root (front-end requests) and wp-admin/error_log (admin requests). For more on where it lives and how to read it, see WordPress PHP errors: deprecated notices and error_log.

In cPanel (no command line):

1. Open Files > File Manager and go to the site's document root (usually public_html). If you don't see error_log, open Settings (top right) and turn on Show Hidden Files (dotfiles).
2. Right-click error_log and choose View, or select it and click Edit.
3. Scroll to the bottom. The newest entries are last. Look for lines that contain PHP Fatal error.
4. The path in that line names the plugin or theme, for example wp-content/plugins/example-gallery/.

If the file is too large for File Manager to open, look in cPanel under Metrics > Errors if your account shows it, which lists recent errors for the site. Otherwise see the large logs note below.

Over SSH (optional): show the most recent fatal errors:

grep -E 'PHP (Fatal|Parse) error' error_log | tail -n 5

A typical entry:

[09-Nov-2026 16:02:26 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /home/exampleuser/public_html/wp-content/plugins/example-gallery/example-gallery.php:4

The path tells you who owns the broken code. Here it's the example-gallery plugin. If the path is under wp-content/themes/, it's the theme.

Count fatals by plugin or theme to see which one dominates:

grep -E 'PHP (Fatal|Parse) error' error_log | grep -oE 'wp-content/(plugins|themes)/[^/]+' | sort | uniq -c | sort -rn

Two practical notes:

• Large logs. A plugin that fails on every request can grow error_log to many gigabytes. cPanel File Manager won't open files that large. If you don't use SSH, don't keep trying to open it: use the recovery mode email, or contact us and we'll read the log for you. tail and grep over SSH work on any size, because they don't load the whole file.
• The stack trace matters. The fatal line names the file that crashed, but the lines below it (#0, #1, and so on) show what called it. If a plugin crashes while the theme's footer is rendering, both appear there, and that's your conflict.

If you can't open the log, the Your Site is Experiencing a Technical Issue email names the plugin too. If you can't find either, contact us and we'll read the log for you.

Step 3: Get the site back up

Pick the option that fits what you found. Each one is reversible.

Option A: Roll the plugin back one version

When the fatal started right after an update, going back to the previous version is the fastest clean fix. It brought one of this month's sites back immediately.

For a plugin from WordPress.org, download the previous version from the plugin's page (Advanced View, then Previous Versions). For a premium plugin, get the previous version from the vendor's account area. You'll have a .zip file. Then put the older copy in place, using whichever of these works:

In wp-admin (if you can log in, including through the recovery mode link):

1. Go to Plugins > Add New Plugin > Upload Plugin, choose the .zip and click Install Now.
2. WordPress says the plugin is already installed. Click Replace current with uploaded.

In cPanel File Manager (if wp-admin won't load):

1. Open Files > File Manager and go to wp-content/plugins/.
2. Rename the plugin's folder to example-gallery.broken. This also deactivates it, which gets the site up right away.
3. Click Upload, add the .zip, then back in the folder select it and click Extract.
4. Log in to wp-admin and activate the plugin. Delete the .broken folder once the site is working.

After either method, turn off auto-updates for that plugin until the vendor ships a fix, or the next update run will break the site again. In wp-admin, go to Plugins and click Disable auto-updates in that plugin's row.

With WP-CLI over SSH (optional), for a WordPress.org plugin:

wp plugin install example-gallery --version=2.3.1 --force --skip-plugins --skip-themes

--skip-plugins --skip-themes lets WP-CLI run even though the site is throwing a fatal.

Option B: Deactivate the plugin

If you can't roll back, or the plugin isn't essential, deactivate it.

If wp-admin still loads, go to Plugins and click Deactivate under the plugin. If it doesn't, use the recovery mode link in the WordPress email: log in through the link, and WordPress pauses the failing plugin for your session so you can deactivate it under Plugins.

If neither works, rename the plugin's folder in cPanel. WordPress deactivates a plugin when it can't find its folder:

1. In cPanel, open Files > File Manager.
2. Go to the site's wp-content/plugins/ folder.
3. Rename example-gallery to example-gallery.off.

With WP-CLI over SSH (optional):

wp plugin deactivate example-gallery --skip-plugins --skip-themes

Before you do this on a live site, check what the plugin provides. Anything that depends on it, such as its blocks, widgets or shortcodes, stops rendering. Shortcodes show up as plain text like [example_gallery]. The site is up, but those parts of the page may be empty until the plugin is replaced.

If the fatal is in the theme, roll the theme back the same way as Option A. Switching to a default theme also brings the site up, but it changes how every page looks, so treat it as a last resort.

Option C: Switch PHP back, as an emergency step only

If the fatal started right after a PHP version change, switching the domain back to its previous PHP version in MultiPHP Manager brings the site up in a minute or two. Use this only to buy time while you do Option A or B.

• It doesn't fix anything. On the older version the same bug is usually still there and logged as a warning instead of a fatal, so error_log keeps growing.
• If the previous version was PHP 7.4, or 8.0 or 8.1, the site is now on a PHP version that no longer gets security fixes. Plan to be back on a supported version within days, not weeks.
• It doesn't always work. If the plugin has a bug that fails on every PHP version, switching back changes nothing. We've seen that too.

Step 4: Purge the cache and confirm it's fixed

1. Purge LiteSpeed Cache: in wp-admin, hover over the LiteSpeed icon in the admin bar and click Purge All. See How to clear LiteSpeed Cache on WP Aligned hosting for other ways.
2. Load the home page and two or three inner pages in a private window.
3. Confirm the response is fresh and not an error. In the private window, add a made-up query string to the address, like https://example.com/?nocache=1234. That forces a page that isn't cached yet. Change the number each time. The page should load normally, without the critical error message.

Over SSH, you can check the same thing from the command line:

bash curl -s -o /dev/null -w '%{http_code}\n' "https://example.com/?nocache=$(date +%s)" curl -s "https://example.com/?nocache=$(date +%s)" | grep -c 'critical error'

You want 200 from the first command and 0 from the second.

4. Watch error_log for a few minutes. In File Manager, right-click it, choose View, and check the last lines. No new PHP Fatal error lines from that plugin means you're done with the emergency.

Step 5: Fix it for good

Getting the site up is half the job. Then:

• Update when the vendor fixes it. Send the vendor the fatal line from error_log, including the file and line number. That's what they need to fix it. Check the changelog before updating again.
• Replace abandoned plugins. A plugin that calls create_function() hasn't been updated for PHP 8, which came out in 2020. It won't be fixed, so replace it with a maintained plugin or with your page builder.
• Get back to a supported PHP version. If you used Option C, move the site back once the plugin is fixed or removed, and check error_log again afterward.
• Empty the log. Once the errors stop, empty error_log so the next problem is easy to spot. In cPanel File Manager, delete the file. PHP creates a new one on the next error. Over SSH, : > error_log empties it in place.

How to prevent it

• Update in small batches. Thirteen plugins updated at once means thirteen suspects. Update a few at a time, check the front end between batches, and update the plugins with the most custom integration (page builders, block libraries, custom field plugins) on their own.
• Test PHP changes on staging first. Set a staging copy to the new PHP version and read its error_log before you change production. See How to change the PHP version per domain or subdomain in cPanel.
• Check the front end uncached after updates. A cached home page tells you nothing. Use the cache-busting check from Step 4.
• Keep the admin email address current. The recovery mode email goes to the address in Settings > General. If that's an old client mailbox nobody reads, you lose the fastest clue.
• Watch for warnings. Most PHP 8 fatals were warnings on PHP 7.4 first. A plugin that fills error_log with warnings today is the likely fatal after the next PHP upgrade.

When to contact us

Open a ticket if any of these are true:

• error_log has no fatal error at the time the site broke.
• The fatal points to WordPress core (wp-includes or wp-admin) rather than a plugin or theme.
• wp-login.php also fails, or the site shows a server error page rather than the WordPress critical error page.
• You can't open error_log because of its size and don't have SSH access.

Include the domain, the time the site broke and anything that changed just before. If you have the fatal line, send that too. See Need Help? for how to reach us.

FAQ

Why does wp-admin work when the front end shows a critical error?

WordPress only loads the code a request needs. If the broken code runs while the theme renders a page, or in a block, widget or shortcode, the front end fails and wp-admin doesn't. The reverse also happens.

Did I lose content or data?

No. A fatal error stops PHP before the page finishes. It doesn't delete posts, media or settings. Once the plugin is rolled back or deactivated, the site comes back as it was.

Why does the site still show the error after I fixed it?

LiteSpeed Cache may have saved the error page. Purge the cache, then check with a cache-busting query string as in Step 4.

Should I restore a backup?

Usually not. A restore rolls back every plugin, plus any content added since the backup. Rolling back the one broken plugin fixes the same problem without losing anything.