If you manage WordPress sites for a living, the dashboard eventually becomes the slow path. Clicking through Plugins → Updates, waiting for an admin screen to paint, doing a database find-and-replace through a clunky plugin UI — all of it is fine for one site and miserable across twenty. WP-CLI, the official command-line interface for WordPress, replaces most of that with one-line commands you can script, pipe, and run over SSH. Below are the commands that earn their place in a working developer's muscle memory, grouped by the job they actually do.

The one command that justifies WP-CLI: search-replace

If you learn nothing else, learn wp search-replace. The reason it matters is subtle: WordPress stores a lot of data — widget settings, theme mods, plugin options — as PHP-serialized arrays inside the database. A serialized string encodes the byte length of each value. If you run a raw SQL REPLACE() to swap an old domain for a new one, you change the string but not the recorded length, and every serialized blob that touched that value silently corrupts. Widgets vanish, sliders break, settings reset.

WP-CLI unserializes each value, performs the replacement, and re-serializes it correctly. A typical HTTP-to-HTTPS or domain migration looks like this:

wp search-replace 'http://oldsite.com' 'https://newsite.com' --dry-run — always run the dry run first. It reports how many rows in which tables would change without touching anything.
wp search-replace 'http://oldsite.com' 'https://newsite.com' --skip-columns=guid --report-changed-only — the real run. Skip the guid column because GUIDs are permanent feed identifiers and rewriting them can cause RSS readers to re-flag every post as new.
Add --all-tables when a plugin created custom tables that don't carry the default WordPress prefix.

This single capability is why migrations that used to be a half-day of anxiety become a 30-second command.

Keeping core, plugins, and themes current

Updates are the most repetitive dashboard chore and the easiest win on the command line.

wp core update followed by wp core update-db — the second command runs the database migration routine that the admin normally triggers for you. Forgetting it after a major-version bump is a classic cause of "the site looks broken after updating."
wp plugin update --all and wp theme update --all — update everything in one pass. Pair with --dry-run to preview, or update a single item with wp plugin update woocommerce.
wp plugin install wordpress-seo --activate — install from the wordpress.org repository by slug and activate in the same step. You can also point it at a .zip URL or local path for premium plugins.

Two security-adjacent commands belong here too. wp core verify-checksums compares your core files against the official wordpress.org hashes and flags anything modified — one of the fastest ways to spot an injected file after a suspected compromise. wp plugin verify-checksums --all does the same for plugins hosted in the repository.

Database work without phpMyAdmin

You can manage the entire database from the shell, which is invaluable on hosts that don't ship a friendly GUI.

wp db export backup.sql — a full mysqldump to a file, with no PHP memory limits to fight. wp db import backup.sql restores it.
wp db optimize — runs OPTIMIZE TABLE across the database to reclaim space and defragment after large deletions.
wp db query "SELECT option_name FROM wp_options WHERE autoload='yes' ORDER BY LENGTH(option_value) DESC LIMIT 10" — run arbitrary SQL. The query above surfaces bloated autoloaded options, a frequent and overlooked cause of slow TTFB, since every page load reads all autoloaded data into memory.
wp db size --tables — quickly see which tables have grown out of control (often wp_options from orphaned transients, or wp_postmeta).

Getting back into a site you're locked out of

WP-CLI shines in exactly the moments the dashboard fails you, because it bypasses the login screen entirely.

wp user create editor jane@example.com --role=administrator --user_pass=Str0ngPass — mint a fresh admin when you've lost credentials.
wp user update 1 --user_pass=NewSecret123 — reset a password directly. There's no email round-trip and no SMTP dependency, which is the whole point when password-reset mail isn't being delivered.
wp plugin deactivate --all — the canonical "white screen of death" recovery move. A fatal error from one bad plugin can lock you out of wp-admin too; deactivating everything from the shell gets the site loading again so you can reactivate plugins one at a time to find the culprit.
wp theme activate twentytwentyfour — fall back to a default theme when a custom theme is throwing fatals.

Maintenance, caches, and the "did you flush?" checklist

A surprising share of "it's not working" reports are stale state. These commands clear it deterministically.

wp cache flush — empties the object cache (Redis or Memcached if you're using a persistent backend).
wp transient delete --all — clears expired and lingering transients, which accumulate in wp_options and slow things down.
wp rewrite flush — regenerates rewrite rules. This is the command-line equivalent of the old "go to Settings → Permalinks and click Save" trick, and it fixes more mysterious 404s on custom post types than it has any right to.
wp media regenerate --yes — rebuilds all the registered thumbnail sizes, essential after you change image dimensions in a theme or add a new size.

Cron, scheduled events, and bulk data

WordPress's default cron is request-triggered, so low-traffic sites miss scheduled tasks. The professional setup is to define DISABLE_WP_CRON as true in wp-config.php and run a real system cron every five minutes calling wp cron event run --due-now. Inspect what's queued with wp cron event list — it's the fastest way to debug a plugin whose scheduled job stopped firing.

For content operations, wp post list --post_type=page --format=ids emits machine-readable output you can pipe straight into another command, for example wp post delete $(wp post list --post_status=trash --format=ids) --force to permanently empty the trash.

Running commands at scale and over SSH

This is the section that separates occasional users from people who run WP-CLI as their daily driver. You can target a remote server without manually SSH-ing in first by defining aliases in a wp-cli.yml file:

Define an alias like @production: { ssh: user@host.com/var/www/site }, then run wp @production plugin list from your laptop — WP-CLI opens the SSH connection and runs the command remotely.
wp @all core version runs across every alias at once, perfect for auditing a fleet.
Use --path=/var/www/site when the command isn't run from the WordPress root, and --allow-root in containers or automation where you're executing as root.

Two debugging tools round out the kit. wp shell drops you into an interactive REPL with WordPress fully loaded, so you can call any function — get_option('siteurl'), wp_get_current_user() — and inspect live data. For one-liners, wp eval 'echo home_url();' executes a snippet of PHP in the WordPress context without writing a file.

Where to go from here

The fastest way to internalize these is to alias your most-run commands and add --dry-run reflexively wherever it's offered. Every command supports --help, and the full reference at developer.wordpress.org/cli/commands documents flags worth exploring once the basics are habit. WP-CLI rewards investment: the commands above will handle the overwhelming majority of day-to-day WordPress administration, and they do it in seconds instead of clicks.

The WP-CLI Commands Every Developer Should Know