An agent buying something on a person's behalf arrives at your shop with no account, no session cookie and no intention of running your JavaScript. It has to find a product, read a price it can rely on, put the item in a basket and reach a point where payment can happen. Check C5, commerce actionability, is four one-point signals that correspond to those four steps, and the last two are where a login-gated cart falls down.
C5 is worth 4 of the 25 actionability points, carries a High effort rating, and runs only when the engine has typed a site as e-commerce. For everyone else it is marked not applicable and its points move to C1 to C4. This post covers the four signals as the v1.0.1 engine actually computes them, which is narrower in places than the rubric sentence, and what each one buys an agent trying to complete a purchase.
The four signals
The check works on the crawled pages that returned a 200 with a body. The crawl is the homepage plus up to five more pages chosen from the sitemap and the homepage's links, with product and cart paths ranked ahead of most others; the limits are published at /bot. Every signal below is read from the raw HTML of those pages, before any script runs.
A product page was crawled. The first page whose URL contains /product/, /products/, /shop/, /collections/ or /item/ is taken as the product page. If none of the crawled URLs has one of those segments, the signal is false, whatever your catalogue looks like. The rubric phrases this as "within two clicks of the homepage"; the engine's version is "within the crawl", which in practice means linked from the homepage or listed in the sitemap under a conventional path. The evidence field is productPageFound.
An Offer is present in the schema. The raw HTML of that product page, or of the homepage if no product page was found, is searched for the literal text "@type": "Offer", with any whitespace around the colon. This is a presence test. It does not open the Offer, read the price, or compare it to the price shown on the page. Product and Offer schema that matches the page covers what a correct block looks like, why AggregateOffer on its own does not pass this test, and how to do the value comparison yourself. The evidence field is offerSchema.
A cart or checkout path returned 200. The first crawled page whose URL contains /cart, /checkout or /basket is taken as the cart page, and the signal is true if it returned a 200 with a body. The crawler sends no cookies and holds no session, so this is a 200 to an anonymous request. The evidence field is cartReachable.
An express or guest checkout signal appears. The raw HTML of the cart page, or of the homepage if no cart page was crawled, is searched case-insensitively for shop pay, apple pay, google pay (each with or without the space) or guest checkout. The evidence field is expressCheckout.
Each signal is a point, and the recommendation on the report names the ones that were missed.
What each one means at the point of purchase
Each signal stands in for a step an agent cannot skip.
A product page under a conventional path is the difference between an agent that can navigate a catalogue and one that has to guess. Paths like /products/field-notebook tell a program what kind of page it is about to fetch before it fetches it. A bare slug at the root or an opaque /p/48213 does not, and neither is recognised by this check.
An Offer in the raw HTML is the price stated in a form a machine is designed to read. Without it, the agent has to find the price in prose, which is slower and less certain; with it, the agent has a number, a currency and an availability value it can compare against a budget. The definition of the type is at schema.org/Offer. The check confirms the block exists; keeping it truthful is your job, and the earlier post explains why a wrong price is worse than none.
A cart that returns a page to an anonymous request is the first moment the agent can do something rather than read something. The cart is where the item, the quantity and the running total become state, and an agent that cannot get a cart page cannot get any further.
A wallet or guest option on that cart page is the sign that the purchase can be completed without the agent first inventing an identity. Shop Pay, Apple Pay and Google Pay keep the payment credential with the wallet rather than with your account system; a guest checkout keeps it with the card entry form. Either way there is no password to create and no verification email to wait for.
How a login-gated cart shows up
There are two common ways a shop gates its cart behind an account, and the engine sees them differently.
If the cart path answers an anonymous request with a 401 or 403, or with an error page, it never enters the set of pages the check reads. cartReachable is false, and because the express checkout regex then falls back to the homepage, expressCheckout is usually false as well. That is two of the four points gone for a single design decision.
If the cart path answers with a redirect to a login page, and the login page returns a 200, the picture is different. The crawler follows redirects and records the status of the final response against the URL it asked for, so as of v1.0.1 cartReachable is true. The login page then stands in for the cart page in the express checkout search, and a login form does not usually mention a wallet or a guest option, so that point is normally still lost. The report is honest about what it captured either way: the evidence shows exactly which URL was treated as the cart and what the search found.
Two further ways to lose the cart point have nothing to do with login. If no cart or checkout URL is linked from the homepage or listed in the sitemap, the crawler never chooses it, and the check has nothing to examine. And if your robots.txt disallows the cart path for all user agents, our crawler obeys the rule for its own user agent and does not fetch the page at all. Some platforms ship a default robots.txt that does this. That is a legitimate choice for search crawlers, but it means the signal cannot be earned until the rule is reconsidered.
What to change
Most of this is configuration rather than engineering.
Open the cart to anonymous GET requests and let it render a page with the basket in the HTML. If your platform offers guest checkout as a setting, turn it on; if it offers wallet buttons, enable them and make sure the words appear in the server-rendered HTML of the cart page. The regex runs over the raw document, including inline scripts, so a button drawn by an external script after load is invisible to it, and to any agent doing a plain fetch.
Make sure at least one product page under /products/ or one of the other recognised segments is linked from the homepage, and that the product template emits a Product with a nested Offer server-side. Do not disallow the cart path in robots.txt unless you mean to keep every agent out of it.
Then read the whole checkout as an agent would, one fetch at a time and without a browser. Each step that needs a session, a script or an account is a step where the purchase stalls, and the person who asked for it is told nothing about why. Forms an agent can fill covers the address and card forms that come after the cart, which C1 scores separately.
Check your own site
The free scan tells you whether the engine typed you as a shop and, if it did, which of the four signals it found, with the evidence for each. The e-commerce leaderboard shows how other shops scored on the same check, and the full definition is on the methodology page under actionability.