Audit your pricing page for the questions AI buyers ask

To audit a pricing page for AI buyers, list the questions a buyer would ask about cost, then check that your page answers each one in plain text a reader can verify: the price and its currency, what the price is per, how it is billed, what each plan includes, what happens at a limit, which add-ons cost extra, what terms apply, and the date the figures were last reviewed. A page that leaves any of these out forces a reader, or an AI engine, to fill the gap from somewhere else. The 20-item checklist below turns that into a review you can run page by page.

In short

• Buyers can put specific cost questions to an AI engine: what it costs for a team of a given size, what is included, what is extra. Your page should answer those questions in plain text.
• Common gaps are missing units ("per what?"), unstated limits, unmentioned add-ons and no effective date. Each is usually a small edit.
• Audit the page as text first. Anything shown only through a toggle, slider or image needs a written equivalent.
• After editing, check whether engines state your prices correctly. That is a measurement, not a promise: an edit does not guarantee a correct or cited answer.
• If an engine is already wrong about your pricing, that is a different job. See what to do when AI gets your pricing or product facts wrong.

Why does the pricing page matter to AI answers?

Pricing questions are factual, specific and easy to check, which makes wrong answers costly. A buyer who asks "how much does this cost for ten people?" wants a number, a unit and a condition. If your page gives a headline price and nothing else, an engine may combine it with an old review, a reseller listing or an assumption.

We cannot say which source any engine will use, and a stated answer is an observation, not proof of why the model produced it. What you control is the quality of the facts on your own page. A clear page gives a reader something to quote and something to verify; a vague one leaves both to chance.

This is a review of the page itself. It sits before a fact-checking workflow, which measures what engines say afterwards.

Which questions should a pricing page answer?

A pricing page should answer six groups of questions: price and unit, plan limits, add-ons, terms, currency and region, and freshness. Each group is a kind of question a buyer might put to an assistant or a salesperson before buying.

• Price and unit: "What does it cost per user per month?" "Is that billed annually?" "Is tax included?"
• Plan limits: "How many documents can I review on the entry plan?" "What happens if I go over?"
• Add-ons: "Is single sign-on included or extra?" "Is there a setup fee?"
• Terms: "Can I cancel mid-term?" "Does the price go up at renewal?"
• Currency and region: "Can I pay in euros?" "Is it available in my country?"
• Freshness: "Is this current?"

Notice how many of these are about the qualifiers around a number, not the number. A price without its unit, period and conditions is an incomplete fact, and the missing parts are the easiest to misquote.

Enlarge image

How do you review a pricing page step by step?

Work from the buyer's questions toward the page, not the other way round. This keeps the review about what a reader can find, not what your team knows.

1. Collect the questions. Write 10 to 15 pricing questions in a buyer's words. Sales calls, support tickets and the prompts you already track are good sources. If you need help choosing prompts, see how to choose AI tracking prompts.
2. Read the page as plain text. Open the page with styles and scripts off, or copy its text into a document. Whatever disappears is invisible to a reader that does not run your page's scripts.
3. Score each checklist item as present, partial or missing, and note where the answer lives (this page, another page, nowhere).
4. Compare every figure across pages. The pricing page, plan comparison, FAQ, checkout and any downloadable price sheet should say the same thing. A mismatch gives a reader two answers to one question.
5. Fix in priority order, starting with anything that changes what a buyer would pay or expect.
6. Record the review date on the page and in your own log, so the next review has a starting point.

The pricing page completeness checklist

Score each row Present, Partial or Missing. "Present" means a reader can find the answer on this page in plain text, with its unit and condition. Copy the table into your own document.

Some rows will not apply to you. Mark them "Not applicable" with a reason rather than deleting them, so the next reviewer sees the decision.

How to weigh the gaps

Not every gap is equal. A useful order:

• Fix first: anything that changes the amount or the unit (P1 to P5, L2, A1, A2). A buyer who is wrong here pays the wrong amount.
• Fix next: limits, terms, region and sales-led plans (L1, L3, A3, T1 to T3, R1, R2). These decide whether the purchase works for the buyer.
• Then: presentation and freshness (L4, F1 to F3), which make everything else checkable.

Which pricing facts should you write down for checking?

Turn the settled facts from the audit into short statements, one per line, that you can verify against later answers. The statements come from your page and your billing system, not from an engine.

For instance, "Team plan: $40 per reviewer per month when billed annually" is a fact. "Our pricing is competitive" is not, and cannot be checked.

DiscoveredBy's Fact check works this way, depending on your plan (see plans and limits). You keep a list of approved facts about your brand, each in one of six categories (pricing, company, product, availability, policy or other) and each a one-line statement of 5 to 300 characters. A project can hold 50 active facts. An AI model then judges engine answers against them, and your team reviews each finding the model says contradicts a fact.

Enlarge image

Two limits are worth knowing before you rely on it:

• Drafts are the model's wording. The Suggest from my site feature asks an AI model to propose facts from your homepage and up to seven linked pages whose paths contain words such as pricing, plans or price. The product checks that the sentence shown is on your page, not that the statement means the same thing, so read every draft against its sentence before approving it.
• A finding is a judgement, not a ruling. The verdict is the model's; what the product guarantees is that the quote is in the answer and the fact is one of yours. Your review corrects a wrong verdict.

How can you check the page itself?

Use a page check to confirm that the page delivers readable text, then judge the content yourself. A check can tell you about the delivered page; it cannot tell you whether your prices are complete or right.

