WP-CLI Commands Worth Automating in 2026

Prerequisites and Environment Setup

Before automating anything, confirm the runtime. As of 2026, WP-CLI 2.11+ is the current stable line and supports PHP 8.1 through 8.3; PHP 7.4 is end-of-life and will produce deprecation warnings. Check versions with wp --info and php -v. Ensure the binary is executable and in PATH, and that you run commands as the same Unix user that owns the WordPress files (often www-data or a per-site user). If you manage multiple servers, keep a shared ~/.wp-cli/config.yml with default path: and url: so scripts do not depend on the current working directory.

For team workflows, pair this with a safe WordPress staging environment so every automated job is rehearsed off production first.

Step-by-Step Automation Process

1. Provision the install with correct ownership and file permissions.
2. Run core, plugin and theme updates, then execute search-replace for URL changes.
3. Export the source database and media, then import into the target site.
4. Reschedule cron events and flush object/page caches after content changes.
5. Verify each phase with built-in WP-CLI verification commands.
6. Roll back using backups and checksum verification if any phase fails.

Install and Permissions

Automated installs should never leave files owned by root. Download core, generate wp-config.php, create the database, then set ownership and permissions explicitly. Use wp core download, wp config create, and wp core install with flags so the script needs no interactive input.

Commands

wp core download --version=6.7 --locale=en_US
wp config create --dbname=site_db --dbuser=site_user --dbpass=secret --dbhost=localhost
wp core install --url=https://example.com --title='Example' --admin_user=admin --admin_email=admin@example.com --admin_password=strongpass
wp core update-db
find /var/www/example.com -type d -exec chmod 755 {} ;
find /var/www/example.com -type f -exec chmod 644 {} ;
chmod 600 /var/www/example.com/wp-config.php
chown -R www-data:www-data /var/www/example.com

Verify: run wp core is-installed and check the exit code with echo $?; 0 means installed. Run wp core verify-checksums to confirm files match the official release. Run wp option get siteurl and compare to the expected URL.

Pitfalls: 644 on directories breaks directory listing; always 755 for dirs. If wp core install fails with a database connection error, the DB user lacks privileges — grant them before retrying. Running as root with --allow-root is a last resort; prefer the correct user.

Rollback: if install half-completes, delete the web root contents, drop the database with wp db drop --yes, and re-run from step one. Keep the DB credentials in a secrets manager so the rollback script can cleanly remove the schema.

Updates and Search-Replace

Update core, plugins and themes in one scheduled pass, then handle URL changes with wp search-replace. Always dry-run first so you see the replacement count before touching data.

Commands

wp core update
wp core update-db
wp plugin update --all
wp theme update --all
wp search-replace 'https://old.example.com' 'https://new.example.com' --dry-run
wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables --precise
wp cache flush
wp rewrite flush

Verify: wp core version should print 6.7 (or your target). wp plugin list and wp theme list show status active and no update available. After search-replace, run wp option get home and wp option get siteurl; both must show the new domain. The dry-run output tells you the row count — compare it to the real run.

Pitfalls: serialized data breaks if you use a plain SQL replace; --precise with --all-tables handles serialization correctly. Skipping wp cache flush leaves stale options in Redis or Memcached. See the official search-replace documentation for flag details.

Rollback: take a snapshot first with wp db export backup_before_update.sql. If an update breaks the site, restore with wp db import backup_before_update.sql and reinstall the previous plugin versions via wp plugin install plugin-slug --version=x.y.z --force.

Export and Import

Migrations and backups rely on wp db export / wp db import plus wp export / wp import for content. Use wp db export for full SQL dumps and the WordPress eXtended RSS (WXR) flow for content-only moves.

Commands

wp db export /backups/site_2026-03-14.sql --add-drop-table
wp db import /backups/site_2026-03-14.sql
wp export --dir=/tmp/wxr --post_type=post,page --start_date=2026-01-01
wp import /tmp/wxr/example.wordpress.xml --authors=create

Verify: after import, run wp post list --post_type=post --fields=ID,post_title and count rows; compare to the source with wp post list --post_type=post --format=count. Run wp db check to confirm tables are not corrupt. For SQL imports, wp option get siteurl must reflect the target environment.

Pitfalls: large WXR imports hit PHP max_execution_time; raise it or use --user= mapping. The wp import command needs the wordpress-importer plugin installed and active — install it with wp plugin install wordpress-importer --activate. Media attachments referenced in WXR do not transfer unless you also rsync wp-content/uploads.

Rollback: keep the pre-import SQL dump. Restore with wp db import on the backup file and delete imported terms with wp term delete category <id> --by=id if partial content landed. For CDN-fronted sites, remember that asset URLs may also need attention — see our notes on WordPress behind a CDN after any migration.

Cron and Cache Flushing

WP-Cron is not a real system cron; it fires on page load. Automate it by disabling the internal spawn and driving events from the server crontab, then flush caches after any bulk operation.

Commands

wp config set DISABLE_WP_CRON true --raw
wp cron event list
wp cron event run --due-now
wp cron schedule event --event=my_hook --recurrence=hourly
wp cache flush
wp transient delete --all
wp super-cache flush || wp rocket clean --confirm || true

Add the system cron entry: */5 * * * * www-data cd /var/www/example.com && wp cron event run --due-now >> /var/log/wp-cron.log 2>&1.

Verify: wp cron event list shows hooks with correct recurrence and next-run timestamps. After wp cron event run --due-now, check your log file for errors. Confirm cache flush by loading a page and inspecting response headers, or run wp transient list to see the set is cleared.

Pitfalls: forgetting --raw on wp config set writes the boolean as a string, which evaluates truthy and does not disable cron. Multiple cache plugins conflict; guard the flush line with || true in scripts. If cron events vanish after migration, re-add them with wp cron schedule event.

Rollback: set DISABLE_WP_CRON back to false with wp config set DISABLE_WP_CRON false --raw, remove the crontab line, and run wp cron event run --due-now to drain pending hooks. Restore transients from cache TTL naturally or repopulate via your application code.

When these automations grow beyond a single site, teams often bring in specialists for custom WordPress development to standardize the scripts across environments.

Action Checklist

• Verify WP-CLI 2.11+ and PHP 8.1+ before writing any script.
• Always snapshot the database with wp db export before updates or search-replace.
• Use --dry-run on search-replace and compare counts to the real run.
• Replace internal WP-Cron with a system crontab entry every 5 minutes.
• Confirm every step with wp core is-installed, verify-checksums, and cron event list.

Need these WP-CLI automations built and maintained for your sites? Our engineers handle installs, migrations, cron and caching at scale. See our WordPress development services.

Frequently asked questions

Which WP-CLI commands should I automate first?

Start with wp core update, wp plugin update --all, wp db export for nightly backups, and wp cron event run --due-now from a real crontab. These cover the highest-frequency maintenance tasks.

Is search-replace safe on serialized data?

Yes, when you use wp search-replace with --precise and --all-tables. It unserializes and re-serializes arrays correctly, unlike raw SQL REPLACE statements.

How do I know cron automation worked?

Run wp cron event list to see scheduled hooks and next-run times, then check the log file your crontab writes to. If events ran, the log shows execution without fatal errors.

References & further reading

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