Why SaaS Prices Go Missing or Stale in Search and AI Answers

A price that is missing, wrong or out of date in a search result or a generated answer is not automatically a schema problem, and treating it as one can waste the first day of the investigation. The commercial fact you care about passes through six layers between your billing system and someone reading an answer, and it can be lost, contradicted, hidden, cached or transformed at any of them. Diagnosis means finding the first layer where the current fact stops being present and correct - because every layer downstream of that one will show the same symptom for a reason that is not its fault.

Two labels mark evidence boundaries on this page. Documented means the guidance that follows is directly supported by published Google or Schema.org documentation, quoted. Recommendation means a diagnostic sequence, threshold or corrective action that CoreAEX prescribes and the documentation does not. Diagnostic pages are unusually easy to read as authoritative, so the distinction matters here: an untagged step below is our procedure, not a platform rule. Untagged text is ordinary explanation or a conclusion following from something already labelled.

Start by Naming the Symptom

Six different problems get reported as "our pricing isn't showing up right." They have different causes and different first checks, so the investigation starts by picking one.

"Wrong" and "incomplete" are worth separating carefully, because the fix is different and the two are operationally distinct on SaaS pricing pages. "$79 per month" is wrong if the plan is $89. It is incomplete - but not wrong - if the plan is $79 per user per month with a five-seat minimum, and the answer omitted the unit and the minimum. The first is a data fault. The second usually traces back to a page that states the conditions in a footnote. Recommendation

What Each Test Can and Cannot Prove

Before running anything, it is worth being clear about what a result would license you to conclude. Diagnostic dead ends on this topic tend to come from a test that proved something narrower than the investigator thought.

No single test on this page proves that a machine can read your pricing. That is not a limitation of the tooling so much as a property of the question: readability is a claim about a system you cannot inspect. The tests above narrow where a fault is; none of them certifies a success. Recommendation

Layer 1: The Source Data

Start here, always, and be willing to find that the investigation ends here. The question is narrow: is the price you are complaining about actually wrong, or is it the price your system currently holds?

Check the authoritative pricing model, not the page. Then check when it last changed, who changed it, and whether the change propagated to everything downstream that holds a copy - the CMS, the billing system, any exports or feeds, any regional price lists. If the pricing model and the visible page already disagree, every layer below is reporting faithfully and the investigation is over.

Two source-layer faults are worth checking early in reported "AI is showing the wrong price" cases, and both are found here rather than anywhere technical. A price changed in one system and not another. Or a promotional price expired in the billing system while the page kept displaying it. Recommendation

Layer 2: The Visible Page

The question at this layer is whether the current commercial fact is present, complete and unambiguous in what a reader sees.

Check the amount, the currency, the unit, the billing cadence, the commitment, any minimum quantity, and whether promotional terms carry an end date. Then check the states: what does the page show before anyone touches the toggle, and is any material term visible only in one toggle position?

Google's requirement here is a content rule rather than a markup one: Don't mark up content that is not visible to readers of the page, and for anything time-limited, Provide up-to-date information. We won't show a rich result for time-sensitive content that is no longer relevant. Documented

This layer is where "incomplete price" symptoms can resolve. If the seat minimum is in a footnote, the annual commitment is in a tooltip and the currency is implied by a flag icon, then a reader - human or otherwise - working from the visible page will produce an answer that omits them. That is not a retrieval failure. It is the page.

Layer 3: Structured Data and Feeds

Only now does markup enter the investigation, and it enters as two separate questions: does the markup say the same thing as the page, and does any feed say something different again?

Parity first. Compare the JSON-LD to the visible page and to the source of truth. This is the check no validator performs, and it catches the characteristic markup-layer fault: markup that was correct when written and has not tracked a price change since.

Then validity, then eligibility, in that order - and read each result for what it establishes. Malformed JSON is reported by Search Console's unparsable structured data report, which lists structured data found on your site that could not be parsed because of a serious syntax error. Valid markup that lacks a feature's required properties is an eligibility fault, not a syntax one. Both are real; neither explains an absence from a generated answer.

Feeds are a separate source of truth that can contradict the page, and Google documents a specific consequence. Merchant Center compares them: Googlebot routinely crawls your website landing pages and compares the price attribute in your data source with the prices on your landing page or in your structured data markup (if implemented), and Prices reflected in the HTML need to match exactly the prices uploaded in Merchant Center. Where they disagree, the product with the mismatch may be disapproved. Documented

