# SoftwareApplication Schema for SaaS

> SoftwareApplication schema for SaaS: Google's required name, offers.price and rating properties, honest pricing markup, and a tested JSON-LD template.

Source: https://mentionx.ai/learn/technical/softwareapplication-schema-for-saas  
Author: Dipuck Jones, founder of MentionX  
Updated: 30 October 2026  
Level: Practitioner

**SoftwareApplication schema describes a software product, its category, operating system, price and ratings, in JSON-LD. For Google's Software App rich result you need `name`, `offers.price` and either `aggregateRating` or `review`; `applicationCategory` and `operatingSystem` are recommended ([Google](https://developers.google.com/search/docs/appearance/structured-data/software-app)).** For SaaS, the hard parts are honest pricing and reviews you actually collected.

*Facts are from Google Search Central and schema.org, accessed 30 Oct 2026. Points marked "Our view" are interpretation.*

> **Key takeaways**
>
> - SoftwareApplication markup describes an app, its category, operating system, price and ratings.
> - For Google's software rich result, a page needs a name, an offer price and a rating or review; category and operating system are recommended.
> - Mark up pricing accurately, and never use self-serving reviews of your own product.
> - Add the markup to the product page, test it and keep it matched to visible facts.

*Checked on 31 October 2026. "Our view" marks MentionX opinion. Ledgerline is a fictional company used for illustration.*

## What does Google require?

| Property | Status | Notes |
|---|---|---|
| `name` | Required | The app's name |
| `offers.price` | Required | Use `0` if free; add `priceCurrency` when above 0 |
| `aggregateRating` or `review` | Required (one) | Must follow review snippet guidelines |
| `applicationCategory` | Recommended | A supported type, e.g. BusinessApplication |
| `operatingSystem` | Recommended | e.g. Windows, macOS, Android, or a web context |

Source: [Google](https://developers.google.com/search/docs/appearance/structured-data/software-app). 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](https://developers.google.com/search/docs/appearance/structured-data/software-app)). Most B2B SaaS fits BusinessApplication or DeveloperApplication.

## Which schema type fits a web app?

schema.org defines SoftwareApplication with subtypes including WebApplication and MobileApplication ([schema.org](https://schema.org/SoftwareApplication)). *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.

## How 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](https://developers.google.com/search/docs/appearance/structured-data/software-app)).
- **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](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)). *Our view:* if your pricing page changes often, generate the offer from the same data the page uses so they never drift apart.

## What are the review rules?

Google's review snippet guidelines ([Google](https://developers.google.com/search/docs/appearance/structured-data/review-snippet)):

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

## What does a template look like?

Fictional example with a hypothetical product:

```json
<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](https://mentionx.ai/learn/technical/organization-schema-brand-entities).

## Where should the markup go?

*Our view:*

| Page | Markup |
|---|---|
| Homepage or product page | SoftwareApplication or WebApplication |
| Pricing page | The same entity with offers matching visible plans |
| Feature pages | Usually none beyond breadcrumbs; avoid duplicate app entities with conflicting data |
| Docs | TechArticle or Article |

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

## Does 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.

## How do you test it?

1. Paste the URL into the [Rich Results Test](https://search.google.com/test/rich-results).
2. Run the [Schema Markup Validator](https://validator.schema.org/) for schema.org validity.
3. Compare markup price with the visible pricing page.
4. Re-test after every pricing change.

## Exercise

Write SoftwareApplication markup for your product. List each value and the visible page element that backs it up. Remove any value you can't back up.

## Which 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`.

## Checklist

- 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

## From MentionX data: how often pricing pages are cited

**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:

| Cited URL type | Share of 9,750 citations |
| --- | --- |
| Blog or article | 19.6% |
| Homepage | 10.0% |
| Review page | 2.7% |
| Docs | 2.6% |
| Pricing | 1.9% |
| Wikipedia | 1.6% |

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

| Intent | Brand mentioned | Share of voice |
| --- | --- | --- |
| Brand-specific | 100% | 64.3 |
| Comparison | 91.9% | 44.6 |
| Recommendation | 29.2% | 26.8 |
| Best-of | 26.6% | 22.7 |
| Problem | 5.7% | 7.7 |

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

## Worked 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.

> **Pro move:** Generate the price in the markup from the same source as the visible pricing table. When prices change, the two can't drift apart.

## How 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.

## How 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.

## Should 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.

## How 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.

## How 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.

## How 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.

## How 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.

## How 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.

## How 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.

## Should you mark up competitors?

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

## How 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.

## Common 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.

## Related

- [Review and AggregateRating schema](https://mentionx.ai/learn/technical/review-and-aggregaterating-schema)
- [Schema markup for AI search](https://mentionx.ai/learn/technical/schema-markup-ai-search)

## Sources

- Google, [Software App structured data](https://developers.google.com/search/docs/appearance/structured-data/software-app); [review snippet structured data](https://developers.google.com/search/docs/appearance/structured-data/review-snippet); [structured data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies); [Rich Results Test](https://search.google.com/test/rich-results)
- schema.org, [SoftwareApplication](https://schema.org/SoftwareApplication); [Schema Markup Validator](https://validator.schema.org/)
All accessed 30 Oct 2026.

## Frequently asked questions

### Does a SaaS product need SoftwareApplication schema?

It isn't required, but it describes your product, category, platform and price in a machine-readable way. Google's Software App rich result needs name, offers.price and a rating or review.

### What if my SaaS has no public price?

Google requires offers.price for the rich result. If you have a free plan, price 0 is valid. If pricing is quote-only, you can still use the markup for description but won't qualify for the rich result.

### Can I add my G2 or Capterra rating?

No. Google's review snippet guidelines say not to aggregate reviews or ratings from other websites.

---

Written and reviewed by Dipuck Jones for MentionX Learn. The HTML version of this page: https://mentionx.ai/learn/technical/softwareapplication-schema-for-saas