If you ship one piece of structured data this quarter, make it Product JSON-LD with a complete Offer. It's the difference between an agent knowing your price and guessing it — and agents don't buy on guesses.
The minimum that matters
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aurora 40-inch USB-C Monitor",
"sku": "AUR-40-UC",
"offers": {
"@type": "Offer",
"price": "279.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
}
}
</script>Name, price, currency, availability. Everything else — images, brand, ratings, GTINs — strengthens the record, but these four fields are what a buying decision needs.
The mistakes that get markup discarded
Invalid structured data is often worse than none, because parsers throw it away silently. The repeat offenders from our scans: trailing commas (invalid JSON, whole block dropped), price with a currency symbol baked in ("$279" instead of "279.00" + priceCurrency), availability as free text instead of the schema.org URL, and JSON-LD that disagrees with the visible page — a mismatch that erodes exactly the trust it was supposed to build.
Keeping it true at scale
The hard part isn't writing one block; it's the thousandth SKU and the redesign eighteen months from now. Structured data drifts: a template change drops the script tag, a pricing migration changes the field, and nothing visibly breaks — for humans. The durable setup treats JSON-LD like an API contract: generated from the same source of truth as your rendered price, validated in CI, and covered by a deterministic check that fails the build when a product page stops being machine-readable. Markup you can't keep true is marketing; markup under test is infrastructure.