How to Structure a SaaS Pricing Page for Search and AI Answers

A one-minute test: choose a plan, copy the single passage that names it, and read it alone. If the amount, currency, billing period and the condition are not all inside that passage, anyone quoting only that passage cannot state them, so move them into it.

A SaaS pricing page is useful as a source when a reader can identify the plan, amount, currency, billing period and conditions from the same passage. A number detached from its qualifiers is easy to quote incorrectly, even when the visual layout looks clear.

In short

• Keep the plan name, amount, currency, billing period and conditions in the same visible passage.
• Put the real price in text and in a real table; a client-side widget may not be seen by a fetcher.
• Mirror the page in structured data, and never publish a rating to satisfy a validator.
• Test the page against the questions a buyer asks, then fix the canonical source first.

The goal is an accurate buying answer. Clear pricing and appropriate structured data do not guarantee an assistant citation or a search rich result.

Define the buying questions before changing the table

List the questions your sales and support teams actually receive: what the base plan includes, whether the commitment is monthly or annual, which usage unit is billed, what happens above an allowance and whether a particular feature requires a higher tier.

Assign each question to a visible section. Put commercial terms on the pricing page; link detailed operational definitions to documentation. Avoid a second blog post that independently restates changing plan figures.

Keep the qualifiers attached

Use a pricing fact record rather than a bare number:

Field	What the passage should establish
Plan	The exact name and intended workload
Amount and currency	The payable amount and its currency
Period	Monthly billing or the actual annual commitment
Scope	Sites, seats, storage or usage included
Adjustments	Overage, additional seats, taxes and minimums
Exceptions	Quote-required terms or unavailable features

In a fictional example, “Team includes the stated number of projects per workspace, billed annually” is more complete than “Team, per month” under a disconnected annual-billing toggle. Publish the real numbers only after the commercial owner verifies them.

Read the page without its layout

Copy the pricing section as plain text and inspect the initial HTML. Do plan names remain attached to their allowances? Does each column have meaningful headings? Does a billing toggle change the visible conditions and amounts together? Are footnotes comprehensible without hovering?

Test on a narrow screen and with keyboard navigation. A horizontal table can work if headers remain understandable and scrolling is available. Do not make the annual commitment visible only through color or a tooltip.

Vercatus’s own earlier audit found qualifiers and cross-page inconsistencies worth correcting. That is an owned-site observation, not evidence that a specific pricing layout improved citations. Our current pricing page owns prices; the plan reference explains allowances.

Align visible content and markup

Describe the actual application and offers using appropriate schema. Match currency, availability, plan identity and conditions to what a visitor can read. Keep amounts sourced from the same commercial data as the page.

Do not assume that any valid Offer makes a subscription eligible for Google’s shopping or software-app rich results. Google’s software-app documentation specifies its own requirements, including review or rating information. Publish only genuine evidence; never create a rating to satisfy a validator.

Test answerability with concrete cases

Ask the page to answer a small set of workloads: one domain, several brands, additional editors and enterprise procurement. Check whether a buyer can identify the right plan and all applicable conditions without inventing missing facts.

Record errors by type: missing information, ambiguous unit, contradictory documentation or outdated commercial claim. Fix the canonical source first, then update cross-links and any duplicated statements.

Maintain a commercial review process

Give pricing content an owner. When a plan changes, review the page, checkout, documentation, structured data, sales collateral and saved comparison pages in one release. Record the date and changed terms; do not merely replace a visible update date.

What the evidence says about pricing pages

• A pricing question is answerable only when the facts are visible together. A pricing question is fully answerable when each plan’s price, currency, billing period and inclusions are visible text, ideally a real HTML table with the plan name in every row, mirrored in Offer markup. In Vercatus’ own retrieval simulations, pricing tables that flatten into passages without plan attribution answered pricing questions only partially (pricing page citability, grade C).
• Client-side prices can be invisible. Many agents read a page without running its JavaScript. Anthropic’s web fetch tool does not support pages rendered dynamically with JavaScript, and a price, stock state or plan table inserted client-side is invisible to such fetchers (raw HTML price and action, grade C). If a billing toggle swaps the numbers in the browser, check that both states exist in the HTML a fetcher receives.
• Recurring prices need an explicit unit. schema.org can express a recurring price, but it has no single billing-period field: a UnitPriceSpecification carries the price, and the unit and billing duration are separate properties (subscription price markup, grade A).
• Time-limited prices need a window. Sale prices get an explicit validity window in ISO 8601 (sale price validity, grade A). A promotion that has ended but is still quoted is the commonest source of a wrong price in an answer.
• Offer data is data. An agent that compares or buys needs price, currency and availability as data, with a dot as the decimal separator and no currency symbol in the price field (offer state as data, grade A).

A page structure that works

1. A one-line summary of how pricing works. For example: “Priced by the number of sites; billed monthly or annually; tax shown.” Say it in words before the table.
2. A plan table. Plan name in every row, amount, currency, billing period, what is included, what is extra.
3. A conditions block. Overage, minimum commitment, taxes, discounts, quote-only plans.
4. Questions people ask. Free trial, changing plan, refunds, who counts as a user. Link to the policy page rather than restating it.
5. A dated review line. “Prices checked on [date]” is more honest than a date that moves on every deploy.

A worked example, with invented figures

A fictional tool, TeamBoard, has two plans. A page that says only “Team: $49” with a toggle labelled “Annual” invites a wrong answer: per user or per workspace, per month or per year, in which currency? A page that says “Team: 49 US dollars per workspace per month, billed monthly; 490 US dollars per workspace per year, billed annually; includes five projects; extra projects cost 9 US dollars each per month” answers the same question once. The figures are invented for the example; publish only numbers your commercial owner has verified.

Common mistakes

• A price shown only inside an image or a widget.
• A table where the plan name appears once at the top and the rows do not repeat it.
• A blog post that restates a plan price which the pricing page later changed.
• Schema that describes a different currency or plan than the visible page.
• A “from” price whose conditions sit three screens away.

Questions people ask

Should I hide enterprise pricing?

That is a commercial choice. If a plan is quote-only, say so plainly and say what the quote depends on, so the page still answers “how do I buy this?”

Do I need schema for software pricing?

Markup should describe what is visible. Google’s software-app feature has its own requirements, and a valid Offer does not guarantee a rich result.

Why does an assistant quote an old price?

Often because an old page, a third-party listing or a cached comparison still says it. Fix the canonical page, then the copies (the correction workflow).

Vercatus’s plays and the content workflow connect those checks to implementation. After publishing a pricing correction, test the same buying questions again. Treat better answer completeness as an observable content result and citation changes as a separate measurement.