Maintaining a WooCommerce Store with Claude Code: How SSH, WP-CLI and MCP Split the Work, No Coding Required (Jason Career Case Study)

Jason Career is my WordPress site where I sell ebooks, online courses and consulting services, and the store runs on WooCommerce. Since October 2026, day-to-day maintenance has been Claude Code’s job: it connects to the server over SSH and uses WP-CLI, the WordPress command-line tool, to look up data and change settings. How the first 10 days started and what got done is in Running WordPress Without Knowing SSH. This post covers only the store side: payments, checkout, caching, the firewall, and the WordPress MCP that many people have been asking about lately.

The short version: on an online store, I let Claude Code handle read-only checks, cache clearing and backed-up settings changes on its own, and I confirm everything involving payments, checkout, prices and customer data. As for tools, as of 29 October 2026 Jason Career uses only SSH and WP-CLI and has not installed any MCP. WordPress, WooCommerce and Cloudways all have official MCPs now, each suited to different jobs; the summary below follows their official documentation.

This is a maintenance record of my own website, plus the official Anthropic, WordPress, WooCommerce and Cloudways documentation I checked on 29 October 2026. Plugin versions, MCP features and each vendor’s interface will change, so check the official documentation before doing anything. This post is not security or legal advice.

What on an online store can go to Claude Code, and what needs human review

When an ordinary blog breaks, the worst case is usually a messed-up page layout. When a store breaks, a customer might pay and never receive the course, or the checkout page might not load at all. So I sort the work into three categories by one question: if this goes wrong, does it touch money or customer data?

Claude Code can technically do the third category too, but if it gets something wrong, the customers pay the price. Whether to switch off a payment method, for example, depends on customer habits and the payment provider contract, which AI cannot see.

Case 1: A read-only inventory of plugins and payments with WP-CLI, without touching keys

On 29 October, I asked Claude Code to put together Jason Career’s payment and server information. On the live site it used only read-only commands, such as listing active plugins (WP-CLI’s wp plugin list), and then checked which WooCommerce payment methods were switched on.

The inventory (29 October 2026):

The whole report contains no API keys, merchant IDs, HashKey, HashIV, passwords, customer personal data or order details. Payment plugin settings store exactly these values, so even “reading the settings” needs ground rules up front: look only at which payment methods are on, never read out the key fields, and never paste them into the chat or a document.

The inventory also turned up something I hadn’t noticed: the checkout page showed two PAYUNi credit card options at the same time, one from PAYUNi Pro for WooCommerce and one from Pay with PAYUNi, two separate plugins. Customers seeing two near-identical options may not know which one to pick.

This falls into the third category. Which one to switch off affects the checkout page and the existing payment flow, so Claude Code only reported it and left the decision to me.

Case 2: Don’t let the Cloudflare firewall block payment callbacks

On 24 October, a flood of crawlers brought Jason Career down: the server ran out of memory and crashed, and the checkout page went down with it. After Cloudflare firewall rules were added, server load dropped from about 13 to around 0.5.

The thing to watch most when adding the rules was payment callbacks. When a customer finishes paying with PAYUNi or LINE Pay, the payment provider’s server calls a URL on the site to report that the order has been paid. These requests don’t come from a person, so they can’t pass a human verification challenge; if they are blocked, the customer has paid but the order never changes to paid. That is why the rules specifically exempt these three URL patterns from human verification:

• /wc-api/
• ?wc-api=
• /wp-json/

Afterwards, a few “unable to process callback” entries appeared in the payment provider’s dashboard logs, a few each on 24 and 26 October. On checking, they were empty requests we had sent to the callback URL while testing the firewall, not errors on real orders; the logs also showed no case of “payment completed but the order not updated”.

Caching has to be thought about in layers as well: Cloudways has Varnish at the server level, and clearing only WP Rocket may not clear it, so after changing settings both layers need clearing. Details in Cloudways Varnish and WP Rocket, Two Cache Layers.

