Six of the fifty had something broken between a visitor and a completed purchase. That is 12%, and because the sample is drawn from portfolio pages, it should be read as a floor rather than an estimate of the wider web. These are the stores agencies chose to show off.
No store is named anywhere in this article, and no test orders were placed. The full method is at the end so you can repeat it.
What We Found
| What was wrong | Stores | Would a visitor notice? |
|---|---|---|
| Storefront offers the product, the catalogue API refuses it | 1 | Only at the point of trying to buy |
| Catalogue API reports £0 and "not purchasable" for every product while the shop displays real prices | 2 | Not on the page — but apps, feeds and block checkout see the broken version |
| Catalogue API returns HTTP 500 | 2 | Not until something that depends on it fails |
| TLS certificate does not match the www hostname | 1 | Yes — a full-page browser security warning |
| Total with at least one defect | 6 of 50 |
Three other stores looked broken and were not: their catalogues are deliberately price-free because they sell by quote, appointment or trade account. Checking that before counting is the difference between a number and a press release — more on it below.
The Three Patterns Worth Understanding
1. The product page says buy. The checkout API says no.
On one store, a product page showed a price of $394, an "In stock" label and a working Add to cart button. The store's own catalogue API reported the same product as is_purchasable: false.
That mismatch matters because modern WooCommerce increasingly runs through that API. The block-based cart and checkout, the mobile apps, the feeds that publish products to shopping surfaces, and the AI shopping agents now doing the browsing all read it. A visitor clicking the button may get an error, or may get nothing at all — and the store's own uptime monitoring will report a perfect month, because every URL involved returns HTTP 200.
This is the single most expensive failure in the study, because it is invisible from the outside and invisible on the page.
2. The catalogue is priced on screen and priceless in the data
Two stores returned every product at zero, flagged not purchasable, while their shop pages displayed real prices — £7.25 here, £779.99 there. Whatever the underlying cause, anything consuming the catalogue programmatically sees a shop with nothing to sell.
A year ago that would have been a minor SEO annoyance. It now decides whether your products appear in shopping feeds and whether an AI agent asked to "find me this part" can see your price at all.
3. A certificate that only covers half your domain
One store's certificate did not match its www hostname. The bare domain loaded fine, which is why nobody had noticed: the site works for anyone who types the domain or follows a link from search. Everyone who reaches www — old bookmarks, printed material, an old link on a supplier's site, a mistyped address — gets a browser interstitial warning them away.
SSL expiry gets monitored because it is easy to monitor. Hostname coverage rarely does.
What We Could Not Check, and Why That Matters Too
We attempted 65 stores and could only complete the check on 50. The other 15 blocked the check itself: firewalls returning 403, robots rules disallowing the endpoint, connection timeouts, and catalogue endpoints returning 404 because they are disabled or the store runs an older WooCommerce.
That is a finding of its own. Roughly a quarter of these stores cannot be checked from outside by anything that identifies itself honestly — which includes most monitoring tools, and increasingly includes the shopping and AI crawlers your store may want to be visible to. If you run a store behind a strict WAF, the question worth asking is not "are we secure" but "do we know what we are refusing".
Two more things we deliberately did not measure: whether checkout actually completes (we do not place test orders on other people's stores), and anything that requires logging in.
How to Check Your Own Store in Five Minutes
- Open your catalogue API at
/wp-json/wc/store/v1/products?per_page=20. Every product you sell should show a non-zero price andis_purchasable: true. If it errors, that is your answer already. - Compare it to a product page. Pick the same product in a private window. Price, stock status and the add-to-cart state should agree with the API.
- Test both hostnames. Load your site with and without
www. Both should be secure, and one should redirect to the other. - Check the cart and checkout pages load as a guest, in a private window, with a product in the cart.
- Do it again after the next plugin update. Every defect in this study is the kind that arrives with a change and stays until someone looks.
Steps 1 to 4 take five minutes once. The reason they are worth automating is step 5: none of these stores broke on the day they launched, and none of them had anyone watching the buying path afterwards.
Method
- Frame: WooCommerce stores named as clients in the published portfolios of WordPress and WooCommerce agencies, where WooCommerce was confirmed independently (catalogue API response, generator tag, or Woo-specific robots rules). Maximum two stores per agency, across the UK, Ireland, US, Canada, the Netherlands, Germany, Austria, Denmark, Sweden and Finland.
- Checks, all public and read-only: the catalogue endpoint
/wp-json/wc/store/v1/products, the storefront shop and product pages, and the TLS handshake. No orders, no form submissions, no logins, a handful of requests per store. - Defect rules: in stock and priced but
is_purchasable: false; all products at zero price while the storefront shows prices; catalogue endpoint returning 5xx; certificate invalid or not matching the hostname; store unreachable. - Gating check, applied before counting anything: stores that hide prices from guests on purpose — trade, wholesale, quote or appointment-based — are reclassified as gated, not broken. Three stores moved out of the defect column this way, after reading their own shop pages.
- Re-verification: every defect was re-checked and confirmed a second time, and each one was cross-checked against the storefront before counting.
- Dates: checks run 18 September 2026.
Limitations, stated plainly. Fifty stores is a small sample and the portfolio frame biases it toward healthy sites. We did not verify that checkout completes, so the true rate of broken buying paths is higher than 12% by an unknown margin. Stores that blocked the check are excluded rather than assumed broken. And a defect found at one moment may have been fixed the next day — that is rather the point.
If One of These Is Yours
If you are an agency and you want to know whether a store of yours was in the sample and what we found on it, ask and we will tell you — privately, with the evidence, whether or not you are a customer.
And if the answer to "who would notice if this broke tomorrow?" is "the client, eventually", that is the gap this study is really about. Journey monitoring runs the buying path on a schedule and names the step that failed, which is how the six defects above would have surfaced within minutes instead of never.