What Is minPrice Schema?

minPrice states the lowest monetary amount allowed or represented by a PriceSpecification when the exact price can vary within a defined range. It establishes the lower boundary of that pricing rule and is normally paired with priceCurrency and, when appropriate, maxPrice.

Primary definition: Schema.org minPrice. The lower boundary should match the price range a buyer can verify on the page.

The property is useful when one price specification covers a configurable service, measured job, negotiated package, or another offer whose final amount depends on valid choices. It should not be used merely to advertise the cheapest unrelated product on a category page.

1. Frame the decision raised by What Is minPrice Schema.
2. Read the primary property definition and expected value type.
3. Compare markup with the visible price and commercial terms.
4. Correct the source catalog or template without inventing a value.
5. Validate the rendered page and recheck it after pricing changes.

• Use it only for a genuine bounded pricing rule.
• Keep the currency explicit.
• Show the same minimum and qualifying conditions visibly.

The definition is a boundary, not a promotion: minPrice is the lowest valid amount within one structured price specification.

minPrice works by defining the floor of a PriceSpecification while other properties describe currency, upper boundary, eligibility, validity, quantity, and billing terms. Together, those fields explain what price range applies and under which conditions.

A design service may range from $500 to $2,000 depending on scope. minPrice can identify $500 as the valid lower boundary, maxPrice can identify $2,000 as the upper boundary, and visible page copy must explain what changes the final amount.

• Evidence for How Does minPrice Work in PriceSpecification must come from the exact page and pricing context.
• Locate the Offer or PriceSpecification node that contains the property.
• Confirm the currency, price boundaries, tax treatment and eligibility context that apply.
• Compare rendered structured data with catalog, checkout and visible page terms.
• Retain a fresh validation result and the URL where the value was observed.

1. Define one coherent commercial price rule.
2. Identify its lowest attainable amount.
3. Add an upper boundary only when one exists.
4. Connect eligibility and validity conditions.

See PriceSpecification Schema for the parent entity.

The graph needs the whole rule: minPrice is meaningful only when its currency, scope, and conditions identify a real attainable price.

Use minPrice when one offer or price specification genuinely permits multiple valid amounts and a reliable lower boundary is visible to buyers. Common examples include configurable services, usage-dependent packages, rentals, project estimates, variable-size products, and plans with bounded customization.

Do not use it when the page has one fixed price, when the advertised “starting at” amount is unavailable, or when the number merely represents the cheapest item across unrelated offers. Those cases require a fixed price, separate offers, or an aggregate model.

1. Frame the decision raised by When Should You Use minPrice.
2. Read the primary property definition and expected value type.
3. Compare markup with the visible price and commercial terms.
4. Correct the source catalog or template without inventing a value.
5. Validate the rendered page and recheck it after pricing changes.

• Confirm a customer can actually qualify for the minimum.
• Explain the variables that move the price upward.
• Avoid combining unrelated products into one price specification.

Use minPrice for bounded variability: the lower amount must belong to the same offer and be realistically attainable.

minPrice defines the lower boundary inside a PriceSpecification, while lowPrice reports the lowest offer price summarized by an AggregateOffer. They can contain the same number in some situations, but they describe different entities and search intents.

A configurable consulting offer priced from $500 to $2,000 can use minPrice and maxPrice in one price specification. A marketplace page summarizing 12 seller offers from $480 to $2,100 can use lowPrice and highPrice in AggregateOffer.

• Evidence for minPrice vs lowPrice: What Is the Difference must come from the exact page and pricing context.
• Locate the Offer or PriceSpecification node that contains the property.
• Confirm the currency, price boundaries, tax treatment and eligibility context that apply.
• Compare rendered structured data with catalog, checkout and visible page terms.
• Retain a fresh validation result and the URL where the value was observed.

1. Ask whether the page describes one variable price or many offers.
2. Use minPrice for the former.
3. Use lowPrice for a truthful aggregate of the latter.
4. Never add both simply to increase property coverage.

Review AggregateOffer Schema before marking up product collections or marketplaces.

The parent entity decides the property: minPrice belongs to a pricing rule; lowPrice belongs to an offer aggregate.

