How to Roll Back a WordPress Plugin After a Bad Update

A plugin updated overnight and now something is wrong: the layout has shifted, the contact form doesn't send or checkout throws an error. The fastest way to stop the damage is usually to put the previous version back, then work out what went wrong with time on your side.

This guide covers when to roll back, four ways to downgrade a WordPress plugin (from one click to WP-CLI), how to roll back a theme or WordPress core, and what to do afterwards so the same update doesn't reinstall itself tonight.

When should you roll back a plugin?#

Roll back when an update clearly broke something that matters and you can't fix it in a few minutes. Typical signs:

• The layout broke. A page builder, theme add-on or block plugin update moves sections, drops styles or hides content.
• Checkout or cart stopped working. A payment gateway, WooCommerce extension or caching plugin update breaks the purchase flow. See WooCommerce checkout not working for other causes.
• A form stopped sending. Contact or lead forms fail silently after a form plugin or SMTP plugin update.
• SEO tags changed. Titles, canonicals or robots tags disappear or change after an SEO plugin update, which you won't see by looking at the page. Our WordPress SEO guide covers the tags worth watching.
• The site shows a critical error. If the update causes "There has been a critical error on this website", follow our WordPress critical error guide first. Recovery Mode can get you back into wp-admin to do the rollback.

Don't roll back for cosmetic changes you can fix with a setting, or when the update was a security release. If the changelog mentions a security fix, rolling back reopens the hole. In that case, fix forward or contact the author quickly.

Before you roll back: back up and check for database changes#

Plugin files are easy to swap. Data is not. Some plugin updates change the database as well as the code: they add tables, rename columns, migrate settings to a new format or convert stored data. WooCommerce, for example, can ask you to run a database update after a new version installs. Rolling back the plugin files puts the old code back, but the database stays in the new format. The old code may then misread its own settings or fail outright.

Before you downgrade:

1. Take a full backup of files and database, even though the site is already broken. You want a way back from the rollback too.
2. Read the changelog for the version you're leaving. Look for words like "database", "migration", "data update" or "schema".
3. Check for a database update notice in wp-admin after the update. If you ran one, rolling back the files alone may not be enough. Restoring a backup taken before the update is the safer route.
4. Test on staging if you can. Most managed hosts offer one-click staging. Try the rollback there first when the plugin handles orders, memberships or bookings.

Method 1: Use the WP Rollback plugin#

WP Rollback is a free plugin on WordPress.org that adds a Rollback option for plugins and themes installed from WordPress.org. It's the easiest method if you can still reach wp-admin.

1. Go to Plugins > Add New Plugin, search for "WP Rollback", then install and activate it.
2. Go to Plugins > Installed Plugins.
3. Under the plugin you want to downgrade, click Rollback.
4. Choose the version you were on before the update. Pick the last version that worked, not an older one.
5. Confirm the rollback and wait for WordPress to finish installing it.
6. Check the pages that broke.

It only covers plugins and themes hosted on WordPress.org, and it rolls back files only, not database changes. Deactivate it when you're done if you don't need it day to day.

Method 2: Download an older version from WordPress.org and upload it#

This works without installing anything extra.

1. Open the plugin's page on WordPress.org, for example https://wordpress.org/plugins/plugin-slug/.
2. Click Advanced View in the sidebar.
3. Scroll to the bottom to Previous versions, choose the version you want from the dropdown and click Download.
4. In wp-admin, go to Plugins > Add New Plugin > Upload Plugin.
5. Choose the zip file you downloaded and click Install Now.
6. WordPress sees the plugin is already installed and shows a comparison of the current and uploaded versions. Click Replace current with uploaded.
7. Check that Plugins > Installed Plugins shows the older version number.

You can also build the download link yourself, since WordPress.org uses one pattern for every version:

https://downloads.wordpress.org/plugin/plugin-slug.1.2.3.zip

For a premium plugin, log in to the vendor's account area. Most keep previous versions available to download, or will send one if you ask support.

If wp-admin is unreachable, upload the older version by FTP instead: rename the current folder in wp-content/plugins (for example to plugin-slug-broken), then upload the unzipped older version as plugin-slug. Delete the renamed folder once the site works.

Method 3: Use WP-CLI#

If you have SSH access, WP-CLI is the quickest and most precise way to downgrade a WordPress plugin:

# See the installed version first
wp plugin get plugin-slug --field=version

# Install a specific older version over the current one
wp plugin install plugin-slug --version=1.2.3 --force

# Confirm it worked
wp plugin list --name=plugin-slug --fields=name,status,version,update

The --force flag tells WP-CLI to overwrite the installed copy. The plugin keeps its active status and settings, because those are stored in the database, not in the plugin folder.

Method 4: Restore from a backup#

If the update ran a database migration, or several plugins updated at once and you don't know which broke things, restoring a backup taken before the update is often the cleanest fix.

• Host backups. Most managed hosts keep daily snapshots you can restore from the hosting dashboard.
• Backup plugin. If you use one, restore both files and database from the point just before the update.
• Partial restore. Some tools let you restore only the wp-content/plugins/plugin-slug folder and selected tables. That avoids losing orders or comments made since the backup.

