SoftwareApplication Schema for SaaS

#01What does Google require?

Source: Google. If the app costs more than 0 and you omit priceCurrency, Google says it will try to find the right currency; it's better to state it.

Supported applicationCategory values include BusinessApplication, DeveloperApplication, FinanceApplication, SecurityApplication, CommunicationApplication, EducationalApplication and UtilitiesApplication, among others (Google). Most B2B SaaS fits BusinessApplication or DeveloperApplication.

#02Which schema type fits a web app?

schema.org defines SoftwareApplication with subtypes including WebApplication and MobileApplication (schema.org). Our view: use WebApplication for a browser-based SaaS product and MobileApplication for app-store apps, or keep SoftwareApplication with a clear operatingSystem if you ship across platforms. Google's doc lists the properties above for SoftwareApplication; test whichever type you choose.

#03How should SaaS pricing be marked up?

SaaS prices are often per seat, per month, with several plans. Options:

• Free plan exists: "price": 0 is valid and true (Google).
• Single entry plan: mark up the starting price with priceCurrency, and make sure the same price is visible on the page.
• Quote-only: don't invent a number. You won't qualify for the rich result, but the rest of the markup still describes the product.

Google's general guidelines require markup to represent the visible page content and not mislead users (Google). Our view: if your pricing page changes often, generate the offer from the same data the page uses so they never drift apart.

#04What are the review rules?

Google's review snippet guidelines (Google):

• Reviews and ratings must be visible on the marked-up page.
• Don't aggregate reviews or ratings from other websites, so no pasting your G2 average.
• Don't include fake or undisclosed incentivised reviews, such as reviews given in exchange for discounts without clear disclosure.
• Provide reviews about a specific item, not a category or list.
• If you include individual reviews, also include an aggregate rating.

Our view: many SaaS homepages don't host first-party reviews, so they don't qualify for stars. That's fine: don't force it. The descriptive properties still help.

#05What does a template look like?

Fictional example with a hypothetical product:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "ExampleCRM",
  "url": "https://www.example.com/",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web browser",
  "description": "CRM for small B2B sales teams.",
  "offers": {
    "@type": "Offer",
    "price": 0,
    "priceCurrency": "EUR",
    "description": "Free plan for up to 2 users"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "ratingCount": 212
  },
  "publisher": {"@id": "https://www.example.com/#organization"}
}
</script>

The rating must reflect reviews collected and shown on that page. Link publisher to your Organization schema.

#06Where should the markup go?

Our view:

Use a single @id for the product so every page refers to one entity.

#07Does it help with AI answers?

There's no published evidence that SoftwareApplication markup on its own causes AI citations. Our view: AI tools comparing software lean on clearly stated category, platform and pricing facts, and markup that matches a clear pricing page reduces ambiguity. Treat it as part of entity hygiene, alongside consistent descriptions on your site and third-party profiles.

#08How do you test it?

1. Paste the URL into the Rich Results Test.
2. Run the Schema Markup Validator for schema.org validity.
3. Compare markup price with the visible pricing page.
4. Re-test after every pricing change.

#09Exercise

#10Which pitfalls are most common?

Our view, from reviewing typical SaaS sites:

• Stale prices. The pricing page changed months ago but the JSON-LD still shows the old plan. Generate markup from the pricing data source.
• Borrowed ratings. A badge from a review platform turned into aggregateRating. Google's guidelines rule this out, so remove it.
• Several product entities. Each feature page declares its own SoftwareApplication with a different name. Keep one entity and refer to it by @id.
• Vague category. Leaving out applicationCategory, or using a value Google doesn't list. Pick one of the supported types.
• Marketing copy as name. Put the product name in name and the tagline in description.

#11Checklist

• name, offers.price, applicationCategory, operatingSystem
• priceCurrency when price > 0
• Price matches the visible page
• Ratings are first-party and visible, or omitted
• One @id for the product
• Tested in both validators

#12From MentionX data: how often pricing pages are citedOriginal data

Method. Read-only aggregate queries over MentionX scans from 22 August to 29 October 2026 (UTC): 2,217 engine runs (2,154 completed) across 18 anonymised projects and six engines.

