WP-CLI is the official command-line tool for WordPress. It lets you manage plugins, themes, users, and the database directly from SSH, without a browser.
Installing WP-CLI
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
# Check
wp --version
# WP-CLI 2.10.0
Basic commands
Updates
# Update WordPress core
wp core update
# Update all plugins
wp plugin update --all
# Update all themes
wp theme update --all
# Update everything at once
wp core update && wp plugin update --all && wp theme update --all
Plugins and themes
# Install a plugin
wp plugin install wordfence --activate
# Deactivate a plugin
wp plugin deactivate contact-form-7
# List plugins
wp plugin list
# Delete a plugin
wp plugin delete hello-dolly
Users
# Create an administrator
wp user create admin2 admin2@example.com --role=administrator --user_pass=SecurePass123!
# Change a password
wp user update admin --user_pass=NewPassword456!
# List users
wp user list --role=administrator
Database
# Export the database
wp db export backup-$(date +%Y%m%d).sql
# Import the database
wp db import backup.sql
# Search and replace a URL (during migration!)
wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables
wp search-replace automatically handles serialized PHP data — safer than a manual SQL UPDATE.Useful commands for debugging
# Flush the cache
wp cache flush
# Regenerate thumbnails
wp media regenerate --yes
# Check and repair the database
wp db check
wp db repair
# Get/set an option
wp option get siteurl
wp option update blogname "My Site"
| Command | What it does |
|---|---|
| wp core update | Updates WP to the latest version |
| wp plugin update --all | Updates all plugins |
| wp db export | Backs up the database |
| wp search-replace | Changes the URL during migration |
| wp cache flush | Clears the cache |
Common WP-CLI mistakes
Almost every WP-CLI error comes down to three causes: the wrong path, root permissions, and CLI running a different PHP than the web server.
Error: This does not seem to be a WordPress installation.
WP-CLI looks for the wp-load.php file in the current directory and upward through the tree. If the command runs from outside the site root, point it there explicitly: wp --path=/var/www/example.com/public_html core version.
Error: YIKES! It looks like you're running this as super user (root).
WP-CLI blocks running as root by default — files created as root break ownership for the PHP-FPM user. If you fully understand the risk (say, inside a single-user container), add the --allow-root flag. Otherwise switch to the site's own user: sudo -u www-data wp core version --path=....
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
Running wp search-replace on a large database (tens of thousands of postmeta rows) hits the PHP CLI memory limit — it's set separately from the web server's PHP limit, in its own CLI-mode php.ini. Raise the limit temporarily: php -d memory_limit=512M $(which wp) search-replace ....
WP-CLI or wp-admin: when to use which
| Task | WP-CLI | wp-admin |
|---|---|---|
| Bulk-updating 50+ plugins | Seconds, one script | Click each one, or Bulk actions in the browser |
| A one-off text edit on a page | Awkward | Faster |
| Automation in CI/CD | Only option | Not available |
| Working with the frontend down | Always works | Unavailable during a critical site error |
WP-CLI's main advantage is that it talks to WordPress Core directly, bypassing HTTP and the browser, so it still works when the site shows a white screen or a 500 error.
When WP-CLI doesn't fit
Some shared hosting plans don't provide SSH access at all — WP-CLI is physically unavailable there; see SSH access on cPanel hosting to check which plans support it. On some setups, PHP CLI and the web server's PHP are different binaries with different versions and php.ini settings: a command might run fine under PHP 8.3 in CLI while the site itself runs on PHP 7.4 on the web, and behavior can differ. For a one-off edit to a single page or checking one plugin, opening wp-admin is almost always faster than recalling command syntax.
How to verify the result
After bulk changes via WP-CLI, check more than "the command finished without errors" — check the site's actual state:
# Check that WordPress is installed and reachable
wp core is-installed; echo "Exit code: $?"
# General environment info
wp cli info
# Check site state after bulk changes
wp plugin list --status=active
wp option get siteurl
An exit code of 0 after wp core is-installed confirms the installation is intact. A non-zero code in an automation script is a signal to stop and not run the next steps (like a deploy) against a broken site.