Keep that scoped. It is Merchant Center feed documentation governing Shopping ads and free product listings. It documents a mechanism by which a page/feed price disagreement removes an item from those surfaces. It says nothing about organic Search results and nothing about generated answers.

Layer 4: Delivery and Rendering

The question here is whether what your server returns to Google is what you think it returns.

Separate the JavaScript failures rather than treating them as one. "It's a rendering problem" is a conclusion, not a diagnosis, and at least six distinct faults hide behind it: the script did not load; it loaded but threw; it ran but the pricing API call failed; it ran but the component was in a state that renders no price; the response was cached in a state that predates the price change; or the price is genuinely there and something else is wrong. Each has a different fix, and the render result alone does not distinguish them. Recommendation

Google's own rendering behaviour is documented and worth checking against. It processes structured data that's available in the DOM when it renders the page, and rendering is queued: The page may stay on this queue for a few seconds, but it can take longer than that. If the same pricing also reaches Merchant Center, that path has a stricter rule - Structured data markup must be present in the HTML returned from the web server. The structured data markup can't be generated with JavaScript after the page has loaded. Documented

Caching is where stale prices hide, and Google documents the mechanism without naming the failure. Google supports conditional requests: Based on that value, the server may choose to return a 304 (Not Modified) HTTP status code with no response body, in which case Google will reuse the content version it crawled the last time. A server or CDN that answers 304 for a page whose price has in fact changed will therefore keep Google on the old content. Documented

That last inference is ours, and worth flagging as such: Google documents the 304 behaviour, and separately documents nothing at all about CDNs, caching layers or bot-protection services serving stale or different content. We located no Google documentation connecting cache configuration to incorrect prices in results. The mechanism is documented; the failure mode is our reading of it.

Also check access. If a firewall or bot-protection layer is involved, Google's network-error guidance is direct: Look at your firewall settings and logs. There may be an overly-broad blocking rule set. Make sure that Google IP addresses are not blocked by any firewall rule.

Layer 5: Indexing and Retrieval

The question here is whether the current version of the page can be found at all, and whether Google is treating your pricing URL as the page it serves.

Three documented blockers and one documented selection process, each covered below.

Access first. Google's merchant listing guidance states the requirement plainly: Be sure that your page is accessible to Google and not blocked by a robots.txt file, the noindex tag, or login requirements. Three separate blockers, each with a distinct signature.

A robots.txt block has a counter-intuitive consequence worth knowing before you diagnose one. Google is explicit that robots.txt is not a mechanism for keeping a web page out of Google - a disallowed URL can still be indexed if linked to from other sites, and in that case its URL can still appear in search results, but the search result won't have a description. So a blocked pricing page can be present in Search and contain no price, which reads exactly like a markup failure and is not one.

The related trap: blocking a page you also want de-indexed. If the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results.

Then canonicalisation. If Google has clustered your pricing page with another URL and picked the other one, Search serves that other page - which is a complete explanation for a pricing page whose content never appears. Google describes the process as choosing the page that, based on the factors (or signals) the indexing process collected, is objectively the most complete and useful for search users, and is unambiguous about your degree of control: indicating a canonical preference is a hint, not a rule.

This matters for the multi-currency pattern specifically. Google's canonicalisation guidance covers regional variants in the same language and recommends using canonicalisation and hreflang together for them. It says nothing about pages that differ in price or currency. A US and a UK pricing page in English, differing only in the numbers, is a plausible instance of that documented case - but Google does not name prices or currencies anywhere in it, so treat the mapping as our reading rather than a documented rule.

Search Console's Page indexing report names the state directly, and its labels are worth using precisely because they carry Google's own definitions:

• "Crawled - currently not indexed" - The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling. Google gives no cause and declines to predict. Resist the urge to supply a reason.
• "Discovered - currently not indexed" - The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl.
• "Duplicate without user-selected canonical" - Google has chosen the other page as the canonical for this page, and so will not serve this page in Search.
• "Duplicate, Google chose different canonical than user" - This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical.
• "URL blocked by robots.txt" - Note that this does not guarantee that the page won't be indexed through some other means.
• "URL marked 'noindex'" - When Google tried to index the page it encountered a 'noindex' directive and therefore did not index it.

