WP-CLI Commands Worth Automating in 2026

Preparation Before Automating WP-CLI Commands

Confirm you run WP-CLI 2.11 or newer in 2026, since older builds miss flags used here. Check with wp --info and look for PHP 8.2+ and the wp-cli.yml or wp-cli.local.yml in the project root. If you manage many sites, pin paths in wp-cli.yml so cron-driven scripts always target the right install. For staging parity before you script anything, review Setting Up a WordPress Staging Environment Safely so your automation never runs untested against production.

Set a backup policy first. Every destructive command in this guide assumes you have a .sql dump and a wp-content tarball. Store them outside the web root, for example /var/backups/wp/2026/, and record checksums. If your host varies, compare environments using Choosing WordPress Hosting: Shared, VPS or Cloud in 2026 because shared hosts often disable proc_open and break WP-CLI subprocesses.

Step by Step Process to Automate Core WP-CLI Commands

1. Install WP-CLI and lock file permissions for the runtime user.
2. Run updates and perform a dry-run then real search-replace.
3. Export the database and import it into the target environment.
4. Control cron events and flush every cache layer.
5. Verify with core checks, row counts and event listings.
6. Roll back from backups when any verification fails.

Install and Permissions

Install the Phar binary to a system path so cron and CI can call it without a login shell. Use the 2026 release channel and verify the signature.

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
sudo chmod +x /usr/local/bin/wp
wp --info --allow-root
wp package install wp-cli/checksum-command

Set ownership to the web user, usually www-data on Debian or nginx on RHEL derivatives, and fix directory versus file modes. Wrong permissions cause silent update failures because WordPress cannot write wp-content/upgrade.

sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} ;
sudo find /var/www/example.com -type f -exec chmod 644 {} ;
sudo chmod 600 /var/www/example.com/wp-config.php

Verify with wp core is-installed and wp core version. If you see a write error, the pitfall is a mismatched user: the cron job may run as root while PHP-FPM runs as www-data. Roll back by restoring ownership from your backup record, then re-run the find commands. Never leave wp-config.php at 644 in production.

Updates and Search-Replace

Update core, plugins and themes with explicit --dry-run first, then apply. Use --exclude for plugins you patch manually.

wp core update --dry-run
wp core update
wp plugin update --all --dry-run
wp plugin update --all
wp theme update --all
wp core update-db

Search-replace is the highest risk command. Always dry-run to count replacements, then execute with --skip-columns=guid to avoid breaking GUIDs, and recurse over tables.

wp search-replace 'https://old.example.com' 'https://new.example.com' --dry-run --skip-columns=guid
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid --recurse-objects
wp search-replace 'http://' 'https://' --dry-run --all-tables

Verify with wp core verify-checksums and wp option get home. If serialized data corrupts, the pitfall is replacing without --recurse-objects on PHP serialized arrays. Roll back by importing your pre-change .sql dump. For complex multisite or vendor-led recovery after a bad replace, see Custom WordPress Development for hands-on remediation.

Export and Import

Export with consistent flags so imports are deterministic. Use --skip-plugins and --skip-themes when the target lacks those files, and gzip for size.

wp db export /var/backups/wp/2026/example-$(date +%F).sql --skip-plugins --skip-themes
gzip /var/backups/wp/2026/example-$(date +%F).sql
wp db size --size_format=mb

Import into the destination only after confirming the target database is empty or disposable. The --dbuser and --dbpass come from the target wp-config.php, not the source.

wp db reset --yes
wp db import /var/backups/wp/2026/example-2026-05-14.sql.gz
wp search-replace 'https://source.example.com' 'https://target.example.com' --skip-columns=guid
wp cache flush

Verify with wp db check and wp post list --post_type=page --fields=ID,post_title to compare counts. A common pitfall is importing a dump larger than max_allowed_packet; split with --tables or raise the MySQL setting. Roll back by re-importing the previous dump and restoring wp-content/uploads from tar.

Cron and Cache Flushing

Replace WP-Cron with a real system cron to stop missed schedules under load. Disable the internal spawner in wp-config.php.

define('DISABLE_WP_CRON', true);

Then schedule every minute with the site path and log output.

*/5 * * * * www-data cd /var/www/example.com && /usr/local/bin/wp cron event run --due-now >> /var/log/wp-cron.log 2>&1

List and test events to confirm registration.

wp cron event list
wp cron event run my_custom_hook
wp cron schedule list

Flush every layer: object cache, transient store and opcode if you use Redis or Memcached.

wp cache flush
wp transient delete --all
wp rewrite flush
wp option update rewrite_rules ''

Verify with wp cron event list showing the next run time and wp cache get returning empty. The pitfall is forgetting external CDN or proxy caches; pair this with WordPress Behind a CDN: Cache, Origin, Purging to purge at the edge too. Roll back by re-enabling WP-Cron (set the constant false) and restoring prior rewrite rules from your options backup.

Verification and Rollback Checklist

After every automated run, execute this sequence and compare against your baseline.

wp core verify-checksums
wp db check
wp plugin list --field=name,status,version
wp theme list --field=name,status,version
wp cron event list
wp option get siteurl

Keep a rollback script that restores files then database in order.

tar -xzf /var/backups/wp/2026/wp-content-2026-05-14.tar.gz -C /var/www/example.com/
wp db import /var/backups/wp/2026/pre-change-2026-05-14.sql
wp cache flush

Action Checklist

• Install WP-CLI 2.11+ and set www-data ownership with 755/644 modes.
• Update core, plugins and themes only after a --dry-run.
• Run search-replace with --skip-columns=guid and verify checksums.
• Export before every change and import with a post-import replace.
• Move cron to system level and flush all cache layers after deploy.

Frequently asked questions

How do I know my WP-CLI search-replace worked?

Run wp search-replace with --dry-run first to see the replacement count, then execute and confirm with wp option get home and wp post list. If serialized menus break, import your backup dump.

Can I automate WP-CLI on shared hosting?

Only if the host allows SSH and proc_open. Check wp --info for disabled functions. If subprocess calls fail, fall back to manual updates or use a provider compared in our hosting guide.

What should I do if an update breaks the site?

Immediately import the pre-update .sql dump and restore wp-content from tar, then flush cache. Verify with wp core verify-checksums before investigating the faulty plugin.

Need these WP-CLI commands scripted for your stack? Our engineers build audited automation and rollback pipelines. See our WordPress development services to get started today.

References & further reading

• WordPress Developer Documentation
• WordPress Theme Handbook
• WordPress Plugin Handbook