WooCommerce Maintenance: Checkout Tested After Every Update

The update that only fails at checkout

A store gives you one signal that a content site does not: revenue, by the hour. It is the most honest monitoring there is, and almost nobody watches it after an update.

The failures that survive a normal update check are the ones that only appear in a state a crawler never reaches. A gateway extension updates and the redirect back from the payment page loses its parameters, so orders are taken and never marked paid. A shipping plugin changes how it rounds, and a zone that used to qualify for free delivery stops doing so. A tax table is re-imported and one region is charged nothing. Each of these leaves the homepage, the product pages and the category pages entirely intact.

This is why the sign-off here is a purchase rather than a page load. It is also why the window matters as much as the testing: the same fault costs a hundred times more applied at eleven on a Monday than at four on a Sunday. The general form of this discipline is on WordPress updates, and the guide to updating without breaking the site writes the sequence out. On a store, one step is added and it is not optional.

Where a store’s speed actually goes

Store owners are shown a fast homepage and told the site is fast. The homepage is the one page WooCommerce is not responsible for.

Cart, checkout and My Account are excluded from full-page caching because they are different for every visitor – and they should be, since caching them is how one shopper sees another’s basket. That exclusion means those three pages run PHP and hit the database on every single request, and they are the three pages standing between a visitor and a payment.

What slows them is almost always accumulation rather than code. WooCommerce writes a session row per visitor, a transient per shipping calculation and a set of meta rows per order, and on a store that has traded for a few years those tables carry millions of rows that no query was ever indexed for. The checkout that answered in 400ms at launch answers in four seconds at year three, with nothing having changed except volume. Clearing and indexing them is routine work that pays back immediately, and it belongs to the same discipline as Core Web Vitals work even though no front-end change is involved.

Stores are attacked for a different reason

A brochure site is compromised for what it can send – spam, links, redirects. A store is compromised for what passes through it.

Card skimming on WooCommerce is a few lines injected into the checkout template or a hooked function that copies the payment fields before they are submitted. It changes nothing a visitor can see, breaks no functionality, and generates no errors. Sites run this way for months, and the discovery usually arrives from the payment processor rather than from the owner.

The defence is not different in kind from any other WordPress site, only in urgency: file-change monitoring on the checkout path, daily scanning, and updates that do not sit for weeks. What is different is the aftermath. A skimmed store has a disclosure obligation and a card-brand problem alongside the technical one, which is why hardening and daily scanning is bundled here rather than sold separately, and why malware removal on a store starts by establishing when the injection landed rather than by deleting it. The plans that carry this cadence are set out on maintenance plans and pricing, and the whole of it sits inside ongoing WordPress maintenance rather than being a separate product.