Confirm that the service provides the required shell access and WP-CLI installation. Use the hosting account's authorised user rather than root. Review the PHP executable and version used by the command line, which can differ from the website's web PHP configuration.

Locate the actual WordPress root and check for WP-CLI configuration files or aliases that may supply default paths, URLs or other options.

wp core is-installed --path=/path/to/wordpress
wp option get home --path=/path/to/wordpress
wp option get siteurl --path=/path/to/wordpress

Use the confirmed real path in place of the placeholder. Compare the returned URLs with the intended site. In Multisite, add the appropriate --url=https://example.com selection when the command operates in a subsite context.

1. Read the official help for the exact subcommand and options.
2. Determine whether it reads data, writes files, changes the database or triggers external actions.
3. Take a suitable backup before meaningful writes and use a dry-run option when that command provides one.
4. Run against the single verified target and review the output before expanding the scope.
5. Verify the actual application result through a separate check.

On a verified Multisite installation, first list the network’s site addresses, then inspect the intended subsite with an explicit URL. These commands read the site inventory and home setting; they do not loop through the network or change content.

wp --path='/home/ACCOUNT/sites/network' \
  site list --fields=blog_id,url --format=table
wp --path='/home/ACCOUNT/sites/network' \
  --url='https://shop.example.com' option get home

Compare the selected address with the actual shop before planning any maintenance. Site-aware commands can use --url to choose context, but raw database commands require deliberate table names and can ignore that selector. Keep network-wide operations separate from a task affecting only one subsite.

Expected result: The maintenance record identifies both the network path and selected site. A command intended for the shop cannot be approved merely because it succeeded against the network’s main website or another valid installation.

Do not loop over every directory or installation with a destructive command until the target list and recovery plan are reviewed. A wildcard can include staging sites, old copies or unrelated applications.

Keep secrets out of shell history and process arguments where possible. Use documented secure input mechanisms for credentials rather than pasting passwords into reusable scripts or support transcripts.

Many WP-CLI commands load WordPress and can execute plugin bootstrapping. A command that appears read-only can still encounter a fatal plugin error. Record that failure rather than repeatedly adding broad skip flags without understanding the resulting context.

If a command times out or disconnects during a write, inspect the resulting state before repeating it. Some work may have completed. Provide support with the command, target path context and sanitised output, and state whether the site is single-site or Multisite. Explicit targeting and verification are the foundation of a safe command-line workflow.

• Listing plugins and themes with WP-CLI for support
• Checking WordPress cron events with WP-CLI
• Performing a serialisation-safe WordPress search and replace
• Checking WordPress core file integrity with WP-CLI

• WP-CLI configuration
• WordPress: Get
• WordPress: Is Installed

• WP-CLI Multisite site inventory
• WP-CLI SQL query scope