We Checked 100 Agency-Built WooCommerce Stores. 5 Had a Public Defect, 15 Had a Problem a Homepage Check Would Miss

Five of the 100 had a defect I could reproduce from the outside: three stores whose product API crashes with a WordPress critical error, one whose product data contradicts its own product page, and one whose certificate does not cover the www address. That is 5% of this sample.

Then I went back over the same 100 stores and clicked where a shopper would click: the menu and footer links, the cart, and the product pages the catalogue points to. Ten more stores had at least one of those leading to a "page not found". None of the ten is among the five above, so 15 of the 100 had something wrong that I could show you.

Every one of those 15 homepages loaded normally. A check that only asks "is the homepage up?" would have passed all of them. (The certificate problem is only on the www address; the main address works.)

Two things up front. I did not place any orders, so this is not "five checkouts were broken". And I am not naming any of the stores. The aggregate data and the full method are below, so you can check my reasoning or run the same checks yourself.

The numbers

15 + 76 + 9 = 100. The other two of the 11 "by design" stores had a dead link, so they are counted among the ten: being deliberately offline for sales doesn't make a broken cart icon or menu link intentional.

Download the aggregate data (CSV).

The three kinds of defect

The product API crashes

Three stores, one in Austria and two in the UK, return WordPress's "There has been a critical error on this website" page when you ask for their product list at /wp-json/wc/store/v1/products. Two of them did it on 18 September and still did on 29 September. The third turned up in the second round: its product and cart endpoints both crashed, twice, ten minutes apart, and again when I re-checked that evening.

One wrinkle on that last one: it isn't constant. During my link check that afternoon, one request to the same endpoint got a normal answer. Every other attempt I made that day crashed, with or without the site's cookies. An error that comes and goes is harder for the store's own team to spot, not easier.

All three homepages loaded normally. A homepage-only uptime check would have passed them. But WooCommerce's Store API is what the newer product blocks and block-based Cart and Checkout read from, and extensions or headless frontends can use it too. A fatal error in that code path can sit unnoticed until a store change puts it in front of shoppers.

The product page and the API disagree

An Australian store shows a product at A$394, "In stock", with an Add to cart button. Its own public product data, for the same item, says is_purchasable: false. When I re-checked, two more products on the same store were doing the same thing, and all three still were on 1 October.

All three are bundle products ("type": "bundle"), so my best guess is that the bundle setup reports itself differently to the API than to the page. That makes it a less dramatic finding than it sounds: a shopper on the classic product page may never notice. But it meets the rule I wrote down before I started, so it counts. And anything that builds a cart from the API, or a shopping feed that trusts it, sees a product that cannot be bought. A check that only asks "does the product URL return 200?" will pass this store every time.

The certificate only covers half the domain

One UK store works fine at the bare domain, but Chrome shows "Your connection is not private" (NET::ERR_CERT_COMMON_NAME_INVALID) on the www version. Still true on 29 September. People reach www more often than you would think: old bookmarks, printed flyers, supplier links, someone typing it out of habit. Expiry monitoring on the main hostname will never catch this; you have to test both.

The second check: links that go nowhere