Server errors reduce crawling, and Google documents the mechanism without documenting a duration. Verbatim: 5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling; For Google Search, already indexed URLs are preserved in the index, but eventually dropped; and on recovery, Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.

For the 503 and 429 subset there is one further warning, and it is scoped. Where those codes are returned deliberately to throttle crawling, Google advises against sustaining it: We don't recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products, and if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google's index. Read that as written: the 1-2 day figure is the limit of Google's recommendation, not a documented deadline, and the consequence is stated as may be dropped after multiple days, without a threshold. It is still the closest thing to an incident-response clock Google publishes for these codes, and it is worth knowing during an outage. Documented

"Gradually" is as specific as Google gets on recovery, and it should stay that way in your incident report. No recovery period is documented anywhere. Google does publish a removal timeframe for a different situation - network and DNS errors, where already indexed URLs that are unreachable will be removed from Google's index within days - and it does not transfer to 5xx. Two different failures, two different documented consequences, one of them with a timeframe.

For 4xx the treatment is separate again: In the case of Google Search, Google doesn't index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.

Do not reach for crawl budget. It is a frequently misapplied explanation at this layer, and Google scopes its own guidance narrowly: the guide is an advanced guide intended primarily for sites of 1 million+ unique pages with weekly change, 10,000+ unique pages with daily change, or sites with a large portion of URLs marked Discovered - currently not indexed. Google adds: If your site doesn't have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don't need to read this guide. Documented

Note what that sentence is and is not. It scopes the guide's audience; it does not say small sites have no crawl budget. And Google defines crawl budget as the set of URLs that Google can and wants to crawl - a set, not an allowance. There is no documented per-site quota to have exhausted, so a diagnosis of "we ran out of crawl budget" on a fifty-page marketing site is not something the documentation supports.

Layer 6: The Generated Response

This is the layer people start at and the one where least is observable. It is worth being blunt about how little can be established here.

No Google documentation we located describes how prices are sourced, refreshed, cached or validated for AI Overviews or AI Mode. Everything in the layers above is documented for Search crawling and indexing, or for the Merchant Center feed. Google does document that eligibility for its AI features depends on ordinary Search requirements - its 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 - which makes Layer 5 relevant to them. It does not describe what happens after that. For OpenAI, Perplexity and Anthropic we reviewed the crawler and publisher documentation each publishes and located no statement about structured-data use or price handling at all.

So what can you actually do here?

Record rather than infer. For each observation, capture the exact prompt, the system and model label if shown, the date, the geography, whether search was enabled, the full response text, and every linked source. Repeat the prompt across phrasings and across days. One answer is an anecdote; a pattern across repetitions is an observation. Recommendation

Look at what was cited, not at what you hoped would be. If an answer cites a third-party review site with an outdated price rather than your pricing page, that is a source-selection observation and a useful one - it points the investigation at Layer 5 and at the third party, not at your markup.

When sources disagree, report the disagreement. If your page says $89, a comparison site says $79, and an answer says $79, you have observed that the answer matches one source. You have not observed that the system preferred that source, trusted it, or evaluated yours - and describing it that way attributes a decision process you cannot see. The honest finding is that a stale third-party figure is in circulation and your page is not the only thing describing your pricing. Recommendation

What you cannot conclude from a wrong price in an answer: that your schema failed, that your page was not retrieved, that a particular source was preferred, or that any specific layer is at fault. The generated answer is the symptom. The diagnosis happens in the layers above it.

Symptom to Layer: Where to Look First

The sequence is always source data first and generated answer last, but the symptom tells you where the fault is most likely to be, and starting there saves a day.

Every row is a starting point, not a conclusion. Confirm the layer before acting on it - the evidence column is what would make the diagnosis defensible. Recommendation

Six Worked Diagnostics

Six representative failure modes on SaaS pricing pages, walked through in full. Each names the layer, the evidence, and the corrective action - and each fix preserves the current commercial truth rather than only repairing the markup.

1. Wrong Currency

Symptom. A UK visitor's answer or result quotes dollars, or the currency shown does not match the amount.

Layer 2 and 5. One plausible cause is a single URL serving several currencies through a client-side switcher or a geo-redirect, so there is no stable address at which any single currency is the page's content. Where Google Product snippet or merchant listing eligibility is in scope, the requirement is structural and Google states it directly: When offering products for sale in multiple currencies, have a distinct URL per currency. Documented That sentence sits in the technical guidelines for those Product surfaces. For ordinary organic results and for AI-answer diagnosis, no equivalent universal Search requirement was located, and a stable locale-specific URL per priced variant is a CoreAEX recommendation - it improves testability and removes geo-dependent ambiguity, which is what this diagnosis needs. Recommendation