For a comparison of the plugins, fees and payout times of PAYUNi, LINE Pay and ECPay, see Choosing WooCommerce Payment Gateways in Taiwan.

Case 3: Bank transfer orders, and purchases GA4 missed

Jason Career’s service products can be paid by bank transfer. A transfer is paid afterwards: the customer has long since left the thank-you page after ordering, so by the time we confirm the payment, the browser-side tracking code no longer has a chance to run, and GA4 misses the purchase.

On 13 October this was changed so that the server sends the purchase event when an order changes to “paid”. A change like this touches the order flow but doesn’t change prices or payment methods, so I put it in the second category: explain the scope before starting, verify after the change.

WordPress MCP, WooCommerce MCP, Cloudways MCP: what is officially available now

MCP (Model Context Protocol) is an open standard for connecting AI to external systems. In Claude Code, claude mcp add adds an MCP server, and /mcp shows its status and handles sign-in (Claude Code official documentation). These are the official options I found on 29 October 2026:

The built-in abilities listed in WooCommerce’s official documentation are: listing, creating, updating and deleting products; listing orders, listing order notes, updating order status and adding order notes. The documentation also warns plainly that order and customer operations may expose personal data, and recommends a dedicated account with only the permissions it needs, keeping application passwords out of version control, and revoking ones no longer in use.

I could read Cloudways’ official MCP overview page, but its setup guide was blocked by the site’s bot verification when I checked, so I couldn’t read it in full. For the actual endpoint URL and token settings, go by what you see after signing in to the Cloudways dashboard.

Why Jason Career still uses SSH and WP-CLI

The upside of SSH plus WP-CLI is that it can do anything: check plugins, change settings, run database queries, clear caches, all with one set of tools. The downside is also that it can do anything, so safety depends entirely on rules and backups. I wrote about how I set those rules in the CLAUDE.md post.

MCP works the other way around: the site exposes only a few abilities, and AI can use only those. For a store, that scope is easier to control, for example exposing only product lookups and order status. But WooCommerce’s MCP is still a preview, and WooCommerce says the interface may change. Most of Jason Career’s work is also at the hosting and plugin settings level, such as Varnish, Cloudflare rules and the payment plugin inventory, none of which is among WooCommerce’s built-in abilities.

So for now I split the work like this:

• Site content and plugin settings: keep using SSH and WP-CLI, limited by rules.
• When I want AI to touch only products and order status: WooCommerce MCP is the cleaner approach; I’ll evaluate it once it leaves preview.
• Hosting-level tasks: Cloudways MCP can use a read-only token, which suits checking status first.

One more point relates to the firewall: the MCP Adapter’s HTTP endpoint sits under /wp-json/, and Jason Career has already exempted /wp-json/ from human verification for the payment callbacks. If I install it later, the only thing keeping people out will be the WordPress account and application password, so that account’s permissions need to be kept to the bare minimum.

A safety checklist before letting AI change a store

Here is the checklist I put together. It applies whether you use SSH or MCP:

1. Least privilege: read-only wherever possible. If you use MCP, create a dedicated account with only the permissions it needs; with a Cloudways token, start with read-only and an expiry time.
2. Keep each site separate: one set of accounts, keys and settings per site, so trouble on one doesn’t spread to another. Jason Career’s server also hosts another WordPress site, so every command has to specify which one.
3. Keys stay out of the chat: payment keys, application passwords and database passwords never get pasted into a conversation with Claude, and never go into Git. During the inventory, only on/off status is read, never the key fields.
4. Back up before changing: back up before any settings change; if the backup fails, don’t make the change.
5. A human approves payments and checkout: for payment method switches, payment plugin settings, checkout fields, prices and discounts, Claude Code can only propose changes and describe their impact.
6. Verify all the way to the last step: after changing the firewall or caching, confirm the checkout page loads and the payment callback URLs aren’t blocked.
7. Customer data stays on the server: when checking orders, look only at status and counts; never read names, email addresses or phone numbers into the chat.

If you’re new to Claude Code, start with Claude Code for Beginners for installation, permissions and basic MCP setup.