WP-CLI commands let you manage WordPress from the terminal: export and import the database, update core, plugins and themes, run search-replace, manage users, regenerate images, flush caches, run cron events and manage WooCommerce data. The commands below are the ones I use most, with the exact syntax and the safety habits around them.
This is part of my automation series.
What is WP-CLI and why use it?
WP-CLI is the official command-line tool for WordPress. It is faster than clicking through the admin, works when the admin is broken, and makes tasks repeatable in scripts. On slow servers it also avoids web timeouts for long jobs, such as regenerating thousands of thumbnails.
Check it is available:
wp --info
wp core version
Run commands from the WordPress root, or add --path=/path/to/site.
Backups and the database
# Export before anything risky
wp db export ~/backups/site-$(date +%F).sql
# Import (overwrites the database!)
wp db import ~/backups/site-2026-10-01.sql
# Database size and tables
wp db size --tables
# Optimise tables
wp db optimize
Rule I never break: export first, then change.
Updates
wp core check-update
wp plugin list --update=available
wp plugin update --all --dry-run
wp plugin update woocommerce
wp theme update --all
wp core update && wp core update-db
For stores, I update major plugins one at a time on staging first. Combined with a plugin audit, this keeps sites stable.
Search and replace
The classic use: moving a site to a new domain or from HTTP to HTTPS. WP-CLI handles serialised data correctly, unlike a raw SQL replace.
wp search-replace 'http://old.example.com' 'https://example.com' --all-tables --dry-run
wp search-replace 'http://old.example.com' 'https://example.com' --all-tables --precise
Read the dry-run output before running it for real. Useful for migrations.
Users
wp user list --role=administrator --fields=ID,user_login,user_registered
wp user create jane [email protected] --role=editor
wp user update 12 --role=subscriber
wp user application-password list 1
Reviewing administrators regularly is part of my security checklist.
Content and options
wp post list --post_type=page --fields=ID,post_title,post_status
wp post create --post_type=post --post_title='Draft title' --post_status=draft
wp post meta get 123 _thumbnail_id
wp option get permalink_structure
wp option update blog_public 1 # make sure search engines are not discouraged
wp rewrite flush
Media
wp media regenerate --only-missing --yes
wp media import ~/images/*.jpg --post_id=123
wp media image-size
--only-missing is gentle on slow servers. See image optimisation.
Cache and transients
wp cache flush # object cache
wp transient delete --expired
wp transient delete --all
Page cache plugins usually register their own commands; check wp help to see what is installed.
Cron
wp cron event list
wp cron event run --due-now
wp cron test
Details in the WP-Cron guide.
WooCommerce
WooCommerce adds commands under wp wc, mapping to its REST API. Most need a user:
wp wc product list --user=1 --fields=id,name,sku,stock_quantity
wp wc order list --user=1 --status=processing
wp wc webhook list --user=1
wp wc tool run clear_transients --user=1
Related: WooCommerce webhooks and CSV product imports.
Running PHP
wp eval 'echo get_bloginfo("name");'
wp eval-file scripts/fix-meta.php
wp shell
eval-file is my preferred way to run one-off data fixes: the script is reviewed, versioned and repeatable.
Writing a custom command
When I repeat the same steps, I make a command. In a plugin:
if ( defined( 'WP_CLI' ) && WP_CLI ) {
WP_CLI::add_command( 'mx stale-drafts', function ( $args, $assoc ) {
$days = isset( $assoc['days'] ) ? absint( $assoc['days'] ) : 90;
$posts = get_posts( array(
'post_status' => 'draft',
'numberposts' => -1,
'date_query' => array( array( 'before' => "$days days ago" ) ),
) );
foreach ( $posts as $p ) {
WP_CLI::log( sprintf( '%d %s', $p->ID, $p->post_title ) );
}
WP_CLI::success( count( $posts ) . ' stale drafts.' );
} );
}
Run with wp mx stale-drafts --days=60. Custom commands are also safer for AI-assisted work: one reviewed command is easier to trust than many ad-hoc changes.
Running remotely
WP-CLI supports SSH aliases in wp-cli.yml:
@prod:
ssh: [email protected]:22/home/user/public_html
Then wp @prod plugin list runs on the server from your machine.
Safety habits
- Export the database before data-changing commands.
- Use
--dry-runwhen available. - Test on staging first.
- Run heavy jobs off-peak on slow hosting.
- Keep scripts in version control.
Common mistakes
- Running search-replace without a dry run.
- Running commands as root, creating files the web server cannot write.
- Forgetting
--userfor WooCommerce commands. - Running from the wrong directory and changing another site.
Installing WP-CLI and checking your environment
On most managed and shared hosts in the region, including Hostinger and many cPanel providers, WP-CLI is already installed; run wp --info over SSH to confirm the version and the PHP binary it uses. If it is missing, the official handbook shows how to download the phar file and put it on your path (WP-CLI Handbook: Installing). Keep WP-CLI itself current with wp cli update where you have permission, because new WordPress and WooCommerce releases sometimes need a newer CLI.
A small detail that saves confusion: the PHP version used by the command line can differ from the one serving your website. If a command fails with a syntax error that the site does not show, compare wp --info with Site Health.
A safe update routine I use on client sites
Here is the sequence I run before and after monthly maintenance. It is short enough to memorise and covers the common failure points:
wp db export ~/backups/pre-update-$(date +%F).sql
wp core check-update
wp plugin list --update=available
wp plugin update --all --dry-run
wp plugin update --all
wp theme update --all
wp core update && wp core update-db
wp cache flush
wp option get siteurlThe dry run lists what will change without changing it. If one plugin is known to be risky, such as a page builder or payment gateway with a big version jump, exclude it with --exclude=plugin-slug and update it separately on staging first. Every command and flag is documented in the official reference (WP-CLI Commands reference).
Handy diagnostics
wp plugin list --status=active --fields=name,version,updategives a quick inventory for a plugin audit.wp doctor(an official package) runs a set of health checks, such as autoloaded option size and cron count (wp-cli/doctor-command).wp db size --tablesshows which tables are bloated, often logs or old sessions.wp option list --autoload=on --format=total_bytestells you how much data loads on every request; large values slow down every page.wp cron event listshows overdue events; see the WP-Cron guide for fixing them.
Scripting for multiple sites
Freelancers and small agencies often manage ten to fifty client sites. WP-CLI aliases let you run the same command against several of them from your own machine. You define aliases in a wp-cli.yml or ~/.wp-cli/config.yml file, each pointing at an SSH host and path, and then group them (WP-CLI Handbook: Running commands remotely).
@client-a:
ssh: [email protected]:65002/home/user/public_html
@client-b:
ssh: [email protected]/var/www/site
@all-clients:
- @client-a
- @client-bThen wp @all-clients plugin list --update=available gives you one report for every site. Start read-only like this; only move to bulk updates once you trust your backups on each site.
WP-CLI on bilingual WPML or Polylang sites
On multilingual sites, remember that search-replace touches every language, and that translation plugins store relationships in their own tables. Always include --all-tables-with-prefix on migrations so those tables are updated too, and test a few translated URLs afterwards. For language-specific content queries, the plugin’s own documentation is the reference, as core WP-CLI does not know about languages. More on structure in the multilingual WordPress guide.
Moving a site from staging to live
A typical WP-CLI migration from staging to production looks like this: export the staging database, import it on live, then replace the staging domain everywhere, including serialized data, which a plain SQL find-and-replace would corrupt.
wp db export staging.sql
wp db import staging.sql
wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables-with-prefix --dry-run
wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables-with-prefix
wp rewrite flush
wp cache flushRun the dry run first and read the count of replacements per table; an unexpected zero or a huge number is a sign the domain or protocol is wrong. Afterwards, log in, check a few pages, a form and, on stores, a test order.
If you want routine WordPress work scripted for your team, contact me.
Frequently asked questions
What is WP-CLI?
WP-CLI is the official command-line interface for WordPress. It lets you manage plugins, themes, users, content, the database and settings from a terminal without using the admin dashboard.
How do I clear the cache with WP-CLI?
wp cache flush clears the WordPress object cache. Page caching plugins usually provide their own commands, and wp transient delete --all clears transients.
Is WP-CLI available on shared hosting?
Many hosts include it over SSH. Check your host's documentation; if not installed, it can often be added as a single phar file in your home directory.
Can WP-CLI break my site?
Commands that change data, such as search-replace or plugin updates, can. Take a database export first, use --dry-run when offered, and test on staging.
