Shopify and SKU.md: A Merchant-Owned Knowledge Layer for AI Shopping

A shopper asks whether a wool sweater can be worn every day and washed in a machine. The product page gives the fiber blend. A care page explains hand washing. The support team knows which kinds of wear tend to cause pilling. The brand has an answer, but its knowledge is split across pages and people.

Shopping conversations increasingly move beyond a product name and a few filters. Shoppers ask whether something suits a particular routine, climate, or device. Those questions call for conditions and explanations, not a longer list of promotional claims. Shopify merchants can start by organizing what the brand knows best: why a product was made, how it should be used, and where its limits begin.

Shopify is already building AI shopping channels

Shopify’s Agentic Storefronts bring eligible products into supported AI shopping channels. Availability and features vary by region, store eligibility, and channel. A discovery or purchase experience in one channel should not be assumed to exist in another. The requirements for Shopify Catalog also give merchants a practical reason to keep their core product data accurate and complete.

That native data deserves attention first. A vague title, a missing material, or a specification buried in lifestyle copy makes the product harder to understand everywhere it appears. Improving the product record inside Shopify usually creates more immediate value than opening a separate content project.

Shopify also maintains its own agents.md template. Merchants should retain the platform-managed information by default. SKU.md is a separate, experimental 1.0.0-beta proposal for a catalog entry point and optional source-backed product knowledge. Shopify’s channels, Catalog, and managed agent document do not indicate that Shopify has adopted SKU.md.

Suitability is where the brand can add useful context

A specification answers what a product is. A shopper often needs to know whether it fits a particular use. The percentage of wool in a sweater does not answer a washing question, and “made for everyday wear” does not replace specific care limits. A merchant-owned knowledge document can connect an answer to the public page that supports it.

Good product knowledge also knows when to stop. Care instructions do not support a claim that the sweater suits every sensitive skin type or will never pill. Materials, durability, and compatibility are all areas where dropping a condition can turn a true statement into an unsupported promise.

The product team can own the facts while the content team owns the wording. Both should work from the same public sources. Every fact or suitability statement in an optional product knowledge document needs a Source link. That makes later corrections easier to trace and lets a shopper inspect the basis for an answer.

Public source pages also give support staff, resellers, and content partners a common place to check a detail. Each partner can arrange its own product presentation, then return to the product-specific care instructions when a condition needs confirmation. The brand maintains those instructions and the document links to them. Whether a channel uses that document depends on its own reading mechanisms.

Start with a small catalog, not the whole store

A first trial does not need every SKU. The root catalog described in the current specification can identify the brand, the site, and the relevant catalog with very little content. Add an optional Product knowledge document only after one product has enough reliable public material to support it.

Choose an item that already attracts recurring questions and has a useful product page, care guide, or manual. Work through those questions one by one. If two public pages conflict, ask the product owner to settle the fact and correct the pages before publishing a knowledge document. A file format cannot resolve a disagreement inside the brand.

Stable specifications, intended uses, and documented limits fit this layer. Price, inventory, shipping, tax, and order status change too often and remain the responsibility of Shopify’s live systems. Cart, payment, and checkout should continue through the existing Shopify flow. A static document may explain why a product suits a use, but it should not turn today’s stock level into a lasting availability claim.

This separation gives the pilot a sensible scope. The merchant is testing whether product explanations can be made easier to find and verify. The merchant is not replacing Shopify’s catalog or transaction services.

The publishing route depends on the storefront you already have

Teams already running Hydrogen or another custom storefront can ask the people who control hosting whether the same origin can serve /sku.md. Generate the minimal catalog, identify the route owner, publish it as plain Markdown, and check the public response with the published URL validator. A direct 200 response is the clearest arrangement. The specification also permits a bounded chain of safe redirects, up to three, so a redirect is not automatically a failure.

Merchants using only a Shopify-hosted theme have a different starting point. Improve native product data and public guidance first. There is no reason to migrate a storefront only to publish this file. Shopify’s agents.md.liquid is a platform-defined template, not permission to add any arbitrary root-file template. App Proxy routes are limited to the a, apps, community, or tools prefixes, so they cannot provide the root catalog path.

The Shopify platform guide lays out the publishing choices for a site team. Do not place an unsupported proxy in front of the domain for this experiment. Shopify’s own domain troubleshooting guidance identifies Cloudflare Proxy as unsupported. The right route is the one the current storefront owner can operate safely.

Product knowledge should change when the product changes

After the first item is published, watch how the team handles ordinary corrections. Can an editor find the source? Does a material or care change prompt a review of both the product page and the knowledge document? Can support staff point out a missing condition without creating another disconnected note? Those signals say more about whether the work is sustainable than a count of generated files.

Google’s guidance for AI features in Search states that special AI Markdown files neither help nor hurt Google visibility or rankings. Accessible HTML pages, accurate product content, and normal SEO work still matter. Publishing SKU.md also does not guarantee that any model will read it.

For a different ownership model, compare WooCommerce’s approach to scattered product information and BigCommerce’s multichannel view. If your storefront already has a suitable publishing route, open the Shopify generator and begin with one merchant-owned catalog.