TechnicalAugust 18, 2026 · 9 min read

Schema markup for clear, machine-readable product facts

By Arcanoris editorial team · Updated September 22, 2026. Technical references checked against the sources linked below. Send a correction.

Google says its Search AI features need no special schema. Treat the examples below as ways to describe visible facts, not established ranking factors. Structured-data policies also require accurate, relevant markup and do not guarantee a rich result.

Schema.org markup doesn't persuade a model of anything - it just says something once, unambiguously, in a shape built to be parsed rather than read. An Offer can label a price and currency explicitly, but a consuming system still decides whether and how to use those fields. For a system that's synthesizing an answer from many pages under time pressure, that difference is exactly what makes markup worth the hour it takes to add.

Start with the types that answer real questions

Type	Answers	Priority
Organization	"Who makes this?"	Add first - every page benefits
Product / Offer	"How much does it cost?"	High - price questions are constant
FAQPage	Direct buyer questions	Optional - no AI visibility guarantee
BreadcrumbList	"Where does this page sit?"	Low - cheap, mechanical, do it once
Dataset	"What did you measure?"	Medium - only if you publish data

Organization and Product/Offer cover the two questions buyers ask an assistant most - who are you, and what does it cost - so they're worth adding even if you do nothing else. A minimal Offer block looks like this:

Offer JSON-LD

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Team plan",
  "offers": {
    "@type": "Offer",
    "price": "29",
    "priceCurrency": "USD",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "billingDuration": "P1M"
    }
  }
}

FAQPage describes content; it does not promise visibility

Schema.org defines FAQPage as a page with frequently asked questions. That vocabulary definition is not a promise that Google will show a rich result or that an assistant will retrieve it. Write useful visible answers first; check current platform eligibility before adding markup for a specific search feature.

Where teams overreach

Review and AggregateRating schema exist for genuine customer reviews, not for badging your own product with stars it didn't earn from a third party. Google's guidelines are explicit about this, and misuse risks a manual action - a bad trade for a few gold stars in a search snippet. If you don't have real, collected customer reviews, leave that schema out entirely rather than approximate one.

Dataset schema for anything you publish as data

If you publish benchmark results, a pricing comparison, or market data, Dataset schema with a variableMeasured list turns your numbers into machine-readable claims instead of prose a model has to parse and hope it read correctly:

Dataset JSON-LD

{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "name": "Q3 2026 support response time benchmark",
  "description": "Median first-response time across 12 helpdesk tools, sampled weekly.",
  "variableMeasured": [
    { "@type": "PropertyValue", "name": "Median response time", "value": "4.2 hours" }
  ]
}

It's a small, specific addition, and it's exactly the kind of structured fact an assistant can quote with confidence - a number with a named variable and a source, instead of a claim buried in a paragraph.

Validate before you ship it

Markup with a typo doesn't degrade gracefully - it just fails silently, and you won't notice unless you check. Run new schema through Google's Rich Results Test or the schema.org validator before it goes live, and again whenever the page it's on changes. Syntactic validity alone does not establish platform eligibility or factual accuracy; also compare the markup with the visible page.