Critical error on a WordPress site after an update: what to do

The website worked fine last night, and this morning, instead of the home page, there is a single line: “There has been a critical error on this website.” Most often this is the result of an update: of a plugin, a theme, WordPress itself or the PHP version on the hosting. In this article, we explain what broke, how to bring the website back on your own or with a contractor and how to update it on a maintenance schedule so that customers never see this message again.

What a “critical error” in WordPress means

Behind the message is a PHP fatal error: a failure after which PHP stops executing the page code. The cause is almost always specific: a plugin called a function that no longer exists in the new version; a theme passed data of the wrong type to a function; a script ran out of memory.

Since version 5.2, WordPress catches such failures: instead of a white screen, the visitor sees a page with an error message, and WordPress tries to determine which plugin or theme caused it. The message depends on where the failure happened:

• “There has been a critical error on this website.” On regular pages, visitors see it.
• “There has been a critical error on this website. Please check your site admin email inbox for instructions…” In the admin area and on the login page.
• “There has been a critical error on your website, putting it in recovery mode…” For the person who logged in via the link from the email.

Two other failures look similar but work differently. “Error establishing a database connection” means that WordPress could not connect to MySQL: the access credentials in wp-config.php are wrong or the database server is down. Plugins usually have nothing to do with it, and troubleshooting starts with the hosting provider. A blank white page or a “500 Internal Server Error” without any WordPress message means that the error page never got a chance to appear: the failure happened at the server level (for example, because of an error in .htaccess) or the fatal error handler is disabled with the WP_DISABLE_FATAL_ERROR_HANDLER constant. In that case, look for the cause in the PHP error log in the hosting control panel (more on it in step 2).

The “technical issue” email from WordPress

When WordPress identifies the culprit, it sends an email with the subject “[Site Name] Your Site is Experiencing a Technical Issue” to the administrator address from “Settings → General.” A different address can be set with the RECOVERY_MODE_EMAIL constant in wp-config.php. The email names the plugin or theme with the error, the page where it occurred, technical details and a link to enter recovery mode.

Recovery mode pauses the broken plugin or theme only in the browser of the person who logged in via the link. Visitors still see the error, but you get into the admin area and can deactivate the plugin or roll it back to its previous version.

The email does not always arrive, and there are three reasons for that.

1. WordPress sends it only if the error occurred in the admin area, on the login page or in some background admin service requests (AJAX). If only the checkout page crashes, there will be no email until someone opens /wp-admin/. So the first thing to do is open the admin area: if the error repeats there and a plugin or theme is to blame, the email will be sent.
2. By default, the email is sent no more than once a day, and the link in it is valid for the same period. If an email was already sent in the last 24 hours, there will be no new one. Find the earlier one, including in your spam folder: until the day has passed, the link still works.
3. The email is sent through the website’s regular mail. If email sending is not configured, it may not arrive or may land in spam. For this case, there is a path without the email below.

The core developers described how the mechanism works in a note on fatal error protection in WordPress 5.2.

Why WordPress crashes after an update

A website has three layers of code: the WordPress core, the theme and the plugins. All of them run on the PHP version set by the hosting provider. Update one layer, and the code of another may stop working with it. Typical cases are below.

A plugin is not ready for the new core version. WordPress 7.1 was released on August 19, 2026. The next day, the developers of the WP Rocket caching plugin confirmed that on 7.1 the plugin was crashing websites with a fatal error, and the admin area might not open either. The fixed version 3.23.2.2 was released about two and a half hours after the cause was found. For those locked out of the admin area, the WP Rocket documentation recommended renaming the plugin folder via FTP. The plugin itself was not updated that day: the websites were broken by the core update.

A plugin update shipped with a bug. On July 29, 2026, a website owner wrote on the wordpress.org forum that after updating YOP Poll from 7.0.7 to 7.0.8, the admin area stopped opening because of a critical error. Rolling back to 7.0.7 helped. The owner turned off automatic updates for the plugin, and the plugin’s support team approved this decision.

The theme or code in functions.php. The most common sources of failure are themes bought many years ago and never updated since, and edits made directly in theme files without a child theme (a theme layered on top of the main one, whose edits survive updates of the parent).

