Structured Data for Agentic Commerce

PRODUCT DATA DECISION

Publish one product truth through several controlled formats

Structured data is a machine-readable representation of the visible offer; a merchant feed is a submitted catalogue; neither should become a separate marketing story. Product identity, variant, price, availability and policies must resolve to the same purchasable reality.

01 – MODEL

Choose the right entity

Separate product family, variant and offer so identifiers, attributes, price and stock attach to the correct record.

02 – ALIGN

Synchronise each surface

Generate page, markup and feeds from controlled fields with known owners and update timing.

03 – VALIDATE

Test eligibility and truth

Check syntax, required properties, visible agreement, crawlable pages and real checkout behaviour before submission.

Validate one variant from source record to checkout

Trace its identifier, visible details, JSON-LD, merchant feed, price, availability and final checkout validation; resolve every mismatch before scaling.

Structured data helps a machine understand the entities and offers already present on a page. It is not a hidden keyword field and does not guarantee a rich result, ranking or recommendation. For agent-assisted shopping, it belongs inside a broader product-data system that also supplies accurate visible content, merchant feeds, inventory and checkout validation.

Use the ecommerce service for store implementation, the AI-ready description guide for editorial fields, and the agentic-commerce comparison for channel decisions. Only publish values the business can substantiate and keep current.

1. Identify the product, variant and offer

EntityExamplesCommon mistake
Product familyShared model or designAssigning one identifier to unlike variants
VariantSpecific size, colour, capacity or packShowing a variant image with another variant’s attributes
OfferPrice, currency, availability, condition and sellerPublishing an offer that cannot be purchased
PolicyShipping and return conditionsMarkup disagrees with the visible policy

Choose the canonical product page and variant representation deliberately. If variants have separate URLs, each URL should describe the selected item consistently. If one page switches variants dynamically, ensure the rendered visible state and structured representation correspond to the purchasable selection.

2. Establish the source-of-truth matrix

FieldAuthoritative sourceUpdate trigger
SKU, GTIN or MPNApproved item masterCatalogue governance change
Title and descriptionProduct information recordReviewed content release
Price and currencyCommerce pricing serviceApproved price event
AvailabilityInventory and fulfilment promiseStock or reservation event
ImagesApproved media libraryVariant media approval
Shipping and returnsPolicy and commerce configurationPolicy effective date

Generate downstream formats from these sources where practical. If a feed has its own manual price field, drift is almost inevitable. Record last successful publication and validation per channel so an integration failure does not leave old availability presented as current.

3. Follow feature-specific requirements

Google Search Central documents Product structured data for product snippets and merchant listings, with different requirements and recommendations depending on the experience. Check the current feature documentation when implementing because supported properties can change. Markup must describe visible page content and meet general structured-data policies. Eligibility does not guarantee that Google will display a feature.

4. Build a complete merchant product feed

Google Merchant Center’s product-data specification defines product attributes and formatting used for its destinations. OpenAI’s March 2026 update describes product discovery supported by merchant feeds and promotions through the Agentic Commerce Protocol, with Shopify Catalog integration for Shopify merchants. Treat each provider specification as a contract: map fields explicitly, validate rejected items and do not assume one feed format is accepted everywhere.

  • Use stable item and variant identifiers across updates.
  • Provide landing-page URLs that resolve directly and remain crawlable where required.
  • Keep price, currency and availability consistent with the merchant page.
  • Use images that show the actual product and selected variant.
  • Remove or update discontinued, expired and unavailable offers promptly.
  • Preserve provider error messages and correction history.

5. Validate in four layers

LayerValidation
SyntaxJSON parses and the markup vocabulary is valid
FeatureCurrent required and recommended properties are assessed
Visible truthPage content and markup describe the same product and offer
TransactionCheckout revalidates variant, stock, price, delivery and terms

Use Google’s Rich Results Test for supported Google features and the Schema.org validator for vocabulary-level inspection. Provider diagnostics and feed reports are separate evidence. Automated validation cannot prove that the underlying product claim is true; a product owner still needs to review source data.

6. Handle availability as a fulfilment promise

Do not derive in-stock status only from a positive physical quantity. Reservations, quality holds, supplier feeds, location eligibility and delivery cut-offs may change what can be promised. Define the logic and its freshness threshold. The checkout must confirm the state again because a crawler or shopping assistant may have seen an earlier representation.

7. Monitor drift and correction

Track invalid markup, feed rejection, missing identifiers, price mismatch, stale availability, broken canonical links and variant-image errors. Prioritise errors by customer impact and commercial exposure. When a source field changes, verify the page, markup and feeds after publication rather than assuming the update propagated.

Worked implementation

A retailer sells a shoe in six sizes and three colours from one family page. The old setup exposes one family SKU, a single image and a generic in-stock value. The rebuild gives every purchasable variant a stable SKU and approved identifier, maps colour and size, selects the correct image, and derives price and availability from the commerce record. The JSON-LD and merchant feeds use those same fields. A test variant is traced through page, markup, feed diagnostics and checkout. Only after the selected colour, size, price and availability remain aligned does the team release the remaining variants.

Sources checked

Reviewed by

Mitrend Digital editorial team

2026-07-17

Evidence used for this page

Reviewed against current Google Product structured-data documentation, Google Merchant Center product specifications and OpenAI’s March 2026 product-discovery update. Includes an original source-of-truth matrix and validation sequence.

Turn the guide into a practical next step

This resource provides general implementation guidance. Verify platform settings, tax, legal, payment and operational requirements against the current business context before making a live change.

Similar Posts