What Is UnitPriceSpecification Schema?

UnitPriceSpecification is structured data for expressing a price within an Offer, including active, unit-based, original list and member-tier pricing contexts.

The type extends PriceSpecification and provides a place for price, priceCurrency, effective dates, reference quantity, price type and membership eligibility. It is useful when a simple Offer.price cannot accurately describe all visible pricing dimensions. A merchant might use one specification for the active unit price, another for the original strikethrough amount, or separate specifications for eligible member tiers. The object does not create a discount or override checkout; it must serialize genuine commerce terms already shown to shoppers. Current search support recognizes a defined subset of the broader Schema.org vocabulary, and conflicting properties can cause a specification to be ignored. Valid markup establishes data quality and possible eligibility, not guaranteed search presentation or CTR.

1. Frame the decision raised by What Is UnitPriceSpecification Schema.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Nest pricing under Offer.
• Assign one role per specification.
• Match visible checkout terms.
• Avoid search guarantees.

UnitPriceSpecification is valuable when each nested price has one explicit role, currency, eligibility context and visible commercial meaning.

The decision for What Is UnitPriceSpecification Schema should rest on live, traceable evidence and a verified follow-up check.

Use UnitPriceSpecification when pricing needs more context than a single Offer price, such as unit measures, sale list prices, member tiers or bounded validity periods.

A straightforward product with one public price can use Offer Schema directly. Add UnitPriceSpecification when the page shows flooring priced per square meter, detergent priced per liter, a current sale alongside a genuine original price or different prices for defined loyalty tiers. Do not create a specification merely to repeat the same active amount already stored on Offer. If both Offer.price and priceSpecification encode the active price, the Offer-level value takes precedence in current product handling, so any disagreement becomes a verification defect. Complex does not mean vague: shoppers must understand which amount applies, to what quantity, during which period and under which eligibility conditions. The same pricing engine should drive page, checkout, feed and structured data.

• Evidence for When Should You Use UnitPriceSpecification: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Identify visible price roles.
2. Choose simple or complex model.
3. Remove redundant active prices.
4. Verify checkout application.

Add UnitPriceSpecification only when it expresses a pricing dimension shoppers can see and the Offer-level price alone cannot represent clearly.

The decision for When Should You Use UnitPriceSpecification should rest on live, traceable evidence and a verified follow-up check.

The supported core requires price and priceCurrency, while referenceQuantity, priceType, validForMemberTier, dates and membershipPointsEarned add specific pricing context.

Use a numeric price without symbols and a three-letter ISO 4217 currency such as USD. referenceQuantity links a QuantitativeValue when price is tied to a unit. priceType currently uses the supported StrikethroughPrice value for a full original listing price, not the active sale amount. validForMemberTier connects a member price to a real tier, while membershipPointsEarned remains beta and belongs only with a tier. validFrom and validThrough bound effective periods. The broader Schema.org type includes additional properties, but search-specific implementation should follow the documented subset. Never fill optional fields with invented values just to clear a warning.

1. Frame the decision raised by Which Properties Does UnitPriceSpecification Use.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Always state price and currency.
• Use supported roles only.
• Reference real member tiers.
• Omit unverifiable context.

A specification should contain the smallest supported property set that completely explains one real price and who, when or what quantity it applies to.

The decision for Which Properties Does UnitPriceSpecification Use should rest on live, traceable evidence and a verified follow-up check.

When Offer.price and priceSpecification both encode an active price, the Offer-level price takes precedence and the specification’s competing active amount is ignored.

This rule makes contradictory output especially dangerous: the page may show $79, Offer.price may publish $89 and an active specification may publish $69, leaving three possible truths. Choose one authoritative active price pattern. A common merchant approach keeps the current public price on Offer, then uses specifications only for the original strikethrough amount, unit basis or member-tier alternatives. Another valid implementation can put the active amount in priceSpecification when Offer.price is absent. The same currency rule follows the selected path. Do not assume the richest object wins. Build automated checks that identify two active specifications with overlapping dates, a mismatched Offer-level amount or specifications lacking a clear role. Reconcile with cart and checkout before validating syntax.

• Evidence for How Does Offer Price Precedence Work: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Choose the authoritative active path.
2. Label nonactive roles clearly.
3. Detect overlapping specifications.
4. Compare with checkout.

Price precedence is safe only when every active path agrees or when each specification has a distinct noncompeting role.

The decision for How Does Offer Price Precedence Work should rest on live, traceable evidence and a verified follow-up check.