A PHP version change. The hosting provider moved the website to PHP 8.2 or 8.3, and an old plugin uses functions that no longer exist in the new version. PHP support timelines and the upgrade process are covered in our article on what a website owner should do when PHP 8.1 and 8.2 reach end of support.

Not enough memory. In the log, this appears as “Allowed memory size of … bytes exhausted.” After an update, a plugin may gain a heavy function and hit the PHP memory limit. By default, WordPress tries to allocate 40 MB on a regular website and 64 MB on a multisite (a network of websites on one WordPress installation). The limit is raised with the WP_MEMORY_LIMIT constant, and the upper bound is set by the hosting provider. A higher limit removes the symptom; if a plugin no longer has enough memory when it had plenty before the update, the plugin is what needs attention.

The update was interrupted. The hosting provider cut the process off on a timeout, the disk ran out of space or the browser tab was closed. Some files stayed old, and some became new. A sign of such a failure is the message “Briefly unavailable for scheduled maintenance. Check back in a minute.” During an update, WordPress creates a .maintenance file in the website root and ignores it after 10 minutes. If the message stays up longer, you are most likely seeing a cached copy of the page: clear the plugin, server and CDN cache (a CDN is a network of servers that delivers copies of pages, for example Cloudflare). After a failed update, you can delete the .maintenance file itself manually.

A conflict between two plugins. Each works on its own, but together they crash. Common pairs: a caching plugin and a page builder; two plugins in the WooCommerce checkout.

The website is down: what to do

If the website brings in leads or sales, first get it working again, then look for the cause. Go step by step without skipping ahead.

Step 1. Log in via the link from the email

Follow the link, log in as an administrator and open “Plugins” or “Appearance → Themes.” WordPress will mark the culprit and show the error message. Then you have two options: deactivate the plugin or install its previous version (step 5). After that, exit recovery mode with the button in the top toolbar and check the website in a regular browser window without logging in to the admin area.

No email? Open your-site-url/wp-admin/ (why this helps is explained above), wait a few minutes and check your spam folder. If the email still has not arrived, go to step 2.

Step 2. Find the error in the log

First, open the hosting control panel. Most hosting providers have a PHP error log (error_log) there, and the fatal error is usually already recorded in it with the file name and line number, without any WordPress settings. If there is no log or it is empty, turn on WordPress’s own log, the debug.log file. You need access to the website files: the file manager in the hosting control panel, FTP or SFTP. In wp-config.php, before the line /* That's all, stop editing! Happy publishing. */, add the following (or correct it if these lines already exist):

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

Open the broken page again. The error will be written to wp-content/debug.log. Find the line with “PHP Fatal error” and look at the file path: wp-content/plugins/folder-name/… points to a plugin, and wp-content/themes/… points to the theme.

Setting WP_DEBUG_DISPLAY to false is mandatory: otherwise visitors will see the error text with file paths. A second caveat: the wp-content folder is publicly accessible, and on many servers debug.log can be downloaded via a direct URL. Once the cause is found, set WP_DEBUG back to false and delete the file. If you need the log for a long time, set WP_DEBUG_LOG to a file path outside the public folder (this has been possible since version 5.1). All parameters are described in the official WordPress debugging guide.

Step 3. Disable the plugin without admin access

Open wp-content/plugins/ and rename the folder of the plugin from the log, for example wp-rocket to wp-rocket-off. WordPress will not find the plugin and will deactivate it. The website will most likely open.

If your hosting provides SSH access and WP-CLI (a command-line tool for managing WordPress), you can use the command wp plugin deactivate wp-rocket --skip-plugins. The --skip-plugins flag prevents the broken plugin from loading and crashing the command itself.

If the log showed nothing, rename the entire plugins folder to plugins_old: this deactivates all plugins at once. Then restore the name and activate the plugins in the admin area one by one until the error comes back. Do not do this on a live store: payments, shipping and forms will be disabled together with the plugins. This method is for finding the cause on a copy of the website.

“Must-use” plugins from the wp-content/mu-plugins folder cannot be deactivated this way. They always load, they have no deactivate button and they do not appear in the regular plugin list. They are often installed by the hosting provider or a previous developer, and people forget about them when looking for the cause.