SoftwareApplication markup often sits on product and pricing pages. In the MentionX sample, pricing pages are a small share of cited URLs:

Brand-specific and comparison prompts, where pricing and features matter, mention brands most often:

Our view: pricing and product pages are cited less often than articles, but for brand-specific and comparison questions accurate visible pricing is the fact engines most need. Markup can help make it clear.

Limits. A convenience sample of mostly B2B software projects, run through engine APIs, which can behave differently from the consumer apps. Perplexity, Copilot and DeepSeek figures come from a single day (26 October 2026), so treat them as a snapshot, not a trend.

#13Worked example: Ledgerline marks up its web app

Ledgerline is a fictional accounts-payable tool. Figures are illustrative.

Ledgerline's product page has no structured data. The developer adds SoftwareApplication markup with the name, an applicationCategory of BusinessApplication, an operatingSystem value for the web app and an Offer for the starting plan with the price and currency.

The team doesn't add an aggregateRating, because its only reviews are testimonials on its own site. It links instead to its profiles on independent review sites, and accepts that without a rating or review the page isn't eligible for Google's software rich result. The markup still describes the app and its price clearly.

It tests the page in the Rich Results Test, fixes a currency code error and adds a step to the pricing change process: update the visible price, the markup and the facts sheet at the same time.

#14How do you mark up free plans and trials?

Use an Offer with a price of 0 for a free plan, and include the currency. For trials, describe the trial in the visible text, and mark up the price that applies after the trial. Don't mark up a free price for a product that isn't actually free.

#15How do you handle several plans?

List several Offers, one per plan, each with its own price. schema.org also has AggregateOffer with a low and high price, but Google's software app documentation lists offers.price as required, so individual Offers are the safer choice. Make sure each price matches the visible pricing table. Our view: if pricing is complex, a clear visible table matters more than the markup.

#16Should mobile apps use different types?

Use MobileApplication for mobile apps and WebApplication for web apps, both subtypes of SoftwareApplication. Include the operating system. Link to the app store listings in the visible text.

#17How do you keep the markup current?

Re-test after any pricing, name or template change. Review Search Console for errors monthly. Add markup updates to the checklist for each product launch.

#18How should features be described?

Describe features in visible text with clear names and short explanations, and use featureList in the markup only if it matches the page. Avoid marketing phrases that don't say what the feature does. Our view: a plain feature list on the product page helps engines answer "does this product do X?" questions.

#19How do you describe system requirements?

State supported browsers, operating systems and devices in the visible text, and mark up operatingSystem to match. If the app needs integrations or other software, say so. Clear requirements help answer compatibility questions.

#20How do you mark up an app marketplace?

On marketplace listing pages, mark up each app with its own SoftwareApplication, using its name, category and offer. Use Review or AggregateRating only for genuine reviews shown on the page, written by users about apps they don't own.

#21How do you coordinate pricing changes?

Make one person responsible for each pricing change across the pricing page, the markup, the facts sheet and external profiles. Use a checklist so nothing is missed.

#22How do you describe the app for engines?

Write a short visible description that says what the app does, who it's for and how it's priced. Use the same wording in the markup's description. Our view: a plain one-sentence description often answers "what is this product?" better than a tagline, and it's what engines tend to quote.

#23Should you mark up competitors?

No. Mark up only your own products, or apps reviewed on your own marketplace with genuine user reviews.

#24How do you handle localised pricing?

If prices differ by country or currency, show the local price on each localised page and mark up the matching currency. Don't mark up one currency on every page. Make clear which prices include tax. Our view: mismatched currencies are a common reason engines quote the wrong price. Check each localised page after a price change, because regional pages are often updated last and can show old prices for weeks.

#25Common questions

Can we mark up a price range? schema.org allows an AggregateOffer, but Google's documentation requires offers.price, so list one Offer per plan instead.

Does SoftwareApplication markup affect AI answers? There's no published evidence of a direct effect. Clear visible pricing matters more.

Do we need ratings to use the markup? For Google's rich result, yes: it needs a rating or review as well as a price. Without one, the markup can still describe the app, but won't produce a rich result.

#26Related

• Review and AggregateRating schema
• Schema markup for AI search