Evidence. Fetch the URL from outside your usual geography and compare. If the response differs by requester location at one address, that is the finding.

Action. A stable URL per priced variant, with the visible currency on that URL matching its markup. Where the variants are same-language regional pages, Google's canonicalisation guidance recommends combining canonicalisation with hreflang - noting it addresses regional variants generally and does not mention prices or currency.

2. Missing Billing Period

Symptom. An answer states "$780" with no indication that it is annual, per user, or both.

Layer 2 first, then Layer 3. The instinct is to add markup, and there is nothing useful to add: Schema.org has no clearly documented property for payment recurrence, and the duration property that exists is not documented as consumed by Google. If the cadence is not in the visible copy, no markup change will supply it.

Evidence. Read the visible page as a stranger. If "$780" appears in large type and "per user, billed annually" in small type below a fold, the omission is faithful reporting.

Action. Put the cadence, the unit and the commitment in the same visible sentence as the amount.

3. Stale Discount

Symptom. A promotional price that ended months ago is still being quoted.

Layer 1, then 3, then 4. Check whether the promotion is still live in the pricing model; whether the page still displays it; whether the markup still carries it; and whether a validity date was ever set. Google's freshness rule applies directly: We won't show a rich result for time-sensitive content that is no longer relevant. Documented

Evidence. A dated pricing source of truth showing the promotion ended, while a downstream layer still exposes the old price. A priceValidUntil or validThrough in the past confirms the marked-up offer has expired. An absent end date does not confirm anything - it shows the markup carries no explicit expiry, which is a governance gap worth closing, but it does not establish that the promotion ended, that an answer used the markup, or which layer retained the old price. Compare the pricing authority, the visible page, the markup and Google's indexed version before assigning a layer.

Action. Remove the promotion from page and markup together, and set an end date at the moment a future promotion is created rather than afterwards. Note that priceValidUntil works on the Offer only - Google states it isn't applicable to the PriceSpecification type - so a validity date placed on a specification does not do what it appears to.

4. Free Trial Reported as a Free Plan

Symptom. An answer says your product is free when it has a 14-day trial of a paid plan.

Layer 3, and probably a markup fault of your own making. The specific thing to look for is price: 0 on an offer that is not a free plan. Encoding a trial that way states the product is available without payment, which stops being true when the trial ends.

Evidence. A zero price in the markup with no correspondingly free plan on the page.

Action. Mark up the plan the trial converts into, at its real price, and describe the trial in visible copy: length, conversion price, first billing date, card requirement, cancellation terms. There is no dedicated trial property in the vocabulary, so the visible copy is doing this work regardless. Recommendation

5. Contact-Sales Plan Given an Invented Price

Symptom. An answer quotes a specific figure for your enterprise tier, which has no public price.

Layer 1 and 3 first, then accept the limits. Check whether anything you publish contains a number attached to that tier - a zero, a placeholder, a "starting from" figure in a blog post, an old deck, a partner listing. A price: 0 on an enterprise offer is the version of this fault you control.

Evidence. Any published figure associated with the tier, anywhere you own.

Action. Remove it. An Offer with a name, URL and seller and no price is the accurate representation, and the resulting ineligibility for price-based features is the correct outcome. If the figure originates with a third party, this layer cannot fix it - the finding is that a number is in circulation, and the response is commercial rather than technical.

6. Toggle State Hiding the Real Price

Symptom. The annual price is quoted as if it were monthly, or a plan's price appears absent entirely.

Layer 2 and 4. Two distinct faults share this symptom. The page may default to a toggle position that displays a monthly-equivalent figure for an annually-billed plan, so the visible number is not a charge anyone incurs. Or the alternate state may be fetched on click rather than present in the response, so only one state exists to be read.

Evidence. Compare the raw HTTP response with the rendered DOM. If a price exists only after interaction, it is not in what a crawler receives without one.

Action. Render both states in the HTML and toggle visibility rather than fetching on click; give each billing option its own offer in the markup; and make sure the amount displayed in the default state is a real charge with its cadence stated beside it.

Retest Protocol

