Stop Clicking Through wp-admin: A WordPress WP-CLI Guide

Most WordPress work happens through a browser: you log in, click into a menu, wait for a page to load, click again. That’s fine when you’re writing a post. It falls apart the moment you need to update forty plugins, swap a domain name across ten thousand database rows, or figure out whether a site has been hacked. The dashboard was built for editing one thing at a time, and bulk work is exactly where it gets slow and error-prone.

The last emergency cleanup we did started with a client swearing nothing had changed. One command — wp core verify-checksums — flagged a modified wp-blog-header.php in under two seconds, and there it was: an IndoXploit webshell quietly serving pharma spam to Google. Finding that through the admin screens would have taken an afternoon of guessing. From the command line it took one line.

That command is part of WP-CLI, the official command-line tool for WordPress. If you run more than one site, do migrations, or ever have to clean up someone else’s mess, it’s the single biggest time-saver you can learn. Here’s what it does and how to start using it.

What Is WP-CLI?

WP-CLI is the official command-line interface for WordPress. Instead of clicking through wp-admin, you type commands in a terminal and WordPress does the work — installing plugins, creating users, exporting the database, searching and replacing text, running updates, flushing caches, and hundreds of other tasks. It ships as a single PHP file (a “Phar”) and talks to your WordPress install directly, so anything the dashboard can do, WP-CLI can usually do faster and in bulk.

It’s a mature, well-supported project. WP-CLI’s resources moved under the official WordPress.org project in early 2017 (announced by Matt Mullenweg in December 2016), and today it’s preinstalled on most managed WordPress hosts. The tool itself is free and open source under the MIT license, and the full command reference lives at developer.wordpress.org/cli.

Installing WP-CLI

You install WP-CLI on the server where WordPress lives — usually over SSH — not on your laptop. The official install guide requires PHP 7.2.24 or newer and has no additional requirements beyond those of WordPress itself. It’s built for UNIX-like environments (Linux, macOS, FreeBSD); Windows has its own separate install path.

The standard install is three commands. Download the Phar, confirm it runs, then move it somewhere on your PATH so you can call it as wp:

After that, wp --info confirms the version, and wp cli update keeps WP-CLI itself current later on. Run any command from inside your WordPress directory (the folder with wp-config.php) and it picks up your site automatically. If you manage sites as a different system user, prefix commands with that user (for example sudo -u www-data wp <command>) so files stay owned correctly.

The Commands You’ll Actually Use

WP-CLI has hundreds of subcommands, but a handful cover most of what you’ll do day to day. They all follow the same shape: wp <noun> <verb> [options].

Core: updates and integrity

The wp core commands manage WordPress itself. You can check the version, update to the latest release, or verify that your core files haven’t been tampered with:

• wp core version — print the installed WordPress version
• wp core update — update WordPress core to the latest release
• wp core verify-checksums — compare every core file against the official checksums from WordPress.org and report anything that’s been changed, added, or is missing

That last one is worth memorizing. It’s the fastest first pass on any site you suspect is compromised, because injected malware almost always modifies a core file that’s supposed to be byte-for-byte identical to the official release.

Plugins and themes in bulk

This is where WP-CLI saves the most clicking. Updating plugins one at a time in the dashboard is tedious; from the command line it’s a single command:

• wp plugin list shows every plugin, its status, and whether an update is available
• wp plugin update --all updates everything in one shot
• wp plugin install wordpress-seo --activate installs and turns on a plugin from the WordPress.org directory in one line
• wp plugin deactivate --all is a lifesaver when a bad plugin has locked you out of the admin — deactivate everything, log in, then reactivate one at a time to find the culprit

The wp theme commands mirror these exactly (list, install, activate, update), so once you know one, you know both.

Users

Managing accounts from the terminal is quick and scriptable. To list everyone, create an editor, or hand off content before deleting a departing user:

