What Is priceType Schema?

priceType is the Schema.org property that identifies the role of a price specified for an offered product, such as list price, temporary sale price, manufacturer suggested retail price, regular price, invoice price, or strikethrough price. It accepts PriceTypeEnumeration or Text.

The property helps distinguish multiple price values that otherwise look identical in a graph. A $120 list price and a $79 sale price are not alternative amounts without context: one is a reference and the other may be the currently purchasable amount. Each price node needs its type, amount, currency, validity, and Offer relationship preserved.

priceType does not prove that a discount is genuine. A list, MSRP, or strikethrough amount must be supported by the page and commerce history. Do not create a higher reference price merely to make the sale appear more compelling. Truthful pricing and checkout consistency remain the controlling evidence.

1. Frame the decision raised by What Is priceType 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.

• Classify each real price by its role.
• Keep reference and purchasable amounts distinct.
• Never fabricate a comparison price.

priceType adds meaning to a price only when the underlying amount and role are both truthful.

Schema.org lists priceType on UnitPriceSpecification and CompoundPriceSpecification. Place it on the specific pricing node whose role you need to identify, not directly on Product or an unrelated page entity.

Connect the pricing node to the applicable Offer through priceSpecification. The Offer identifies the item, seller, plan, and market; the specification carries the amount and classification. Review the PriceSpecification guide and itemOffered guide for the surrounding relationships.

If multiple sellers provide the same Product, each seller may have different regular and sale prices. Never reuse one merchant’s comparison price across all Offers. Separate nodes by seller, variant, condition, region, and eligibility whenever those facts change the price role.

• Evidence for Where Can priceType Be Used: 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. Resolve the Offer and seller.
2. Identify the price node being classified.
3. Attach priceType to that exact node.

Correct placement keeps priceType tied to the exact price specification whose commercial role it describes.

PriceTypeEnumeration currently includes InvoicePrice, ListPrice, MSRP, MinimumAdvertisedPrice, RegularPrice, SRP, SalePrice, and StrikethroughPrice. Choose the defined member whose meaning matches the visible commercial price.

These labels are not interchangeable. List price represents an offered product’s list amount and is typically the same as MSRP, while SalePrice represents a sale amount usually active for a limited period. StrikethroughPrice reflects a comparison amount displayed with a strike-through, but its factual basis must still be documented.

Schema.org also allows a UN/EDIFACT 5387 code or free-form Text for price types not predefined. Prefer a defined enumeration where it accurately fits. Free text should not become an uncontrolled collection of internal labels such as “promo2,” “web_special,” or “best price.”

1. Frame the decision raised by Which PriceTypeEnumeration Values Exist.
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.

• Prefer precise enumeration members.
• Keep internal campaign labels out of public schema.
• Document the source of reference prices.

Select a price type by definition and evidence, not by whichever label creates the strongest discount impression.

ListPrice identifies an offered product’s list price and is typically the same as MSRP; MSRP is the manufacturer suggested retail price; RegularPrice identifies the seller’s normal price. They may share an amount, but they describe different sources and roles.

A retailer’s regular price can be lower than MSRP without being a temporary sale. Likewise, a manufacturer’s suggestion does not prove the seller previously charged that amount. Use the role that matches the source record and visible wording, and do not substitute MSRP for prior selling price.

Reference-price practices can carry regulatory and platform obligations. Schema markup should follow approved merchandising and legal policy rather than establish it. Retain effective dates and price history so teams can explain why a comparison value was published on a given day.

• Evidence for How Are List Price, MSRP, and Regular Price Different: 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 who set the price.
2. Verify how the page labels it.
3. Preserve evidence and effective dates.

List, MSRP, and regular prices should remain separate whenever their source or commercial meaning differs.

Use SalePrice for a currently obtainable sale amount and StrikethroughPrice for a visible comparison amount shown as struck through. The sale price must match checkout, while the comparison value must have a substantiated basis and not be manufactured for urgency.

A strike-through is presentation, but priceType describes the role of the corresponding pricing node. Publish separate amounts with separate classifications. Do not mark one amount as both SalePrice and StrikethroughPrice, and do not leave an expired sale active while only changing the visual styling.

Time-limited sale pricing needs validFrom, validThrough, or another appropriate verified deadline on the relevant specification. The existing priceValidUntil guide explains Offer price deadlines; choose temporal properties based on the entity and fact rather than copying one date everywhere.

1. Frame the decision raised by How Should SalePrice and StrikethroughPrice 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.

• Create separate nodes for sale and comparison amounts.
• Verify the sale at checkout.
• Remove or update expired pricing atomically.

Sale and strikethrough price types work only when current checkout and historical comparison evidence support both amounts.

priceType classifies the pricing node, price supplies its amount, and priceCurrency supplies the currency. Keep all three on the same applicable UnitPriceSpecification or CompoundPriceSpecification so roles and amounts cannot drift apart.

Follow the price schema guide: a visible US sale of “$79.00” can use price “79.00,” priceCurrency “USD,” and priceType “SalePrice.” A separate comparison node can carry its own amount, currency, and type.

Multi-market pages must not reuse a USD comparison value for a CAD sale or combine prices converted at different times. Amount, currency, type, seller, and validity should update from one source transaction. Cache keys must distinguish every crawlable market and selected variant.

• Evidence for How Do priceType, price, and Currency Work Together: 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. Resolve amount, currency, and role together.
2. Serialize them on the same node.
3. Test every market and variant.

A typed price is complete only when its role, amount, currency, and Offer context refer to one real commercial value.

Create the Offer and applicable price specifications, give each amount its own node and priceType, then add currency, validity, unit, and eligibility facts from the commerce source. Keep the currently purchasable price unmistakable.

Do not build pricing solely in an SEO editor. The source should retain Offer ID, seller, price-record ID, amount, currency, role, validity, and history. Templates should omit missing comparison values rather than copying the regular price or inventing a discount.

{
 "@context":"https://schema.org",
 "@type":"Offer",
 "itemOffered":{"@type":"Product","name":"SEO Field Guide"},
 "priceSpecification":[
  {"@type":"UnitPriceSpecification","price":"79.00","priceCurrency":"USD","priceType":"https://schema.org/SalePrice"},
  {"@type":"UnitPriceSpecification","price":"99.00","priceCurrency":"USD","priceType":"https://schema.org/RegularPrice"}
 ]
}

• Evidence for How Do You Mark Up Multiple Price Types: 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. Resolve each price record and role.
2. Serialize a distinct typed node.
3. Verify current and reference values independently.

Multiple price types are useful only when distinct nodes preserve the role and evidence of every displayed amount.

Common errors include marking every price as SalePrice, treating MSRP as prior selling price, classifying the current amount as StrikethroughPrice, using internal campaign labels, mixing sellers or variants, omitting currency, and leaving expired price roles in cached markup.

Templates often serialize both old and new prices but give them the same type, or update the visible sale while keeping the prior JSON-LD amount. Multi-currency conversion can produce a CAD sale beside a USD MSRP. These graphs can pass syntax checks while misrepresenting the commercial comparison.

Test sale activation, expiration, variant selection, currency switching, member eligibility, coupon requirements, out-of-stock options, and cache refresh. Compare every price node with source history, visible labels, and checkout outcome. Remove unsupported comparison values instead of repairing them with cosmetic type labels.

1. Frame the decision raised by What priceType Mistakes Are Common.
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.

• Validate price history beyond syntax.
• Keep seller and variant scope intact.
• Re-crawl every sale transition.

Prevent typed-price errors by proving both the amount and the commercial role through source history and checkout.