What Is priceComponent Schema?

priceComponent is the Schema.org property that links the PriceSpecification nodes applying in parallel inside a CompoundPriceSpecification. It is used to connect the separate price dimensions that jointly define one compound pricing structure.

Primary definition: Schema.org priceComponent. The property connects the PriceSpecification parts that apply in parallel within a CompoundPriceSpecification.

A component is not automatically an optional add-on or an alternative plan. In this context, linked components apply together: a platform fee plus a per-user rate, a nightly charge plus final cleaning, or a fixed utility charge plus measured consumption. If customers choose one price instead of another, those values generally should not be bundled as parallel components.

Use priceComponent only when the page makes each linked part understandable and the billing system can calculate them together. Missing component names, units, or conditions can make a valid graph commercially meaningless. A simple total remains better when no useful breakdown exists.

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

• Link only components that apply together.
• Make every component independently understandable.
• Keep alternatives outside the parallel bundle.

Primary specification: Schema.org definition for priceComponent.

priceComponent should connect the real parts of one combined billing equation, not every price visible on the page.

Schema.org lists priceComponent on CompoundPriceSpecification, and the property expects a PriceSpecification value. The parent organizes the combined price; each linked node carries one applicable price part.

Do not place priceComponent directly on Product, Service, or a generic page node. Connect the CompoundPriceSpecification to the applicable Offer through priceSpecification, then connect its parts through priceComponent. This preserves the path from item to transaction to combined equation to individual rates.

Review the CompoundPriceSpecification guide for the parent model and the PriceSpecification guide for component fields. A graph should remain scoped to one seller, plan, region, and item whenever those conditions affect pricing.

• Evidence for Where Can priceComponent Be Used 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. Resolve the item and Offer.
2. Attach the compound pricing node.
3. Link each applicable component from that parent.

Correct placement keeps priceComponent inside the compound structure belonging to one coherent Offer.

Components apply in combination, while alternative prices represent choices or mutually exclusive commercial terms. A base fee and usage rate can be components; monthly versus annual plans, basic versus premium plans, or two competing sellers are usually alternatives.

This distinction controls what customers appear to pay. Bundling monthly and annual prices as components implies both charges apply. Splitting a mandatory setup fee into another Offer can imply it is optional. Begin with the checkout equation and determine which amounts are summed or otherwise combined for the same transaction.

Conditions can create apparent alternatives within one plan. A component may apply only above a threshold or during a validity period, but its conditional role must be explicit. Do not link mutually exclusive promotional and regular amounts simultaneously unless the graph clearly preserves their separate price types and applicability.

1. Frame the decision raised by How Are Components Different From Alternative Prices.
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.

• Start from the actual billing equation.
• Separate choice from simultaneous application.
• Retain conditions and cadence for every part.

If customers choose between amounts, they are alternatives; if the same transaction uses them together, they can be components.

Give every linked PriceSpecification a name that identifies its pricing dimension, such as “Platform fee,” “Active user,” “Electricity usage,” or “Final cleaning.” The name should match visible language and be specific enough to distinguish components.

Schema.org explicitly notes using the attached unit price specification’s name to indicate the dimension. Labels such as “Fee,” “Charge 1,” or internal billing codes do not help customers or auditors. Avoid exposing internal SKU names, provider identifiers, or operational notes that are not part of the customer experience.

Use stable names across the source, page, and graph so changes are traceable. If a component changes meaning, create or update the appropriate commercial record instead of retaining the old label with a new calculation. Localization may change displayed wording, but component identity should remain stable underneath.

• Evidence for How Should Component Names Be Written 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. Name the customer-visible dimension.
2. Match terminology across page and billing.
3. Preserve a stable internal component ID.

A component name should let a customer understand what is priced without decoding an internal billing system.

Add a clean price amount and matching priceCurrency to each component. For US-dollar pricing, use USD when that is the actual transaction currency; keep dollar signs, commas, and descriptive labels outside the machine-readable amount.

Follow the price schema guide. A visible “$1,250 setup fee” can serialize as price “1250” and priceCurrency “USD.” Use decimal-safe arithmetic and never turn an unknown component into zero. Zero means the exact component is free.

Components should normally participate in one coherent transaction currency. If the source presents mixed currencies, verify whether they truly settle together and how conversion occurs. Do not silently convert only one component or pair a converted amount with a stale currency code.

1. Frame the decision raised by How Should Amounts and Currencies Be Added.
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.

• Separate amount from symbols.
• Keep component currencies coherent.
• Distinguish zero from unknown.

Every price component needs a precise amount and currency that match its visible and billable role.

Use the applicable UnitPriceSpecification context to state the unit, reference quantity, billing duration, and eligibility governing a component. A rate is incomplete when customers cannot tell whether it is per month, per seat, per gigabyte, per night, or one-time.

Read the UnitPriceSpecification guide before modeling measured rates. A monthly base fee and per-user monthly fee share a cadence but use different consumption dimensions. A setup fee may apply once and must not inherit the recurring cadence from sibling components.

Test rounding, minimums, maximums, free allowances, prorating, and zero usage. A pricing calculator may count active users at month-end while marketing copy says licensed seats. Structured terms should follow the billing rule customers actually encounter, not an approximate label.

• Evidence for How Do Units, Quantities, and Cadence Work 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. Identify each measured dimension.
2. Add its exact unit and cadence.
3. Test quantity and time boundaries.

Component pricing becomes actionable only when units, quantities, and cadence reproduce the billing calculation.

Create the Offer and CompoundPriceSpecification, then add each parallel PriceSpecification through priceComponent with a meaningful name, verified amount, currency, unit, validity, and eligibility. Generate every node from the same billing source as checkout.

Keep stable Offer, compound, and component identifiers. The source should own names, rates, units, cadence, thresholds, and effective dates. Templates should omit unsupported parts rather than defaulting null amounts to zero or copying the parent total into each child.

{
 "@context":"https://schema.org",
 "@type":"CompoundPriceSpecification",
 "priceComponent":[
  {"@type":"UnitPriceSpecification","name":"Platform fee","price":"49.00","priceCurrency":"USD","unitText":"MONTH"},
  {"@type":"UnitPriceSpecification","name":"Active user","price":"8.00","priceCurrency":"USD","unitText":"USER PER MONTH"}
 ]
}

• Evidence for How Do You Mark Up priceComponent 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. Resolve the compound pricing parent.
2. Serialize every applicable component.
3. Recalculate real transaction examples.

priceComponent markup is complete only when the graph reproduces the visible and billable pricing equation.

Common errors include bundling alternative plans, omitting names or units, copying one total into every component, applying recurring cadence to one-time fees, linking parts from another Offer, and leaving stale rates or conditions in cached markup.

Array-based implementations can create duplicates when a component is appended on every render. Client-side calculators may also change the selected plan while JSON-LD continues to describe the default. A syntactically valid set of nodes can therefore represent a calculation no customer can purchase.

Test minimum, typical, and maximum quantities; zero usage; setup periods; renewals; discounts; plan changes; currency switches; expired rates; and cache invalidation. Compare the same component IDs across source, page, checkout, and crawl evidence.

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

• Validate the equation, not just JSON syntax.
• Preserve component IDs and relationships.
• Re-crawl after every pricing change.

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.

Prevent component errors by proving that each linked part participates exactly once in the real billing equation.