If the theme is to blame, rename its folder in wp-content/themes/. WordPress will switch to a default theme if one is installed. The design will change, but the admin area will work.

Step 4. If PHP was changed the day before

Switch back to the previous PHP version in the hosting control panel, if your hosting provider still offers it. The website will come back up, and you can calmly update or replace the incompatible plugin or theme on a staging copy. Do not stay on the old PHP version for long: support timelines are covered in the article PHP 8.1 and 8.2 without support.

Step 5. Roll back the version or restore a backup

Plugins from the wordpress.org directory have a “Previous Versions” section on the “Advanced View” tab. From there, you can download an earlier version and install it instead of the broken one. The directory warns that older versions may be insecure, so a rollback is a temporary measure until the developer releases a fix. For paid plugins, previous versions are usually available in your account on the vendor’s website.

If the core broke or it is unclear what exactly changed, restore a full backup. The files and the database must be backed up at the same moment: during an update, plugins sometimes change the structure of their tables, and old code on top of an updated database may break in a different way.

What not to do

• Do not remove the plugin with the “Delete” button. Some plugins erase their settings and tables when they are deleted. To deactivate a plugin, renaming its folder is enough.
• Do not reinstall WordPress over the website blindly. When replacing the core manually, keep wp-config.php and the wp-content folder, or the uploaded files and themes will disappear along with the error.
• Do not raise the memory limit to the maximum “just in case,” and do not leave the error log turned on.
• Do not edit plugin code on the live website. The fix will disappear with the next update.

If the log shows files with meaningless names that you did not install, this is no longer an update failure. In that case, you need a website check and hacked website recovery.

What rollback is already built into WordPress

WordPress has two rollback mechanisms and a rule for automatic core updates. They protect against a critical error after an update only in narrow cases.

• Since version 6.3, when you update a plugin or theme manually, the old version is temporarily moved to wp-content/upgrade-temp-backup/. If the installation fails (the archive did not download or the files were not copied), WordPress restores the old version. If the new version installed successfully and only then crashed the website, the mechanism will not kick in.
• Since version 6.6, after an automatic update of an active plugin, WordPress itself requests the home page and checks it for a fatal error. If there is an error, the previous version is restored and the administrator receives an email. Only the home page is checked: the check will not notice an error in the cart, the customer account or the admin area. Themes are not checked at all.
• WordPress installs minor core updates, that is, fixes and security patches such as 7.1.3 → 7.1.4, on its own (as of November 2026, the current version is 7.1.4, released on October 28). Major versions are a different story. A website installed on WordPress 5.6 or later automatically moves to a new major version by default, for example from 7.0 to 7.1. Check this in “Dashboard → Updates.” If it says “This site is automatically kept up to date with each new version of WordPress,” click the link “Switch to automatic updates for maintenance and security releases only.” Your hosting provider or a plugin may change this setting.

How to update WordPress without downtime

Below is the maintenance schedule that we consider the bare minimum for a website that makes money. For a five-page brochure website, some steps can be simplified; for an online store, they cannot.

1. A tested backup

Before updating, make a full copy of the files and the database and store it somewhere other than the same server. A backup that has never been restored may turn out to be incomplete or corrupted, and you will find out on the day of the outage. At least once every few months, restore the copy at a separate address and make sure the website comes up.

2. A staging copy

Staging is a copy of the website at a separate address, hidden from search engines and visitors. Some hosting providers let you create it from the control panel. All updates are installed on it first. The WordPress test team’s FAQ for the 7.0 release explicitly advises against updating a live website right away without checking it first and recommends calmly waiting until you have tested your website.

The copy should be fresh, made right before the update. A three-month-old staging copy with a different set of plugins does not test anything.

3. Update order

On the staging copy:

1. Read the changelogs and requirements of major plugins (WooCommerce, the page builder, caching, payment modules): whether they mention incompatibilities and which WordPress version they need.
2. Decide what to update first. If the new version of a plugin requires a newer core, start with the core: for example, WooCommerce 10.8 requires WordPress 6.9 or later and explicitly recommends updating WordPress first. If there are no such requirements, we recommend first updating the plugins and the theme to versions that work on the current core, and installing the major core version as a separate step. Then, if something fails, you can see right away what caused it.
3. Update plugins one at a time, starting with the ones others depend on: WooCommerce first, then its extensions. Open the website after each one.
4. Update the theme. If it is a child theme, update the parent theme.
5. Run the test scenarios (below).

