The short answer
If customers need a quote, your website's structured data should describe that reality. Do not enter zero as an unknown price or invent reviews to satisfy a test. Product descriptions and eligibility for a particular search enhancement are separate questions. Accurate information is more valuable than a validation badge based on false facts.
A missing public price is not a price of zero
Your catalogue presents configurable products. The final price depends on dimensions, materials or installation, so the page asks customers to request a quote. Then a testing tool complains that the product data is incomplete.
Someone suggests entering a placeholder price to make the warning disappear. That shortcut changes the meaning of the offer. A customer who sees a free or fixed-price product has been given a different promise from the one your business can honour.
An unknown price is not a free product
Zero is a number with a clear meaning. It does not stand for 'ask us', 'depends on specification' or 'not yet entered'. If the business cannot offer the product at that price, publishing it in machine-readable data creates a false description even when the visible page says something else.
Start with the real buying process. Explain what affects the quote and what information the customer should provide. That can improve the enquiry experience while preserving the distinction between a configurable product and a directly purchasable offer.
A worked example
Suppose a supplier sells made-to-measure panels, with prices calculated after dimensions and finish are confirmed.
Where it goes wrong
Publish a zero-price offer so a product test becomes green, while the page still asks visitors to request a quote.
What to do instead
Describe the actual product and quote process, include only supported structured data and document which search features are currently applicable.
The website communicates one consistent offer to people and machines. The test result no longer depends on claiming that a custom product is free.
A search feature has its own entry conditions
Structured data can describe a product without making it eligible for every Google display. Product snippets and merchant listings have different requirements. A tool's warning may mean the page does not qualify for a feature, rather than that the business must change its pricing model.
For product snippets, Google's documented routes include qualifying offer, review or aggregate-rating information. Those alternatives are not permission to manufacture a review when there is no published offer. Use only applicable, genuine information and check the current requirements for the feature being proposed.
Make the visible page the basis of the data
Ask the implementer to show where each important product fact appears to a visitor. The name, specification, availability and any reviews should describe the same product consistently. A technically valid object can still be misleading if it contains stale or unsupported facts.
Treat an unavailable enhancement as a clear outcome. It is better to explain that the current offer does not meet a feature's requirements than to report a successful test with invented data. Revisit eligibility when the underlying commercial information changes.
Take this into your next conversation
Questions to ask your agency
- Which search feature are we trying to qualify for?
- Where is each product fact visible on the page?
- Does any placeholder change the meaning of the offer?
- What should the customer provide to receive a useful quote?
Common questions
Can 'price on request' be used as a numeric price?
No. It describes a buying process, not a number. The implementation should follow the applicable data format without inventing an amount.
Does missing a rich result mean the page is useless for search?
No. Rich-result eligibility is a specific enhancement question. Clear product information, useful navigation and an understandable enquiry process still matter.
Source notes
Platform guidance behind this topic:
From explanation to implementation
This guide is published by NAVIFLARE, a website, CRM and AI workflow practice. Source notes identify the platform guidance; worked examples explain a method rather than claim a client result.
Explore website design and developmentYour next step
Bring a product page and the facts your team actually knows before preparing a quote. We can discuss how the catalogue and its data should represent that offer consistently.
Discuss your catalogue
