Storefront quality has always been judged by human standards: how it looks, how fast it feels, how few steps stand between wanting something and owning it. Those standards are not going away. But a second reader has appeared, and it judges by a different rubric — and increasingly, it is the one summarizing your store to a shopper who never visits it.
A companion piece looks at whether an agent can see your storefront at all. This one starts after that: assuming the pages are fetchable, what makes them actually usable to a machine?
Machine readability is an experience layer, not a technical detail
When a person lands on a PDP, they resolve ambiguity effortlessly. They know the crossed-out number is the old price. They understand that “2-3 days” next to a lorry icon is delivery. They read “Only 2 left” as urgency, not as inventory truth. They open the sizing tab because they know sizing lives behind tabs.
A machine does none of that. It reads what is stated, in a form it can parse, or it does not know it. Which means a whole set of design decisions that are invisible as design decisions — where a fact lives, whether it is text or an image, whether it renders before or after interaction — become the difference between being represented accurately and being represented vaguely.
The facts that matter most, in rough order:
Price, and which price. Current price, original price, currency, and whether tax is included. A single ambiguous price is how a store ends up quoted at the wrong number in an answer it never sees.
Availability. Real availability, per variant, updated as often as the storefront updates it. Structured data that says InStock on the master while the size the shopper asked for is gone is worse than silence.
Variants as distinct things. Size, colour and fit are not decoration; they are the product. If variants are only expressed through client-side state, an agent sees one vague product where there are forty concrete ones.
Shipping and returns policy. These decide purchases and they are usually the least structured content on the site — a content asset full of prose, sometimes an image, occasionally a PDF.
Product specifics. Materials, dimensions, compatibility, care. The attributes that answer “will this work for me”, which is the question an assistant is usually being asked.
The SFCC angles
Content assets and slots carry the substance. In most implementations the shipping table, the sizing guidance and the returns policy live in content assets, edited by merchandisers, rendered inside tabs or accordions. If that content only enters the DOM on click, it is not part of what a machine reads. Knowing which blocks on a page come from assets or slots and which come from the template is the first step to knowing what is actually in the served HTML.
Caching versus truth. Aggressive page caching is correct for performance and dangerous for facts. Availability and price rendered inside a long-cached fragment will be confidently wrong to a parser that has no way to know it is reading a stale page.
Bot management. Rate limiting and bot rules exist for good reasons — scraping, credential stuffing, competitive price harvesting. Those same rules decide whether an AI assistant can read your catalog. There is a real commercial decision here, and it deserves to be made explicitly, per user agent, by someone who understands both sides. What you should not have is an accidental answer inherited from a WAF rule set.
Multi-locale consistency. Structured data and policy content are frequently complete in the primary locale and thin everywhere else. Agent answers about your other markets will be correspondingly thin.
Headless front ends. If the storefront is a JavaScript app over OCAPI or SCAPI, everything above depends on server-side rendering or prerendering. Otherwise the served document is a shell and every fact in this article is missing.
The direction this is heading
Reading is the current state. The next step, already visible in early forms, is agents that do things: compare across stores, check availability against a specific requirement, hold an item, complete a purchase under a shopper’s instructions. That raises questions most commerce teams have not had to answer yet — how an agent authenticates, what it is allowed to do on someone’s behalf, how you distinguish a legitimate delegated purchase from abuse, and whether agent traffic gets its own rules.
Nobody has finished settling those questions, and building for a protocol that has not stabilized is premature. What is not premature is the foundation, because it is the same foundation either way: facts stated in the page, structured data that is accurate and current, policy content that is readable without interaction, and deliberate rules about who may fetch what.
That work has an immediate payoff regardless of how agentic commerce develops. It is the same work that improves accessibility, SEO and the honesty of your own PDP. The only thing the agent audience adds is a deadline you cannot see, because when a machine cannot read your store, it does not report an error — it just answers with somebody else’s products.