Be careful on stores and membership sites: a full database restore wipes out orders, sign-ups and form entries created after the backup was taken. Export them first, or restore files only.

How to roll back a theme#

Themes break sites the same way plugins do. The options mirror the plugin ones:

• WP Rollback also adds a rollback option for WordPress.org themes. Open Appearance > Themes, click the theme for its details, then use the rollback button.
• WP-CLI:

wp theme install theme-slug --version=1.4.0 --force

• Manual download: WordPress.org theme versions use the same pattern as plugins, https://downloads.wordpress.org/theme/theme-slug.1.4.0.zip. Upload it through Appearance > Themes > Add New Theme > Upload Theme and choose to replace the current version.

If you edited the parent theme's files directly, a rollback or a reinstall overwrites those edits. Keep customisations in a child theme so you can swap parent versions safely.

How to roll back WordPress core (with care)#

Rolling back WordPress itself is possible, but it should be your last option, not your first.

wp core update --version=6.7.2 --force

Replace the version number with the release you were running before. You can find every release on the WordPress.org release archive.

Why to be careful:

• The database may not go back. A major WordPress release can update the database. Older code running against a newer database can behave unpredictably. Restoring a backup from before the update is safer.
• You lose security fixes. Minor releases often contain security patches. Staying on an older version keeps those holes open.
• The real culprit is usually a plugin. When a core update breaks a site, it's most often a plugin or theme that isn't compatible with the new version. Updating or rolling back that plugin is usually the better fix.

If you do downgrade core, treat it as a short-term measure while the incompatible plugin gets fixed.

After the rollback: stop the update coming back#

Once the older version is working, WordPress will show the newer version as an available update again. If automatic updates are on for that plugin, it will reinstall the broken version on its next run, often within hours.

Pause auto-updates for that plugin#

1. Go to Plugins > Installed Plugins.
2. In the Automatic Updates column, click Disable auto-updates for the plugin you rolled back.

Or with WP-CLI:

wp plugin auto-updates disable plugin-slug

If you manage auto-updates in code, the auto_update_plugin filter can exclude one plugin while leaving the rest on. Put it in a small must-use plugin in wp-content/mu-plugins:

<?php
add_filter( 'auto_update_plugin', function ( $update, $item ) {
    if ( isset( $item->slug ) && 'plugin-slug' === $item->slug ) {
        return false;
    }
    return $update;
}, 10, 2 );

Our guide to WordPress automatic updates explains which plugins are worth leaving on auto-update and which aren't. Recent WordPress versions also try to restore the previous version if an automatic plugin update causes a fatal PHP error, but that safety net doesn't catch a broken layout, a missing button or a changed meta tag.

Tell the plugin author#

A rollback fixes your site. A bug report fixes it for everyone, and gets you a version you can safely update to.

• For WordPress.org plugins, post in the plugin's support forum at https://wordpress.org/support/plugin/plugin-slug/.
• For premium plugins, open a ticket with the vendor.
• Include the version that broke and the version that works, your WordPress and PHP versions, what broke and the steps to see it. Tools > Site Health > Info has a Copy site info to clipboard button that gathers most of this.
• Watch the changelog. When a fixed release ships, test it on staging, then update and turn auto-updates back on if you want them.

How to know which plugin to roll back#

All of this assumes you know which update caused the problem. Often you don't. Several plugins updated overnight, the break was noticed days later, or a client only says "the site looks wrong".

Ways to narrow it down:

1. Check the update emails. WordPress emails the admin address after automatic updates, listing what was updated.
2. Compare versions. Run wp plugin list --fields=name,version,update and compare with the versions you expected.
3. Use troubleshooting mode. The Health Check & Troubleshooting plugin lets you disable plugins for your own session only, while visitors still see the normal site. Turn plugins back on one by one until the problem returns.
4. Compare before and after. If you have an older screenshot or a saved copy of the page, compare it with the live one. Our free website change detector shows what is different on a page right now.

MyKavo removes most of the guesswork. With the free MyKavo WordPress plugin connected, every plugin, theme and core update, including automatic ones, is followed by a scan of your monitored pages against your approved baseline. Anything that changed is labelled with the update that caused it, for example "Appeared after: Updated WooCommerce 8.1.0 -> 8.2.0", with before-and-after screenshots and the old and new values side by side. Activating or deactivating a plugin is checked the same way.

It also helps before the next update. On Plugins > Installed Plugins, a plugin whose last update changed things on your site is flagged: "Last time this plugin updated, 2 things changed on your site." That's a good cue to update that plugin on staging first. Update checks with a verdict are included in every paid plan, from Starter at $7 a month. On the free plan, updates are still listed so you can see what changed and when.

For a full routine around updates, read how to safely update WordPress plugins. If an update got interrupted halfway and the site shows "Briefly unavailable for scheduled maintenance", see WordPress stuck in maintenance mode before you roll anything back.

Summary#

Back up first and check whether the update changed the database. Then use WP Rollback, upload an older zip from the Advanced View page, or use WP-CLI. Restore a backup when data changed. Afterwards, disable auto-updates for that plugin, report the bug and update again only once a fix has passed on staging.