Unit pricing uses referenceQuantity to describe the quantity covered by a price and the base measure against which shoppers compare it.

A UnitPriceSpecification can state that $18 covers 0.5 gallons, one square meter or another supported measure. The nested QuantitativeValue requires value and unitCode; valueReference can describe the base quantity used for comparison. Use supported UN/CEFACT codes or accepted human-readable equivalents for web markup, noting that some feed-only units are not supported on-page. Product package quantity and unit price are different concepts: a six-pack’s total price should not be mislabeled as six independent offers. Values must match the visible unit label and checkout quantity. Normalize unit conversions carefully so liters, milliliters, feet and square feet are not compared incorrectly. Test decimal precision and locale formatting without putting commas or symbols in numeric fields.

1. Frame the decision raised by How Does Unit Pricing Use referenceQuantity.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Use supported unit codes.
• Separate package and base quantity.
• Verify conversion math.
• Match visible unit labels.

Unit pricing is correct when the structured quantity, unit conversion, displayed comparison and amount charged all reconcile mathematically.

The decision for How Does Unit Pricing Use referenceQuantity should rest on live, traceable evidence and a verified follow-up check.

A sale uses the current active Offer price and a separate UnitPriceSpecification marked StrikethroughPrice for the genuine original listing price.

Set priceType only on the original full price and use the supported https://schema.org/StrikethroughPrice value. Do not mark the current discounted amount as strikethrough. The Offer must still provide a current sale price through its price property or a distinct active specification. Effective dates can define when the original or sale context applies, but they must update with the storefront and promotion engine. A fabricated list price briefly raised before a sale is not a legitimate pricing signal. This model supports visible sale context, while Price Drop Structured Data is a different enhancement computed from observed Offer changes over time. Do not conflate declared original price with externally observed price history.

• Evidence for How Do Sale and Strikethrough Prices Work: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Publish current sale price.
2. Add genuine original specification.
3. Set the supported priceType.
4. Test promotion boundaries.

Sale pricing needs one current purchasable amount and one genuine original price with distinct roles, synchronized dates and visible parity.

The decision for How Do Sale and Strikethrough Prices Work should rest on live, traceable evidence and a verified follow-up check.

Member pricing uses validForMemberTier to connect a price specification to a real loyalty tier, while a regular public price remains available on the Offer.

A member-specific specification identifies the eligible MemberProgramTier, either inline or through a stable @id defined under Member Program Schema or Merchant Center. Multiple tiers can share one price, or separate specifications can carry different amounts. The regular price must remain represented because a member price is not the universal active price. membershipPointsEarned is a beta property for whole points and should appear only with validForMemberTier. Current documentation warns that combining priceType and validForMemberTier on the same specification causes that specification to be ignored, so original-price and member-price roles need separate objects. All membership eligibility must match visible enrollment and checkout behavior.

1. Frame the decision raised by How Do Member Prices and Loyalty Points Work.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Keep a regular public price.
• Reference defined tiers.
• Separate list and member prices.
• Verify enrollment at checkout.

Member pricing is accurate when tier identity, regular baseline, discounted amount and checkout eligibility all agree without conflicting specification roles.

The decision for How Do Member Prices and Loyalty Points Work should rest on live, traceable evidence and a verified follow-up check.

Common mistakes include conflicting active prices, marking the sale price as strikethrough, combining priceType with member-tier eligibility and using incorrect unit codes.

Other defects include missing currency, expired validity dates, symbol-formatted price strings, overlapping specifications and member tiers that do not exist. Product teams may confuse package quantity with unit basis or calculate per-unit prices using the wrong conversion. Plugins can generate Offer.price and a different active priceSpecification from separate data sources. A validator may detect missing required fields but cannot prove a list price is genuine, a member can qualify or the unit math matches checkout. Crawl rendered output, classify every specification by role and independently recompute its value. Remove unsupported complexity when a single Offer.price communicates the transaction better. Fix promotion, catalog or loyalty source systems rather than hand-editing JSON-LD.

• Evidence for What UnitPriceSpecification Mistakes Are Common: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Classify every price role.
2. Detect precedence conflicts.
3. Recompute units and tiers.
4. Repair source systems.

The highest-risk specification errors create a price shoppers cannot reproduce, so role clarity and checkout truth outrank structural richness.

Start with a relevant free SEO check, continue the evidence workflow in Novaverb, and review pricing when comparing continuous monitoring with a one-time manual review.

The decision for What UnitPriceSpecification Mistakes Are Common should rest on live, traceable evidence and a verified follow-up check.