Then repeat the same sequence on the live website during the hours with the fewest orders and run the checks again.

We do not recommend installing major core versions on a live website on release day. Wait for fixes from the main plugins and test the website on a copy. The case of WP Rocket and WordPress 7.1 shows why: websites that postponed the core update by even a couple of days could already install the fixed version of the plugin by then. Postponing for six months is also bad: new plugin versions stop supporting the old core, as in the WooCommerce example. The next major version, WordPress 7.2, is scheduled for December 8, 2026.

With plugin security updates, the logic is the opposite: they are installed quickly. According to the Patchstack report for 2025, the weighted median time to first exploitation for heavily attacked vulnerabilities was 5 hours. If a plugin’s changelog says “security fix,” install the update the same day, after checking at least the main scenarios.

4. Test scenarios

“The home page opened” does not yet mean the website works. Write down the scenarios once and run through them after every update:

• the home page, the catalog, a product page (for variable products, select several variations);
• search and filters;
• the cart, checkout, a test payment or at least the redirect to the payment system page;
• the order email reached the customer and the manager, the order appeared in the admin area and, if there is an integration, in the accounting system or CRM;
• lead forms: the request reached the inbox or CRM, not just showed “Thank you”;
• logging in to the customer account and to the admin area;
• the mobile version;
• all of the above after clearing the plugin, server and CDN cache.

5. Monitoring after the update

Some errors do not show up right away: on a rarely visited page, in a background task or when paying with a specific method. Uptime monitoring will alert you if the website stops responding. Make a point of opening the PHP error log in the hosting control panel (not debug.log, which we turned off) during the first days after the update. Do not delete the backup made before the update until you are sure everything works.

Automatic updates: on or off

Since version 5.5, WordPress lets you enable automatic updates for each plugin and each theme separately: the “Automatic Updates” column on the “Plugins” page and a link in the theme details. By default, they are turned off. WordPress emails the administrator about successful or failed automatic updates; these emails need to be read, not filtered away. Learn more in the wordpress.org documentation on automatic updates.

Our position:

• Minor core updates: leave them on. These are fixes and security patches; the core developers write that disabling them is strongly discouraged.
• Major core updates on a website that sells: install them manually following the maintenance schedule and turn off automatic upgrades to new versions (how to do this is described in the section on built-in rollback).
• Plugins that handle money (WooCommerce and its extensions, payments, shipping, the page builder, caching): update them manually through the staging copy. The YOP Poll case shows that a single plugin update can lock you out of the admin area. An automatic update runs without you, often at night, and the built-in check looks only at the home page. Customers will be the first to see an error at checkout.
• Simple plugins that do not affect orders or layout (for example, a redirect or sitemap plugin) can be left on automatic updates.

The exception is a website that nobody looks after regularly. For such a website, automatic updates are better than two-year-old plugins: in our view, the risk of seeing a critical error is lower than the risk of a hack through a vulnerability that was fixed long ago. The most reliable option is to assign someone who will update the website following the maintenance schedule.

When to handle it yourself or call a specialist

A website owner or marketer can handle it on their own if:

• the email arrived, the link works and the email names a specific plugin;
• there is access to the files, and it is clear which folder to rename;
• there is a fresh backup, and the hosting provider restores it with one click.

Call a specialist if:

• the log shows an error in the theme or in custom-written code;
• the error appears only at checkout, in payments or in data exchange with the accounting system;
• after a plugin rollback, the database broke or orders disappeared;
• the cause is the PHP version and it cannot be rolled back because the hosting provider no longer offers the old version;
• nobody knows what exactly was updated, and there is no backup.

How RIVERIT helps with this

We offer WordPress technical support for your website. We usually run core, theme and plugin updates once a month. Backups are included in support, and we monitor the website and domain. We respond to clients on support within one hour during business hours and to everyone else within one business day; if the website goes down at night or on a weekend, we fix it outside business hours too, if your plan includes this. For websites on Laravel or Django, there is a general section on website support and maintenance. We calculate the cost based on the scope and complexity of the website.