Start with one product: a SKU.md guide for Shopify, SHOPLINE, WooCommerce, and BigCommerce merchants

Preparing product knowledge for shopping agents does not require rebuilding a store. Shopify, SHOPLINE, WooCommerce, and BigCommerce merchants can start with one product: gather accurate information, establish how their storefront can serve a file, and then decide whether to expand.

SKU.md v1.0.0 offers an open, checkable representation that complements product pages, structured data, and channel feeds. Existing inventory, payment, and order systems continue to handle live commerce. These are integration paths to assess, not claims that the four platforms natively support SKU.md.

Establish what your storefront can serve

Content accuracy and online delivery are separate jobs. Merchandising teams can prepare specifications, variants, limitations, and sources. A developer or service provider must verify the actual response on the store’s domain.

The following assessment draws on official platform documentation. Hosting, permissions, and response testing determine what works for a particular store. Being able to upload a file is not sufficient evidence.

Platform	Merchant-controlled surface	Prerequisite to confirm	Verify
Shopify	Theme content; routing on a merchant-managed storefront depends on architecture	App Proxy uses restricted prefixes, not arbitrary root control	The actual URL serves Markdown rather than theme HTML
SHOPLINE	Product content and permitted redirects	Redirect support does not establish a compliant file; confirm same-origin delivery	Destination, response body, and redirect chain
WooCommerce	WordPress routes or static files, subject to hosting permissions	A developer must produce the correct response; a rewrite alone is insufficient	Status, content type, caching, and bytes
BigCommerce	Stencil templates or merchant-managed storefront routing	Custom page templates do not establish a root Markdown endpoint	Distinguish an HTML page from a file response

These are implementation inferences from platform capabilities, not compatibility certifications. If there is no suitable delivery path, improve the source product information and ask your provider to assess the options. Do not replatform solely for one file.

How current discovery works

Prefer the exact same-site /sku.md root. Only after it returns an exact HTTP 404 may a consumer inspect one unambiguous declaration on the same-origin homepage, such as:

<link rel="alternate" type="text/markdown" title="SKU.md" href="/catalog.md">

The declared resource must also conform: same-origin HTTPS, with no query or fragment in its address. A timeout, server error, or invalid document is not absence and must not be hidden behind a fallback.

This is a conditional specification path, not a trick that every theme supports. You must control and verify both the declaration and the actual file. A CDN download, an HTML introduction page, or a cross-origin redirect is not automatically compliant.

Begin with a minimal catalog

This fictional store illustrates a minimal root file. Replace its name, summary, domain, and catalog address with your store’s real values before generating and checking it. The root alone does not claim to describe every product attribute.

# Example Outdoor Gear
> Lightweight outdoor equipment for hikers.

SKU.md: [1.0.0](https://sku.md/spec/1.0.0/)
Website: [example-outdoor.com](https://www.example-outdoor.com/)

## Catalog
- [All products](https://www.example-outdoor.com/collections/all)

Product knowledge documents are optional. Link the first one explicitly from the root and include its catalog backlink, product page, and sources for individual facts. Identify whether each fact applies to the whole product or a particular variant.

Run a five-step pilot

1. Choose a product. Prefer complete public documentation and frequently asked specification questions. A whole-store crawl is unnecessary.
2. Review the facts. Check identity, specifications, limitations, and evidence against real pages. Leave unknowns unknown.
3. Generate and check. Prepare the root with the generator; use the optimizer for detailed attribute review.
4. Publish and verify. Have the store’s responsible operator serve the file, then check the real URL with the published URL checker. Also validate catalog relationships for product documents.
5. Assign maintenance. Name an owner, retain review evidence, and recheck when specifications, variants, or sources change.

Acceptance includes public HTTPS, HTTP 200, UTF-8 Markdown, and a permitted content type (text/markdown or text/plain). Safe redirects, catalog relationships, and sources need checks too. Seeing text in a browser does not prove all layers pass.

Decide whether to expand

A useful pilot establishes that the file is accessible, facts have sources, variant scope is correct, and live questions are handed to the store. Expand after those checks instead of counting generated files.

SKU.md does not log into your admin, publish products automatically, or submit them to external shopping channels. Merchants choose what to publish; agent consumption requires independent verification. Price, stock, and delivery commitments remain with live systems.

Use the quick start and give one reviewed product knowledge document to the person responsible for your storefront. That small handoff is a practical way to find the next problem worth solving.

Platform documentation and specification

• Shopify App Proxy: proxy routing and constraints.
• SHOPLINE redirects: URL forwarding.
• WordPress rewrite rules: routing on WooCommerce’s underlying platform.
• BigCommerce storefronts and custom templates: different control boundaries.
• SKU.md 1.0.0: authoritative file, discovery, and validation requirements.