Is it true that Google only takes one price per product: how can you ensure it’s the right one?

Why does Google only take one price when the page displays several?

Mueller's statement confirms a long-observed behavior in the field: Google deliberately simplifies price display in search results. This logic arises from constraints related to space and readability in rich snippets.

Specifically, if your product listing offers multiple prices (retail price, member price, bulk pricing), Google will only retain one for display. The engine cannot show a complex price range in a standardized product snippet.

How does Google choose which price to display among multiple options?

Mueller remains intentionally vague about the selection criteria. In practice, Google generally favors the first price encountered in the Schema.org markup, but this is not an absolute rule.

Some tests show that the engine may favor the lowest price, especially if multiple offers are distinctly marked. Other observations suggest that the order of appearance in the DOM matters more than the numerical value. This ambiguity poses problems for sites with sophisticated pricing logic.

What role does the structured data testing tool play in this context?

The Google tool allows you to preview exactly which price will be extracted from your markup. It is the only reliable way to check that Google will interpret your markup correctly before going live.

This validation becomes essential when you handle multiple price properties: price, lowPrice, highPrice, or multiple Offers. Failing to test systematically exposes you to inconsistencies between the displayed price in the SERPs and that on the landing page, which deteriorates conversion rates.

• Google displays one price per product in rich results, regardless of the number of prices present on the page.
• The exact selection criterion is not officially documented: position in the DOM, lowest value, or the first price encountered depending on the case.
• The structured data testing tool is the only reliable method to verify which price Google will actually retain.
• This limitation particularly affects sites with price variations (subscription vs. one-time purchase, member pricing, bulk discounts).
• A gap between SERP price and landing page price significantly deteriorates conversion performance.

Is this statement consistent with field observations?

Yes, but it simplifies a more complex reality. Tests show that behavior varies according to the type of Schema.org used. A Product with several Offers does not react like an AggregateOffer with lowPrice and highPrice.

Marketplace sites that aggregate offers from various sellers notice that Google sometimes displays the lowest price, and sometimes that of the primary seller. This inconsistency suggests that the selection algorithm remains contextual and non-deterministic. [To verify]: no official documentation details the exact prioritization logic.

What nuances should be added to this general rule?

Mueller says "generally" one price, which leaves room for interpretation. In specific contexts, Google may display a price range: this is common for Product Knowledge Graph results or certain event-related rich snippets.

The AggregateOffer structure with lowPrice and highPrice can sometimes produce a display of "from X €" in the SERPs, especially for products with many variations (sizes, colors). However, this is not systematic, and Google remains in control of the final display, regardless of your markup.

In which cases does this limitation pose critical business problems?

B2B sites with complex pricing grids are particularly impacted. Displaying a pre-tax price in the SERP when the customer expects VAT-inclusive creates immediate friction. Likewise, showing a full price when a promotion is active undermines the urgency factor.

SaaS platforms with multiple subscription tiers face the same issue: which price to highlight, the starter plan or the business plan? Google forces a simplification that does not always reflect the business strategy. If your differentiation relies on pricing flexibility, this constraint becomes a competitive disadvantage in the SERPs.

How can you control which price Google will display in the SERPs?

The only reliable variable is the order of appearance in your Schema.org markup. Place the price you want to see displayed first: it is the one Google will retain in most cases. This empirical rule works better than a minimum or maximum price logic.

If you offer a temporary promotional price, make sure it appears before the crossed-out price in your markup. Conversely, if you target a premium clientele, only markup the non-discounted price to prevent Google from displaying the lowest price by default.

What technical mistakes should be absolutely avoided?

Do not multiply Offer tags without a strategic reason. Each additional Offer increases uncertainty about the displayed price. A single Offer object with a single price ensures maximum predictability.

Another common pitfall is using AggregateOffer when a simple Offer suffices. Google interprets AggregateOffer as a signal of multiple variants and may choose to display "from" rather than a fixed price. Reserve AggregateOffer for genuinely relevant cases (products with significant pricing variations).

What verification routine should be implemented to avoid inconsistencies?

Integrate the structured data testing tool into your pre-production validation workflow. Every product template change must go through a manual check of the price extracted by Google. This is tedious but essential for sites with dynamic catalogs.

For large catalogs, automate monitoring with a script that parses the JSON-LD of your pages and compares the price marked up with the price actually displayed. A delta greater than 1% should trigger an alert. Desynchronizations often appear after ERP updates or poorly propagated promotional campaigns in the markup.

• Always verify with the Google tool which price is extracted from the markup before going live.
• Place the priority price first in the order of the Schema.org markup.
• Limit to a single Offer object with a single price when there is only one unique price.
• Reserve AggregateOffer for products with true pricing variants (sizes, volumes, subscriptions).
• Monthly monitor the consistency between SERP price and landing page price on a sample of strategic products.
• Document in a register the price prioritization rules to avoid inconsistencies during team handovers.