A plugin update broke your WordPress site: how to recover and prevent it next time

It usually starts with an email from a client: “the site looks strange” or “the checkout doesn’t work anymore”. You check the dashboard and everything says “update successful”. And yet the site is broken. This guide walks you through what to do in the first ten minutes, how to get the site back without losing today’s orders or form entries, and how to make sure the next update doesn’t do the same thing.

First ten minutes: find out what actually broke

Resist the urge to click “update” on something else or to restore the whole site straight away. First establish what kind of breakage you are looking at. There are three common types, and each has a different fix.

• White screen or a “critical error” message. PHP stopped. Usually a plugin that is incompatible with the PHP version or with another plugin. WordPress sends an email to the admin address with the name of the plugin and the file that failed; check that inbox first.
• The site loads, but something looks wrong. A menu that no longer opens on mobile, a product grid that lost its columns, a form that renders as plain text. These are layout and JavaScript problems, typically caused by a theme, page builder or caching plugin update.
• The site looks fine, but something no longer works. Forms that don’t send, a checkout that stalls, logins that fail. Often a plugin that changed how it stores settings, or two plugins loading conflicting scripts.

Open the site in a private browser window on desktop and on a phone, and look at the five pages that matter most: the homepage, the main menu pages, the contact form, the shop and checkout if there is one, and the login page. Write down what you see. You will need this list again when you check the fix.

Step 1: identify the update that caused it

Go to Dashboard → Updates, or to Plugins, and look at which plugins, themes or core versions changed today. If several updates ran at once, the most likely suspects are, in this order: the page builder or theme, WooCommerce and its extensions, caching and optimisation plugins, and security plugins. Anything that touches how pages are rendered or how scripts are loaded is more likely to cause visible breakage than a small utility plugin.

If you can still reach the admin area, enable debugging briefly to see the actual error: add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to wp-config.php, reload the broken page, and read wp-content/debug.log. The first lines of the log usually name the plugin. Turn debugging off again afterwards; it should never stay on for a live site.

Step 2: get the site back, in the least destructive way

Work from the smallest fix to the biggest. Each step below is less precise and more disruptive than the one before it, so stop as soon as the site works again.

1. Clear every cache. Page cache, object cache, CDN cache and the browser. A surprising number of “broken” updates are the old CSS being served with the new HTML. If the site is fine after a hard refresh on a page that was not cached, you are done.
2. Deactivate the suspected plugin. If you can log in, deactivate it and check the five pages again. If you cannot log in, rename its folder over SFTP or in your hosting file manager (wp-content/plugins/plugin-name to plugin-name-off); WordPress will deactivate it on the next page load.
3. Roll back that one plugin to the previous version. Most plugins on WordPress.org keep older versions under “Advanced view” on their plugin page. Download the previous version, delete the broken one, upload the old one, reactivate. For premium plugins, the vendor’s account area usually has older releases. This keeps all of today’s content and orders intact, because you only touched the plugin’s files.
4. Only then restore from a backup. A full restore puts the files and the database back to the moment of the backup. Everything the client did since then, such as orders, form entries and edits, is lost unless you merge it back by hand. Before you restore, check when the backup was made and ask the client what has happened on the site since. If possible, restore only the files and keep the current database; many backup tools allow that.

After each step, go through your list of five pages on desktop and mobile again. “The homepage loads” is not the same as “the site works”.

Step 3: tell the client before they tell you

Send a short message as soon as the site is back: what broke, for how long, what you did, and what you will do to prevent it. Clients forgive a broken update; they do not forgive finding out from a customer. A two-line message is enough. Keep the technical detail for your own notes.

Step 4: make sure it doesn’t happen again

Every broken update in this guide has the same root cause: the update ran on the live site, and the first check happened after it was already live. The fix is to change the order, not to stop updating. A routine that works for agencies with many client sites:

• Keep a fresh backup, every night. Files and database. A backup you can actually restore from, which means you have tested a restore at least once.
• Run the update on a copy of the site first. Not on the live site. If your hosting has no staging feature, a copy in a subfolder of the same server works for most sites; see our guide on testing WordPress updates before going live.
• Compare the key pages, on desktop and on mobile, before and after. Most breakage is visual and does not throw an error. Screenshots before and after catch it; our guide on visual regression testing for WordPress explains how.
• Update the live site only after the copy passed, and check it once more. The full routine, including what to do after the update, is in our WordPress update checklist for agencies.
• Update in small batches. One page builder update on its own tells you more than twelve updates at once. When something breaks, you know what caused it.

Frequently asked questions

Can I undo a WordPress plugin update?

Yes. WordPress itself has no undo button, but you can install the previous version of the plugin by hand (older versions are available on the plugin’s WordPress.org page under “Advanced view”, or in the vendor’s account area for premium plugins), or use a plugin-rollback tool. Deactivate or delete the current version first, then upload the older one. Your settings normally stay in the database.

Will restoring a backup lose my client’s recent orders?

A full restore puts the database back to the time of the backup, so any orders, entries or edits made after that moment are gone unless you add them back by hand. That is why rolling back a single plugin is the better first move, and why a restore should only be the last resort. If you must restore, restore the files only and keep the current database when your backup tool allows it.

The dashboard said “update successful”, so why is the site broken?

“Successful” only means the new files were copied into place. WordPress does not check whether the layout, the forms or the checkout still work afterwards. That check has to be done on the site itself, page by page, on desktop and on mobile. Doing it on a copy before the live update is what prevents the client email in the first place.

How do I stop WordPress from auto-updating plugins?

On the Plugins screen, each plugin has an “Enable/Disable auto-updates” link. Turning auto-updates off for page builders, WooCommerce and theme-related plugins is reasonable; keep them on for small security plugins if you do not update often. Better still is a routine where every update, automatic or not, is tested on a copy first.

Related guides: WordPress update checklist for agencies, How to test WordPress updates before going live, Visual regression testing for WordPress updates. See also how Verploy handles safe updates.