Product schema markup
Product schema markup is structured data — typically written in JSON-LD using the Schema.org Product vocabulary — embedded in a web page's HTML to expose product attributes (name, SKU, GTIN, price, availability) as typed, machine-readable facts rather than prose. Search engines use it to generate rich results; AI systems use it to evaluate and recommend products without inferring meaning from unstructured copy.
What product schema markup actually does
A search engine reading a product page as plain HTML has to infer — from title tags, copy, and page structure — what the product is, whether it's in stock, and what it costs. It guesses. Product schema removes the guessing by declaring each attribute in a vocabulary machines read natively: Schema.org's Product type, embedded as a JSON-LD block in the <head> of the page.
The block is invisible to visitors but explicit to every crawler, AI system, and procurement tool that fetches the URL. Google uses it to populate Shopping panels, AI Overviews, and rich results. LLM-based tools use it to answer "best X for Y" queries without loading the full page. When the schema is clean and complete, your product gets evaluated. When it's absent or broken, the system falls back to body copy — if it bothers at all.
This matters more in B2B than most teams realize. Industrial buyers search by part number ("90273A547"), by specification ("3/8-16 Grade 5 zinc hex bolt"), by certification ("UL listed 600V wire connector"), or by compatibility ("replacement for Baldor EHM3554T"). Schema that explicitly declares MPN, GTIN, and technical attributes as structured fields — not buried in a paragraph — is what makes those searches resolve to your listing instead of a competitor's.
The anatomy of a B2B product schema block
The Schema.org Product type is the foundation. A minimal block for an industrial fastener looks like this:
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Hex Bolt, 1/4-20 x 1\" Grade 316 Stainless Steel",
"sku": "HB-1420-SS316-1IN",
"mpn": "90273A547",
"gtin12": "00012345678905",
"brand": { "@type": "Brand", "name": "Fastenal" },
"description": "Grade 316 stainless steel hex bolt for marine and food-processing environments. 1/4-20 UNC thread, 1-inch length, meets ASTM A193 Grade B8M.",
"additionalProperty": [
{ "@type": "PropertyValue", "name": "Thread Size", "value": "1/4-20 UNC" },
{ "@type": "PropertyValue", "name": "Material Grade", "value": "316 Stainless Steel" }
],
"offers": {
"@type": "Offer",
"priceCurrency": "USD",
"price": "0.89",
"priceValidUntil": "2026-12-31",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}
A few fields carry disproportionate weight in B2B contexts:
gtin12 / gtin14: This ties your listing to Google's product knowledge graph. With a valid GTIN, Google can match your SKU against manufacturer data, competitive offers, and aggregated signals. Without it, your listing is anonymous. Google's own documentation calls GTIN the most important identifier for Shopping eligibility.
mpn: The manufacturer part number. Critical for buyers searching by part number and for cross-referencing across distributors carrying the same SKU under different internal IDs.
additionalProperty: Schema.org's Product type has no native fields for tensile strength, IP rating, or operating temperature range. PropertyValue pairs inside additionalProperty are how you express technical attributes in structured form. They don't generate rich results today, but AI systems and procurement tools increasingly parse them when evaluating products.
description: Not a marketing block — a fact statement. Lead with material, grade, and application context. "Grade 316 stainless hex bolt for corrosive marine and food-processing environments" tells a machine far more than "delivers superior performance and durability."
B2B-specific complications: price, variants, and technical specs
Consumer schema is a largely solved problem: one price, one variant, in stock or not. B2B creates friction at every field.
Pricing: Most B2B prices are contract-based, tiered by volume, or quote-only. The Offer block expects a price. Showing $0.00, omitting Offer entirely, or mismatching the schema price against the rendered page price all trigger Search Console warnings — and high mismatch rates across a catalog can suspend rich results eligibility for the entire domain. The pragmatic solution: show a list price on the page and in schema, labeled clearly. For tiered pricing, PriceSpecification supports minPrice / maxPrice. For fully gated pricing, "availability": "https://schema.org/OnlineOnly" signals that the product exists but price requires authentication.
Variant complexity: A single circuit breaker line might have 60 variants across amperage, frame size, and interrupt capacity. Each variant needs its own schema block with its own SKU, GTIN, and MPN. Collapsing them into a single Product schema with a generic description loses exactly the granularity that makes schema useful for part-number searches. Product pages that serve multiple variants from one URL need server-side dynamic rendering or JavaScript injection to swap in the correct schema per selected variant state.
Technical attribute coverage: The hardest part isn't the schema format — it's having the underlying data to populate it. Catalogs migrated from legacy ERP systems often have clean pricing and SKUs but almost no structured attribute data. There's nothing to put in additionalProperty if the spec table was never captured. The schema block ends up technically valid but informationally thin — which a machine reads the same way a buyer would: not enough to be confident.
Common mistakes that invalidate schema — and the data problems behind them
Stale availability is the most common cause of Search Console penalties. A page with "availability": "https://schema.org/InStock" in schema but "Out of Stock" displayed on the page is a mismatch violation. Google flags these, and a catalog with thousands of them risks losing rich results eligibility across the domain. Availability in schema must be dynamically rendered or refreshed frequently — set-and-forget breaks down the moment inventory moves.
Missing identifiers are the most common cause of products being passed over for Shopping and AI recommendations. SKU is internal. GTIN and MPN are how external systems identify what you're selling. Without them, Google can't place your listing in its knowledge graph. The data usually exists somewhere — on the manufacturer's data sheet, in GEPIR, in 1WorldSync — but it hasn't been reconciled into the feed. For large B2B catalogs sourced from ERP systems that pre-date GTIN tracking requirements, this can mean six-figure SKU counts with blank identifier fields.
Price mismatch between schema and page is common in automated pipelines where the schema generator pulls from a different data source or cache than the front-end renderer. If a promotional price is live on the page but the schema still carries list price, that's a violation. B2B distributors with contract pricing, logged-in price tiers, or frequent promotional events need tight coordination between the feed, the schema generator, and the page renderer to keep them in sync.
Generic descriptions waste the description field. AI systems parsing product pages for recommendation tasks read the schema description as a structured summary of what the product is and what it's for. Copy lifted from the manufacturer — "built for performance and reliability in demanding environments" — tells a machine nothing it can act on. An accurate, specific description that names the material grade, the application context, and the key specification is both more findable and more useful to any downstream system reading the schema.
No schema on variant PDPs is a structural problem. Many distributors add schema to their main product pages but not to the filtered or parameterized URLs that represent individual variants. If the canonical URL for a specific part number is a category-filtered view rather than a true PDP, there's no schema to attach to it — and no signal for the crawler to resolve the part to a specific, in-stock product.
Every mistake on this list is ultimately a data problem wearing a schema costume. Stale availability means the feed update pipeline isn't writing back fast enough. Missing GTINs mean the enrichment workflow never sourced them. Generic descriptions mean no one rewrote the supplier copy with a buyer's query in mind. Schema is a presentation layer; what it can accurately declare is bounded by what the underlying product data actually contains. That's why enrichment that closes GTIN gaps, surfaces technical attributes, and rewrites descriptions around buyer search intent doesn't just improve page quality — it directly expands what schema can honestly say, and what a machine can confidently recommend.
Frequently asked questions
What is the difference between product schema markup and HTML meta tags?
Meta tags like `<meta name="description">` provide hints to search engines about a page's topic but aren't typed or structured. Schema markup uses a formal vocabulary — Schema.org — that explicitly declares the type of entity (a Product) and each property (price, availability, GTIN) as a discrete, machine-readable fact. Search engines treat schema as declarations rather than hints, which is why schema — not meta tags — powers rich results, Shopping panels, and AI product evaluations.
Which Product schema fields does Google require for rich results?
Google requires `name` and at least one of: `review`, `aggregateRating`, or `offers`. For Shopping eligibility, `price`, `priceCurrency`, and `availability` inside an `Offer` block are required, and a valid `gtin` or `mpn` is strongly recommended. Google's Rich Results Test validates compliance for a specific URL and shows which fields are missing or mismatched.
Does product schema markup help B2B pages appear in Google Shopping?
Yes, but Shopping eligibility depends on both valid schema and a matching Merchant Center feed. The schema on the product page must agree with the feed data — price, availability, and title in particular. Discrepancies trigger disapprovals. The additional B2B complication: Google's policies require that prices shown in Shopping be accessible without login. Fully gated pricing is either excluded from Shopping or requires a list-price fallback.
Can product schema be generated automatically from a PIM?
Yes, with an important caveat: automated schema is only as good as the data in the PIM. A PIM with incomplete GTINs, missing technical attributes, or stale availability will generate schema that is technically valid but factually thin — or will generate mismatch errors at scale. Automated generation works well when the underlying data is complete and accurate; it amplifies gaps rather than hiding them. The enrichment step that fills those gaps is what makes automation reliable.
Does product schema markup matter for AI answer engines, not just traditional search?
Increasingly yes. LLMs powering Google AI Overviews, ChatGPT Shopping, and Perplexity read structured data when available because it reduces the ambiguity of parsing prose. A product page with complete schema gives an AI system explicit, typed facts to work with — name, GTIN, availability, technical attributes — rather than forcing it to extract meaning from marketing copy, where errors compound. As AI-mediated product discovery becomes a larger share of the channel, schema completeness is becoming a prerequisite for appearing in AI-generated recommendations.