Author
A product-price review method for B2B sellers: check that a visible price identifies the same approved offer as its data, map the commercial conditions that belong beside it, and keep quote-only requests separate from active offers. The article treats the cited merchant-listing specification and the cited search documentation within their own scope, and it does not promise crawling, indexing, citation or ranking outcomes.
The object of this review is a seller’s product offer, not the purchase of a marketing service. Before a price goes live, the question is narrow: can a buyer tell which approved product, at which charging unit, in which currency, the displayed figure describes? If the answer is no, the page is not ready, regardless of how polished the surrounding copy looks.
The cited merchant-listing specification gives the technical anchor. It defines the price property as the current, active offer price of a product, and it requires a price greater than zero for merchant listing experiences. That definition matters here because it ties the number to an active offer rather than to a historical, indicative or aspirational figure.
Currency is part of the same identity, not a cosmetic suffix. The same specification describes the currency property as the currency used to describe the product price, in three-letter ISO 4217 format. A price without a resolvable currency is an incomplete statement of the offer, and a currency that disagrees with the visible page is a mismatch waiting to confuse a buyer.
Our proposed pass condition is deliberately concrete: a buyer can identify which approved product and which charging unit the displayed price describes, and the currency shown on the page matches the currency recorded for that offer. Our proposed fail condition is equally concrete: the product, unit or currency cannot be established from approved commercial records, or the visible figure and the recorded offer disagree.
This is a commercial-fact check first and a technical check second. A team that starts by editing markup before confirming which offer is approved will simply encode an unresolved commercial question. Confirm the offer, then look at how it is represented.
The official specification behind these definitions is the merchant listing documentation published by the cited search service, available at the official merchant listing structured data page. Read it as a specification for merchant listings, not as a rule that every quote-only B2B or service page must publish a numeric price.
A price on its own rarely answers a buyer’s question. The conditions that belong beside it are the ones that determine whether two figures are comparable at all. The table below is a proposed field map for that review; the verification column is intentionally left as a state to be filled from approved records, not as an observation about any seller.
| Proposed field | What it records | Verification state |
|---|---|---|
| Product or service identity | The approved name and identifier of the item being priced | To be confirmed against approved records |
| Charging unit | What one unit of the price covers (for example per item, per package or per engagement) | To be confirmed |
| Currency | The currency the figure is expressed in | To be confirmed |
| Inclusions | What the price covers | To be confirmed |
| Exclusions | What the price does not cover | To be confirmed |
| Validity | The period or conditions under which the figure holds | To be confirmed |
| Responsible owner | The person accountable for the commercial accuracy of the entry | To be confirmed |
The currency row is not optional bookkeeping. Because the cited specification treats currency as the descriptor of the product price, a page that shows a figure without a resolvable currency leaves the offer under-specified for a reader comparing options.
The active-price requirement shapes how the validity row should be read. If the specification expects the current, active offer price, then a figure whose validity cannot be confirmed is not simply old — it is unverified against the definition the page is trying to satisfy.
We recommend that the owner column name a person or role rather than a department, because the review only works if someone can say yes or no to a specific entry. That is an editorial recommendation about how to run the check, not a requirement drawn from the cited specification.
Two pages can display the same number and still describe different offers. The difference usually sits in the unit and in what the figure includes. A per-item price and a per-package price are not comparable even when the digits match, and a figure that excludes delivery, setup or tax is not the same offer as one that includes them.
The review method is to check the unit and the included and excluded scope against the seller’s own approved commercial records, not against a competitor’s page and not against an assumption about how the category usually works. Where the records are silent, the correct state is unconfirmed.
Currency belongs in this comparison for the same reason. The cited specification describes currency as the descriptor of the product price, so a figure whose currency is ambiguous cannot be reliably compared with a figure whose currency is stated.
Questions such as whether tax is included, whether shipping is charged separately, or whether a minimum order applies are questions to verify with the responsible commercial owner. They are not universal legal requirements, and this review does not assert that any particular treatment is mandatory. A page that states its own treatment clearly is more useful than one that leaves the buyer to guess.
The practical test is whether a buyer reading only the price block could form a wrong expectation about what they receive for the figure. If the unit is implicit, the inclusions are unstated, or the exclusions are buried elsewhere, the price block is doing less work than it appears to.
A request for a price is not an offer. When a seller cannot or does not publish an active figure, the page should say so plainly and collect what is needed to produce a quote, rather than presenting an indicative number as if it were the active offer price.
The proposed field map for a quote request is short: the product identity, the requested unit or configuration, any destination or delivery condition that affects the figure, and a seller-confirmed quote state. The last field is the important one. Until the seller has confirmed a figure, the state is unconfirmed, and the page should not display a number as though it were confirmed.
The distinction matters because the cited specification defines the price property as the current, active offer price of a product. A quote-only inquiry has no active offer price to encode, and the honest response is to leave the price unstated rather than to fabricate a figure or reuse an unrelated one.
We recommend treating the quote state as a small set of named states — unset, requested, seller-confirmed — and showing the buyer which state applies. This is a proposed control, not a universal mandatory field, and it does not imply that any particular platform requires it.
This section is about a seller’s product quote request. It is not about selecting an agency or comparing proposals for a marketing engagement; those are different decisions with different evidence.
Once the offer is approved, the remaining question is whether the page and its structured data describe the same thing. The cited search documentation recommends making sure that structured data matches the visible text on the page. That guidance is about consistency for the cited search service; it is not a mechanism that produces an AI citation.
Mismatches tend to enter at a few predictable points. A template may carry a default currency while the page body shows another. A price may be updated in the visible copy but not in the data, or the reverse. A unit may be stated in a heading and omitted from the data. Each of these is a consistency question that can be checked against the approved offer record.
Our recommended order is source facts first, then technical consistency. Confirm the approved product, unit and currency; then compare the visible page and the data against that record. Starting from the markup risks treating a stale value as the reference.
It is worth being explicit about what this check does not establish. Consistency between page and data is a quality condition, not a guarantee of any search or AI outcome. The cited search documentation states that meeting requirements, best practices and policies does not mean the cited search service will crawl, index or serve the content.
Related reading: AI-Search-Ready Website Redesign: Facts, Pages, and Acceptance
Not every offer is ready to display a price, and the page needs a defined state for that. We propose three display states: an active approved offer with a confirmed price, unit and currency; a quote-only inquiry with no stated active price; and a price or condition that is expired or conflicting and awaiting revalidation.
The rule that matters most is the third state. When the matching product, unit or currency cannot be established, the page should not publish an inherited active price. An old figure carried forward because nobody removed it is worse than no figure, because it presents an unverified number as a current offer.
Keep the display state separate from the state of the product itself. A product can be available while its published price is awaiting revalidation, and a product can be discontinued while its page still needs a clear message. The display state describes what the page is allowed to show, not what the business is doing.
Even a well-run release process should not be read as a visibility promise. The cited search documentation is explicit that meeting requirements does not guarantee crawling, indexing or serving. A correct price block is a commercial-fact condition; it is not evidence of how any search or AI system will treat the page.
For teams that want the publishing layer to support this kind of review, SHMLANG publishes a CMS-ready website publishing service that builds a structure future SEO and GEO work can compound on rather than restart. Where the question is how approved facts, useful pages and source research fit together, SHMLANG’s GEO service scope connects question baselines, approved business facts, useful pages and source research. Both are published service scopes; neither is a claim about a client result.
If you want to see how the publishing structure is described, the SHMLANG website systems page sets out the page system and CMS-ready structure. If the question is how approved facts and source research are organised, the SHMLANG GEO visibility page describes that scope.
Related reading: What to Fix First for GEO and AI Search Visibility on a B2B Website
No comments yet. Be the first!