WP-CLI runs WordPress operations from the command line. On hosting with SSH access it turns jobs that take twenty clicks into one command, and it works when the admin area does not, which is when you need it most.
Check whether it is already there
wp --info
Many hosts install it. If the command is not found, it can usually be downloaded into your own account and run from there without needing root. For getting a shell, see cPanel Terminal and SSH Access.
Run it from the WordPress directory, or pass --path=. Running it elsewhere produces "this does not seem to be a WordPress installation", which is exactly what it says instead of a fault.
The commands worth knowing
Updates, which is where most of the time saving is:
wp core update wp plugin update --all wp theme update --all
A user, when you are locked out:
wp user create temp [email protected] --role=administrator wp user update admin --user_pass='a-long-password'
That second one is the fastest recovery from a lost password on a site whose mail is broken, no database editing and no reset email. There is more on the other routes in How to Recover When You Are Locked Out of WP Admin.
Plugins, one at a time or in bulk:
wp plugin list wp plugin deactivate --all wp plugin activate akismet
Deactivating everything and reactivating one at a time is the standard way to find a conflict, and by command line it takes a minute instead of an afternoon.
The search-replace that actually works
The single most useful command here.
wp search-replace 'https://old.example.com' 'https://new.example.com' --dry-run
It understands serialised data, which a plain SQL replace does not, and a plain replace corrupts theme and page-builder settings by leaving recorded string lengths wrong.
Always run it with --dry-run first. It reports how many rows would change in each table, which tells you whether your search string is right before anything is written. How to Change Your WordPress Site URL goes into when this is needed.
Add --skip-columns=guid. Post GUIDs are identifiers rather than addresses, and rewriting them can confuse feed readers.
Database export and import
wp db export backup.sql wp db import backup.sql
Faster than phpMyAdmin and not subject to the upload and execution limits that make a large import fail in a browser.
Export before anything destructive. It takes seconds and it is the difference between a mistake and an incident. How to Restore a WordPress Site from Backup explains using it.
Diagnosing without a browser
Two commands that answer questions the admin cannot when the site is broken.
wp core verify-checksums wp plugin verify-checksums --all
These compare your files against the official releases and list what differs. On a site you suspect is compromised, that is a fast way to find modified core files, and a clean result does not rule out a compromise in wp-contentSee How to Clean Up a Hacked WordPress Site.
Scheduled tasks
wp cron event list wp cron event run --due-now
This is how a real cron job drives WordPress's scheduler on a low-traffic site, instead of relying on visits to trigger it. There is more on the arrangement in WP-Cron: Why Scheduled Posts Do Not Publish.
Listing the events is also how you find a plugin scheduling something every minute, which is a common cause of unexplained load.
Across several sites
The reason agencies use it.
A short shell loop over your sites running wp plugin update --all does in a minute what would otherwise be an afternoon of logins, and it produces output you can read instead of a series of screens you have to trust.
Combine it with a backup command in the same loop, in that order, so every update has a rollback. How to Manage a Portfolio of WordPress Sites deals with the wider arrangement.
Two cautions
It bypasses the interface entirely. There is no confirmation dialog. wp db reset does exactly what it says, immediately.
It runs as your shell user. Files it creates are owned by that user, which is usually correct on cPanel and can produce ownership mismatches on a server where the web server runs as someone else. A symptom that looks like a permissions problem with correct-looking permissions. For that, see Understanding File Permissions and Ownership.
Start with the read-only commands
wp plugin list, wp user list, wp option get siteurl, wp core check-update.
None of them change anything, and running them on a real site is how the tool stops feeling risky. The destructive commands are worth learning on a staging copy first, which is true of everything here. How to Set Up a WordPress Staging Site deals with making one.
Point it at the right site
On an account with several sites, WP-CLI operates on the directory you happen to be in, which is how a command intended for a staging copy is run against the live site.
wp --path=~/dev option get siteurl wp --path=~/public_html option get siteurl
Running option get siteurl before any destructive command is a one-second habit that confirms which site you are about to change. The output is unambiguous in a way that the shell prompt is not.
Where the same commands are run regularly against several sites, a small wrapper that requires the path explicitly removes the ambiguity entirely.
Confirm the interpreter before anything else
WP-CLI runs under whichever PHP the shell provides, which on a cPanel account is frequently not the version serving the site.
wp --info | grep -i 'PHP binary\|PHP version' php -v
A mismatch produces two problems: commands may fail on a version the site never uses, and anything that writes. A plugin update, a database change, is performed by a different interpreter than the one that will read it.
Where they differ, call the versioned binary explicitly:
/usr/local/bin/ea-php83 $(which wp) plugin list
MultiPHP Manager walks through establishing which the site actually uses.
Long commands need to survive the connection
A database export or a bulk regeneration on a large site takes longer than a session reliably lasts, and a dropped connection kills the command partway.
nohup wp db export ~/backup.sql > ~/export.log 2>&1 & tail -f ~/export.log
That detaches the job from the session. For anything interactive, a terminal multiplexer is better because the session can be reattached.
A half-finished export is the specific risk: the file exists, looks plausible, and restores into a broken site, which is why verifying the dump rather than its existence matters. For the checks, see backing up a store.
Reading output as data
The value of the command line over the dashboard is that output can be processed rather than read.
wp plugin list --field=name --status=active wp plugin list --format=csv --fields=name,version,update > plugins.csv wp post list --post_type=page --field=ID | wc -l
The --field form emits bare values suitable for a loop; --format=csv produces something to keep.
That is what makes an audit across several sites practical. A list of every plugin with a pending update, across an entire portfolio, is one loop instead of an afternoon of clicking. For the wider routine, see managing a portfolio of WordPress sites.