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
| Entity | Examples | Common mistake |
|---|---|---|
| Product family | Shared model or design | Assigning one identifier to unlike variants |
| Variant | Specific size, colour, capacity or pack | Showing a variant image with another variant’s attributes |
| Offer | Price, currency, availability, condition and seller | Publishing an offer that cannot be purchased |
| Policy | Shipping and return conditions | Markup 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
| Field | Authoritative source | Update trigger |
|---|---|---|
| SKU, GTIN or MPN | Approved item master | Catalogue governance change |
| Title and description | Product information record | Reviewed content release |
| Price and currency | Commerce pricing service | Approved price event |
| Availability | Inventory and fulfilment promise | Stock or reservation event |
| Images | Approved media library | Variant media approval |
| Shipping and returns | Policy and commerce configuration | Policy 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
| Layer | Validation |
|---|---|
| Syntax | JSON parses and the markup vocabulary is valid |
| Feature | Current required and recommended properties are assessed |
| Visible truth | Page content and markup describe the same product and offer |
| Transaction | Checkout 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
- Google Search Central: Product structured data
- Google Merchant Center: Product data specification
- Google Search Central: Structured data policies
- OpenAI: Powering Product Discovery in ChatGPT
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.
