WP-CLI is one of the few WordPress tools that genuinely saves operations time. If you manage launches, staging copies, handovers, or emergency fixes, it lets you make repeatable changes without clicking through wp-admin. That matters to business owners because repeatable work is cheaper, faster to review, and much less dependent on one person remembering the right screen.
The mistake is treating WP-CLI like a bag of isolated one-liners. The better approach is to use it as an operations layer: point commands at the right environment, dry-run anything destructive, and separate site-address fixes from full database rewrites.
Start by targeting the right site
Before changing anything, make the target explicit. WP-CLI supports global flags such as --path, --url, and --ssh. For agencies and multisite teams, those flags are not optional nice-to-haves. They are how you avoid running a production command from the wrong shell directory or against the wrong site in a multisite setup.
wp --path=/var/www/example.com option get home
wp --url=https://client.example.com user list
wp [email protected]:/var/www/example.com plugin listIf a command could be expensive, ambiguous, or customer-facing, spell out the environment in the command itself. That small habit prevents a lot of expensive cleanup.
Use the right tool for URL changes
For full domain moves or content-wide URL replacements, wp search-replace is still the workhorse. The current WP-CLI docs note that it handles serialized data intelligently and does not change primary key values, which is exactly why it is safer than raw SQL for most WordPress migrations. It also supports --dry-run, so there is very little reason to skip a rehearsal first.
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid --dry-run
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guidThe --skip-columns=guid pattern from the official docs still makes sense for standard domain changes. If you are working on multisite, add the correct --url or --network scope instead of assuming the current site context.
If the site address is wrong but the content itself does not need rewriting, do not run a full database replacement. Update the relevant options only:
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'That distinction matters in real projects. Full search-and-replace is for migrations. Option updates are for correcting configuration.
Handle user admin and plugin audits without the dashboard
When access needs to be fixed quickly, WP-CLI is usually faster and cleaner than going through WordPress admin screens or phpMyAdmin. Start by listing users so you are acting on the right account, then update only what is needed.
wp user list
wp user update USERNAME --user_pass='NEW-STRONG-PASSWORD' --skip-email
wp user update USERNAME --user_email='[email protected]'This is useful during handovers, incident response, and staging refreshes where emails or passwords must be reset in a controlled way. The current user command set also includes a dedicated password reset subcommand, but in day-to-day operations wp user update remains the most flexible option.
For straightforward deployments, wp plugin install really-simple-ssl --activate is still a fast way to add a known plugin to a controlled environment.
Plugins are another area where WP-CLI earns its keep. Instead of guessing what is installed, list what is active, inactive, or recently active first. That gives operations teams something reviewable before they delete anything.
wp plugin list --status=inactive --format=table
wp plugin delete $(wp plugin list --status=inactive --field=name)That second command is practical, but it is not something I would schedule blindly across client sites. Review the list first, especially on older builds where an inactive plugin may still be kept temporarily for rollback, licensing, or compatibility reasons. The same logic applies to themes: audit first, remove second.
Reserve database reset for controlled environments
wp db reset --yes is still a valid command, and it is still destructive. The current documentation shows that database commands run using the credentials in wp-config.php, and that the reset command removes all tables from the database. That makes it useful for local rebuilds, disposable staging environments, and automated test setups, not for casual production housekeeping.
wp db reset --yes
wp db import wordpress_dbase.sqlIf you are rebuilding a local or staging copy from a known SQL dump, this is a fast workflow. If you are on a live environment, step back and make sure you really want reset behavior rather than export, inspect, repair, or search operations.
Do not treat every hardening or cache task as a one-liner
Some older WP-CLI tip lists recommend things like renaming the database prefix as routine hardening or deleting plugin cache folders directly from the filesystem. That is not how I would standardize operations today. Those tasks are environment-specific, easy to get wrong, and often poorly documented outside one-off blog posts.
Prefer documented WP-CLI commands and vendor-approved procedures. When a task depends on a specific hosting stack or plugin internals, document that separately instead of hiding it in a generic tips list. That is especially true for cache layers, security plugins, and anything that behaves differently between local, staging, and production.
Turn useful commands into a repeatable playbook
The real value of WP-CLI is not that it looks technical. The value is that migrations, user fixes, plugin reviews, and rebuilds can be turned into checked steps that somebody else on the team can run safely. That is what reduces dependency on heroics and makes WordPress maintenance easier to quote, delegate, and support.
If you need help turning one-off terminal knowledge into a cleaner workflow for launches, handovers, or ongoing site operations, Greg can help you put the right guardrails around it without overcomplicating the stack.
Need help with this kind of work?
If you want these WP-CLI jobs turned into safer, repeatable workflows, Greg can help your team standardize them. Get in touch with Greg.