Skip to content
WordPress Maintenance

Improving WordPress Maintenance Quality with SSH + WP-CLI — A Framework for Safer Updates

WordPress maintenance usually means updating the core, plugins, and themes. In most agencies, this is done by logging into the admin dashboard, clicking the “Update” button on each plugin, checking the front page, and moving on to the next site.

This works fine for a handful of sites. But once you manage more than a few, the limitations become hard to ignore:

  • The dashboard only offers “Update all” or “Tick each one” — no real middle ground
  • When something breaks after an update, isolating the cause is messy
  • Backups, visual checks, and rollback are all manual steps
  • The quality of maintenance varies by who is on the keyboard, and at what hour

This article walks through how SSH and WP-CLI — two foundational technologies — can be combined into a maintenance framework that delivers a level of safety and reproducibility that’s difficult to reach by hand.

The point isn’t “let’s make this easier”. It’s “let’s make every maintenance run hold a consistent quality bar”.

1. What SSH and WP-CLI Actually Are

Quick refresher before we dive in.

SSH (Secure Shell)

SSH is an encrypted, key-authenticated channel that lets you send commands directly to your server from your local machine. If you’ve used FTP for file uploads, think of SSH as “FTP plus the ability to run any command on the server”. Traffic is encrypted; key-based authentication is the standard for production use.

WP-CLI

WP-CLI is the official command-line tool for WordPress. Almost everything you’d normally do in the wp-admin dashboard — updates, backups, settings, user management — can be done with a one-line command.

Together, these two let you operate WordPress on your server without ever opening the admin dashboard.

If the dashboard is the “front-of-house counter” for site visitors, SSH + WP-CLI is the “staff entrance” for operators. No screens to navigate. No spinners to wait on. You issue a command and the server executes it.

2. Concrete Techniques for Safer Updates

This is the meat of the article. Where exactly does SSH + WP-CLI fit into your maintenance workflow, and how?

2-1. Take a DB Backup Before Every Update

The single worst outcome of any update is “something broke and I can’t roll back”. With WP-CLI, the safety net is one line:

wp db export backup_$(date +%Y%m%d_%H%M%S).sql

This produces a SQL dump on the server. Wrap a generation policy around it (auto-prune older backups), and now every maintenance run starts from a known-recoverable state.

Compared to running a backup plugin from the admin UI:

  • Always runs (no human “I forgot”)
  • Filenames carry timestamps (history is trivially auditable)
  • The same script can back up dozens of sites in sequence

This is about leveling the quality of “did we actually back up?” to the same standard every single time.

2-2. Inventory the Site State

Before touching anything, capture the current setup in a machine-readable form:

wp plugin list --format=json
wp theme list --format=json
wp core version

You now have every plugin name, version, and active/inactive status, ready for diff and audit.

Note: What is JSON?
JSON (JavaScript Object Notation) is a structured data format that’s both machine-readable and reasonably human-readable. Saving output as JSON makes it trivial to compare snapshots before and after updates, or to feed the data into other tools later. Throughout this article, JSON is the format we use to record site state in a form that survives the maintenance window.

If you store this output as JSON, you get:

  • Diffable snapshots before and after updates
  • Audit-ready records of “we updated X from 1.4 to 1.5 on this date”
  • A way to reconstruct the prior state if something goes wrong

In other words, a complete audit trail emerges as a side effect of running WP-CLI commands. The same data that drives your client reports is one command away.

2-3. Step-Wise Plugin Updates

This is where the dashboard’s “Update all / tick each one” model loses to the command line.

With WP-CLI, you can update a single plugin and immediately verify the site is still healthy before moving on:

wp plugin update plugin-name

Wrap that in a loop with an HTTP check between each step:

for plugin in $(wp plugin list --update=available --field=name); do
  wp plugin update "$plugin"
  curl -sI -o /dev/null -w "%{http_code}\n" https://example.com/
  # → halt the loop here if anything other than 200 is returned
done

Once this pattern is in place, you gain two properties that are very hard to achieve manually:

  • The pipeline halts the moment a site breaks
  • The exact plugin that caused the breakage is identifiable, automatically

Compare with “update everything, then visually inspect”: that approach falls back to guesswork once more than one plugin is involved, and reproducibility is poor. With step updates, where it broke is mechanically determined, often eliminating the diagnosis step entirely. This isn’t “faster” — it’s “more precise than is realistic by hand”.

2-4. HTTP Status Checks

After every update step, verify the site responds with a 200:

curl -sI https://example.com/ | head -1

Anything other than HTTP/2 200 (500, 503, etc.) is a strong signal that the previous update introduced a fault. By inserting checks between each step, you build early-detection points into the maintenance run itself.

For better coverage, check several critical paths — the home page, contact form, cart, a sample post — not just /. Multi-path checks catch a wider class of regressions.

2-5. Pinpoint Rollback

