How to update WordPress safely with WP-CLI: backup, update, verify, roll back

Updates are the single most effective thing you can do for a WordPress site's security, and also the most common cause of "the site broke this morning". The fix is not to avoid updates but to make them boring: back up, update in a fixed order, verify, and know exactly how to roll back.

This guide gives you that routine using WP-CLI, the official command-line tool for WordPress. Every command below is from the WP-CLI command reference, and the backup and restore order follows the official Advanced Administration Handbook. The current WordPress release is 7.1.3, a security release published on 6 October 2026 with seven security fixes, so there is a good reason to practise now.

You will need SSH access to the server (or a container with WordPress), and permission to run PHP on the command line. If your host does not offer SSH, the same order of steps applies through its dashboard and backup tools.

Step 0: Install WP-CLI

WP-CLI requires PHP 7.2.24 or later and has no other requirements beyond those of WordPress itself. The recommended install is the Phar archive:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

Many managed hosts already include wp; run wp --info to check. If the server has several PHP versions, the WP-CLI handbook explains how to use a custom PHP binary by putting it first in your PATH. The handbook also publishes a wp-cli.phar.asc signature you can check with gpg --verify before installing.

Step 1: See what will change

Before touching anything, record the current state. These commands are read-only:

cd /var/www/example.com/htdocs      # your WordPress root

wp core version
wp core check-update
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available --fields=name,version,update_version

# Baseline: are core files untouched before we start?
wp core verify-checksums

Read the changelogs for any plugin jumping a major version. A clean verify-checksums result now also gives you a baseline: if it fails later, you know the update caused it.

If a major WordPress release is waiting (for example from 7.0 to 7.1), read the release post and field guide first. WordPress 7.1 made the post editor always load in an iframe, which can affect older plugins that add editor scripts.

Step 2: Back up the database and the files

The handbook's backup page stresses that a WordPress backup has two parts, and that copying the WordPress folder does not back up the database. It recommends backing up the database first and then the files, and keeping both together as one set:

STAMP=$(date +%Y%m%d-%H%M)
BACKUP_DIR="$HOME/backups/example.com/$STAMP"
mkdir -p "$BACKUP_DIR"

# 1. Database first
wp db export "$BACKUP_DIR/db.sql" --add-drop-table

# 2. Then the files (core, wp-content, wp-config.php, .htaccess)
tar -czf "$BACKUP_DIR/files.tar.gz" -C /var/www/example.com htdocs

# 3. Prove the backup is usable
ls -lh "$BACKUP_DIR"
gzip -t "$BACKUP_DIR/files.tar.gz" && echo "archive OK"

wp db export runs mysqldump with the credentials from wp-config.php and accepts any valid mysqldump flag, such as --add-drop-table above. If you omit a file name, it creates one named after the database and date.

Two rules from the handbook are worth repeating:

• Verify the backup is there and usable before updating. The manual upgrade instructions call this "essential".
• Keep copies off the server. The handbook suggests three to five recent backups in different places, such as the server, cloud storage and a local machine. Copy $BACKUP_DIR elsewhere with rsync or your storage tool of choice.

Step 3: Update in a fixed order

Update core first, then plugins, then themes, then translations. Running wp core update-db after a core update applies any database changes the new version needs, the same routine the browser-based updater runs after an upgrade.

# See what would change, without changing anything
wp plugin update --all --dry-run

# Core: update, then run any database upgrade routine
wp core update
wp core update-db

# Plugins and themes
wp plugin update --all
wp theme update --all

# Translations
wp language core update
wp language plugin update --all
wp language theme update --all

WP-CLI puts the site into maintenance mode while it replaces plugin files and takes it out again afterwards. If a run is interrupted and you see "Another update is currently in progress", the reference advises deleting the core_updater.lock option with wp option delete core_updater.lock, but only after confirming no other update is actually running.

Being selective

You do not have to update everything at once. wp plugin update supports exclusions, minor-only and patch-only updates, and pinning to a version:

# Hold back a plugin you need to test separately
wp plugin update --all --exclude=woocommerce

# Only take minor/patch releases of plugins today
wp plugin update --all --minor

# Pin a plugin to a known version (also how you roll one back)
wp plugin update my-plugin --version=2.3.1

The --version flag is also the quickest way to roll back a single plugin, provided the old version is still available from its source.

Step 4: Verify the result

Check integrity first, then behaviour:

wp core verify-checksums
wp plugin verify-checksums --all
wp db check

# Quick HTTP smoke test of key pages
for path in / /blog/ /contact/ /wp-login.php; do
  printf '%s ' "$path"; curl -s -o /dev/null -w '%{http_code}\n' "https://example.com$path"
done

Then check by hand what matters to the business: log in, edit and preview a post, submit the contact form, place a test order if you run a shop, and look at the PHP error log. Open Tools → Site Health to see whether WordPress reports new critical issues.

Step 5: Roll back if something breaks

If the site is broken and a single plugin is the cause, deactivate it with wp plugin deactivate <name> or pin it to the previous version. If the problem is wider, restore the backup set. The handbook's restore order is files first, then the database:

# Put the site in maintenance mode while you restore
wp maintenance-mode activate

# Restore files, then the database (restore order from the handbook)
tar -xzf "$BACKUP_DIR/files.tar.gz" -C /var/www/example.com
wp db import "$BACKUP_DIR/db.sql"

wp maintenance-mode deactivate

wp db import reads the SQL file using the credentials in wp-config.php. By default it also relaxes SQL modes that WordPress core disables, so older dumps with legacy values import cleanly. If database credentials changed during a migration, update wp-config.php before importing.

Practise this on a staging copy at least once. A backup you have never restored is an assumption, not a plan.

Step 6: Decide what to automate

WordPress has four kinds of automatic background updates: core, plugins, themes and translations. According to the upgrade documentation:

• Minor core updates (maintenance and security releases) and translations are enabled by default, and disabling them is "strongly discouraged".
• Since WordPress 5.6, new installations also auto-update to major releases, unless WordPress detects a version-control checkout. Existing sites keep their earlier behaviour until an administrator, constant or filter changes it.
• WP_AUTO_UPDATE_CORE in wp-config.php accepts true, false or 'minor', and overrides the setting on the Updates screen.

A reasonable policy for a small business site is: minor core updates automatic, major core updates by hand after a backup, and automatic updates enabled for low-risk plugins only. WP-CLI can switch plugin auto-updates on:

# Turn on background auto-updates for selected plugins
wp plugin auto-updates enable akismet query-monitor

# Or for every plugin that does not have them yet
wp plugin auto-updates enable --all --disabled-only

For sites deployed from Git, keep updates in your repository instead and set DISALLOW_FILE_MODS so nobody updates production from wp-admin. Run the same update commands on a development copy, commit the result and deploy it.

A one-page update runbook

1. Read release notes for core and any major plugin updates.
2. wp core check-update, wp plugin list --update=available.
3. wp db export, archive files, verify, copy off-server.
4. wp core update and wp core update-db.
5. wp plugin update --all (with --exclude for risky ones), wp theme update --all, language updates.
6. wp core verify-checksums, wp plugin verify-checksums --all, wp db check.
7. Smoke-test key pages and editor; check error logs and Site Health.
8. If broken: deactivate or pin the culprit, or restore files then database.
9. Note what changed and when, for the next person.

Next steps

Turn the commands above into a script stored with your site's documentation, and run it on staging before production for major releases. Schedule it monthly at a minimum, and immediately when WordPress publishes a security release such as 7.1.3.