Roll back a WordPress update that broke your site, without losing data

What was updated?

Four things get updated on a WordPress site, and each one rolls back differently: WordPress core, the plugins, the theme, and the server’s PHP version, which your host upgrades on its own schedule. To find out which one moved:

• WordPress emails: after an automatic update, WordPress writes to the site admin address with a subject such as "[Site name] Some plugins were automatically updated", listing what changed.
• The Plugins screen: the "Automatic Updates" column shows which plugins update themselves, and each row shows the installed version.
• Tools > Site Health > Info: the Server section gives the PHP version, and the plugin and theme sections give each component’s version.
• Folder dates: a plugin folder rewritten by an update carries the date of that update.

wp plugin list
ls -lt wp-content/plugins | head

The first command lists plugins with their version and status; the second lists plugin folders from most recently modified to oldest. Match them against the time the site changed.

Clear the caches before drawing conclusions

After an update, CSS and JavaScript files change, and a cache can keep serving the old ones. The result looks like a failure: layout in pieces, menus that no longer open. Clear, in this order, your caching or optimization plugin’s cache, your host’s cache if it offers one, then your browser’s, and reload. If the site comes back, the update was not the problem.

The site is stuck in maintenance mode

During an update, WordPress creates a .maintenance file at the site root and shows "Briefly unavailable for scheduled maintenance. Check back in a minute." When the update is interrupted, the file stays behind. WordPress ignores it ten minutes after the time recorded inside it; to skip the wait, or if the message persists, delete it over SFTP or with your host’s file manager. Its name starts with a dot, so turn on hidden files to see it.

Then go to Dashboard > Updates: the item whose update was interrupted needs to be run again, or reinstalled at its previous version.

Put back the previous version of a plugin

Reinstalling the previous version replaces the plugin’s files and keeps its settings, which live in the database.

wp plugin install plugin-name --version=2.4.1 --force

• Plugin from the WordPress.org directory: on its public page, the "Advanced View" link leads to the "Previous Versions" list. Download the archive you need, then on the "Add Plugins" screen click "Upload Plugin": WordPress recognizes the installed plugin and offers "Replace current with uploaded".
• Plugin bought from a vendor: previous versions can usually be downloaded from your customer account with them.
• Then: click "Disable auto-updates" next to that plugin until the vendor ships a fix.

WordPress already rolls back on its own in two cases. Since version 6.3, when a plugin or theme update fails partway through, the old version is put back. Since version 6.6, when an automatic update of an active plugin causes a fatal error, WordPress reinstalls the previous version. An update that completes and breaks a feature without a fatal error still has to be rolled back by hand.

The theme: the previous version, and lost customizations

wp theme install theme-name --version=3.1.0 --force

A theme update replaces all of its files. Changes made directly in the theme’s files, in functions.php or a stylesheet for instance, therefore disappear with every update. The backup taken before the update lets you recover them; to keep them for good, they belong in a child theme, which updates to the parent theme leave untouched.

WordPress core

WP-CLI reinstalls a specific core version:

wp core update --version=7.0 --force

A major core update can also change the database structure, which this command leaves as it is. The safer route is often to keep core up to date and roll back the incompatible plugin or theme instead. If going back on core is unavoidable, do it from a full backup taken before the update.

The PHP version, changed by your host

Hosts move PHP forward as older versions stop receiving security fixes. An old plugin or theme can then stop on a fatal error. Hosting panels usually let you choose the site’s PHP version:

1. Note the current version, then switch back to the previous one.
2. Check that the site works again.
3. Update or replace the component at fault, identified through the debug log.
4. Switch back to the recent version.

That switch is a troubleshooting step: a PHP version without security fixes leaves the site exposed. According to the official schedule on php.net, PHP 8.1 has received no security fixes since 31 December 2025, PHP 8.2 receives them until 31 December 2026 and PHP 8.3 until 31 December 2027. WordPress recommends PHP 8.3 or newer.

Restore a full backup, as a last resort

A restore puts the files and the database back to the state of the backup. Everything the site has received since is lost: orders, form messages, comments, sign-ups, published posts.

1. First export what has arrived since the backup: orders, form entries, new accounts.
2. Restore files and database from the same moment, with your host’s tool or your backup plugin. Files from one day and a database from another produce errors that are hard to read.
3. Import the exported data again.
4. Reapply the updates one at a time, checking the site between each: the last one applied before the failure is the one causing it.

For the next update

• A test copy: many hosts offer a staging environment that copies the site in one click. Updates go there first.
• A backup right before, files and database together.
• One update at a time, with a check of the key pages in between: home page, contact form, cart.
• The changelog of the plugin or theme, read before a major update.