The API and certificate checks find the sort of thing only a developer would notice. So I wrote down a second set of rules before running them (which links, what counts, what doesn't) and went through all 100 stores again from their homepages in an ordinary browser:

1. every link to the same site in the header, menu and footer (up to 60 per store);
2. the store's own cart page;
3. the pages of the first five products in its catalogue;
4. insecure http:// scripts or stylesheets that a browser would block.

A link counted only if it returned "not found" (404 or 410) or a server error, and only if it still did when I went back to it later. Firewalls, rate limits and logins didn't count.

(Every one of the ten had a dead menu or footer link. Two also had one of the other problems.)

Some of these are small: a privacy policy link in a massage clinic's navigation, "Careers" and "Customer service" pages on a packaging supplier's site, a "Pick & Mix" link in a chocolate maker's footer. Some are not. An office-chair maker's menu lists nine of its chairs, and every one of them opens a 404. A sauna retailer links three sauna models straight from its menu to pages that are gone. A garden centre's menu sends you to "Pets", "Timber" and "Home" categories that don't exist. A snooker shop links a product from its menu and its homepage, and that product page no longer exists. And on one store the phone number in the header is written as a web link rather than a phone link, so tapping it on a phone opens an error page instead of dialling.

The cart one is the one I would fix first. The store is working by appointment only at the moment, but the basket icon is still in the header, and clicking it gives you "ERROR 404, Sorry, this page does not exist!"

None of this would show up on an uptime monitor either. Every one of those homepages loads normally and returns a 200.

What surprised me

Mostly how healthy these stores were. 76 of the 100 had no problem I could count, and nine more don't sell online by design and had nothing broken either. That is genuinely good news for the agencies that built them. And most of the dead links look like pages or products that were removed or renamed while a menu kept pointing at them, not signs of a badly built site. The five with API or certificate problems were not sloppy one-page shops either; they are established businesses with real customers. And the fastest way to be wrong in a study like this turned out to be mistaking a deliberate setup for a bug. Eleven stores would have looked broken to an automated check and were not: a quote-only shop, an appointment-only shop, catalogues that sell through resellers or in the shop, a made-to-measure configurator, a shop that links out to Amazon, an antiques dealer that sells by enquiry, and one that has closed its checkout until December because it sold out its pre-order capacity.

The other surprise was how often the portfolio itself had moved on. Seven "client stores" were not stores any more, or never were, and one agency's portfolio still links to a shop whose domain now shows an online casino page. None of that is counted here, but if you run an agency, your portfolio page deserves a check too.

What I could not check

Eighteen stores could not be assessed at all. Some block the public Store API with a security plugin or firewall (one politely: "Pricing data is locked"), on some it isn't available at all, a few have a robots.txt that asks crawlers to stay away from it (I respected that), and one store has closed behind a "coming soon" page. None of those count as defects. I report them because quietly dropping them would make the sample look more complete than it was.

The second check had its own gaps. On three stores I couldn't test the menu links at all (two build their menus in a way my check couldn't read, and one firewall blocked me), and on two more most requests timed out. I couldn't find or test the cart on 15 stores, or the product pages on 6. Those stores count as "nothing found", not as clean, so if anything the 10 is an undercount.

How to read the numbers

It is what I saw in this sample, nothing more. These stores came from agency portfolios, not from a random list of WooCommerce sites, so I would not stretch the number to "5% of WooCommerce stores". My guess is that portfolio stores skew healthier than average, because agencies pick the work they are proud of, but I cannot prove that.

The dead-link result is more concrete: click the wrong menu item and the shopper reaches a dead end. It is also the smaller kind of problem, and some of those links may see very little traffic.

Only one of the five API and certificate problems (the certificate) is something every visitor on that address would hit. The other four are API problems whose real impact depends on how that particular store builds its cart and checkout.

Check your own store in ten minutes

1. Open the product endpoint: /wp-json/wc/store/v1/products?per_page=20. It should load (not a critical-error page), and the prices and is_purchasable values should match what a guest should see.
2. Compare one product with its page in a private window: same price, same stock, same buy button.
3. Load the site with and without www. Both should have a valid certificate, and one should redirect to the other.
4. Click every item in your menu and footer, including the cart icon, and tap the phone number on a phone. Removing a product or page doesn't remove the menu link to it.
5. Buy something on a store you control, using test payments or a staging copy. This is the step my study could not do.
6. Do it again after updates. Plugin, theme, WooCommerce and hosting changes all move these results.

If you run a trade, wholesale, quote-only or catalogue-only store, "not purchasable" in step 1 may be exactly what you intended. Check the product type field: external products are never purchasable on the site itself, and bundle products may report differently to the API than to the page.

Method

Sample. Live WooCommerce stores named in the published portfolios of WordPress and WooCommerce agencies, taken from the same list of agencies in a fixed order, at most two stores per agency. (One agency ended up with three in the first pass; I have left it in and am telling you rather than quietly dropping a store after seeing its result.) A store was eligible only if WooCommerce was confirmed through a Store API response, a WooCommerce generator tag, WooCommerce markup or WooCommerce-specific robots.txt rules. The 100 assessed stores were in the UK, Ireland, the United States, Canada, Australia, the Netherlands, Germany, Austria, Denmark, Sweden and Finland. It is a purposive sample, so I report no confidence interval.

