The SaaS pricing page: what it must say for the buyer and for search

Your pricing page must answer two jobs. It must help a buyer choose a plan and start. It must also rank for “your product + pricing” and for competitor comparisons.

• Show two to four plans, with one recommended.
• State who each plan is for and the one limit that matters, in one line.
• Show the price without a click. Add a monthly or annual toggle. State the saving on annual.
• Use the same plan names as the app, docs and emails.
• Answer objections in an FAQ: cancellation, card, limits, trial end.
• Place proof near the decision: quotes with a name and company, real logos, reviews you can link to.

A fixed page looks like this: a short headline, four cards for plans, a clear signup button on each, trust under the cards, and an FAQ that uses the buyer’s words.

Keep plans few. Three is common. Name the audience and the key limit. Not a feature dump. The reader wants to know which plan fits them now.

• Name: Starter, Growth, Team, Enterprise. Use these same names in app UI and invoices.
• Audience line: “For solo founders”, “For teams who ship weekly”.
• Limit line: “Up to 3 projects”, “tracked rows”, “Priority support”. One line only.
• Price: show the figure and the currency. Do not hide it.
• Toggle: Monthly or Annual. State the saving on annual in the UI, for example “2 months free”.

If you have both free trial and freemium, say it plainly. Free trial is time limited for full product. Freemium is free forever with limits. They behave differently and they cost support differently. Do not mix the language.

Buyers check for risk. Put honest, checkable signals on the page. Link to the full page where needed.

• About page with real names and roles.
• Postal address and company registration.
• Security page: what is encrypted, where data lives, how to delete it.
• Status page and a changelog with dates.
• Screenshots of the real product.
• Customer logos only with permission. Quotes with a name and a company.
• Visible support address. Terms and privacy pages in plain language.
• Links to reviews on G2, Capterra or Product Hunt.

No customers yet. Use what you do have. Your own use. Real numbers, for example “2,143 sites checked”. A public roadmap. Open source parts. A comparison that is clear about what you lack today and what you do next.

Each step you add costs starts. Remove friction until a buyer sees the product working. Then ask for more data when it is earned.

• Keep fields to the minimum. Add company and phone later.
• Do not take a card before the buyer sees the product, if you can avoid it.
• Do not force email verification before the first screen. Let them in, then confirm.
• Fix password rules that reject real passwords.
• Offer single sign on with Google, Microsoft or GitHub.
• Write error messages that say exactly what to fix and why.

Place the primary signup button on every plan card. The button text names the next step, for example “Start 14 day trial”, not “Submit”.

Your pricing page ranks on branded pricing searches. It also gets seen for comparisons and “cost” queries. Make the title clear and concise.

1. 1

   Pick a clean URL

   Use /pricing. Redirect any variants. Link to it in the header and footer.

2. 2

   Write the title

   Keep near 60 characters. Example: “YourProduct pricing: plans, limits and free trial”.

3. 3

   Write the meta description

   Use one sentence that names who it is for and the next step. Example: “Choose a plan, see limits, start a free trial today.”

4. 4

   Include your product name

   Buyers search “YourProduct pricing”. Put the name first or second in the title.

5. 5

   Avoid fluff and clickbait

   Say what is on the page. Do not tease. This page serves the intent to buy.

Add a short H1 that matches the page. For example “Pricing and plans”. Keep the first paragraph short. State who the product is for and the outcome. Then show the plans above the fold.

Mark up the page so search can read it. Use JSON-LD. It can sit in the head or body. Google renders pages, so injected JSON-LD is read by Google’s tests too.

• SoftwareApplication for the product, with Offers for each plan. Name is required. Offers need price and priceCurrency.
• Include applicationCategory and operatingSystem. Use aggregateRating only if you have it for the app.
• Organization for your company with name, url and logo.
• BreadcrumbList if pricing sits under a section, for example /product/pricing.
• FAQPage is valid but earns no rich result for product sites as of 2026. It is still readable by assistants.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "name": "YourCompany Ltd",
      "url": "https://yourproduct.com/",
      "logo": "https://yourproduct.com/static/logo-112.png",
      "sameAs": [
        "https://twitter.com/yourcompany",
        "https://www.linkedin.com/company/yourcompany"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "name": "YourProduct",
      "applicationCategory": "BusinessApplication",
      "operatingSystem": "Web",
      "offers": [
        {
          "@type": "Offer",
          "name": "Starter",
          "price": 19,
          "priceCurrency": "USD",
          "url": "https://yourproduct.com/pricing#starter",
          "availability": "https://schema.org/InStock"
        },
        {
          "@type": "Offer",
          "name": "Growth",
          "price": 59,
          "priceCurrency": "USD",
          "url": "https://yourproduct.com/pricing#growth",
          "availability": "https://schema.org/InStock"
        },
        {
          "@type": "Offer",
          "name": "Team",
          "price": 99,
          "priceCurrency": "USD",
          "url": "https://yourproduct.com/pricing#team",
          "availability": "https://schema.org/InStock"
        }
      ]
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        {"@type": "ListItem", "position": 1, "name": "Home", "item": "https://yourproduct.com/"},
        {"@type": "ListItem", "position": 2, "name": "Pricing", "item": "https://yourproduct.com/pricing"}
      ]
    }
  ]
}
</script>

Test the page. The Rich Results Test tells you which rich result types are eligible and what is missing. The Schema Markup Validator checks schema.org syntax. Fix missing required fields, absolute URLs, date formats and prices as numbers, not text with symbols. Structured data is not a ranking factor itself. It makes the content legible to machines and can earn rich results.

Your pricing page will pick up queries like “YourProduct pricing” and “YourProduct vs Rival”. Help that visitor compare. Make it easy to find your standalone comparison pages too.

• Add a short block under the plans: “Comparing tools”. Link to /comparison/yourproduct-vs-rival-a and /alternatives.
• Name the core trade offs. Be honest about where you are weaker and why some teams still pick you.
• Pull one credible quote that mentions switching or value. Link to the full case study.
• Keep internal links clear: /pricing links out to comparisons. Comparisons link back to /pricing.

For a small site, this is how you meet the searcher without building a maze of pages. You serve the intent first. Then you offer the next step with a visible button above the fold and where a section ends.

Use your own rates. Do not quote internet averages. They vary by source and by definition. Only your site’s data over enough sessions means anything for your decisions.

• Landing page conversion rate: conversions divided by sessions that began on /pricing over a period with a few hundred sessions.
• Signup conversion rate: accounts created divided by visitors of the signup path.
• Trial to paid rate: paying accounts divided by trials started in the same cohort.
• Visits from search to /pricing: track clicks from queries that include your brand plus pricing or plan names.
• Clicks to signup: the click on “Start trial” per plan and per device.
• Support questions that still arrive after a visit to /pricing: mine your inbox and chat logs.

Join landing pages to signup events in product analytics. That is how you tell three causes of traffic that does not convert apart: intent was informational, next step was missing, or the visitor was not the buyer. Fix the first two. Accept the third.

Here is a simple before and after. The product is a web app that checks sites for issues. The old page hides prices and lists every feature. Support gets the same four questions each week.

Support questions drop. Search clicks rise on “yourproduct pricing”, “yourproduct cost”, and “yourproduct vs rival”. The Growth plan gets most trials, as intended. The changelog and status links reduce procurement back and forth for Team plans.