Structured data for AI answers and rich results on Shopify
Eighteen live, Deploi-attributed builds across three Shopify storefronts emit hand-authored JSON-LD entity graphs — Product, Offer, CollectionPage, ItemList, BreadcrumbList, FAQPage, HowTo, VideoObject, BlogPosting — routed by page type in the layout and forked on request.host so two market domains resolve to their own entities. One build goes further and registers agent-callable tools on the page itself.
Definition
Hand-authored JSON-LD entity graphs — Product, Offer, CollectionPage, ItemList, BreadcrumbList, FAQPage, HowTo, VideoObject, BlogPosting — emitted per page type and forked per market so .ca and .com resolve to their own canonical entities. Built deliberately for AI answer surfaces, not just rich snippets, and far beyond what an SEO app emits.
The Evidence
- Evidence strength: 18 live, Deploi-attributed builds
- Storefronts: 3 — LUS Brands, Nudestix, Three Ships
- Distribution: 13 on one storefront, 4 on another, 1 on the third. This is not evenly spread work and we are not going to present it as if it were.
- Attribution: 13 Deploi-authored; 5 are our extensions of vendor sections and are labeled that way on their own pages
- Scale: roughly 15,000 lines of markup and markup-emitting Liquid across the three themes
- Evidence: code read from three live themes. Three of the eighteen also carry a client working-session record; the other fifteen are documented from the code, and no client-side record of the decision survives.
- Confidence: 2 strong, 16 moderate
- Status: Live, verified 2026-09-06
A nineteenth build sits in this lineage and is not counted: an article template that is Dawn's, carrying a tag chip we added to the card. Attribution gates the number, so the number is 18.
How It's Actually Built
Routing from a file that always renders. Structured data has to reach <head>, which in a theme means the layout — and it has to differ per URL, which the layout has no hook for. So one storefront carries a routing table in theme.liquid: paired request.page_type and handle guards rendering a named snippet for nine priority collections and one article. Another puts storewide markup in header.liquid, the only section on every template, mapping template.name to a schema.org type. Both choices are about who can accidentally delete the markup.
Cross-referenced @graph documents, not nested blobs. A collection page emits one document wiring four nodes by @id: a BreadcrumbList, a CollectionPage with editorial name and description, an ItemList with numberOfItems and position-ordered entries, and a FAQPage of buyer-intent questions. Product pages go further: AggregateOffer wrapping per-variant Offer nodes, OfferShippingDetails with DefinedRegion and cutoff time, MerchantReturnPolicy, AggregateRating, and an additionalProperty list carrying merchandising facts schema.org has no field for. Every Brand and publisher anchors to one #organization node at {{ request.origin }}, so the nodes accrue to a single entity instead of scattering.
Forking on the host, not the locale. Where one theme serves two market domains, the only reliable discriminator at render time is request.host. Each snippet holds two mutually exclusive documents, each with its own currency, areaServed, inLanguage and absolute @ids. A host matching neither emits nothing rather than the wrong market's prices.
Where the content already lives in Shopify, the markup is generated from it. An article template loops a custom.faq metafield into FAQPage nodes, so the visible accordion and the structured answer cannot drift. A product-page FAQ section emits Question/acceptedAnswer pairs from the same block loop the vendor markup renders, reading answers through pages[block.settings.raw_content].content — one Shopify page sourcing an answer reused across dozens of product templates.
All of it is assembled with Liquid string output, which is hostile to valid JSON. The mature version normalizes ', ’, " and & before | json, prepends https: to image_url's protocol-relative output, and treats a captured Liquid error string as a failure, swapping in a fallback image rather than serving it.
The Buy-vs-Build Position
Hand-authored and market-forked on the storefront that treats AI answers as a channel; no SEO app emits entity graphs at this level.
The reason is not app quality. The fields that decide an answer — a compliance-reviewed category FAQ, a curated item order that fixes what the collection asserts, a per-market return window — do not exist in the Shopify product object, so nothing reading only the catalog can produce them. The cost of building is a real maintenance burden, described below. Our full reasoning on when that trade is worth taking is in structured data and schema markup: buy or build?.
The Builds
All 18 are listed here. Six of the 18 have published pages and are linked; the other 12 are documented and will follow.
Three Ships — 13 builds
- Market-forked product JSON-LD authored in the product section, with a templated tier for the catalog — High · PDP, PLP · roughly 5,000 lines, reached by 132 product templates. Two tiers in one place: a complete per-market
@graphfor the hero SKUs, branched onrequest.hostso every@idresolves on the hostname that was actually requested, and a Liquid-templated Product and Offer block that follows the rest of the catalog from variants, currency and barcode. - Collection-page JSON-LD entity graph for AI search — High · PLP
- Hand-authored per-collection JSON-LD graphs, split by .ca and .com storefront — Med · PLP
- Hand-authored per-market JSON-LD for the Bundles & Kits collection — Med · PLP. One
@graphper storefront domain — BreadcrumbList, CollectionPage, an ItemList of Product-with-Offer nodes and a six-question FAQPage — each node cross-referenced by@idto the Organization the layout already emits, which is the join that makes two separate documents read as one graph. - Hand-authored JSON-LD for the toners collection, split by storefront domain — Low · PLP
- Per-collection JSON-LD routing plus a site-wide Organization graph — Med · global
- Market-split enriched Product and FAQ JSON-LD for the hero PDP — Med · PDP
- PDP supporting entity graph: breadcrumb, HowTo and VideoObject JSON-LD — Low · PDP
- Product-page FAQ accordion: page-backed answers, mobile 'View More' reveal, auto-emitted FAQPage — Med · PDP, 73 templates. One Liquid expression resolves each answer from a Shopify page or the block's own rich text, and the same expression feeds the rendered accordion and the
FAQPagegraph, so the shopper and the retriever get the same words. - Article structured-data graph: BreadcrumbList, BlogPosting and FAQPage in one document — Med · blog
- Per-market blog structured data for AI and search answers — Med · blog
- Blog article template: BlogPosting schema and freshness signals — Med · blog
- Eight WebMCP tools that make a product page answerable — and buyable — by a browser agent — High · PDP
Nudestix — 4 builds
- Product card with award badges, per-variant content payload and per-card structured data — High · PLP, search, home
- Per-page-type JSON-LD emitted from the header section — Med · global
- Blog article template with share popup, prev/next navigation and BlogPosting markup — Med · blog
- Shop-the-tutorial product card for video pages — Low · landing. A card fork that deliberately drops the structured data, because the product is already marked up on the grid and a second Product node would only compete with the first.
LUS Brands — 1 build
What This Rests On
liquid-schema-settings— 15 builds. The markup is composed server-side in section and layout Liquid, so it is in the initial HTML.shopify-markets— 10 builds. Market context, currency and country code carried into the graph.metafields— 7 builds. FAQ corpora, ratings, review counts and author fields read as data.cart-ajax-api— 3 builds. Including the one write an agent is allowed to perform.theme-blocks— the block loop that emits FAQ markup from what the section already renders.liquid-snippets— one snippet per entity graph, which is how a set this size stays navigable.structured-data— the JSON-LD vocabulary itself.
What Varies by Storefront
The theme base sets the ceiling. Three Ships runs Palo Alto 5.8.0 by Presidio Creative, a paid premium theme that ships no CollectionPage, ItemList or FAQPage of its own — so category pages started from zero and everything on them is additive. The other two storefronts are Dawn-derived, and Dawn already ships product and breadcrumb JSON-LD, which changes the job from authoring to not colliding: the Nudestix header markup explicitly excludes product and article templates so it cannot emit a second Product node beside Dawn's.
Market shape is the second divider. One storefront sells one catalog on two hostnames at two currencies, so every graph is written twice and gated on the host; the other two are single-market and never fork. And the third divider is where the answer copy lives. On the storefront with a metafield-backed FAQ corpus, the markup is generated from the same source the page renders and cannot drift. On the storefront where category answers are compliance-reviewed marketing copy that exists in documents rather than in Shopify fields, the markup is literal — which is the correct call for correctness and the expensive one for maintenance.
Where This Gets Hard
Here is the honest cost — the thing a reader would otherwise find alone.
A large share of this hand-authored markup carries literal values: prices, availability, numberOfItems, priceValidUntil and review counts, written into the snippet rather than read from Liquid at render. That was deliberate: several fields could not be reached at render time, and a currency-correct literal beats a wrong dynamic value. But a literal has no relationship to the catalog. When a product sells out or a price changes, the markup keeps asserting the old value and nothing fails, nothing logs, no test goes red. Structured data that disagrees with the page is a merchant-listing problem, not a cosmetic one, and the failure is silent by construction.
What we would do differently, and now advise: keep literal only what is editorial — curated item order, FAQ answers, category description — and read everything transactional from Liquid, even where that costs expressiveness. Move the editorial half into metaobjects so a merchandiser owns it without touching a theme file. Diff the authored graph against the live catalog on a schedule, so drift is a report rather than a discovery. And prefer the generated pattern wherever the content already exists in Shopify: the metafield-driven article template and the block-driven FAQ section solve this structurally — one source.
We'd also advise against this on a large catalog with no priority list. Per-page hand authoring earns its keep for a dozen pages carrying your commercial argument. It doesn't for a thousand.
Related Capabilities
- Metafield-driven PDP content blocks — where the answer copy lives when it is not hard-coded, and the reason some of this markup cannot drift.
- Variant-aware content and media swapping — per-variant payloads serialized into the DOM, the same instinct applied to the shopper instead of the crawler.
- Fixed bundles and kit merchandising — the collection type whose entity graph gets asked "which bundle is right for me" most often.
Answers to Help You Make Smart Decisions
Do I need a schema app to get structured data on Shopify?
No. Every instance in this corpus is theme code, rendered server-side, so the markup is in the initial HTML with no extra script on the page. An app is the reasonable choice when you want generic Product and Breadcrumb markup across a whole catalog. It is the wrong choice when the fields that matter are editorial and do not exist in the product object.
Will this get my products quoted in AI answers?
We can't promise that, and no one honestly can — the engines decide, and they change. What structured data does is remove ambiguity: it states the price, the market, the return window and the answer to a buyer's question in a form a machine does not have to infer from layout. That is a precondition, not a guarantee.
Can the markup be different on my .ca and .com storefronts?
Yes, and it usually has to be. Where one theme serves two market domains, we branch the whole document on request.host and emit two complete graphs with their own currency, areaServed, inLanguage and absolute @ids. A host matching neither branch emits nothing, so a preview or staging theme never publishes the wrong market's prices.
What is WebMCP, and is it worth doing yet?
It is an emerging browser API that lets a page register callable tools for an AI agent running in the shopper's browser. We have built it once, on one product page, feature-detected so it leaves no trace where the API is absent. It is a bet, not a standard, and we would scope it that way — one surface, read tools plus one tightly bounded write.
Ready to Make Your Storefront Answerable?
If your category and product pages are being summarized by an assistant before a shopper ever sees them, the question is what those pages actually assert — and whether it still matches your catalog. Contact us today to talk through what yours would need to emit.