Why WP-CLI
If you manage WordPress sites and you’re not using WP-CLI, you’re spending twice as long on routine tasks. WP-CLI lets you manage everything from the terminal — updates, database operations, user management, configuration — without opening a browser.
For agencies managing 10+ sites, it’s the difference between clicking through admin panels for an hour and running a script in 30 seconds.
Here are the commands I use most, split between core WP-CLI and some that require additional packages.
The Essential 7
1. wp core update + wp plugin update --all
wp core update && wp plugin update --all && wp theme update --all
Update everything in one line. Pair it with wp db export backup.sql first if you’re cautious:
wp db export ~/backups/$(date +%Y%m%d).sql && wp core update && wp plugin update --all
Run this across multiple sites with a simple loop:
for site in /var/www/site1 /var/www/site2 /var/www/site3; do
echo "=== Updating $site ==="
wp --path="$site" db export ~/backups/$(basename $site)-$(date +%Y%m%d).sql
wp --path="$site" plugin update --all
done
2. wp db query
Direct database access without phpMyAdmin:
# Check autoload size
wp db query "SELECT SUM(LENGTH(option_value)) as bytes FROM wp_options WHERE autoload='yes';"
# Find the 10 biggest autoloaded options
wp db query "SELECT option_name, LENGTH(option_value) as size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 10;"
# Count post revisions
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type='revision';"
More powerful than phpMyAdmin for quick checks because you can script it and pipe the output.
3. wp search-replace
The migration command. Changing domains, switching to HTTPS, moving staging to production:
wp search-replace 'http://staging.example.com' 'https://example.com' --all-tables --dry-run
Always run with --dry-run first. The output shows you exactly what would change and in how many rows. When you’re satisfied:
wp search-replace 'http://staging.example.com' 'https://example.com' --all-tables
This handles serialized data correctly — something a raw SQL REPLACE can’t do.
4. wp cron event list + wp cron event run
WordPress cron is unreliable on low-traffic sites and invisible from the admin panel. WP-CLI makes it manageable:
# See all scheduled events
wp cron event list
# Run overdue events
wp cron event run --due-now
# Test a specific hook
wp cron event run wp_scheduled_delete
For production sites, disable WordPress’s fake cron (define('DISABLE_WP_CRON', true); in wp-config.php) and use a real system cron:
*/5 * * * * cd /var/www/site && wp cron event run --due-now --quiet
5. wp transient delete --expired
Expired transients are dead weight. WordPress eventually cleans them up, but “eventually” can mean weeks:
# Delete expired transients
wp transient delete --expired
# Nuclear option: delete ALL transients (safe, they regenerate)
wp transient delete --all
On a site with heavy transient usage (WooCommerce, caching plugins, API integrations), this can free up significant database space. I’ve seen sites with 50,000+ expired transient rows.
6. wp user list + wp user create
User management without the admin panel:
# List all admins
wp user list --role=administrator --fields=ID,user_login,user_email
# Create a temporary admin for debugging
wp user create debuguser debug@example.com --role=administrator --user_pass=TempPass123!
# Delete it when done
wp user delete debuguser --reassign=1
Especially useful for locked-out-of-admin situations. SSH in, create a temp admin, fix the problem, delete the user.
7. wp plugin list + wp plugin toggle
# See all plugins with status
wp plugin list --fields=name,status,version,update
# Quick deactivate/reactivate cycle (clears plugin state)
wp plugin deactivate problematic-plugin && wp plugin activate problematic-plugin
# Deactivate all plugins (nuclear debugging)
wp plugin deactivate --all
The deactivate-all approach is the fastest way to identify a plugin conflict. Deactivate everything, confirm the problem is gone, then reactivate one by one until it returns.
Bonus: WP Multitool CLI Commands
WP Multitool adds 7 subcommands that fill gaps in core WP-CLI:
# Overall site health status
wp multitool status
# Database health report (table sizes, overhead, fragmentation)
wp multitool db-health
# Autoload analysis (size, top offenders, orphaned options)
wp multitool autoload --report
# Capture and analyze slow queries
wp multitool slow-queries --threshold=100
# Frontend optimization status
wp multitool frontend
# Run database cleanup (revisions, transients, orphaned data)
wp multitool clean --revisions --transients --orphaned
# Full health check (combines all above)
wp multitool health
These are the commands I wish existed in core WP-CLI. They turn a 20-minute manual audit into a 10-second script.
Automation Template
Here’s a weekly maintenance script that combines everything:
#!/bin/bash
SITE="/var/www/yoursite"
BACKUP_DIR="$HOME/backups"
# Backup first
wp --path="$SITE" db export "$BACKUP_DIR/$(date +%Y%m%d).sql" --quiet
# Updates
wp --path="$SITE" plugin update --all --quiet
wp --path="$SITE" core update --quiet
# Cleanup
wp --path="$SITE" transient delete --expired --quiet
# Health check (requires WP Multitool)
wp --path="$SITE" multitool health
echo "Done: $(date)"
Add it to cron, forget about it, check the output when something feels off. That’s the WordPress maintenance workflow that actually scales.
Originally published at WP Multitool Blog.
Find what’s slowing your WordPress. WP Multitool — 14 modules, $50 lifetime, zero bloat. Built by Marcin Dudek.