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

Your pricing page wins twice: it converts buyers and ranks on product plus pricing searches. Keep the plans clear, remove friction, add trust, and mark it up so search can read it.

Updated 2026-09-14 · Source: https://porteur.ai/guides/saas-pricing-page

## What your pricing page must do

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.

## Plans, limits and the toggle

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.

## Trust signals a small SaaS can show

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.

## Remove signup friction that blocks trials

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”.

> Interstitials that cover content on mobile are penalised as of 2026. Do not block the pricing content with popups.

## The title, URL and meta description that rank and earn clicks

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

1. **Pick a clean URL** Use /pricing. Redirect any variants. Link to it in the header and footer.
2. **Write the title** Keep near 60 characters. Example: “YourProduct pricing: plans, limits and free trial”.
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. **Include your product name** Buyers search “YourProduct pricing”. Put the name first or second in the title.
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.

## Structured data for a SaaS pricing page

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.

```html
<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.

## Comparison and rival intent you can win

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.

## What to measure and how to read it

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.

## A worked example: yourproduct.com/pricing

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.

| Area | Before | After |
| --- | --- | --- |
| Title and URL | “Plans: YourProduct” at /plan-options | “YourProduct pricing: plans, limits and free trial” at /pricing |
| Hero copy | “Flexible plans to suit everyone” | “Check your site today. Choose a plan that fits, see the limit that matters.” |
| Plans | Six plans. No context lines. Prices behind a tooltip. | Three plans: Starter, Growth, Team. Each has “For…” and one limit line. Prices visible. Growth marked Recommended. |
| Toggle | Annual only with “contact sales for monthly”. | Monthly or Annual toggle. “2 months free on annual” label shown. |
| Signup | “Create account” goes to a long form with six fields and card required. | “Start 14 day trial”. Four fields only. SSO options. Card asked after first run. |
| Trust | Stock photos. “Trusted by 1,000+ users” with no source. | Real screenshots. Two customer logos with permission. A quote with name and company. Links to reviews on G2 and Product Hunt. |
| FAQ | Generic. No answers on cancellation or trial end. | Answers the four real objections: cancel anytime, when card is needed, limits by plan, what happens when the trial ends. |
| Structured data | None. | JSON-LD for Organization, SoftwareApplication with three Offers, BreadcrumbList. Tested and valid. |

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.

## Questions

### How many pricing plans should a SaaS show on one page?

Two to four. Three is often enough. More plans slow choice and push people to leave. If you sell custom contracts, keep Enterprise as a fourth with a clear next step.

### Should I show monthly or annual prices by default?

Either is fine if the toggle is obvious. Many teams default to monthly to avoid sticker shock, and state the annual saving next to the toggle. Test with your own traffic.

### Should I gate prices behind “contact sales”?

Only if your deals are bespoke and you have a sales motion. For self serve, public prices win trust and rank for pricing searches. Hide nothing that matters to the buyer.

### What belongs in a pricing FAQ on the page?

Answer objections support already hears: how to cancel, if a card is needed and when, what the limits mean, and what happens at the end of a trial. Keep answers short and link to fuller docs.

### Do I put pricing on the homepage as well?

Link pricing in the header and footer. On the homepage, repeat the recommended plan’s price and limit in a short block and link to /pricing for details. Do not duplicate the full tables.

### How do I handle VAT or sales tax on the page?

Say if prices include or exclude tax and which regions it applies to. Link to a taxes page with details. Keep the checkout consistent with what the pricing page states.

## Read next

- [Pricing page examples: the patterns that convert, and why they work](https://porteur.ai/guides/pricing-page-examples): See six pricing page patterns that convert, why they work, and how to ship them on yourproduct.com without guesswork or hidden prices.
- [Landing page SEO: one page, one search, one promise](https://porteur.ai/guides/landing-page-seo): Give each landing page a target query, a clear promise, proof, and one CTA. Keep it from clashing with your home page. Steps and examples inside.
- [SoftwareApplication schema for a SaaS: an example that validates](https://porteur.ai/guides/softwareapplication-schema): Add SoftwareApplication schema that passes Google’s Rich Results Test. See the required fields, a clean SaaS example, and how to test and ship it.
- [The Rich Results Test: what it checks and what it does not](https://porteur.ai/guides/rich-results-test): Run Google’s Rich Results Test, read eligibility, warnings and errors, know its limits, and when to use schema.org’s validator and Search Console.
- [SEO for SaaS: a strategy for a team of one](https://porteur.ai/guides/seo-for-saas): What to rank and why for a SaaS site: the page families that work, pricing and comparisons, how to avoid thin content, and how to measure signups.
- [How to track signups from search, by landing page](https://porteur.ai/guides/track-signups-from-search): Join Search Console with analytics to see which landing pages bring signups from organic search, and which pages get clicks but convert nobody.
- [Next.js SEO: what the framework does for you and what it does not](https://porteur.ai/guides/nextjs-seo): What Next.js gives you for SEO and what still needs your work: metadata, sitemap, robots, rendering, redirects, URLs, images, fonts and links.

Want a second set of eyes on your pricing page, title and markup, and the searches around them? Paste your URL to get a free check in about thirty seconds. Free check: https://porteur.ai/
