How SHOPLINE Merchants Can Prepare Product Knowledge for AI Agents
v1.0.0 features
A platform-aware preparation guide that separates merchant-controlled content, discovery hints, hosted-route constraints, strict validation, and compatibility reporting.
Status: This article reflects the current v1.0.0-beta boundary. It reports a method and its evidence requirements, not unverified adoption, ranking, citation, recommendation, or sales outcomes.
A hosted platform can limit the exact root paths and response headers a merchant controls. That does not justify pretending the limitation is solved. It calls for two clearly named publication modes and a validation report that records which one actually works on SHOPLINE.
Current status and evidence threshold
No completed SHOPLINE validation report is registered yet. This public guide therefore distinguishes a strict path from a compatibility path and does not claim that either path has been verified on SHOPLINE.
Strict mode
Strict mode serves the canonical catalog at the merchant’s own origin and preferred root path, with accepted Markdown transport and deterministic discovery. It is the target when SHOPLINE routing, a supported application surface, or a same-origin edge function can provide the response without an authentication wall or storefront fallback.
The test must use the public shop domain, not an internal preview URL. Redirects, caching, and custom-domain behavior are part of the result.
Compatibility mode
Compatibility mode is relevant when the hosted storefront cannot own /sku.md. A merchant-controlled HTML surface declares an alternate Markdown resource. The consumer then applies the specification’s origin, HTTPS, credential, query, fragment, redirect, and conflict checks before accepting it.
Compatibility must be named because it changes the trust path. An external host or cross-origin URL is not equivalent to a resource served by the store itself unless the specification explicitly permits and verifies that arrangement.
Prepare the knowledge before choosing transport
Inventory the stable product claims the merchant can approve: facts, guidance, limitations, compatibility, identifiers, and sources. Exclude live price, stock, discounts, shipping promises, payment, and order state. Build a small catalog first so a routing experiment does not hide content-quality defects.
The same knowledge artifacts should be used in both modes. Only the publication and discovery path should differ.
Validation report template
| Area | Record |
|---|---|
| Store | public custom domain and plan/context |
| Mode | strict or compatibility |
| Route | requested URL and final URL |
| HTTP | status, redirects, MIME, cache headers |
| Discovery | declaration and resolution trace |
| Document | validator version and result |
| Limits | platform constraints and required manual steps |
Failure cases to include
Test missing declarations, conflicting declarations, an HTML storefront response at the Markdown URL, cross-origin redirects, private preview links, and a valid document with an invalid source link. The report should state whether each case is rejected, warned, or accepted.
Evidence threshold
Report SHOPLINE compatibility as verified only when the report contains a repeatable public run, identifies the exact platform capabilities used, and avoids converting a candidate technique into a platform-wide support claim. One successful store demonstrates that configuration, not universal availability.
Inventory the surfaces a merchant can actually control
Before choosing a route, list what the SHOPLINE store can edit on its public custom domain: theme head markup, page content, application endpoints, redirects, headers, asset hosting, and any supported proxy or edge integration. Test the production storefront because preview and administration URLs may have different authentication, caching, and origin behavior. Platform documentation identifies possible mechanisms; only an observed response proves the store’s configuration.
For each surface, record who controls the URL, whether it can return Markdown bytes, whether response headers can be set, and whether updates are atomic. Reject private preview URLs and links that embed credentials. If publication must use another origin, do not call it equivalent to same-origin strict mode unless the specification expressly allows and validates it.
Run strict and compatibility paths against the same knowledge
Prepare the product knowledge before the routing experiment. Use the same Catalog and product documents in both paths so content quality does not confound transport. Strict mode tests the preferred merchant-origin route. Compatibility mode tests a standards-based discovery declaration from merchant-controlled HTML or HTTP to the actual resource, followed by all origin, redirect, conflict, and document checks.
The report should show resolution step by step. A consumer first tries the root, then reads the allowed declaration only when needed, resolves the target, checks security constraints, and validates the bytes. If two declarations conflict, the result must be a recorded warning or rejection according to the contract, not whichever URL happens to be parsed first.
Publish the constraints alongside the result
A useful SHOPLINE report includes store context, plan or feature assumptions, requested and final URLs, redirects, MIME, cache behavior, discovery trace, validator version, document hash, and reproducible setup. It also shows negative cases: missing declaration, conflicting declaration, HTML at the Markdown route, cross-origin redirect, and inaccessible source.
Report SHOPLINE compatibility as verified only after another person can repeat the public run. One working configuration supports a bounded integration recipe; it does not prove universal platform adoption. The article must continue to distinguish strict conformance from compatibility and keep live offers, inventory, shipping, payment, and orders in the platform’s transactional systems.
Keep discovery safe under hosted constraints
A declared target is still untrusted input. Consumers should require HTTPS, reject embedded credentials, apply the specification’s origin policy, limit redirects, block private-network destinations, cap response size and time, and treat document text as data rather than instructions. A convenient external file host does not justify weakening these checks. If a hosted-platform workaround cannot satisfy them, the report should mark it unsupported.
Discovery declarations also need conflict behavior. When HTML and HTTP identify different targets, the consumer must follow the defined precedence or produce a diagnostic. Choosing whichever target responds first creates a nondeterministic trust path and makes an incident difficult to investigate.
Give merchants a preparation workflow before integration exists
Merchants can inventory stable claims, assign owners, collect public sources, bind identifiers to variants, and review limitations before the platform report is complete. They can validate those artifacts locally and keep live commerce fields out. This work remains useful whichever publication mechanism eventually passes.
Once the route is proven, publish a small product set first, repeat discovery from outside the administration session, and archive the evidence. Expansion follows only after update and rollback behavior are understood. This evidence threshold prevents preparation advice from becoming a premature support announcement.
A compatibility report should end with a decision table: strict mode supported, compatibility mode supported with named constraints, or unsupported. Each outcome lists the exact evidence and the next action. This makes the report useful to a merchant choosing an integration path and prevents a warning-heavy experiment from being summarized later as a successful native integration.
The report should identify the maintenance owner and retest trigger. A storefront theme update, custom-domain change, routing feature change, or security policy update can invalidate earlier evidence. Schedule a public health check and show its last successful timestamp separately from the last content edit. That distinction tells a merchant whether knowledge is current and whether it is still reachable. If either check fails, keep the integration claim gated until the cause is understood and the public run succeeds again.