Add minPrice as a numeric monetary value inside the relevant PriceSpecification, pair it with priceCurrency, and include maxPrice when the range has a genuine upper boundary. Keep the structured values synchronized with the visible offer and pricing calculator.

{
  "@context": "https://schema.org",
  "@type": "Offer",
  "priceSpecification": {
    "@type": "PriceSpecification",
    "minPrice": "500.00",
    "maxPrice": "2000.00",
    "priceCurrency": "USD"
  }
}

• Evidence for How Do You Add minPrice in JSON-LD must come from the exact page and pricing context.
• Locate the Offer or PriceSpecification node that contains the property.
• Confirm the currency, price boundaries, tax treatment and eligibility context that apply.
• Compare rendered structured data with catalog, checkout and visible page terms.
• Retain a fresh validation result and the URL where the value was observed.

1. Frame the decision raised by How Do You Add minPrice in JSON-LD.
2. Read the primary property definition and expected value type.
3. Compare markup with the visible price and commercial terms.
4. Correct the source catalog or template without inventing a value.
5. Validate the rendered page and recheck it after pricing changes.

Inspect the deployed object with Novaverb Site Audit rather than validating only a copied snippet.

The implementation should be generated from pricing truth: one data source should feed the page, calculator, checkout, and JSON-LD.

Prove minPrice is attainable by identifying a valid configuration, quantity, date, customer type, and location that produces the stated amount without hidden mandatory charges. A theoretical or expired price is not an honest lower boundary.

Record the inputs needed to reproduce the minimum. If every customer must buy onboarding, pay a platform fee, or select a larger quantity, those mandatory amounts belong in the commercial interpretation and may invalidate a lower headline.

1. Frame the decision raised by How Do You Prove the Minimum Price Is Attainable.
2. Read the primary property definition and expected value type.
3. Compare markup with the visible price and commercial terms.
4. Correct the source catalog or template without inventing a value.
5. Validate the rendered page and recheck it after pricing changes.

• Run the exact minimum configuration through checkout.
• Capture the resulting subtotal and mandatory fees.
• Remove or update the range when availability changes.
• Do not rely on an old promotional price.

“Starting at” is a testable claim: one real buyer path must reach the marked-up minimum under disclosed conditions.

minPrice should be modeled separately for each regional offer when currency, tax treatment, included services, or attainable minimum differs. Never convert one global floor mechanically while the actual product configuration or mandatory fees change by market.

A US price of $500 and a UK price of £500 are not interchangeable merely because both display 500. Each needs its own currency, regional terms, visible page context, and validation path.

• Evidence for How Should minPrice Handle Currency and Regional Offers must come from the exact page and pricing context.
• Locate the Offer or PriceSpecification node that contains the property.
• Confirm the currency, price boundaries, tax treatment and eligibility context that apply.
• Compare rendered structured data with catalog, checkout and visible page terms.
• Retain a fresh validation result and the URL where the value was observed.

1. Select the canonical market for the page.
2. Read the price floor from that market’s catalog.
3. Include the matching priceCurrency.
4. Test taxes and mandatory charges.
5. Prevent alternate-market markup from contradicting visible content.

For currency rules, read priceCurrency in Product Schema.

A minimum is market-specific: currency and regional terms must describe the same attainable transaction.

Validate minPrice by checking syntax, entity placement, range ordering, currency, visible qualifiers, attainable configuration, checkout total, and regional consistency. A parser can approve the number while the commercial claim remains impossible.

1. Frame the decision raised by How Do You Validate minPrice Markup.
2. Read the primary property definition and expected value type.
3. Compare markup with the visible price and commercial terms.
4. Correct the source catalog or template without inventing a value.
5. Validate the rendered page and recheck it after pricing changes.

• Test the cheapest valid configuration.
• Test one common mid-range configuration.
• Test the maximum when one is declared.
• Re-crawl after pricing, fee, product, or promotion changes.

Connect price evidence with the full Novaverb SEO tools system.

Check the rendered page with the free website SEO checker, keep recurring evidence in Site Audit, and compare ongoing Novaverb plans when manual review no longer scales.

Validation ends with reproducibility: the range is correct only when real purchase paths produce its stated boundaries.