Checks. For each store: the public endpoint /wp-json/wc/store/v1/products, the shop and product pages needed to interpret it, and the TLS certificate on both the bare and www hostnames. A handful of requests per store, no logins, no form submissions, no orders.

What counted as a defect (rules written before checking):

• a product offered on the storefront, in stock and priced, that the Store API marked is_purchasable: false;
• every sampled product at zero price and not purchasable in the API while the public shop showed prices, unless the products were external listings or otherwise deliberately gated;
• a 5xx error from the product endpoint (a firewall "access blocked" page does not count);
• an invalid or mismatched TLS certificate on the bare or www hostname;
• a storefront that could not be reached.

Second check (links, cart and product pages). Written down before running, on 29 September 2026, for the same 100 stores with nothing added or removed. From each store's homepage in a logged-out browser: every same-site link in the header, navigation and footer (deduplicated, at most 60, skipping admin, login, add-to-cart, feed, email and phone links); the cart page (WooCommerce's own cart URL, or the header cart link); the permalinks of the first five products in the public Store API; and blocked http:// scripts, stylesheets and iframes on the homepage. Counted: 404, 410 or 5xx, or any blocked mixed content. Not counted: 401, 403, 429, timeouts and network errors. One change after starting, before any result depended on it: on sites whose menus aren't marked up as header, nav or footer, I used all same-site links on the homepage instead. Every flagged link was fetched again later on its own and counted only if it still failed. Three first-pass hits were dropped that way: a server error on one store's shop page that had gone away, a cart error I had most likely caused myself by sending requests too quickly, and a "broken link" that turned out to be hidden placeholder text from a cookie plugin that no shopper could see or click.

Verification. Every finding was reproduced in an ordinary browser on 29 September 2026, with dated screenshots kept, and all of them were checked once more that evening before publishing. Anything I could not reproduce was removed. All five API and certificate defects were still present when I checked again on 1 October 2026.

Sample revision. An earlier 50-store analysis included one intentional external-selling setup as a defect and one finding that could not be reproduced. It also contained seven ineligible non-WooCommerce sites and omitted three deliberately gated stores from the accounting. I corrected those errors before expanding the assessed sample to 100 using the same eligibility rules and stopping points written down before checking the new results. The earlier six-of-50 figure should not be cited.

Exclusions. Blocks, a disabled Store API, robots.txt restrictions and closed stores were treated as "could not assess", never as broken.

Limits. 100 stores is still small, and not random. The link check covers the homepage's menus and footer only, not every page on each site. API findings do not prove a shopper failed to check out. These are observations from 18 and 29 September 2026, and some of these stores may be fixed by the time you read this, which I would be glad to hear.

Disclosure. I run NorthDuty, which sells website and user-journey monitoring, so I have an obvious interest in stores discovering they have problems. That is the reason the rules, exclusions, correction and limits are all written out above.

Using this data

• Data: aggregate CSV
• Chart: results chart (PNG, 1600 × 900)
• Licence: CC BY 4.0. Reuse it freely with credit to NorthDuty.
• Citation: NorthDuty, "We Checked 100 Agency-Built WooCommerce Stores. 5 Had a Public Defect, 15 Had a Problem a Homepage Check Would Miss," observed 18 and 29 September 2026.
• One-line summary: "In a September 2026 sample of 100 agency-portfolio WooCommerce stores, NorthDuty found five with a reproducible public Store API or TLS defect and ten more whose menu, footer, cart or product links led to a missing page. All 15 homepages loaded normally. Checkout completion was not tested."

Journalists and editors: I have dated screenshots for each of the fifteen findings and can walk you through them privately. Agencies: if you want to know whether one of your client stores was in the sample and what I saw, get in touch and I will send it over, no pitch attached.

If one of these is yours

Fix the error, then put a real purchase through on a store you control. A public API response can show you that something is wrong; only a test order shows you whether a customer can actually pay.

That gap is what I built NorthDuty for. Journey monitoring runs a buying path on a schedule and tells you which step failed, instead of taking an HTTP 200 as proof that the shop still works.