You clicked update and now something is wrong. Maybe the whole site is a white screen. Maybe it loads but the layout has collapsed, or the checkout throws an error.
The instinct is to start fiddling. Do not. Rolling back is straightforward if you go in the right order, and the wrong order is how a fixable problem becomes a rebuild.
First, stop and identify what changed
Before you touch anything, answer one question: what did you just update?
If you updated one plugin, you already know the cause and this will take five minutes. If you bulk updated twelve, you have twelve suspects, which is the argument for updating one at a time.
Also check whether the site is actually down or just looks wrong to you. Open it in a private browsing window and purge your cache. A surprising share of "the update broke my site" turns out to be your browser or your cache serving a mix of old and new files. Thirty seconds of checking can save you an unnecessary restore.
Option 1: deactivate the plugin
The least destructive move. If the site loads and the admin is reachable, go to Plugins and deactivate whatever you just updated.
The site should come back immediately, minus that plugin's functionality. If your booking form is gone for an hour, that is usually better than the whole site being broken.
If you cannot reach the admin at all: log into your host's file manager or connect over FTP, go to wp-content/plugins, and rename the plugin's folder, for example from contact-form to contact-form-off. WordPress will not find the plugin, will deactivate it automatically, and your admin should come back. Rename it back when you are ready.
Also check your email. If the update caused a fatal error, WordPress often sends the site admin address a recovery mode link that lets you log in and deactivate the plugin even when the front end is down.
Option 2: reinstall the previous version
Deactivating gets the site up. Rolling back gets the functionality back too.
For plugins in the WordPress repository, every past version is publicly available. On the plugin's page on wordpress.org there is an Advanced view with a version dropdown, and you can download the exact version you were running before. Then delete the broken version in your admin and upload the older one as a new plugin.
Deleting a plugin in WordPress does not usually delete its settings, which live in the database, so your configuration normally survives. Usually is doing some work in that sentence, which is why you take a backup first.
There are also rollback plugins that do this from inside your admin in a couple of clicks. Worth having installed before you need it, not after.
Then stop the update happening again. If auto-updates are on for that plugin, it will reinstall the broken version overnight and you will repeat the whole exercise. Turn auto-updates off for it until the author ships a fix.
Option 3: restore from backup
The blunt instrument. Use it when the site is badly broken, when you cannot work out which of several updates caused it, or when a rollback has not fixed things.
One thing to understand before you press it. Restoring a full backup puts the site back to how it was at the moment the backup ran. Anything that happened since then goes away. Orders placed, form submissions received, comments, a blog post you published this morning. On a site that takes transactions, that window matters.
The fix: before restoring, export anything that arrived since the backup ran. Orders, form entries, enquiries. Then restore, then reconcile. If the outage started an hour ago and your backup is a week old, restoring the database is a much bigger decision than restoring the files.
Where you can, restore files only and leave the live database alone. That undoes the code change without throwing away a week of data.
What to do after it is working again
Do not just move on. Two follow ups take ten minutes and prevent a repeat.
Report it to the plugin author, on the support forum for a free plugin or by ticket for a paid one. Say what version you moved from and to, what broke, and what your PHP and WordPress versions are. Authors fix these quickly when they can reproduce them.
Then keep an eye on the changelog and reapply the update once a fix ships. Staying on an old version forever is not a solution, it is just a slower problem, because the version you rolled back to stops receiving security patches.
Why you should not be the one doing this
Everything above assumes you are available, calm, and near a computer when the update goes wrong. In practice it goes wrong on a Saturday, or while you are with a customer, or overnight when an automatic update fired at 3am and nobody looked at the site until Monday.
This is exactly what the Up Speed care SLA covers, and it is worth being precise about the promise. We test each update before it goes live, and if one breaks something, we roll it back. Not "updates never break", because on any site they sometimes do. The difference is that the checking and the rollback are somebody's actual job rather than something you discover you need at the worst moment.
That sits alongside scheduled off-site backups with one click restore and 30 day retention, 24/7 uptime monitoring on 60 second checks, and a real human replying within 48 hours on Starter. Most hosts will tell you the server was up the whole time, which is true and no help at all when the problem is a plugin.
The Starter plan covers tested updates, rollback and backups for one site. If downtime costs you money by the hour, the Premium plan adds a 1 hour emergency response instead.