WooCommerce maintenance: why a store is not a website with a cart

Your store stopped taking orders at some point over the weekend. Nobody noticed until Monday, when the numbers looked wrong. The site was up the whole time. Every page loaded. The checkout button was right where it has always been.

This is the characteristic WooCommerce failure, and it is the reason store maintenance is a different discipline from website maintenance rather than the same one with a bigger invoice.

We have been building and inheriting WordPress sites since 2008, over 800 projects for 437 clients, and we run maintenance and rescue work on hundreds more. A good share of those are stores, including ones we did not build and were handed after something went quiet. So this is written from the side that gets the Monday morning phone call.

The short answer

A WooCommerce store is a transaction processor that happens to have pages, and four things about it break the standard maintenance routine. The rollback does not exist, because restoring a pre-update backup also deletes every order taken since. The failure is silent, because a broken checkout looks identical to a working one and customers who cannot pay do not complain. Your customisations go stale invisibly, because WooCommerce updates its own templates and your theme’s copies of them stay frozen at the version they were written against. And since 31 March 2025 the checkout page carries a PCI DSS obligation that no plugin satisfies on your behalf. A store maintenance plan that does not name those four is a WordPress plan with the word WooCommerce in the headline.

What the advice out there actually says

We put the three natural phrasings of this question to the search-grounded models this week, the way an owner would ask them.

The answers are a symptom list. Caching problems, plugin conflicts, JavaScript errors, SSL misconfiguration, payment gateway settings, slow pages, 500 errors. It is accurate as far as it goes, and some of it is genuinely good: one model correctly explained stale nonces on a cached checkout page and mixed-content failures on AJAX requests.

But every one of those answers treats the question as troubleshooting. What broke, here is the fix. Not one of roughly thirty sources across the two working models frames the question an owner or an agency actually has, which is: what does routine maintenance do to a store that it does not do to a brochure site, and why does the plan I am already paying for not cover it?

The cost answers have a sharper problem, and it is worth naming because the figures are repeated everywhere. One model returned a range from zero to over 3,000 dollars a month. Another gave 30 to 200 for small and mid-sized stores. Both then reproduced a table, sourced to a single vendor blog, pricing annual maintenance by the store’s revenue: 1,800 to 4,500 dollars for a hobby store, 50,000 to over 200,000 for an enterprise one.

Read that again as a cost estimate and it falls apart. Maintenance effort is set by the number of moving parts a store has, not by what it sells. Two stores with the same theme, the same four plugins, one payment method and no template overrides need the same maintenance whether one turns over 50,000 a year or five million. Pricing by revenue is value-based pricing wearing a cost estimate’s clothes. It tells you what a vendor thinks you can pay.

The other figure worth correcting is the zero. Doing it yourself is listed at zero dollars a month, “but requires 4 to 6 hours of your time monthly”. For most small store owners that is the most expensive labour in the business, being spent on the task they are least equipped to do. It is not a free option, it is an unpriced one.

Difference 1: the rollback you were promised does not exist

Nearly every maintenance plan on the market, ours included, rests on one promise. We take a backup, we apply the update, and if anything breaks we roll back. On an ordinary website that promise is close to free. The pages are the same pages they were yesterday, so restoring yesterday’s copy costs you nothing.

On a store it is not free, because the store changed while you were not looking.

Restoring a backup taken at 02:00 on a site that has been trading since means discarding every order, payment, stock movement, refund and customer account created after 02:00. Some of those customers have been charged. Their money is with your payment processor and the record of why is in the database you just overwrote.

WooCommerce has made this more concrete rather than less. Since High-Performance Order Storage shipped, orders no longer live alongside your posts and pages. WooCommerce’s documentation describes HPOS as “a solution that provides an easy-to-understand and solid database structure - specifically designed for eCommerce needs”, syncing order data into four dedicated tables, and notes that “From WooCommerce 8.2, released on October 2023, High-Performance Order Storage (HPOS) is officially released under the stable flag and will be enabled by default for new installations.” That is better engineering and it makes the point sharper: your orders are a live transactional dataset, not content.

So the safety net the entire category advertises is the one thing you cannot casually use on a store during trading hours. What has to replace it:

• Staging with a real copy of production data. Not an empty test site. An update that works on a store with no orders and no customers has proven very little.
• A release window chosen from your own order data. Every store has a quietest hour. Most owners have never looked it up.
• A rollback plan that separates code from data, so reverting a broken plugin does not mean reverting the day’s trading.

If a maintenance quote promises “full backup and rollback” for a store and does not mention any of those three, it is quoting you a brochure site plan.

Difference 2: a broken store looks exactly like a working one

The second difference is about detection, and it is the one that costs real money.