DiscoveredBy's Page diagnostics runs on an exact URL on your project's domain and saves evidence you can recheck after an edit. Availability depends on your plan. Several of its checks bear on a pricing page:

• Body text reports the extractable text in the delivered HTML. A pricing page with very little of it may be rendering prices with scripts.
• Content that needs JavaScript needs review when rendering in a browser adds at least 200 characters of text and at least doubles the text in the raw HTML.
• Meta description, Page title and H1 and Canonical URL show whether the basics are in place.
• Indexing directives show a noindex value if one has been left on by mistake.

Enlarge image

These are heuristics from one lab request or browser load. They do not measure whether the prices are complete, and the documentation is explicit that they do not predict citation or lift. A page can pass every check and still leave out its billing unit. Use them to rule out delivery problems, then use the checklist above for content.

Worked example: auditing Quillstone's pricing page

Illustrative example: Quillstone and its competitors are fictional, and the numbers are made up to show the method.

Quillstone sells document-review software to mid-sized legal and compliance teams. Its pricing page shows two plans and a "Contact us" option. The team scores the page against the 20 checklist items.

What the page says today:

• Team: "$40" with a monthly and annual toggle
• Business: "$70"
• Enterprise: "Contact us"
• A footer line: "Prices exclude tax"

The first pass:

Seven plus seven plus six is 20, so every item is scored once.

The most serious gaps, and what the team writes down:

• P2, price unit missing. "$40" does not say per what. The billing system charges per reviewer per month. The page now says "$40 per reviewer per month, billed annually".
• P3, partial. The toggle changes the figure, but the monthly price appears only after clicking. The team writes both out: "$40 per reviewer per month billed annually, or $48 per reviewer per month billed monthly".
• P4, minimum missing. Plans need at least three reviewers. Three reviewers on the annual Team plan cost 3 x $40 x 12 = $1,440 a year. The page now states the minimum and gives that example.
• L2, partial. The Team plan includes 500 documents per month, but the page does not say what happens on the 501st. The product manager confirms extra documents are charged, so the page says so and names the rate.
• F3, partial. The toggle shows the monthly price only after a click, so the page needs both figures written out. The P3 fix above closes this gap too.
• F1, effective date missing. The team adds "Prices last reviewed on 1 September 2026" and records the same date in its change log.

Verification. The team adds five pricing facts to the tracked list and picks a small set of pricing prompts. Their plan is to watch what engines say over the following weeks, comparing like with like, and to judge the result at that strength. If one still gets the unit wrong, the next step is the investigation in the pricing-fact-error post, not another rewrite.

What can this audit not tell you?

An audit checks whether your page states things clearly. It does not predict what engines will say, and it cannot make one cite you.

• A complete page does not guarantee a correct answer. Engines draw on many sources and, depending on how an answer is produced, may draw on none of your pages. Treat every edit as a hypothesis to test.
• Clarity is not the only thing that matters. Pricing you would not want repeated, such as bespoke enterprise rates, may be better left as a stated range or "contact us". The checklist asks you to say what is included, not to publish everything.
• Your facts have to be right first. If billing, sales and the page disagree, fix the source before you fix the wording.
• Prices change. A dated page ages. Set a review date after each pricing change, and again on a regular schedule.
• A table or widget that only humans can operate is a gap. See making product tables clear enough to verify for the same idea applied to comparison tables.

Common mistakes

• Listing a price with no unit. "$40" is not a pricing fact until it says per what, per when.
• Hiding conditions in a footnote or an image. Put them next to the price, in text.
• Letting FAQ, checkout and pricing page disagree. Check every place that states a figure. A plain FAQ that restates prices is a useful place to do that; see building an FAQ from observed buyer questions.
• Treating "contact us" as an answer. It is fine as a plan, but say what the buyer will get and what you need from them.
• Publishing without a date. Without one, a reader cannot tell whether a figure is current.

Frequently asked questions

Do I have to publish my prices for AI engines to describe them?

No. If you do not publish prices, say plainly what the buyer will learn on a call and roughly what the pricing depends on (seats, volume, modules). An engine or a reader then has an accurate statement to repeat instead of a guess.

Where should the effective date go?

Put it on the pricing page itself, near the prices, in plain text, for example "Prices last reviewed on 1 September 2026". Keep the same date in your own change log so you can tell later whether an answer reflects the current page.

Should I mention competitor prices on my page?

You do not need to. A pricing page is strongest as an accurate statement of your own prices, limits and terms. Comparisons raise their own accuracy problems and are out of scope for this checklist.

How often should I run this audit?

Run it after any pricing, plan or packaging change, and on a regular schedule your team can keep. Between audits, recurring fact checks can show whether engines still state your figures as you do.

Will fixing these gaps make AI engines cite my pricing page?

We cannot promise that. A clear page is easier to verify and quote, but citations depend on many things you do not control. Measure what engines say before and after, and report the result at the strength the evidence supports.

Does structured data for pricing help?

It can make prices machine-readable for systems that read it, but it does not replace plain text a reader can see, and we make no claim that it improves AI visibility. If you add it, keep it identical to the visible page.

Next step

Run the checklist on your own pricing page, write down the settled facts, and load them as approved facts so later answers can be judged against them. Start with a small set of pricing prompts and read the findings yourself before drawing conclusions. To do that in one place, sign in to DiscoveredBy. For an overview of fact checking, see the brand perception feature page, and the glossary entry on hallucination for the term used when an engine states something that is not true.