• wp user list --fields=ID,user_login,user_email,roles — a clean roster of every account
• wp user create jane [email protected] --role=editor — create an account with a role
• wp user delete 12 --reassign=1 — delete user 12 and reassign their posts to user 1 so nothing is orphaned

The database

WP-CLI wraps the standard MySQL tools so you don’t have to remember their flags. Per the WP-CLI docs, wp db export runs mysqldump to write a .sql file, and wp db import loads one back through the mysql client:

• wp db export backup.sql — dump the whole database to a file before you touch anything risky
• wp db import backup.sql — restore it
• wp db optimize — run OPTIMIZE TABLE across your tables to reclaim space and defragment them

The One Command That Justifies Learning It: search-replace

If WP-CLI had only one feature, this would be the one. Moving a WordPress site to a new domain means the old URL is buried everywhere — post content, widget settings, theme options, plugin config. A naive find-and-replace with a SQL query corrupts your site, because WordPress stores a lot of that data as serialized PHP, where each string is prefixed with its exact byte length. Change the text without fixing the length count and the data breaks.

wp search-replace understands serialized data and rewrites those length counts correctly as it goes. That’s what makes it safe where a raw database query isn’t:

The --dry-run flag reports exactly how many rows in which tables would change, so you can sanity-check the scope before committing. Run the export first, dry-run second, real run third. Do that and moving a site between domains — or from staging to production — goes from a nerve-wracking manual chore to a ten-second command.

Cleaning Up a Hacked Site From the Terminal

Back to that IndoXploit webshell. When a site is compromised, the dashboard is the last place you want to be — the attacker may have hidden admin users, and loading plugin pages can even re-trigger the malware. WP-CLI lets you inspect and repair from outside the browser entirely.

A practical triage sequence looks like this. Start with wp core verify-checksums to catch modified core files. Then wp plugin verify-checksums --all does the same for plugins hosted on WordPress.org. List the users with wp user list and look for accounts you don’t recognize. Check scheduled tasks with wp cron event list, since malware loves to hide a re-infection job there. None of that requires clicking a single admin screen.

For deeper scanning — spotting obfuscated code, backdoors in wp-content/uploads, or nulled-plugin payloads that checksums won’t catch — we built amplifi.security, part of our open-source plugin suite. It complements WP-CLI rather than replacing it: the command line finds the obvious tampering fast, and a dedicated scanner digs out what’s hiding in the corners.

Caches, Cron, and Other Everyday Fixes

A few more commands round out the toolkit. When something looks stale or stuck, these usually sort it:

• wp cache flush — flush the object cache (handy after a change that isn’t showing up)
• wp transient delete --all — clear every transient, which resolves a surprising number of “the dashboard says an update is available but it isn’t” glitches
• wp cron event run --due-now — manually fire scheduled tasks that are overdue, useful on low-traffic sites where WP-Cron doesn’t fire on its own
• wp rewrite flush — regenerate permalink rules after a 404-everywhere situation
• wp media regenerate — rebuild all image thumbnail sizes after switching themes or changing image dimensions

You Might Already Have It

If your site runs on managed WordPress hosting, WP-CLI is very likely already installed and waiting behind SSH. Hosts like WP Engine, Kinsta, SiteGround, and Flywheel ship it by default because their own support teams rely on it. Connect over SSH, cd into your site directory, and run wp --info to check. If it responds, you can start using everything above right now — no install step needed.

Learning WP-CLI has a real payoff curve: the first day feels like extra friction, and by the second week you’ll wince every time you have to do bulk work through a browser instead. Start with the read-only commands (wp plugin list, wp user list, wp core verify-checksums) to build confidence, keep wp db export as your safety net, and add the destructive commands once you trust the flow.

Frequently Asked Questions

WP-CLI is the tool we reach for first on almost every WordPress job — from routine updates to full incident response. If you run more than one site, the afternoon you spend learning it pays for itself the first time you skip a hundred clicks. Start with the official command reference.

Built by amplifi.studio — see also our WordPress malware cleanup guide.