When a brochure site breaks, it looks broken. A layout collapses, a page throws an error, somebody in the office notices within a day. The feedback loop is human and it works.

A store breaks silently. The product page renders. The add-to-cart button is present and styled correctly. The customer clicks it and nothing happens, or the checkout spins, or the payment declines with a message they assume is their bank’s problem. Then they leave. They do not email you. Nobody has ever filed a bug report against a shop that would not take their money, because from the customer’s side there is no bug, there is just a shop that did not work and a competitor who will.

Your monitoring will not catch it either. Uptime monitoring asks whether the server answered. The server answered. It served a perfectly valid page containing a checkout that does not function.

The most common mechanical cause is a caching layer applied to pages that must never be cached. WooCommerce’s own guidance is blunt about which ones: “make sure you exclude the following pages from the cache through your caching systems respective settings. Cart, My Account, Checkout”, because “these pages need to stay dynamic since they display information specific to the current customer and their cart”. Cache them and one shopper is served another shopper’s cart, or an expired security token, and the order never completes.

That single configuration is also the most likely thing to be changed by accident. A new performance plugin, a host enabling edge caching, a well-meaning speed optimisation done for Core Web Vitals, and the exclusion list is silently reset.

Which is why the load-bearing task in store maintenance is not the update. It is the test after it:

• Place a real order end to end, through each payment method, after every update run.
• Confirm the order appears, the confirmation email sends, and stock decrements.
• Check that a logged-in customer and a guest both get their own cart.
• Watch the first hour of real orders after a release rather than closing the ticket.

That takes twenty minutes and it is the difference between a plan that maintains a store and a plan that maintains a website that sells things.

Difference 3: your customisations go stale on a schedule you do not control

Almost every real store has template overrides. It is how WooCommerce is designed to be customised: your theme keeps its own copy of a WooCommerce template file, and WooCommerce uses yours instead of its own.

The consequence is stated plainly in WooCommerce’s own theming documentation, and it is easy to read past: “A (desirable) side-effect of your templates being upgrade-safe is that WooCommerce core templates will update, but your custom overrides will not. You may occasionally see notices in your System Status report that says, e.g. ‘version 3.5.0 is out of date. The core version is 3.7.0’.”

Upgrade-safe means your customisation survives the update. It does not mean it stays correct.

So a store customised two years ago is running checkout markup written against a two-year-old version of WooCommerce, drifting a little further from core with each release. For a long time nothing happens. Then a release changes how a template passes data, and a field stops appearing, or a discount stops applying, or the checkout breaks in one browser. The cause is two years old and the change that exposed it is from Tuesday.

The notice telling you about it lives in WooCommerce’s System Status screen, which nobody opens unless something is already wrong.

For a maintenance plan the implication is simple and almost never quoted: reviewing outdated template overrides is a scheduled task with a real cost, because each one has to be re-merged against the current core template by somebody who can read both. If you have inherited a store and have no idea what was customised, that review is the first thing worth buying, before any monthly plan starts. It is also the point where the honest answer is sometimes a rebuild rather than continued maintenance.

Difference 4: since March 2025 the checkout page carries a compliance duty

This one is new enough that most maintenance scopes have not caught up, and it did not appear in a single answer we probed.

PCI DSS version 4 introduced two requirements aimed squarely at e-skimming, the practice of injecting a script into a payment page to harvest card details. The PCI Security Standards Council states that “PCI DSS v4.x includes Requirements 6.4.3 and 11.6.1, which aim to reduce the risk during e-commerce transactions.” In the Council’s own description they “focus on ensuring that payment page scripts are properly authorized, checked for integrity, and monitored for tampering, and to prevent unauthorized changes to web pages”.

Two things about them matter for maintenance.

First, the timing. They sat in the standard as best practice from March 2022 and then became mandatory: in the Council’s words, “the future-dated requirements are effective … on the 31st of March 2025”. They are not upcoming. They have been in force for over a year.

Second, the scope. A common assumption is that using a hosted payment provider moves this off your plate. The Council’s guidance describes the requirements as applying to “any entity that processes payment card transactions through e-commerce via embedded iframes or with a web page that can impact security of e-commerce payments”. An embedded iframe from your provider still sits on a page you control, and a script you add to that page can reach around it.

In practical maintenance terms this converts a routine act into a controlled one. Adding a marketing pixel, a chat widget, an A/B testing snippet or a heatmap tool to a checkout page is no longer a five-minute favour. It is a change to the script inventory on a payment page, and somebody has to authorise it, justify it and be able to detect if it changes later. Most agencies we talk to are still doing this on request without a record.

