Blog · Content that gets cited
Pricing pages and what AI says your product costs

The short answer: An engine quotes your price from whichever copy of it it can read, and in the sites we audit there are commonly four: the text on your pricing page, the structured data under it, any product feed you push to a platform, and someone else's article from two years ago. If those four disagree, you do not control which one gets quoted. The fix is dull. Make one price readable as plain text, make every other copy agree with it, and date it.
Nobody sets out to publish four prices. It happens because each copy is owned by a different team and updated on a different day.
The four places your price lives
Start with the page itself. If the tier card renders from JavaScript after a pricing API call, a client that reads only the server's HTML sees an empty box where the number should be. Google documents exactly this for Googlebot in its merchant price mismatch help page: data passed dynamically with JavaScript after load triggers an error, and prices in the HTML have to match what you submitted. For other engines' fetchers we have no equivalent documentation, so we cannot tell you which of them execute JavaScript and which do not.
Second is the markup. Structured data carries a number that no human reads, which is exactly why it rots. In audits we have opened pages where the visible card said one thing and the JSON-LD underneath still carried last year's figure. We have not counted how often that happens across any defined sample, so treat it as a thing worth checking rather than a rate.
Third is any feed. The two shopping surfaces that publish a specification, OpenAI's commerce product feed and Google Merchant Center, both take price from a file you submit and then check it against your page. Surfaces that publish no specification may work differently, and we have no way to see which do.
Fourth, and least controlled, is everyone else: a roundup post, a review listing, a forum thread, a slide from a conference. Nothing obliges that copy to update, and most of it does not.
The vacuum behind "contact sales"
Hiding the number does not stop an engine answering the question. It changes who can be cited. If no page of yours states a number, the only candidates left are the third parties that do: a procurement blog, a review site profile, a thread quoting a quote. Ask an assistant what your product costs and watch where the citations land.
It is a failure we hit often in audits, and it is not a markup problem. It is an absence problem. From outside, the retrieval step is not visible to us, only the citations an answer prints, so we describe this as what is available to be quoted rather than as what the model did. What review sites, G2 and what AI repeats about your product covers applies with extra force here, because price is the field reviewers are most likely to record once and never revisit.
You do not have to publish a rate card to fix this. A sentence that says what the pricing model is, what drives the number, and the floor of the range gives retrieval something of yours to grab. "Seat-based, annual contract, implementations start in the low five figures" is a citable fact. Silence is not.
What the markup can say, and what it cannot
An Offer carrying only price and priceCurrency cannot say per seat per year, so a reader of that markup has no way to know the unit. The vocabulary for the unit already exists. Schema.org's UnitPriceSpecification definition, read on 12 October 2026, carries billingDuration, billingIncrement, referenceQuantity and priceType, which is how you say 29 USD per user per month with a twelve month commitment rather than just 29.
Two details repay attention, both from Google Search Central's merchant listing page, read on 12 October 2026. It states that merchant listing experiences require a price greater than zero, so a free tier marked up as an offer at 0 does not qualify. It also states that a listing may not display when priceValidUntil indicates a past date. Note the word may: Google describes a risk, not a certainty, and we have not tested the threshold ourselves. The deeper treatment of the vocabulary sits in product schema for AI shopping answers.
Markup cannot rescue a page whose text does not state the price. Treat the markup as insurance that the number survives parsing, and the prose as the thing an engine has a passage to quote from. Do both. That is the argument in what makes a page citable by an AI engine, applied to the one field buyers check first.
Feeds beat pages, so the feed has to be right
OpenAI's published product feed specification, read on 12 October 2026, is worth reading even if you do not sell physical goods, because it shows what a price field looks like when a platform depends on it. The spec asks for the amount in major units, a space, then an uppercase three letter ISO 4217 code, as in 79.99 USD. A sale price has to be greater than zero, strictly below the regular price, and in the same currency, or the row is rejected. It tells you to submit at the currency's precision rather than round. Dates attached to a sale window are accepted as metadata and do not schedule the sale, so the current price has to be current in the file.
Google enforces the same idea from the other direction. Its merchant price mismatch help page describes Googlebot crawling landing pages and comparing the submitted price against the price on the page or in the markup, and it names JavaScript-loaded prices as a cause of mismatch errors. Read that as a free test rig for one engine's fetcher. When Merchant Center disapproves an item for a price mismatch, it has told you that Googlebot reading your page sees a different number than you do. It says nothing about what any other engine sees.
A twenty minute check
Fetch your pricing page the way a machine does, with JavaScript off, and look for the number in the raw HTML.
`` curl -sL example.com/pricing | grep -oE '[$₹€£][0-9,]+' | sort -u ``
If nothing comes back, the number is not in the document and nothing downstream can read it. Then pull the JSON-LD from the same response and compare it against what the card shows. Then search for your product name with the word pricing and read the top handful of third party pages, noting the figure each one states. Finally, ask three engines what your product costs, twice each, a few hours apart. Record the number, the unit, and the source cited.
Four lists, one comparison. In our audits this check usually turns up at least one stale number the team did not know about, most often in markup or in a partner directory. That is what we keep running into, not a measured rate, and a handful of prompts on one afternoon is a sample rather than a census. The self-check has the rest of the drill. If the question you care about is what buyers see when they compare you against an alternative, the mechanics are different and sit in comparison pages that get cited.
Add a date, and keep the old URL
Two habits make pricing hold up over time.
Put a visible last updated line next to the price, and repeat it in dateModified. We have not found published documentation from the engines we test on how a tie between two conflicting figures gets broken, and we cannot observe it from outside. What a date does is make the newer copy identifiable to whatever reads the page, and it costs you one line.
Do not move the page. A URL that has been linked and cited for years carries that history and a new one starts empty. Google's own merchant help notes that crawling is limited by your server's capacity, so a redirect is not reflected the moment you ship it, and we have no visibility into re-crawl timing at other engines. Keep the URL and change the contents.
Honest limits
We cannot tell you how long a corrected price takes to propagate, and we have no clean model of why a fix lands quickly in one engine and sits uncorrected in another. The frequency claims in this post, that four copies is the common count and that a check like this usually surfaces a stale number, come from audits we have run rather than from a counted sample, so a careful reader should read them as what we keep meeting and not as rates. Everything here about what an engine does internally is inference from citations we can see, because retrieval itself is not observable from outside. The two platform rules we quote, OpenAI's feed specification and Google's merchant listing requirements, are documented behaviour for those two surfaces only, and we have no documentation for how other assistants treat a price field. We also have no reliable way to measure how often an assistant states a price without citing anything, because when there is no citation there is no thread to pull.
FAQ
Should we publish prices if we sell enterprise deals? Publish the model and a floor, not necessarily a rate card. Something of yours is then available to quote. Full silence hands the question to third parties who recorded a number once.
Does an engine prefer the markup price or the visible price? It varies by surface, and that is the point. The two platforms with published specs take the submitted feed and check it against the page. For retrieval over ordinary web pages we have no documentation to point at, and we cannot see which copy was used. Keeping all of them identical removes the question.
Our price is correct everywhere and the answer is still wrong. Why? Likely an older copy outside your control, or a model answering from memory rather than retrieval. Check whether the engine cited anything. An uncited price leaves you nothing to trace, and from outside you cannot tell whether retrieval ran and found nothing or did not run at all.
Is a pricing FAQ worth adding? Yes, when it answers the real questions: what is billed, per what, with what minimum. A question and answer pair maps closely onto how the prompt was phrased.
Sources
All four sources were opened and checked on 12 October 2026.
- Schema.org, UnitPriceSpecification type definition, billingDuration, billingIncrement, referenceQuantity, priceType: schema.org/UnitPriceSpecification
- OpenAI, product feed specification, price format, sale price rules and sale date metadata: developers.openai.com/commerce/specs/feed
- Google Search Central, merchant listing structured data, price greater than zero and priceValidUntil: developers.google.com/search/docs/appearance/structured-data/merchant-listing
- Google Merchant Center Help, mismatched product price, page crawling and JavaScript-loaded prices: support.google.com/merchants/answer/12159029