Pricing schema: Offer and PriceSpecification explained

Pricing schema describes an offer in machine-readable fields such as price and currency. Start with the visible offer, preserve its payment and commitment terms, then choose properties that accurately express it. Valid Schema.org markup does not guarantee a Google rich result or an accurate AI answer, and Google does not require special AI schema.

If you are investigating what assistants say about your pricing, a QuotedWrong provisional scan is a separate observation step. This tutorial covers the source page you control. You will need its visible pricing copy, the page template that emits JSON-LD, and access to inspect the rendered page.

1. Write the complete visible offer.
2. Choose an accurate entity and offer scope.
3. Map amount and currency without changing their units.
4. Validate syntax, vocabulary and visible-content agreement.
5. Maintain the markup when the offer changes.

1. Establish the visible offer first

Collect the product and plan name, currency, amount, price unit, payment cadence, commitment and applicable region. Preserve unknowns. If the pricing team has not decided whether tax is included, a developer cannot resolve that uncertainty by selecting a schema property.

The pricing-page checklist provides a review record for these fields. Complete it for the offer state the page represents. A default annual price and an optional monthly price should not be merged into a single unexplained number.

Google’s structured-data policies, accessed 26 September 2026, require markup to reflect the page content. Start with a statement a person can read and verify. Structured data should express that statement rather than introduce a cheaper, broader or more flexible offer that the visible page does not support.

2. Choose an accurate entity and offer scope

Schema.org’s Offer type describes an offer and provides properties including price, priceCurrency and priceSpecification. Choose the surrounding entity to match what the page actually describes. A software service, a particular plan and a promotional offer are related concepts, but they are not interchangeable labels.

Do not select a type solely because a competitor’s snippet looks attractive. Schema.org vocabulary and a search engine’s supported search features have different scopes. Before pursuing a particular Google appearance, inspect that feature’s current requirements and establish whether your page qualifies.

A useful implementation question is: “Which visible statement does this object describe?” If the answer is “the annual Team plan for new customers in this market,” the object should not silently also represent monthly billing, legacy contracts or every regional offer.

3. Map a conservative Offer example

The following ExampleCo offer is fictional, prepared for this tutorial on 26 September 2026. No product is offered at this URL. Assume the visible page says: “Team monthly: USD 30 per seat, paid each month, with a month-to-month commitment.” The example preserves that sentence in a description and uses explicit currency.

{
  "@context": "https://schema.org",
  "@type": "Offer",
  "name": "ExampleCo Team monthly",
  "url": "https://example.com/pricing",
  "price": "30.00",
  "priceCurrency": "USD",
  "description": "USD 30 per seat, paid each month, with a month-to-month commitment."
}

This small object illustrates vocabulary, not a complete Google rich-result implementation. The prose description carries conditions that the bare number cannot express. Do not assume that every consumer of the markup will interpret a description as a formal recurring-price model.

Use this fictional example to review the field mapping, then replace every value with the terms of your actual offer before adding markup to your pricing page. Publishing ExampleCo’s invented price as a live Offer would describe a product you do not sell.

When PriceSpecification adds useful detail

Offer can use priceSpecification for a more structured price description. UnitPriceSpecification is relevant when the price applies to a unit or quantity. Choose fields from their current definitions, then test whether they accurately represent your offer and the consumer you intend to support.

In Schema.org, billingDuration describes the duration for which a price component is billed, including contractual duration. billingIncrement concerns the minimum quantity or rounding basis. It is not a universal switch where “1” means monthly and “12” means annually. referenceQuantity describes the quantity to which a price applies.

For an annual offer displayed as a monthly equivalent, write down which amount the property will represent before coding. A number of 20 with an unexplained duration can obscure an actual annual payment of 240. The billing-period guide works through that arithmetic and the conditions that must travel with it.

Payment APIs have their own representations. Stripe’s Price object documentation, accessed 26 September 2026, distinguishes currency, unit amount, recurring interval and interval count. Its unit_amount uses the currency’s minor-unit convention. Do not copy that integer blindly into Schema.org price; USD 30 is not represented as a displayed USD 3,000 price.

4. Validate three different things

First, parse the JSON. Missing quotes, trailing commas or template substitutions can make an otherwise thoughtful mapping unreadable. Inspect the emitted page, since a valid object in a source file does not establish that the production response contains the same object.

Second, use the Schema Markup Validator to inspect vocabulary and structure. Review warnings against the actual property definitions instead of adding fields merely to silence a message. Keep a copy of the tested page or code and the date of the check.

Third, if you are targeting a supported Google search feature, use the Rich Results Test for that feature’s requirements. A vocabulary-valid Offer may not qualify for the feature you want. A passing test also does not guarantee that Google will show a rich result.

Complete a human comparison beside these tools: the same plan name, amount, currency and terms should appear in the visible page and the markup. Validators cannot determine that an invented review is genuine or that a promotional offer is still applicable. Never manufacture ratings or customer reviews to meet an eligibility rule.

For a useful validation record, save the tested URL, time, selected offer state and tool output together. Name the person who compared the marked-up offer with the visible copy. If the tool fetched a default currency while your screenshot shows another currency, the two artifacts do not establish agreement. Repeat the comparison for the same state before closing the issue.

Also check whether the page emits duplicate objects. A shared layout and a pricing component can each contribute markup. Inspect both before deleting either: they might describe different entities, or they might conflict about the same offer. Record the intended source of each object so the next pricing edit has a clear owner.

5. Maintain schema with the pricing release

Treat visible copy and structured data as two outputs of the same offer decision. Include both in the release checklist. When a price changes, inspect the default page and every materially different selector state, then retain the dated before-and-after captures.

Google’s AI-features guidance, accessed 26 September 2026, says no special schema is required for its AI features. Keep ordinary technical eligibility, useful visible text and accurate markup in view. None gives a vendor control over a future answer.

If a sampled answer still differs, return to the QuotedWrong evidence method. Record the observed claim and applicable source version. A successful schema release and a corrected sampled response are separate events; each needs its own evidence.

A common schema question

Can you give me an example of a product schema?

The fictional Offer above demonstrates a price object, not a complete product-page implementation. Start with the actual entity your page describes, then consult the requirements of the search feature you want to support. Adding a Product label to an unsuitable page does not make its offer eligible.