AIO for Shopify.
Parse it. Act on it.
Whether an AI system can correctly parse and act on the record without guessing. Includes transactability as a named sub-score. An agent that quotes a price, compares variants or starts a checkout needs the record to state those facts once, in a form it does not have to guess at.
- Target
- TGT-04 · AIO · AI optimisation
- Checks
- 10 in pillar layer v1.0
- Weight sum
- 108 — relative within this pillar; not rescaled to 100
- Heaviest
- Structured attributes (16)
- Fix classes
- 4 automatic · 5 assisted · 1 guided — the design
- Crawler rule
- No crawler penalty applies to this pillar.
- Transactability
- 5 checks · weight sum 60
- Composite
- A separate layer (rubric v1.0). Pillars do not sum to it.
- Fixes
- Planned automatic · Planned assisted
- Verify · rollback
- Planned · Planned
Described, not bought.
Contradictory markup is worse than absent markup: a parser that finds two prices on one page cannot pick one, and an agent that cannot resolve price or availability cannot transact at all. Without a SKU there is no stable way to refer to what is being bought, so the record can be described but not acted on.
A record,
not a page.
What an acting system reads on a Shopify storefront, and why two sources of markup are one too many.
An agent that compares two throws, quotes a delivery estimate or starts a checkout is not reading a page for meaning. It is reading a record for facts — price, currency, availability, which variant, which identifier — and each has to be stated once, in a form that parses, and agree with itself.
On Shopify that record is the product and its variants. A product can have up to three options and, since October 2025, up to 2,048 variants; each variant carries its own price, SKU, barcode and weight. The storefront publishes a slice of it as JSON-LD — from the theme, and apps can add their own — and that published slice is what a parser sees. When the theme and an app both publish a Product node, the parser sees two records for one product.
That is why AIO comes last and sits closest to money. The first three pillars decide whether a store is found, quoted and cited. This one decides whether what was found can be acted on without guessing.
What AIO means
here.
The acronym is used three ways in the industry. Rank Sniper uses one.
Parse and act.
AIO here means machine readability — whether the record parses and can be acted on. It is not the umbrella definition that treats AIO as all four disciplines at once, and it is not the off-site trust definition.
The pillar is scored from 10 checks; 5 of them also form a named transactability sub-score.
10 checks.
The most of any pillar.
The AIO pillar as the scorer runs it today, read from the live derivation.
| Weight | Shareif all scored | Fix classdesign | What the scan reads | |
|---|---|---|---|---|
| Structured attributes | 16 | 15% | Automatic | Units, list markup, or material, dimension or composition words in the description |
| SKU coverage | 14 | 13% | Assisted | A non-empty SKU on every variant |
| Variant-level offers | 12 | 11% | Automatic | An offers node in the Product JSON-LD |
| Price with priceCurrency | 12 | 11% | Automatic | price and priceCurrency together in JSON-LD |
| Availability in schema | 12 | 11% | Automatic | availability in the Product JSON-LD |
| Shipping weight | 10 | 9% | Assisted | A weight above zero on at least one variant |
| Imagery present | 8 | 7% | Assisted | At least one image per product |
| Real variant options | 8 | 7% | Assisted | A real option name, or a single variant |
| Schema conflict detection | 8 | 7% | Guided | More than one price or availability value on one page |
| Entity consistency | 8 | 7% | Assisted | Vendor agreement with the catalogue’s dominant vendors |
| Sum of weights | 108 | — | — | Relative within this pillar; not rescaled to 100. |
Offers and availability are read from the Product JSON-LD the scan finds; price with currency and the conflict test from every JSON-LD block on the sampled pages. The rest are catalogue checks over the public product listing.
Share assumes every check was scored. A check whose input could not be read is unscored and leaves the denominator instead of counting against the store. The same rows, and how the pillar layer sits beside the composite, are on the rubric. The fix class column is the design — who will have to act — not a shipped fix.
Could an agent
complete the purchase?
A named sub-score: the 5 AIO checks that decide whether an agent can quote, identify and ship what it is buying — scored on their own.
| Weight | Shareif all scored | What the scan reads | Why an agent needs it | |
|---|---|---|---|---|
| SKU coverage | 14 | 23% | A non-empty SKU on every variant | A stable identifier is how an order refers to the exact variant. |
| Variant-level offers | 12 | 20% | An offers node in the Product JSON-LD | Without an offer there is nothing to quote — the product can be described, not priced. |
| Price with priceCurrency | 12 | 20% | price and priceCurrency together in JSON-LD | A price with no currency is ambiguous across markets. |
| Availability in schema | 12 | 20% | availability in the Product JSON-LD | Whether it is in stock decides whether a recommendation is honest. |
| Shipping weight | 10 | 17% | A weight above zero on at least one variant | Weight is what turns a listing into a delivery estimate. |
| Sum of weights | 60 | — | Relative within the sub-score; not rescaled to 100. |
The sub-score uses the same check objects as the pillar, so a value can never disagree between them. It asks the question a buying agent asks first: is there an offer, at a price in a currency, in stock, for an identifiable variant that can be shipped?
Two prices,
one page.
Why contradictory markup is worse than absent markup, and exactly what the conflict check flags.
<!-- from the theme -->
<script type="application/ld+json">
{ "@type": "Product", "name": "Linen Throw",
"offers": { "@type": "Offer", "price": "48.00", "priceCurrency": "EUR",
"availability": "https://schema.org/InStock" } }
</script>
<!-- from an app -->
<script type="application/ld+json">
{ "@type": "Product", "name": "Linen Throw",
"offers": { "@type": "Offer", "price": "52.00", "priceCurrency": "EUR",
"availability": "https://schema.org/OutOfStock" } }
</script>An absent price leaves a parser with a gap it can report. Two prices leave it with a choice it has no basis for, and an agent that cannot resolve price or availability does not act on the listing. That is why resolving a conflict matters more than filling a blank field.
Schema conflict detection (weight 8) reads every JSON-LD block on each sampled product page and fails the page if, across them, it finds more than one distinct price or availability value. The test is deliberately blunt. It catches the theme-plus-app duplicate above; it also fires on a product whose variants are legitimately priced differently or partly out of stock, because those values sit on one page too. Read a failure as “inspect the markup”, not as proof of a duplicate.
The fix class is guided: the conflicting node usually belongs to the theme or another app, which the Shopify app cannot remove. The durable fix is one source of Product markup per page.
SKU, GTIN
and the variant behind the offer.
How a record says exactly what is being bought — what Shopify stores, what Rank Sniper checks, and what it does not check yet.
Shopify defines a SKU as a case-sensitive identifier for a product variant in the shop. It is optional, which is exactly why catalogues lack it. SKU coverage (weight 14) passes a product only when every variant has a non-empty SKU.
The barcode is the other identifier; Shopify’s barcode field accepts several types, GTIN among them. Neither score layer checks GTIN today: the composite reads it without scoring it, and the pillar layer has no GTIN check. It matters downstream — Google Merchant Center lists GTIN as strongly recommended rather than required, and OpenAI’s product feed specification requires a GTIN or an MPN — which is why it belongs to the connected scan, designed to read per-variant identifiers through the Admin API. Planned
Variants and options
Google’s product-variant structured data groups variants under a ProductGroup with hasVariant, variesBy and a productGroupID, and its merchant-listing documentation requires each Offer to carry price and priceCurrency. Variant-level offers (weight 12) passes when the Product JSON-LD carries an offers node — it does not yet test for one offer per variant. Price with priceCurrency (weight 12) passes when price and priceCurrency appear together.
Real variant options (weight 8) reads option names. A single-variant product passes; a product with several variants fails if none of its options has a real name — Shopify’s placeholder option “Title” (value “Default Title”) says nothing about what separates one variant from the next. Shipping weight (weight 10) passes when at least one variant has a weight above zero.
What a parser
receives.
The served JSON-LD and the public product listing — the storefront’s published slice of the record.
- Served JSON-LD
- Every application/ld+json block on up to three product pages, parsed as JSON — @graph wrappers included — with no JavaScript run.
- Offer fields
- offers, price, priceCurrency and availability in the Product markup.
- Contradictions
- More than one distinct price or availability value across a page’s blocks.
- Variant fields
- sku and weight on every variant, and option names, from the public product listing.
- Imagery
- Whether each product has at least one image.
- Attributes
- Material, dimensions or composition in the description: units, list markup or the attribute words themselves.
- Vendor consistency
- Whether each product’s vendor matches the catalogue’s dominant vendors.
Who acts
on the record.
Structured-data parsers
Read Product, Offer and ProductGroup markup. Google documents which properties its merchant listings require.
Product feeds
Google Merchant Center and OpenAI’s product feed each specify required fields — id, title, price and availability among them.
Agents and agentic checkout
Assistants that act for a shopper, and the protocols — UCP, ACP — that define how they transact. See agentic commerce.
The Shopify storefront
Theme and app markup built from product and variant fields — the published slice of the record anything above can read.
Where the record
gets acted on.
What the platforms say about AI agents buying from Shopify stores — dated, sourced, and kept apart from what Rank Sniper does.
Shopify describes Agentic Storefronts as a sales channel in the Shopify admin that connects a merchant’s products to AI shopping platforms. In a post dated 18 June 2026 it lists ChatGPT as live for Shopify merchants selling to US buyers, Microsoft Copilot as live for Catalog merchants selling to US buyers, and AI Mode in Google Search and the Gemini app as available to select brands, with broader rollout underway. In December 2025 Shopify described its Catalog as inferring categories, extracting attributes and consolidating variants.
Shopify calls the Universal Commerce Protocol, which it co-developed with Google, an open standard for how AI agents transact with merchants — cart, checkout, payment and post-purchase. The Agentic Commerce Protocol, developed by Stripe and OpenAI, describes itself as an open standard for programmatic commerce between buyers, AI agents and businesses.
Rank Sniper connects to none of these. It does not read Shopify Catalog, submit a feed or test a checkout. The overlap is the record they all start from: price, currency, availability, identifiers and variants stated once and in agreement. That is the part a storefront scan can observe. The agentic commerce guide goes further.
Four records
an agent would stall on.
Illustrative cases, not customers — including one where the check itself is the limit.
Theme markup plus app markup
The theme and a reviews app each publish a Product node; one carries last season’s price. Schema conflict detection fails. The conflicting node belongs to the theme or the app, so the fix class is guided.
Sizes added later, SKUs never
The original variant has a SKU; the sizes added since do not. SKU coverage fails for the product — every variant has to carry one.
Markup injected by script
An app writes its JSON-LD with JavaScript after load. The served HTML has none, so offers, price with currency and availability all fail: the scan, like any parser that does not run scripts, never sees it.
A digital catalogue
Downloads have no shipping weight, so Shipping weight fails by construction — the check cannot know a product ships nothing. Read it there as not applicable; the score does not.
How AIO fails
at the point of action.
Contradictory
Two prices or two availabilities on one page. Worse than none.
Unpriceable
No offers node, or a price with no currency.
Unidentifiable
Variants without a SKU: no stable way to say what is being bought.
Unknown stock
No availability value in the markup.
Undistinguished variants
Several variants, none of the options with a real name.
Invisible
Markup that exists only after JavaScript runs.
What happens today.
What is still planned.
Rank Sniper finds and scores. Today the merchant corrects the record or the markup and re-runs the scan.
- NOW-01Available
The scan reads and scores
Reads the public product listing and up to three product pages as raw HTML, and scores the 10 AIO checks and the 5-check transactability sub-score.
- NOW-02Beta
The full report lists what fails
Every failing AIO check, heaviest-weighted first, in the full report sent by emailed sign-in link.
- NOW-03
You make the change, then re-scan
A SKU on every variant, offers carrying both price and priceCurrency, and an explicit availability value are what let an agent quote and transact rather than merely describe. Shipping weight is what turns a listing into a delivery estimate. Resolving a schema conflict matters more than filling a blank field: contradictory markup is worse for a parser than absent markup.
- FIX-APlanned
Automatic · 4 of 10 checks
Published through Rank Sniper’s own metafield namespace, structured data or feed. Designed to need no approval, because it never touches a field you wrote.
- FIX-BPlanned
Assisted · 5 of 10 checks
Changes a native Shopify field — a title, description, tag, image or variant field. Drafted and staged; written only when you approve and apply it.
- FIX-C
Guided · 1 of 10 checks
Outside the app’s write scope — a theme template, a file at your domain root. You make the change from exact instructions; the next scan checks it. Until the app ships, the failing check and its fix class say where the change lives.
- VER-01Planned
Verification after a fix
Designed to re-fetch what agents actually receive once a change ships, and confirm it landed.
- VER-02Planned
Rollback
Designed to store the prior value of every write, with per-product restore.
AIO in
five lines.
What it is
AIO here means machine readability — whether the record parses and can be acted on. It is not the umbrella definition that treats AIO as all four disciplines at once, and it is not the off-site trust definition.
Why it matters
An agent that cannot resolve price, currency, availability or identity does not transact — and contradictory markup is worse than none.
What Rank Sniper observes
10 checks over the served JSON-LD and the public product listing, 5 of them forming the transactability sub-score.
What Rank Sniper does today
Available Scores the pillar and its sub-score on every public scan. It does not write markup, read GTINs or test a checkout.
What remains planned
Planned Structured data published from Rank Sniper’s own layer. Planned Per-variant identifiers read through the Admin API.
The last pillar.
It inherits the first three.
SEO
Same product pages, different layer: SEO reads the head, AIO the structured data. A page can have a perfect title element and two contradicting prices.
Engage →AEO
AEO serves reading, AIO acting — and they share a test: Structured attributes here (weight 16) and List and table density there (weight 16) are scored from the same catalogue check.
Engage →GEO
GEO uses the vendor field to ask whether a claim has a source; AIO uses it to ask whether that source is one entity or several spellings of one.
Engage →Scan a store.
See if an agent could buy.
The public scan scores all four pillars and the transactability sub-score from what the storefront serves.
- OfficialProductVariant object (Admin GraphQL API)Shopify
- OfficialAdding variantsShopify Help Center
- OfficialThe product variant limit is now 2,048 for all merchantsShopify changelog
- OfficialMerchant listing (Product, Offer) structured dataGoogle Search Central
- OfficialProduct variant (ProductGroup) structured dataGoogle Search Central
- OfficialProduct data specificationGoogle Merchant Center
- OfficialProduct feed specificationOpenAI
- OfficialHow agentic commerce works (18 June 2026)Shopify
- OfficialWinter ’26 Edition: Agentic Storefronts (10 December 2025)Shopify
- OfficialUniversal Commerce ProtocolUCP
- OfficialAgentic Commerce ProtocolAgentic Commerce Protocol
