What Is PriceCurrency in Product Schema?

PriceCurrency is the three-letter ISO 4217 code that identifies the currency of a price inside an Offer, AggregateOffer, or PriceSpecification.

Primary definitions: Schema.org priceCurrency. Product-search requirements vary by experience; the Google product structured-data documentation distinguishes those requirements.

The property turns an ambiguous number into a commercial amount. A price of 49.99 cannot be interpreted reliably without knowing whether it is USD, CAD, AUD, EUR or another currency. The value should travel with the exact price it describes and match what the customer sees and can pay.

1. Frame the decision raised by What Is PriceCurrency in Product 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 an uppercase three-letter ISO 4217 code.
• Keep the numeric amount free of currency symbols.
• Place currency beside the price it qualifies.

Use the free backlink checker while reviewing linked commerce pages.

PriceCurrency makes a product price meaningful by attaching one unambiguous currency code to the same commercial node.

PriceCurrency matters because it prevents pricing ambiguity and helps keep the page, structured data, feeds, shipping costs, checkout, and market targeting aligned.

It does not produce rankings by itself or guarantee a rich appearance. Its business value is truthfulness. The dollar symbol is shared by multiple currencies, and a converted price can differ materially from the catalog base amount. Missing or conflicting currency creates a stronger error than a formatting issue because the same number represents a different value.

• Evidence for Why Does PriceCurrency Matter for Ecommerce SEO 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 the market and customer-facing currency.
2. Compare page, Offer, feed and checkout.
3. Trace the code to a governed pricing source.
4. Repair the mapping at source.
5. Verify a real localized session.

Currency therefore belongs in every price-quality audit, especially for US sites that also serve Canada or Australia.

Reliable currency data protects click intent by ensuring the price promise means the same thing throughout the purchase journey.

Use the active ISO 4217 alphabetic code for the currency customers are shown and charged, such as USD, CAD, AUD, EUR, or GBP.

Do not use symbols, country codes, locale codes or informal abbreviations. “US,” “en-US,” and “$” answer different questions and cannot replace USD. Zero-decimal or multi-decimal currency behavior also belongs in price formatting and payment logic; the three-letter code itself remains the same.

1. Frame the decision raised by Which ISO 4217 Currency Code Should You Use.
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.

• Maintain a controlled list of supported currencies.
• Reject unknown codes during imports.
• Separate market, language and currency fields.
• Review retired or changed currencies when expanding markets.

The correct code comes from the transaction context, not from the user's browser language alone.

Use one current ISO 4217 alphabetic code and never substitute a symbol, country, or locale identifier.

PriceCurrency belongs on the same Offer or PriceSpecification node as its price, or on AggregateOffer beside lowPrice and highPrice.

Scope is the central rule. A Product can have several Offers in different currencies, so a currency placed at the Product root cannot describe them accurately. When the active price is nested in UnitPriceSpecification, its currency should be nested there as well. Avoid publishing a second conflicting active price at Offer level.

• Evidence for Where Should PriceCurrency Appear 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. Map the Product.
2. Identify each Offer and pricing node.
3. Pair the amount and code at one level.
4. Remove duplicate conflicting active prices.
5. Validate the rendered graph.

A simple example is "price":49.99,"priceCurrency":"USD" within the same Offer.

Currency must remain beside its amount so every pricing node can be interpreted independently and correctly.

Multi-currency pages should expose the currency and price actually rendered for the current market or URL, with separate Offers when several currencies are simultaneously represented.

A currency switcher changes more than a symbol when conversion is real. The amount, currency, taxes, shipping rules, rounding and sometimes seller can change. If a localized URL has a stable USD price, its structured Offer should use that exact USD amount. If one URL varies solely by cookies or geolocation, crawl consistency and caching require additional care.

1. Frame the decision raised by How Should Multi-Currency Product Pages Be Marked Up.
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.

• Choose a deterministic default currency.
• Align canonical and localized URL behavior.
• Do not infer currency only from IP.
• Test cached pages from multiple markets.

Currency architecture should be designed with internationalization, checkout and canonicalization together rather than patched inside JSON-LD.

Multi-currency markup is trustworthy when each rendered market context produces a stable, matching Offer.

Converted structured prices should use the same exchange rate, rounding policy, taxes and effective time as the customer-facing price and checkout.

Do not convert only the JSON-LD amount or reuse a stale daily rate while the page uses a live commerce price. Currency conversion is a pricing decision, not a display transformation. Psychological rounding, minimum margins and tax-inclusive markets may produce amounts that cannot be reconstructed from a raw rate alone.

• Evidence for How Should Currency Conversion and Rounding 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. Read the final commerce price, not a raw catalog base.
2. Store currency with the calculated amount.
3. Apply governed rounding.
4. Generate page and markup from one result.
5. Test checkout without completing a purchase.

See priceValidUntil for time-bounded converted promotions.

Converted currency data is correct only when the exact payable amount and structured price share one calculation.

Shipping charges and monetary return costs should use currencies compatible with the Offer's market and must not silently introduce a different currency into the same purchase context.

A USD product price paired with an unlabeled or CAD shipping rate makes the total ambiguous. Shipping rules can vary by destination, but the monetary component still needs an explicit code. Refund fees, restocking amounts and thresholds deserve the same treatment when represented as structured monetary values.

1. Frame the decision raised by How Should PriceCurrency Work With Shipping and Returns.
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.

• Join shipping rules to the correct market Offer.
• Keep thresholds and fees in the same currency context.
• Do not copy USD shipping amounts to every locale.
• Retest after logistics or tax configuration changes.

Review OfferShippingDetails schema and Merchant Return Policy schema for the surrounding models.

Every monetary component in an Offer should preserve a coherent market currency from product price through delivery and returns.

Common mistakes include using symbols instead of codes, labeling CAD or AUD prices as USD, separating currency from its amount, and allowing localized pages, feeds, shipping, or checkout to disagree.

Another frequent error is formatting the numeric price with commas or a currency symbol inside the price field. Human display formatting belongs in page copy, while structured values should keep a machine-readable number and separate ISO code. Defaulting every page to USD can conceal a failed localization pipeline.

• Evidence for What PriceCurrency Schema Mistakes Are Common 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. Extract amount and currency as a pair.
2. Trace both to the commerce source.
3. Fix market and formatting mappings.
4. Regenerate affected Offers.
5. Verify localized pages and checkout.

Syntax validation cannot determine whether a USD code describes a price actually charged in CAD.

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.

Currency errors require market-aware source corrections, not isolated text replacements in JSON-LD.