AI Commerce Validator · one finding
Product feed item lacks a stable identifier
Recommended action: Give every feed item a stable, unique product identifier that remains unchanged across feed refreshes.
Fix principle: A sellable product needs one stable merchant-owned identity whose URL, identifiers, price, currency, and availability agree across the visible product page, Product/Offer structured data, discovery/feed records, and variant model. Fix the upstream catalog owner rather than reconciling each export independently.
Implementation for your setup
Confirm first: A product lacks a stable ID, duplicates another product ID, or points to a different product/variant across feed and discovery records. The Product/Offer price, currency, availability, URL, or identifier disagrees with the currently visible purchasable offer. The feed/discovery location references a different or unavailable product source than the page and schema represent.
Do not apply when: The same stable product and variant identifiers resolve consistently through catalog, feed, discovery, page URL, and structured data. Visible price and availability match the active Offer data, including currency and the specific variant being purchased. A deliberate aggregate/variant model is documented and each identifier remains unique at its intended level.
Likely control points: cms-app · content-data · managed-vendor
Choose the layer that owns the final response.
Generic HTTP / HTML
Steps
- Choose the authoritative merchant product and variant IDs; inventory duplicate, missing, recycled, or channel-specific identifiers before changing exports.
- Map each sellable page and variant to exactly one stable identity and canonical URL. Preserve IDs across ordinary title, price, inventory, or URL-label changes.
- Generate Product and Offer structured data, merchant feeds, and discovery documents from the same catalog record rather than independent hand-maintained values.
- Require the active visible price, currency, availability, offer URL, and variant selection to match the emitted Offer and feed values.
- Reject duplicate IDs and feed/discovery references to unavailable or different products during export, then publish the corrected artifacts together.
Verify on this platform
- Validate Product/Offer structured data and compare every material value with the visible purchasable offer.
- Join feed, discovery, page, and schema records by the stable identity and confirm one-to-one or explicitly modeled parent/variant relationships.
- Test representative in-stock, out-of-stock, sale-price, and multi-variant products after publication.
Rollback
- Restore the prior catalog/export revision if the identity migration breaks purchasing, inventory, or channel attribution.
- Do not recycle the newly corrected stable IDs during rollback; preserve an explicit alias/migration record.
Caveats
- Structured data must describe visible page content; it is not a substitute for fixing the storefront offer.
- Parent products and variants may legitimately have different identifiers, but the relationship and selected offer must be explicit.
- Search result enhancements remain discretionary even when markup is valid.
Official sources
Shopify
Implementation is controlled by the platform or vendor.
Verify on this platform
- Identify whether the product, variant, SKU, or an app-specific value is the authoritative exported ID for each channel.
- Compare the live theme JSON-LD and feed output with the selected storefront variant and Shopify catalog values.
Caveats
- Theme and feed-app implementations vary; no universal Shopify admin path or identifier mapping is asserted without verifying the installed theme and app.
- Escalate duplicate or conflicting output when more than one app/theme component emits Product JSON-LD.
Official sources
WordPress
Implementation is controlled by the platform or vendor.
Verify on this platform
- Identify the authoritative WooCommerce product/variation identifier and every plugin exporting schema or feed data.
- Compare a representative variation's visible offer, JSON-LD, and feed row after clearing page/cache layers.
Caveats
- Plugin settings and schema ownership vary; do not enable a second schema/feed owner to patch the first.
- No specific WooCommerce plugin path is claimed until the installed stack is verified.
Official sources
Platform-managed / ask the vendor
Implementation is controlled by the platform or vendor.
Verify on this platform
- Ask the vendor to document its product/variant identity key and how page, schema, feed, price, and availability updates are synchronized.
- Independently compare exported records with the live purchasable offer.
Caveats
- Escalate when the vendor cannot export the identity mapping or identify which channel overwrites values.
Official sources
How to verify
- Join catalog, page, schema, feed, and discovery records by the stable product/variant identity.
- Require visible and emitted price, currency, availability, URL, and identifiers to agree.
- Test representative inventory, sale, and variant states.
- Validate the final structured data and channel exports after cache invalidation.
Escalate when
Escalate when identities have been recycled, multiple apps own the same export, parent/variant relationships are ambiguous, or correcting the feed would conflict with the live purchase system.