Step updates and HTTP checks together can mechanically detect “this specific plugin update broke the site”. The next thing you need is a way to roll back that one plugin, without disturbing anything else.

WP-CLI handles this in a single line:

wp plugin install plugin-name --version=1.2.3 --force

--version pins the older version, --force overwrites in place. The plugin is back to its prior version; everything else stays current.

Doing this from the dashboard would mean SFTPing into the plugin folder and replacing files by hand, or re-uploading an old ZIP. WP-CLI completes the same operation in one command, which makes it practical to roll back only the plugin that actually broke, while keeping every other safe update applied.

Rolling back an entire site loses the safe updates too. Minimum-scope rollback is preferable both for site state and for security posture: you don’t carry an outdated version forward longer than you have to. This is another instance of “precision that’s difficult by hand”.

2-6. Automatic Audit Trails

When you script everything above, an enormous amount of evidence accumulates as a byproduct:

  • Which plugins moved from which version to which version, and when
  • What HTTP status codes were observed at each step
  • Where things went wrong, and what the auto-recovery did
  • If a rollback fired, which plugin and to which version

These artifacts are how you explain maintenance quality to a client objectively. Once you outgrow “trust me”, being able to point to evidence becomes the foundation of the relationship.

3. SSH / WP-CLI Across Major International WordPress Hosts

Real deployments hit different host quirks. A quick survey of the major international hosts most agencies see:

WP Engine (managed WordPress)

  • SSH access is included on Startup plans and up
  • WP-CLI is preinstalled — wp plugin list works out of the box
  • A managed environment, so the tooling story is consistent across customers

Kinsta (managed WordPress)

  • SSH access is included with all plans
  • WP-CLI is preinstalled in the SSH session
  • Easy to use for one-off operations or full automation

SiteGround (shared hosting)

  • SSH is available on the GrowBig plan and above
  • WP-CLI is installed; wp is on the PATH
  • Newer PHP versions are the default on recent plans, which matters for WP-CLI

Cloudways (managed VPS)

  • Full SSH access on every plan; you choose the underlying cloud (DigitalOcean, AWS, GCP, Vultr, Linode)
  • WP-CLI is part of the standard image and “just works”
  • More flexibility, more responsibility — closer to running your own server

Common operational notes

  • WP-CLI paths can differ between hosts. A multi-site automation script should look up the correct binary per host rather than assuming wp is in PATH everywhere.
  • PHP version matters. Newer WP-CLI releases require newer PHP. An old shared host can refuse to run modern WP-CLI at all.
  • Pin host fingerprints in known_hosts. This protects against man-in-the-middle attacks during automation runs.
  • Use key authentication with a passphrase. Even if a private key file leaks, the passphrase is the second wall.

4. What About Sites That Don’t Support SSH?

Some clients are on hosts where SSH isn’t available, or you can’t get the credentials. That’s a real-world constraint.

The fallback is browser automation (Playwright, Puppeteer, etc.) — a script that drives the wp-admin UI as if a human were clicking through it. The updates do happen.

But browser automation comes with limitations you should be aware of:

  • DB backups are not as reliable as wp db export (you depend on a backup plugin)
  • True pinpoint rollback is essentially unavailable (no versioned reinstall path)
  • Inventory and HTTP checks happen at a coarser granularity
  • A wp-admin UI change can break your automation overnight

Put bluntly, browser-based automation operates one tier below SSH + WP-CLI on the safety axis. That’s a useful, evidence-based argument when proposing that a client move to an SSH-capable host as part of the maintenance contract.

5. Summary — Raising the Quality Bar

SSH + WP-CLI isn’t a tool for “doing maintenance faster”. It’s a tool for achieving a level of safety and reproducibility that’s hard to reach by hand.

The framework, in one paragraph:

  • Always take a DB backup before any change
  • Update plugins one at a time, with HTTP checks between steps
  • If something breaks, roll back only the plugin that broke
  • Save the audit trail automatically along the way

When this is in place, you get:

  • Incidents prevented (the pipeline halts before things spread)
  • Fewer human errors (the procedure is mechanical)
  • Faster anomaly detection (checkpoints are dense)
  • Defensible quality (the evidence speaks for itself)
  • A higher bar for what “professional maintenance” means (the floor is consistent)

Conversely, manual-only maintenance is structurally hard to keep at a high quality bar — it depends on which person is on duty and how attentive they are that day. The point of using these tools is to remove that variance.

About WP Maintenance Manager

If you’d rather get the SSH + WP-CLI framework described above without writing the scripts yourself, WP Maintenance Manager is a desktop app that bundles the whole pipeline.

  • Manage SSH credentials for many WordPress sites in one place
  • DB backup, step-wise updates, HTTP checks, pinpoint rollback — all from a GUI
  • Update logs and screenshots are recorded automatically (white-label PDF/HTML reports included)
  • Customise the report with your company name, logo, and colour

Free download and full feature breakdown at the WP Maintenance Manager site. FAQ and the User Guide are linked from the top page.

Tags