How to Roll Back a WordPress Update Safely

A rollback replaces the files an update installed with the files that were there before. It does not touch your posts, pages, comments, uploads or settings, because those live in the database and in the uploads folder, and a rollback does not go near either. That is the short answer to the question that stops most people: your content is not what is at risk here. What is at risk is the opposite, and it is worth understanding before you start: the update may already have changed something in the database, and putting older files back does not change it back.

This article covers three separate procedures, because “roll back the update” means three different jobs depending on what was updated. It also covers the case where the right answer is not a rollback at all.

Version and verification. Written against WordPress 7.0.2, released 2026-07-17, current stable. WordPress 7.0 shipped 2026-05-20. Last verified 2026-07-30 against WordPress’s own documentation.

Before anything: the backup you have not tested is an assumption

Do not start a rollback without a backup you have confirmed you can restore.

That is not the same instruction as “make a backup”. A backup file that exists, that your host says it takes nightly, or that a plugin reports as successful, is an assumption until someone has restored one. The failure mode this warns against is specific and common: a rollback goes wrong, the reader reaches for the backup, and discovers the backup is incomplete, or is a database dump with no files, or cannot be restored without the host’s help on a Sunday.

So before you touch anything: find out where your most recent backup is, find out whether it contains both the database and the files, and find out what the actual restore procedure is. If your host takes the backups, that procedure is in their control panel and you should read it now rather than later.

What can go wrong in a rollback, stated plainly: installing an older version of a plugin can produce a version mismatch with data the newer version already wrote, which can leave a feature non-functional in a new way. Rolling back WordPress core across a major version, after the database has already been upgraded, can leave the site unable to load the admin at all. Neither is likely. Both are recoverable from a working backup and difficult to recover from without one.

Why “will I lose my content” is the right question, and the real answer

Your site is two things that get updated at two different moments.

Files are WordPress core, your theme, your plugins, and your uploads. An update replaces core files and plugin or theme files. It does not replace uploads.

The database holds your posts, pages, comments, users, options and settings. A WordPress update sometimes needs to change the structure of the database, and it does that in a separate step. Plugins do the same thing on their own schedule: a major plugin version often migrates its own stored data on first activation.

A rollback puts older files back. It does not, and cannot, undo a database migration. That is the whole risk profile of a rollback in one sentence, and it explains why rolling back a plugin the same afternoon is nearly always fine, while rolling back core three weeks after a major release is not. If you want the full sequence of what an update does and in what order, what actually happens during a WordPress update sets it out phase by phase.

Which of the three rollbacks do you actually need?

Answer this before you do anything, because the procedures are different and doing the wrong one wastes the afternoon.

One plugin’s feature stopped working, right after that plugin updated. You need a plugin rollback. This is the most common case and the safest.
Your design changed, or a layout broke, right after a theme update. You need a theme rollback, and there is a good chance you do not want one, for reasons below.
The admin will not load, or many things broke at once, right after WordPress itself updated. You may need a core rollback, and this is the case where restoring a backup is often better.

If you are not sure which of these you are in, the triage in plugin not working after the update narrows it in about two minutes, and if you are looking at “There has been a critical error on this website”, start with the critical error walkthrough instead, because recovery mode may get you back into the admin without any rollback at all.

Rolling back a plugin to its previous version

Every plugin hosted in the WordPress.org directory publishes its own older versions, and you do not need a third-party tool to get them.

Write down the version you are on and the version you want. The current version is on the Plugins screen. The version you want is the one before it, which the plugin’s changelog will name.
Go to the plugin’s page in the WordPress.org directory and open its Advanced View. The URL pattern is wordpress.org/plugins/PLUGIN-SLUG/advanced/.
Find the Previous Versions section, select the version you want from the selector, and download the zip.
Read the warning on that page before you continue. WordPress.org states directly that previous versions of plugins may not be secure or stable, and are not recommended for use on production websites. That warning is accurate and it is the reason a rollback is a temporary measure rather than a destination.
Deactivate the plugin. Do not delete it yet.
Delete the plugin. Deleting a plugin through the Plugins screen removes its files. Most plugins leave their database tables and settings in place, which is why the rollback usually keeps your configuration, but a small number offer to remove their data on deletion, and if you are prompted, decline.
Upload the older zip through Plugins > Add New > Upload Plugin, and activate it.
Turn off auto-updates for that plugin, on the Plugins screen, in the Automatic Updates column. Otherwise WordPress will reinstall the version you just removed, on its own, within about half a day.

