If an update left your site showing "There has been a critical error on this website" or a blank page, switch the plugin off before you think about restoring a backup. Disabling the plugin is reversible; restoring a backup overwrites everything that changed since the backup was made, including orders, form entries and posts.

Here is the order, from the least to the most drastic step. Stop as soon as the site works.

1. Look for the recovery email

Since version 5.2, WordPress watches for this kind of crash. When it happens, visitors see the critical error message and WordPress emails the site's admin address a link to log in using Recovery Mode. The email also includes details about the error.

Click the link and log in. The faulty plugin is paused for your login only; visitors still see the error. Go to the Plugins screen, deactivate the plugin named in the notice, then exit Recovery Mode and check the site.

Check the spam folder before deciding the email never came. The WordPress documentation explains why it can go missing: if the crash happens before the plugin that normally sends your site's email has loaded, the message goes out straight from the web server and may be filtered as spam or blocked. Also check which address it went to. It's the admin email in the site's settings, which may be an old address or a developer's.

2. No email? Rename the plugin's folder

You can switch a plugin off without logging in to WordPress by renaming its folder. You need your host's file manager or an SFTP login, nothing else.

  1. Open the folder wp-content/plugins.
  2. Find the folder of the plugin you just updated. Look for a folder named after the plugin, for example contact-form-7.
  3. Rename it, for example to contact-form-7-off. WordPress can no longer load it, so it treats the plugin as switched off.
  4. Reload your site in a private browser window.

If the site comes back, you've found the cause. Renaming the folder back undoes the step; leave it renamed until the developer releases a fix.

If you updated several plugins at once and don't know which one did it, switch them all off. The WordPress troubleshooting FAQ describes this:

  1. Rename the plugins folder itself to plugins.hold. Every plugin stops loading.
  2. Log in at yoursite.com/wp-admin/plugins.php. WordPress will report the plugins as missing and deactivate them.
  3. Rename plugins.hold back to plugins. The plugins are back on disk but stay deactivated, and their settings are kept.
  4. Activate them one at a time from the Plugins screen, reloading the site after each. The one that brings the error back is your culprit.

One warning for shops and booking sites: if the shop or the booking system is itself a plugin, it goes offline with the rest. Do this at a quiet hour and work through the list quickly.

3. Read the error if you still can't tell which plugin

When the recovery email is missing and renaming one folder didn't help, the error message tells you where to look. WordPress can write errors to a log file without showing them to visitors.

  1. Download a copy of wp-config.php from your site's main folder. That copy is your way back.
  2. Open the file and add these lines just above the line that says to stop editing:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
  1. Reload the broken page once.
  2. Open wp-content/debug.log and look for a line containing "Fatal error". The file path in that line shows which file failed; if it is under wp-content/plugins/, the next folder name is the plugin.
  3. Put the original wp-config.php back, and delete debug.log.

Keep this short. The WordPress debugging guide says debug settings aren't recommended on live sites, so they should be on for minutes, not days.

4. Restore a backup only as the last step

Restoring is right when the site is still broken with every plugin switched off, or when you can't find the cause and need the site back today. It is not undo for one plugin: it rolls back the whole site to the backup date.

Before you restore:

  1. Download the current state, files and database, even though it's broken. If the restore goes wrong, this is what you go back to.
  2. List what happened since the backup date. Orders, bookings, form entries, new posts and comments made after that date will be gone. Export or note anything you need.
  3. Restore files and database from the same date. New plugin files with an old database, or the reverse, can leave the site in a worse state than before.

5. After the site is back

Clear every cache you have: the caching plugin, your host's cache if it has one, and your browser. Otherwise you may still be looking at a stored copy of the broken page.

If visitors see "Briefly unavailable for scheduled maintenance", an update was interrupted. WordPress puts a file named .maintenance in the site's main folder during updates; delete it and run the update again.

Then check the pages that make you money: the contact form, the booking page, the checkout. Keep the broken plugin off until its developer has released a fix, and read the plugin's support page before updating it again.

Updating safely next time

Must have: a backup of files and database made right before you update, downloaded to your own computer, and one plugin updated at a time with a check of the site after each. Also know your file manager or SFTP login and make sure the admin email goes to an address you read.

Nice to have: a staging site, which is a private copy of your site where you run updates first. If your host offers it, it's the safest way to test a big update, such as a new major version of your shop plugin.

At Hostinger, for example, WordPress staging needs the Business web hosting plan or higher, and so do manual backups on the entry-level plans. Publishing the staging copy replaces the live site's files and database, so anything that changed on the live site after you created the staging copy is lost. For a site that takes orders or bookings, use staging to test the update, then run the same update on the live site rather than publishing the copy over it. Hostinger's restore also replaces your current files and database with the backup, and its own guide suggests downloading your current data before you restore.