The temptation after a fix is to promise a date. Don't. Google publishes timings for several different things in this area, none of them for the outcome you actually want.

What you can verify immediately is your own delivery, across four boundaries that answer four different questions. The raw HTTP response tells you the server delivered the intended content. The rendered DOM tells you the intended price and terms survive JavaScript. The Rich Results Test tells you Google detects the intended supported markup and reports no blocking issue for it. URL Inspection's live test tells you Google can currently fetch and render the page. Run the parity check against your pricing source of truth separately again, because none of these four compares the price to the billing system. All four are available the moment you deploy, and none of them establishes indexing, and none establishes future display.

What you cannot verify immediately is anything about Google's stored state, because Google has not looked again yet: Remember that Google does not crawl your page immediately after you publish a fix. Therefore Search Console (and Google Search) can continue to show an error for a page that you have fixed until the page is crawled again. Documented

The published timings measure different processes and should not be added together or averaged into an expectation:

None of these is a timeline for a corrected price appearing in a search result or a generated answer. We located no Google statement giving one, which is consistent with Google declining to promise the outcome at all: Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly.

So the protocol is observational rather than scheduled: Recommendation

• Day of the fix - verify your own delivery through all four checks above, and record the result with a timestamp. This is the only step that returns a definite answer.
• After Google recrawls - not on a fixed date, but when URL Inspection's indexed view shows a crawl later than your deploy. Then compare the indexed view to the live page.
• Across weeks - watch the rich result reports for template-wide recurrence, remembering they are a sample of detected items rather than a complete inventory.
• For generated answers - re-run the same recorded prompts on a schedule and compare. A single corrected answer proves nothing; a change in pattern across repetitions is the observation.

Write the incident report in terms of what changed and what was observed, not what will happen. "The corrected price was live and in the server response on 12 September; the indexed view still showed the old price on 15 September; it matched on 19 September" is a defensible record. "The fix will propagate within a week" is a promise nobody documented.

What This Page Doesn't Settle

How to build the implementation so this happens less. Source-of-truth architecture, CI parity gates, release governance and the full validation stack belong to the implementation page in this cluster. This page assumes something has already gone wrong.

What to encode, and which type carries it. Type selection and commercial-term modelling are settled by the type-selection page and the complex-pricing page in this cluster.

How often any of these failures actually occurs. This page describes failure modes and how to tell them apart. It offers no rates, and there are none to offer - measuring how frequently AI answers state SaaS prices incorrectly is the subject of original CoreAEX research in progress, and no figure should be inferred from the order in which faults are listed here.

Ongoing monitoring and experimental design. Turning the retest protocol into a standing measurement practice - with baselines, cohorts and defensible before-and-after comparisons - belongs to the measurement page.

Sources

Sources: Visibility, freshness and the non-guarantee statement are from General structured data guidelines (last updated July 10, 2026). Access requirements, currency URL structure and the priceValidUntil placement rule are from Merchant listing structured data (reviewed August 29, 2026; a specific last-updated date could not be independently confirmed for this page). Rendering behaviour is from JavaScript-generated structured data (last updated December 10, 2025) and JavaScript SEO basics (last updated March 4, 2026). Status-code behaviour is from HTTP status codes and network errors (last updated February 4, 2026) and Reduce Googlebot crawl rate, with the network and DNS removal timeframe and the firewall guidance from Debug network and DNS errors (last updated December 18, 2025) - a different failure from 5xx, with a different documented consequence. Conditional-request and caching behaviour is from Troubleshooting crawling errors (last updated December 18, 2025). Crawl budget scoping is from Managing crawl budget for large sites (last updated July 22, 2026). robots.txt and noindex behaviour is from Introduction to robots.txt and Block search indexing with noindex (both last updated December 10, 2025). Canonical selection is from Canonicalization (last updated August 20, 2026). Google's AI-features eligibility statement is from AI features and your website (last updated December 10, 2025), and crawl-lag guidance from Debugging your pages (last updated December 10, 2025). Schema Markup Validator scope is from schema.org's 2021 announcement. Search Console Help and Google Merchant Center Help pages publish no last-updated dates, so the following were reviewed on August 29, 2026 and that is the only date we can give for them: URL Inspection tool, Page indexing report, Rich result reports, Validation details, Unparsable structured data report, Mismatched product price and Set up structured data for Merchant Center. Merchant Center material governs Shopping ads and free product listings and is separate from Google Search throughout.

---