Step 8 is the one people skip, and it is why some rollbacks appear to undo themselves overnight. WordPress runs auto-updates twice a day by default for any plugin that has them enabled.

If the plugin is commercial and not in the WordPress.org directory, its older versions come from the vendor’s own account area. There is no generic path, and if the vendor does not publish previous versions, a rollback is not available to you and a backup restore is the only route.

Rolling back a theme without losing your customizations

The procedure is mechanically the same as a plugin: get the previous version from the theme’s Advanced View in the WordPress.org directory, and install it over the current one.

The important part is the reason you are doing it. If your design reverted after a theme update, the cause is usually not the new version being faulty. It is that customizations were made by editing the theme’s own files, and a theme update replaces those files. Rolling back restores your work, and the next update will destroy it again.

So treat a theme rollback as a way to buy time, not as a fix. The permanent fix is that theme-file customizations belong in a child theme, and settings-based customizations belong in the theme’s own options, both of which survive updates. If your customizations were made through the site editor or the theme’s settings screens rather than by editing files, then a theme update did not overwrite them, and whatever broke is something else.

Rolling back WordPress core, and when not to

WordPress publishes every past release. Its own update documentation names the release archive at wordpress.org/download/release-archive/ as the route back to a previous version, and it is worth reading their exact framing: they present restoring your backup and replacing the files from the previous version as one combined recovery step, not as two alternatives.

Rolling back a minor release (7.0.2 back to 7.0.1, for example) is comparatively low risk, because minor releases rarely change the database structure.

Rolling back a major release (7.0 back to 6.9) is a different proposition. The 7.0 update ran a database upgrade. Older core files do not expect the upgraded database. You may get a working site. You may get an admin that will not load.

If you are going to do it, the order is:

Confirm your backup, per the first section. This is not optional here.
Deactivate your plugins. WordPress’s own manual-update instructions include this step for the same reason.
Download the target version from the release archive and unpack it.
Replace the wp-admin and wp-includes directories entirely, and replace the loose files in the root such as index.php and wp-login.php.
Do not delete or replace your wp-content directory. Your themes, plugins and uploads live there. Copy only individual files from the archive’s wp-content if you have a specific reason to.
Do not replace wp-config.php. WordPress’s own instructions confirm it is not touched by a core update, and it holds your database credentials.
Load /wp-admin. If WordPress needs to adjust the database it will send you to /wp-admin/upgrade.php and tell you so.
Reactivate your plugins one at a time, not all at once.
If you see a “failed update” notice, delete the leftover .maintenance file from your WordPress directory. This is WordPress’s own documented instruction for that specific notice.

Nothing in this procedure asks you to edit a core file, and you should not. Replacing whole directories with official ones is not the same as editing code, and if you find yourself opening a PHP file in an editor during a rollback, stop.

The case where you should restore a backup instead

A rollback is the better choice when one component broke and you know which one. A backup restore is the better choice when:

WordPress core was updated across a major version and the site is badly broken. The database has already moved. A restore returns files and database together, consistently. A file rollback returns only half.
You cannot tell what broke. A restore does not require a diagnosis.
More than one thing updated at once, which is what happens when auto-updates fire overnight and you wake up to a broken site.
The site earns money and every hour matters. A restore is one operation with a known outcome. A rollback is an investigation.

The trade is that a restore also reverts anything that happened after the backup was taken, including posts, comments and orders. That is a real cost and it is why the timing of your most recent backup determines which of these two options is even available to you.

After the rollback: four things to check

Clear every cache. Your caching plugin, your host’s page cache, and your browser. WordPress’s own documentation calls this out because a stale cache makes a successful change look like it did nothing.
Log in from a private window. If login behaves oddly, clearing cookies is the documented first step.
Check the thing that was broken, then check three things that were not. Rollbacks fix the reported symptom and occasionally create an unreported one.
Check Tools > Site Health. It will tell you if PHP, background updates or the connection to WordPress.org are now in a different state than before.

How to not need this again

A rollback is an unwinding of a decision that was made too fast. The two things that remove nearly all of them are running the twenty-minute pre-update checklist before a major release, and applying the update to a copy of the site first if the site matters enough that an afternoon of downtime would hurt.

Neither is glamorous and both are considerably faster than the procedure above.