The maintenance-side answer is unglamorous and cheap: keep a written inventory of every script that loads on the checkout page, review it on a schedule, and treat additions as changes rather than requests. Compliance obligations arriving through the back door of a marketing task is a pattern worth recognising, and it is the same shape as the accessibility rules that landed in 2025.

So what should a store plan actually contain

Start from a good general plan. Everything in what a monthly WordPress maintenance plan should include still applies to a store: tested updates, restorable backups, uptime and security monitoring, performance upkeep, a real response time, and a report you can hold the invoice against. That article is the baseline and this is not a replacement for it.

What a store adds on top:

Store-specific task	Why it exists
Staging seeded with production data	An update tested against an empty catalogue has proven nothing
Post-update transaction test, per payment method	The only reliable detector of a silent checkout failure
Cache exclusion audit for cart, checkout and account	The single most commonly reset setting on a store
Template override review against current core	Overrides freeze at the version they were written against
Checkout script inventory, reviewed on a schedule	PCI DSS 6.4.3 and 11.6.1, mandatory since 31 March 2025
Release windows chosen from your own order data	Every store has a quietest hour and most owners never look
Payment, tax and shipping integration checks	Third-party changes arrive on their schedule, not yours
Order and stock integrity spot checks	Data problems compound quietly and are expensive to unwind

Eight items. None are exotic and none appear on a standard WordPress checklist, because on a site without transactions none of them are necessary.

What it costs, and how to read a quote

We publish our thinking on maintenance pricing in the general maintenance article, and the honest position is unchanged: automated-only plans sit at the bottom of the market, standard managed care in the middle, and business-critical and store work at the top or above it.

What is worth adding here is how to read a store quote, since the published ranges are not much help.

Ask which of the eight tasks above are included, and what happens when one of them finds something. That second question is where quotes diverge most. A plan that includes “template review” and then bills every remediation separately is a plan that includes a search, not a fix. Neither is wrong, but you should know which you bought.

Then ask the question that prices the plan properly, which is not what the plan costs but what an outage costs you. Take an ordinary trading day, work out the revenue, and halve it for a failure you catch by lunchtime. For most stores that number is larger than a year of the plan. If it is not, you probably do not need the plan, and we would rather tell you that now.

If you are an agency with one store in a portfolio of brochure sites

This is the situation we get called into most often, so it is worth addressing directly.

You look after a set of client sites on a care plan that works. Then one client opens a shop, or you take on a client who already has one, and it joins the same plan at the same price because it is still WordPress and it is still one site.

Every assumption underneath that plan has just changed. The rollback you rely on now destroys trading data. Your update routine has no transaction test in it. Nobody has looked at the template overrides the previous developer left. And a payment page has walked into your scope carrying a compliance requirement that was not in your service description.

The honest options are to build the store-specific capability, to price the store differently and put a real process behind it, or to place the store with a partner who already runs that process and keep the relationship. GWM is set up for the third: roughly 60% of our work is delivered under other agencies’ brands, and store care is one of the places where specialising in one platform stops being enough, because client portfolios rarely match the agency’s stack. We cover white-label maintenance across systems for exactly this reason.

What we would not advise is the fourth option, which is the common one: leave it on the brochure plan and hope. That works until the weekend it does not, and the client will not remember that the plan was cheap.

When a WooCommerce maintenance plan is the wrong call

A few cases where we would tell you to skip it.

The store is barely a store. A handful of orders a month, a stock theme, no template overrides, one payment method. That is an ordinary WordPress site with a checkout attached, and a general care plan covers it. Revisit when any of those four change.

You are replatforming within months. If the decision to move to a different platform is genuinely made and dated, buy security updates and backups and nothing else. Paying to review template overrides on a store you are retiring is money set on fire. If the decision is not actually made, that is a different problem, and the platform comparison is the place to start.

You are on a fully managed commerce platform already. Some of the eight tasks are handled for you upstream. Check which, in writing, rather than assuming.

The real problem is that the store does not convert. Maintenance keeps a store working. It does not make a working store sell more, and a plan bought to fix a revenue problem will disappoint. That is a build and optimisation question, and it belongs with store development.

Nobody will act on the reports. If updates get deferred for six months because there is never a good moment, the plan is producing paperwork rather than protection. Fix the decision-making first.

Where to go from here

If your store is currently fine and you want it to stay that way, the eight-item table above is a specification you can hand to whoever maintains it now, including us. You do not need to buy anything to use it.

If something is already wrong, if orders have stopped or a checkout is behaving strangely after an update, that is not maintenance work. That is a rescue, and the first hour matters more than anything in this article.

And if you want it handled, we run care plans for stores as well as sites, in Europe and North America, directly or under your agency’s brand. You can see what we have built first.