Structured data can make your pricing explicit and machine-readable, and it can establish eligibility for supported Google Search features. It does not guarantee rich results, retrieval, citation, inclusion in an AI answer, or a correctly quoted price. Visible, crawlable, current and internally consistent pricing remains the foundation - and while the research on why is thinner than it is usually presented as, the available findings are mixed but support the same cautious operational conclusion. This page sets those boundaries and routes to the five implementation and measurement guides that work through each part in detail. A sixth page, reporting CoreAEX's own study, is added when that study is complete.
That is a narrower claim than most writing on this topic makes, and it is narrower than what a pricing page's owner usually wants to hear. It is also close to what Google now says in its own documentation, which is a recent development worth reading before deciding how much to invest.
Two labels mark evidence boundaries on this page. Documented means the guidance that follows is directly supported by published Schema.org or Google documentation, quoted. Recommendation means a modelling choice, threshold or workflow that CoreAEX prescribes and the documentation does not. Statements from platform staff in interviews, forums or podcasts are attributed in the prose rather than tagged - they are first-party, but they are not documentation. Untagged text is ordinary explanation or a conclusion following from something already labelled.
What Structured Data Establishes, in Google's Own Words
Google's guidance on generative AI search, last updated July 10, 2026, addresses this directly under a heading about what you don't need to do. In a bullet titled "Overfocusing on structured data" it states: Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add.
The same bullet continues: However, it's a good idea to continue using it as part of your overall SEO strategy, as it helps with being eligible for rich results on Google Search.
Documented
Google's separate page on AI features, last updated December 10, 2025, says the same thing in different words - There's also no special schema.org structured data that you need to add
- and sets out what eligibility for those features actually rests on: Google's AI features guidance states a page must be indexed and eligible to be shown in Google Search with a snippet
, and that There are no additional technical requirements
. Documented
Read only that far and the conclusion looks like "don't bother." The same page does not support that reading. Among the SEO fundamentals it says remain worthwhile for AI features, Google lists Ensuring structured data matches the visible text on the page
.
Those two statements have to travel together, and neither survives being quoted alone. "No special markup is needed" is not "markup is pointless." "Parity with visible text matters" is not "schema helps AI visibility" - it is a consistency requirement on markup you have already chosen to publish, and it appears alongside an explicit statement that the markup is not required in the first place. Anyone quoting one half of this pair is building an argument the source does not make.
What markup does establish is eligibility for a named feature, which is a smaller and more precise thing than it sounds. Eligibility means your markup meets the documented requirements for one specific Google Search feature. It does not mean the feature will be displayed for any query, and it is not permanent. FAQ rich results were supported for years; FAQ is no longer listed in Google's structured data gallery as of its June 15, 2026 update, while Product and Software app both still are. A feature you are eligible for today is a feature Google can withdraw, and the vocabulary outlives the feature: FAQPage, Question and Answer remain core Schema.org terms in the current release. A discontinued Google feature and a withdrawn Schema.org type are different events, and the distinction between them runs through everything below.
"Does Schema Help?" Is Six Questions
Most disagreement about pricing schema is people answering different questions with the same word. Six distinct things get compressed into "does it work," and they have different answers, different evidence and different ways of being measured:
- Schema validity - does the markup parse and use the vocabulary correctly?
- Google eligibility - does it meet the documented requirements for a named, currently supported feature?
- Rich-result appearance - is an enhanced result actually displayed for a query someone ran?
- Retrieval - did a system access the page while generating an answer?
- Citation - did the page appear as a linked source in that answer?
- Price accuracy - does the amount, currency, unit, billing period and commitment in the answer match what the page currently says?
A page can pass every one of these and fail the next. Perfectly valid markup can be eligible for nothing. Eligibility does not produce appearance. Retrieval is not citation. And a system can cite your page while quoting a price you stopped charging eight months ago - the citation is correct and the answer is wrong, which is the failure mode a pricing page owner actually cares about and the one that shows up in none of the usual reporting.
Keeping these apart is not pedantry, it is the only way to tell what a study measured or what a tool is telling you. The full definitions, the metrics that track each one, and the places where standard reporting quietly substitutes one for another are set out in measuring pricing schema and AI visibility.
What the Research on Schema and AI Citation Found
Four studies from four organisations have looked at whether structured data affects how AI systems treat a page. Their findings are mixed, and they are not four measurements of one thing. Two found no general citation effect, one of those also reporting a positive association for a subgroup; one controlled preprint found modest improvement from JSON-LD in a constructed retrieval setting; and one single-page practitioner test failed to extract a price that existed only in markup. Three of the four were published by companies selling AI-visibility or schema products and the fourth is a practitioner test, so they are vendor and practitioner findings rather than independent confirmation, they measure different outcomes, and their numbers should never be pooled. What they share is a cautious conclusion, not a common result.
The largest matched sample found no meaningful citation increase. Ahrefs studied 1,885 pages that added JSON-LD between August 2025 and March 2026, matched against roughly 4,000 control URLs with similar pre-period citation levels, comparing 30 days before with 30 days after. Measuring citations - linked source appearances - across Google AI Overviews, AI Mode and ChatGPT, it found AI Overviews down 4.6% (statistically significant), with AI Mode at +2.4% and ChatGPT at +2.2%, both statistically indistinguishable from zero.
Two things must travel with that result. The authors describe the AI Overviews decline as real but unexplained, and it should not be reported as schema harming citations. And the sample was drawn from pages already heavily cited - 100+ AI Overview citations in a single month - so it says nothing about a page with no AI visibility to begin with. The same study reported, descriptively, that AI-cited pages were almost three times more likely to contain JSON-LD than non-cited pages, and its authors read that as a site-quality confound rather than a schema effect. This is vendor research, and it is the largest matched sample located on the question.
A second vendor study found the same null, with one exception. Marshal examined 730 AI citations across 75 commercial queries and 1,006 unique pages on ChatGPT and Gemini, published February 2026 as a working paper that has not been peer-reviewed. Schema markup on its own showed no effect (OR 0.678, p = .296). What dominated was Google rank position: OR 0.762 per position, p < .001. Pages ranking first were cited in 43% of the queries in which they appeared - not of all queries in the study - against 5% for pages ranking seventh.
The exception in that study is the finding most often left out, and it cuts against the tidy conclusion: attribute-rich Product and Review schema carrying concrete fields was associated with a 61.7% citation rate against 41.6% for generic schema types (p = .012). The authors describe that advantage as most pronounced among lower-authority domains, at DR 60 or below. Treat it as observational and exploratory. It is single-source - no independent replication was located - and it comes from the same study that found schema in general null. It qualifies "structured data does not guarantee citation." It does not overturn it, and a page that states the boundary without stating this exception is presenting a cleaner picture than the evidence supports.
Two sources looked at the mechanism instead, and what they isolate is narrower than it is usually reported as. Rather than asking whether schema correlates with citation, both asked which layer of a page a system actually reads a fact from.
The one formal, multi-domain controlled experiment reviewed is Volpini, Raad, Gamba and Riccitelli, submitted to arXiv on March 11, 2026, testing document representations across four domains on Vertex AI Vector Search and Google's Agent Development Kit. The practitioner test described below also varied its conditions deliberately, on a much smaller scale and on the live web; the two are not equivalent and are kept separate here. Its result, in the authors' own words: while JSON-LD markup alone provides only modest improvements, our enhanced entity page format, incorporating llms.txt-style agent instructions, breadcrumbs, and neural search capabilities, achieves substantial gains: +29.6% accuracy improvement for standard RAG and +29.8% for the full agentic pipeline.
The first half of that sentence is the part relevant here, and it is the part that isolates a single variable. The second half does not: the enhanced condition changes several things at once - agent instructions, breadcrumbs, neural search, entity interlinking - so it cannot be read as showing what happens when the same data is simply made visible to a reader. It is a preprint, it has not been peer-reviewed, it ran on a constructed corpus rather than the live web, and the authors sell schema markup. What it supports is that JSON-LD markup on its own produced only modest improvement in this setting, and nothing narrower about visible text.
The layer question itself was tested directly, once, on one page. A practitioner test by searchVIU, run October 30, 2025 and published December 2, 2025, built a single page carrying eight product variants, each with its price placed deliberately in a different layer - visible HTML, JavaScript-rendered, Microdata hidden and visible, RDFa hidden and visible, and one case with deliberately conflicting values. In the third case, a price of €8.99 existed exclusively in the JSON-LD. Across ChatGPT, Claude, Gemini, Perplexity and Google AI Mode, none of the five returned it. The author separates direct-fetch systems from index-based ones and retested the latter after indexing. The stated limitation travels with the result: this is one page, tested on one date, and it says nothing about what a system may have taken from indexing or training.
Neither source establishes that AI systems ignore structured data, and the pull towards reading them that way is strong enough to name. One preprint on a constructed corpus and one page tested on one date are a thin basis for a general claim about retrieval. What they jointly support is narrower and still worth acting on: where a commercial fact exists only in markup, current evidence does not establish that it will be extracted reliably. searchVIU tested one such price directly and none of the five systems returned it; the preprint found modest improvement from JSON-LD in a constructed retrieval setting, which is not the same as reliable extraction of pricing facts from the live web. That is the reasoning behind leading with visible pricing - and on the layer question specifically it rests on one test of one price, which is why CoreAEX is running its own.
Choosing the Type
Before any of the AI questions, there is a modelling question with a defensible answer: what is this page about, and which Schema.org type describes it? Most published advice answers this with a template, and the templates disagree because the vocabulary is less tidy than it looks.
Two facts settle more arguments than anything else. SoftwareApplication is not a subtype of Product - it descends from CreativeWork - and Service is not one either, sitting under Intangible. Yet Schema.org's own definition text for Product explicitly covers services, and three of its five examples are non-physical. The definition and the class hierarchy disagree, and a page that resolves that silently is hiding the thing the reader needs to know. Separately, AggregateOffer is defined for a single item associated with multiple offers. Schema.org illustrates that with the same pair of shoes offered by different merchants, but multiple sellers are an example in the definition rather than a formal requirement, so a tiered SaaS table can be vocabulary-valid as an AggregateOffer range. Separate Offer nodes are usually the better model anyway, because they preserve each plan's name, URL, price and terms instead of collapsing them into a low and a high.
The choice also has a consequence most people meet too late. Google's three pricing-adjacent features have different and partly incompatible requirements, and the Software app rich result requires a rating or a review in addition to name and price. A SaaS pricing page with accurate price markup and no ratings is not eligible for it, and the honest response to that is to accept the ineligibility rather than to manufacture reviews. Documented
The full hierarchy, the decision matrix across the three features, and the minimal graph patterns are in choosing schema for SaaS pricing.
Modelling the Commercial Terms
SaaS pricing is rarely one number. Monthly against annual, per-seat minimums, usage allowances and overage, trials that are not free plans, discounts with validity dates, several currencies, tax treatment. Schema.org can express a good deal of this, and that is where the trap is.
Several of the properties that express it - billingDuration, billingStart, and the enumeration behind priceType - are marked "new" in the current published vocabulary (version 30.0). Schema.org's own framing for that status is lighter than "pending" implies: implementation feedback and adoption from applications and websites can help improve our definitions.
More importantly, no Google documentation was located stating that Google consumes billingDuration, billingIncrement, billingStart or CompoundPriceSpecification. That absence is unknown, not irrelevant: we searched Google's structured data documentation and located no statement either way, which is a different finding from a demonstration that these fields do nothing.
One correction worth carrying, because it is easy to get backwards: billingDuration specifies how long a price is billed for, not how often payment recurs. Contract length and payment cadence are different facts, and payment frequency has no clearly documented property. It belongs in visible copy. Recommendation
Semantic expressiveness is not documented consumption, and the commercial terms have to survive in visible content regardless. The property-by-property treatment is in modelling subscription and usage pricing.
Getting It Live and Keeping It True
Markup that was correct at launch and is wrong now is worse than none, because it is confidently wrong at scale. The durable fix is structural: generate the visible pricing and the structured data from one authoritative pricing model, so that a price change cannot update one and leave the other. Recommendation
Delivery has a documented wrinkle specific to pricing. Google states that Google Search can understand and process structured data that's available in the DOM when it renders the page
, and in the same breath: Using Product markup? Be aware that dynamically-generated markup can make Shopping crawls less frequent and less reliable, which can be an issue for fast-changing content like product availability and price.
That caveat is scoped to Shopping crawls and it is conditional. It is not a statement about AI crawlers, and it is not a general claim about Google Search. Documented
Testing is four separate checks that prove four different things: does the markup parse and use the vocabulary correctly, does it meet a named feature's documented requirements, does the rendered page actually contain what you think it contains, and does the markup match what a reader sees. A tool that answers one of these is silent on the other three - and validators check syntax and field presence, not whether the markup tells the truth about the page. The placement, delivery, parity and release-QA detail is in implementing and validating pricing schema.
When an AI Answer Gets Your Price Wrong
The common reaction is to add or fix schema. That is a guess, and it is usually the wrong first move.
A missing or incorrect price in a generated answer is not automatically a markup failure. The useful question is which layer the current commercial fact first stops being available at: whether it is absent from the page, present but inaccessible, contradicted somewhere else on the site, stale in a cache or an index, ambiguous between plans or currencies, or transformed somewhere between the page and the answer. Those failure modes can involve markup, visible content, access, indexing, caching or answer generation, and more than one can be true at once. Diagnose the first layer at which the current fact becomes unavailable or contradictory before deciding that schema is the cause. The layered diagnosis is in troubleshooting wrong or missing AI prices.
Measuring Any of This Honestly
Most reporting on this topic silently substitutes one of the six questions above for another, and the substitution is usually in the flattering direction. Two examples that recur.
Search Console's rich result reports cover detection and validity - whether Google found your markup and whether it passes - not whether an enhanced result was ever shown to anyone. Reading them as appearance evidence is the same eligibility-for-display conflation this page opened with, in tool form.
And Search Console's Generative AI performance report, on partial rollout, covers AI Overviews and AI Mode together by page, country, device and date, reporting impressions only: no clicks, no click-through rate, no position and no queries. Clicks from AI features are folded into the "Web" search type with no AI value in the Search appearance dimension. It is genuinely useful and it is not what "track your AI performance in Search Console" implies. Documented
The metric definitions this cluster uses, the data sources that can and cannot answer each question, and how to classify a before-and-after change without overclaiming causation are in measuring pricing schema and AI visibility.
What CoreAEX Is Measuring
Everything above is documentation and other people's research. The gap it leaves is specific: no credible study, dataset or documented incident was located giving a figure for how often AI answers state SaaS prices incorrectly. We looked for one. That space is currently occupied by vendors selling a remedy, and the honest position is that the number does not yet exist.
CoreAEX is running the study to produce it. The question is narrow on purpose: for a defined sample of SaaS pricing pages and a published prompt set, what do named AI systems reproduce about price, currency, billing period, unit, commitment and trial status; how often is what they reproduce correct against the page on the same date; and which sources do they cite? Schema presence is recorded as a characteristic of each page, not as a treatment applied to it - an observational study cannot support the claim that markup caused an answer, and this one will not make it.
A separate, smaller controlled component runs alongside it on pages CoreAEX controls and can leave unchanged for the length of an observation window. Its purpose is to address the weakness in the evidence described above: existing sources cannot separate what a system read from visible text from what it read from markup, because on a normal pricing page the price is in both. Until that is separated, every extraction result - including ours - carries an unknown source layer, and we will label it that way.
The prompts, the sample, the coding rules, the dates and the limitations publish with the results. If the data does not support a clean conclusion, the page will say the evidence is mixed, or platform-specific, or insufficient. Recommendation
What This Cluster Does Not Claim
Six boundaries, stated plainly, because each one is routinely crossed in writing on this topic.
We do not claim structured data improves AI citation. The two largest studies located both found no meaningful general effect, with one exception in one of them, and that exception is single-source.
We do not claim it does nothing. The Marshal finding on attribute-rich Product and Review schema in lower-authority domains is a real result in a real study, and "not demonstrated in general" is not "demonstrated to be useless."
We do not claim to know what non-Google systems do with schema. We reviewed OpenAI's crawler documentation, publisher FAQ and Agentic Commerce feed specification, and Perplexity's and Anthropic's bot and robots.txt documentation, and located no first-party statement on schema.org consumption in any of them. OpenAI's one page documenting structured pricing input describes Structured metadata from first-party and third-party providers (e.g., price, product description)
- provider feeds, not on-page markup, and its feed specification excludes JSON and XML. Absence of located documentation is not evidence of no effect.
We do not claim Bing documents nothing. Microsoft's webmaster guidance and structured data help pages are JavaScript-gated and could not be read in this pass. Bing has supported schema.org historically. The widely circulated line that Microsoft has confirmed schema helps its language models traces to a conference remark relayed by a third party, roughly eighteen months old, with no locatable first-person quote. That is a remark, not documentation, and we treat it as unverified rather than absent.
We do not treat statements from platform staff as documentation. Forum posts, podcast answers and conference remarks from people who work at search companies are first-party and often illuminating, and they are not published guidance. Where this cluster uses one, it names the person and the venue in the prose and does not label it as documented.
We do not promise a timeline. Google publishes latency figures for its render queue, for noticing changes, for requested indexing, for crawl requests and for Search Console validation, and they have five different denominators and should never be merged. For rich-result appearance specifically, Google publishes no timeline at all, and neither do we.
Not sure how much of this applies to your pricing page?
Most SaaS pricing pages have one or two real problems and a long list of imaginary ones. Working out which is which is a short conversation. Book a Session.
Sources
Sources: Google's position on structured data and generative AI is from Optimizing for generative AI (last updated July 10, 2026) and AI features and your website (last updated December 10, 2025). Feature requirements, eligibility and delivery are from Google Search Central: General structured data guidelines (last updated July 10, 2026), Search gallery (last updated June 15, 2026), Software app structured data (last updated December 10, 2025), Product snippet (last updated December 10, 2025), Merchant listing (reviewed August 29, 2026; a specific last-updated date could not be independently confirmed for this page) and JavaScript-generated structured data (last updated December 10, 2025). Vocabulary definitions and class hierarchies are from Schema.org, verified against published release version 30.0 (released March 19, 2026). Research on schema and AI citation: Ahrefs, "Does schema markup help AI citations?" (Linehan and Guan, published May 11, 2026 - vendor research, matched difference-in-differences, 1,885 pages, metric is citations); Marshal, "Does schema markup predict AI citation?" (Fischman, February 12, 2026 - vendor working paper, not peer-reviewed, 730 citations across 75 commercial queries, ChatGPT and Gemini); Volpini, Raad, Gamba and Riccitelli, "Structured Linked Data as a Memory Layer for Agent-Orchestrated Retrieval" (arXiv preprint submitted March 11, 2026 - not peer-reviewed, constructed corpus, authors sell schema markup); and searchVIU, "Schema Markup and AI in 2025" (Michael, published December 2, 2025, tests run October 30, 2025 - practitioner test, one page, five systems). Three of those four were published by companies selling AI-visibility or schema products and the fourth is a single-page test; they are heterogeneous vendor and practitioner findings rather than independent confirmation; they measure different outcomes, and their figures are not pooled anywhere on this page. Google's documentation is revised frequently - three of the pages above were updated during 2026 - so last-updated dates are given individually rather than as a single review date.
About the author
Zarko Zivkovic is the founder of CoreAEX, building technical SEO, AEO, and AI-visibility systems for B2B SaaS companies. Connect on LinkedIn.