Updating WordPress breaks a site more often than anyone would like: version conflicts, outdated code in a theme, an incompatible plugin. Here is a safe update procedure and a way to roll back if something goes wrong.
Why a WordPress update can break a site
WordPress core, plugins, and the theme evolve independently of each other. A plugin author might rely on a function that core developers marked deprecated and removed in a new release — the site gets a white screen right after the update. A theme written for WordPress 6.0 is not guaranteed to run without errors on WordPress 6.7.
The risk grows if a site has more than 15-20 plugins installed or runs an outdated PHP version. A gap between the PHP version on the server and the minimum requirements of a new plugin is a common cause of a 500 error after an update; diagnosing that error is covered in the article White Screen and 500 Error in WordPress: Find the Cause.
Preparation: a backup before every update
A rule with no exceptions: updating without a fresh backup is a gamble, not proper work. The backup must include the site files and the entire database, not just the theme folder. The process for creating and restoring a backup is described in the article WordPress backup: UpdraftPlus and the manual method.
Before starting an update, check the date of the last backup in the backup plugin's panel. If the copy is older than a day, make a new one manually instead of relying on the schedule.
Update order: plugins, theme, core
Update components one at a time, not all at once through the "Update All" button:
- Plugins first — one by one, checking the site after each.
- Then the child or main theme.
- WordPress core last.
This order narrows the search for the culprit to a single component if the site breaks. Updating twenty plugins at once turns finding the conflict into hours of work; updating one at a time turns it into minutes.
Updating through WP-CLI on the server
From the terminal, updates run faster and log more conveniently:
# Show the list of plugins with updates available
wp plugin list --update=available
# Update a single plugin
wp plugin update plugin-name
# Update WordPress core to the latest version
wp core update
The full list of commands for managing updates and backups from the terminal is in the article WP-CLI: managing WordPress from the command line. The wp core update command creates a database restore point before the schema migration on its own, but it does not back up files — that has to be prepared separately.
How to check a site after an update
Opening a production site right after an update is risky. The right order is to run the update on a staging copy first and repeat it on production afterward; how to set up a test copy is described in the article Staging site for WordPress: a test environment without risk.
After the update, check at least three things: the home page with no errors in the browser console, the contact form or the cart if WooCommerce is installed, and the admin panel — logging in as an administrator and saving any post.
Rollback: how to restore the previous version
If the site breaks after an update, follow this plan:
| What broke | Action |
|---|---|
| One plugin | Roll back the plugin through the version archive or restore its files from a backup |
| Theme | Restore the theme folder from a backup, leaving core and plugins alone |
| WordPress core | Restore the entire database and files from the backup made before the update |
A full site restore from an archive is usually faster than manually hunting for a compatible plugin version. Checklist before starting every update:
- A fresh backup of files and the database, no older than a day.
- The update tested on a staging copy.
- Components updated one at a time, not all at once.
- The home page, a form, and the admin panel checked after the update.