How to Use WP-CLI on cPanel Shared Hosting

WP-CLI is the command-line tool for WordPress. It can update plugins, check the site’s health, search and replace addresses, and create users, all faster and more reliably than clicking through the dashboard. Many people assume it needs a server they control, but it runs on a cPanel account too, over SSH, with the PHP version the site already uses. This guide installs WP-CLI in a home folder, runs the commands that do the most useful work, and shows the safety habits that keep a shared account safe.

WP-CLI works on SiteHarbour’s cPanel hosting and on the WordPress hosting plans, as long as SSH access is enabled for the account. Enable it in cPanel under SSH Access before you start, and use a key rather than a password where you can.

Before you start#

• SSH access to the account, from a terminal on your own computer.
• A backup of the site, as described in how to back up and restore a cPanel account. WP-CLI changes the database directly, so the backup matters more than usual.
• The WordPress folder. On a cPanel account, this is usually ~/public_html, or a subfolder if the site lives there.

Step 1: Download WP-CLI into your home folder#

Connect over SSH and download the phar file. Keep it in your home folder, outside the web root, so visitors cannot download it:

cd ~
curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info

Expected: a block of version and PHP details. The PHP version shown is the one the command used, so check that it matches the site’s version, as shown in Step 2.

Step 2: Use the same PHP version as the site#

The php command on the PATH may not be the version the site runs. Find the version used by the domain in Select PHP Version in cPanel, then call that binary directly. For PHP 8.4, the path is:

alias wp='/opt/cpanel/ea-php84/root/usr/bin/php ~/wp-cli.phar --path=$HOME/public_html'

Replace ea-php84 with the version you use, and the path with the folder where WordPress is installed. Add the alias to your shell profile so it stays, or type it each session. Test it with wp core version, which prints the WordPress version the site runs.

Step 3: Check the site’s health#

Three commands give a quick picture of the site without changing anything:

wp core version
wp plugin list --update=available
wp theme list --update=available

Expected: the WordPress version, then lists of plugins and themes that have updates waiting. An empty list means the site is current. Use these commands before any change, so you know what state the site started in.

Step 4: Update plugins safely#

Update one plugin at a time, and check the site after each one. Updating everything at once makes a failure hard to trace:

wp plugin update example-plugin

Expected: a line that shows the old and new version, and a success message. Load the site and the page the plugin affects. For a plugin that runs a form, a shop or a membership, test that feature as well. The steps for testing on a copy first are in how to set up a WordPress staging site before updates.

Step 5: Search and replace with a dry run#

Replacing an address across the database is one of the most useful things WP-CLI does, and one of the riskiest. Always run it with --dry-run first, and read the count before you save anything:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

Expected: a table of tables and the number of replacements in each. When the numbers look right, run the same command without --dry-run. The command handles serialized data correctly, which a plain text replace does not.

Step 6: Manage users without the dashboard#

To check who has admin access, list the users and their roles:

wp user list --role=administrator --fields=ID,user_login,user_email

Expected: the administrators you know. Remove access for anyone who should not have it, with wp user remove-role for one role, or delete the account, after you have confirmed no content depends on it. An unknown administrator is a sign of a break-in, so check this list after any security incident.

Step 7: Clear caches and keep the site healthy#

After changes, flush the object cache and rewrite rules when the site needs it:

wp cache flush
wp rewrite flush

Run wp rewrite flush only after a permalink or routing change, because it rewrites rules on every request until it finishes. The cache flush is safe to run after any change.

Common mistakes#

• Running WP-CLI as root. Run it as the account user, so the files it writes keep the right owner.
• Using the wrong PHP. A command that runs on an older PHP can fail or change the database in a way the site does not expect.
• Skipping the dry run. A search and replace can change thousands of rows at once.
• Updating everything in one command. A failure is then impossible to trace back to one plugin.
• Keeping the phar in public_html. Visitors can download it.

Frequently asked questions#

Is WP-CLI safe on shared hosting?#

Yes, as long as it runs as your account user, uses the site’s PHP version and stays out of the web root. The commands run with your account’s permissions, not the server’s.

Can I use WP-CLI without SSH?#

No. It needs a shell. Use the dashboard or cPanel’s tools if SSH is not available.

Which command should I learn first?#

Start with wp core version and the update checks in Step 3. They change nothing, and they show the state of the site.

Does WP-CLI replace the dashboard?#

For many tasks, yes. It is faster for bulk work and for scripts. The dashboard is still the easier place for editing content.

WP-CLI gives you a fast, exact view of a WordPress site on a shared account. Install it in your home folder, use the site’s own PHP version, check the state before you change anything, update one plugin at a time, and always dry-run a search and replace. Keep a backup before any bulk change, and it becomes one of the most useful tools you have. For the wider security checks that go with it, read how to keep your cPanel account and sites secure.