The short answer
During a sale, a Google feed can retain 100.00 USD as the regular price while its sale_price and the page’s structured Offer.price show the current product amount of 80.00 USD. Those values have different roles. Compare the active product price for the same item, seller, market, customer tier, currency, quantity, and capture context; preserve missing facts instead of choosing the lowest number.
A 100 regular price and an 80 active price can agree
In Google Merchant Center, an active sale uses sale_price while price retains the original base amount. Google Search structured data has a different representation: Offer.price can carry the current active amount, with the higher original amount separately marked StrikethroughPrice. Comparing every field named price directly would therefore produce a false mismatch.
The fictional example below is one public US offer for DEMO-MUG-BLUE sold by Example Retailer. It is quantity one, in USD, with an active promotion and captures within the same short window. The comparison covers the merchandise amount; shipping, tax, and the final order total remain outside it.
| Surface | Fictional values | Role in the comparison |
|---|---|---|
| Google feed | price 100.00 USD; sale_price 80.00 USD | Regular amount 100; active product amount 80 |
| Selected product page | Current USD 80.00; original USD 100.00 | Current product amount 80 |
| Checkout line, quantity one | Merchandise subtotal USD 80.00 | Product amount 80; full order total not established |
| Structured Offer | price 80.00; priceCurrency USD; StrikethroughPrice 100.00 | Active product amount 80; original amount separate |
Source: Google Merchant Center: Sale price [sale_price]; Google Search: Merchant listing structured data — pricing
Read the price role before normalizing the number
This illustrative JSON fragment shows the active and original structured amounts from the control case. It is not complete merchant-listing markup or a provider-tested payload. Link the Offer to the selected Product before using its amount; a different item’s price does not become evidence merely because it appears on the same page.
Google documents that a top-level Offer.price takes precedence over a nested specification when both encode an active price. Our manual review still records contradictory active values as a conflict. A documented precedence rule and a coherent source record answer different questions.
{
"@context": "https://schema.org",
"@type": "Product",
"sku": "DEMO-MUG-BLUE",
"offers": {
"@type": "Offer",
"price": "80.00",
"priceCurrency": "USD",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"price": "100.00",
"priceCurrency": "USD",
"priceType": "https://schema.org/StrikethroughPrice"
}
}
}Source: Google Search: Merchant listing structured data — pricing
Declare the offer context on every capture
For ordinary product offers in the scope of this guide, Google requires amount and currency to agree between submitted data, the landing page, and checkout. Member pricing has separate rules. Schema.org separates price from priceCurrency; a dollar symbol alone is ambiguous. Preserve the raw text, explicit currency evidence, and your interpretation together.
The context checklist is an original evidence method. Record it on each surface rather than assuming that one page’s market, seller, or customer session applies to the others. This guide does not resolve subscriptions, minimum advertised pricing, installments, regional-pricing programs, currency conversion, or tax and fee allocation.
| Context | Evidence to retain |
|---|---|
| Exact item | Selected variant ID and submitted URL |
| Seller and market | Seller identity and the offer’s target market |
| Customer tier | Public, trade, or member session; do not infer it from the amount |
| Currency and quantity | Explicit currency code and purchasable unit count |
| Price basis | Merchandise amount versus shipping, tax, and full order total |
| Time and source | Capture time with timezone, saved evidence reference, and promotion-state evidence |
Source: Google Merchant Center: Price [price]; Schema.org: price; Schema.org: priceCurrency
A planned sale end is not a fresh observation
Captures made before and after a promotion changes can both accurately describe their own times. Retain each timestamp and obtain a new capture when you need a current comparison. Specify a suitable capture span and observation age before interpreting the result. A newer file-creation time alone does not establish newer underlying facts.
The fictional cases use a maximum ten-minute span between surface captures as an illustrative review convention. It is not a Google deadline or a guarantee that all facts remain unchanged for ten minutes. Case P8 crosses a sale transition and exceeds that span; its old feed observation cannot establish the current feed amount.
In the worksheet, null preserves an unresolved value. A null sale amount means confirmed no active sale only when accompanying evidence states that explicitly. It must not turn an unknown promotion into a regular-price conclusion. A saved evidence reference is a locator, not proof that a source is authorized.
Eight fictional cases expose different failure reasons
Download the authored observations and their expected editorial conclusions. All products, sellers, URLs, timestamps, and captures are fictional. The set is an answer key for manual review, not an executed validator result, a catalog sample, or a provider acceptance test.
Aligned means the supplied evidence agrees within this bounded context. Conflict means comparable observations contradict one another. Hold means the necessary currency, customer context, or concurrent evidence is unresolved. These are local editorial decisions; they do not predict a destination’s acceptance or display.
| Case | Evidence distinction | Expected local conclusion |
|---|---|---|
| P1 · Valid sale | Regular feed 100; active amount 80 on all four surfaces | Aligned |
| P2 · Stale markup | Offer.price 100 while other active amounts are 80 | Conflict |
| P3 · Different currency | Page CAD 80; target and other records USD 80 | Hold currency context |
| P4 · Missing currency | Page $80 without explicit currency evidence | Hold missing fact |
| P5 · Member session | Public feed versus member page and checkout | Hold customer context |
| P6 · Two active values | Offer.price 80; nested active specification 75 | Conflict despite documented Google precedence |
| P7 · Confirmed sale end | Fresh no-sale evidence and all active amounts 100 | Aligned |
| P8 · Different times | Feed captured during sale; page captured after it | Hold current comparison |
Keep evidence and decisions in a reusable review record
The blank JSON worksheet gives each surface its own raw observation, interpretation, context, capture time, and evidence reference. It also separates a reviewer’s decision from any later provider outcome. Copy it into your own review process; retain original captures beside it and replace missing fields only with supported facts.
These two downloads are manual reference formats. No new runner, interactive checker, API, upload, or automatic price repair is supplied. The case file is an authored answer key; the worksheet begins not_reviewed and leaves provider results unobserved. It is not an input to the existing product-record or freshness tools.
- Declare the exact item and price context first.
- Label regular, active, member, and total-order prices separately.
- Retain both values when comparable evidence contradicts.
- Request fresh evidence when captures straddle a transition.
- Record the reviewer, reason, next action, and any later provider evidence separately.
Use agreement to narrow the next decision
An aligned review supports the stated product-price comparison at the supplied time. It leaves stock, imagery, identity authenticity, fulfillment, required destination fields, full checkout total, and future changes outside that conclusion. Resolve an explicit conflict with the source owner; resolve a hold by obtaining the named missing evidence.
Use the review record to pass a precise discrepancy to its owner: the surface, price role, offer context, observation time, and unresolved evidence. Keep the proposed correction separate from any later provider receipt or observed result.
Sources & scope
Primary references checked for this edition. The notes below distinguish source-backed facts from the frameworks and examples proposed in this guide.
- Google Merchant Center: Price [price] ↗
Supports product amount/currency consistency with landing page and checkout, and separate member-price handling. Product-specific exceptions and full-order tax/fee reconciliation are outside this guide.
Checked October 17, 2026 - Google Merchant Center: Sale price [sale_price] ↗
Supports retaining the original base price and using sale_price for the current sale amount. No sale annotation or provider acceptance is promised.
Checked October 17, 2026 - Google Search: Merchant listing structured data — pricing ↗
Supports active Offer.price, separately marked StrikethroughPrice, member-price distinctions, and top-level active-price precedence. The worksheet decisions remain original editorial proposals.
Checked October 17, 2026 - Schema.org: price ↗
Supports the price role, decimal-point representation, and separate explicit currency rather than ambiguous symbols. Schema vocabulary alone does not establish Google eligibility.
Checked October 17, 2026 - Schema.org: priceCurrency ↗
Defines currency for an offer or price component. The fictional currency-conflict case does not perform conversion.
Checked October 17, 2026
AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.
Editorial policy & corrections ↗Cite this guide
George Kelly. Why feed price and Offer.price can differ without an error iamgeorgekelly. Updated October 17, 2026. https://www.iamgeorgekelly.com/field-guide/offer-price-reconciliation
Keep the source notes and example labels with an excerpt. For a provider requirement, follow the original documentation in Sources & scope.