SoftwareApplication Schema: The Complete Property Reference for SaaS

SoftwareApplication is the schema.org type most SaaS marketing sites reach for, because it maps onto what you actually sell: a product, a category, a price, a rating. The full type carries dozens of properties, but Google reads a small subset of them when it decides whether your page earns anything in search, and that subset is both smaller and stricter than the vocabulary suggests. Mark up forty properties and get offers slightly wrong, and you get nothing extra in the results.

This is a reference for the properties that matter, the two Google is genuinely picky about, and the one rule that silently caps what your own domain can earn. If you want the wider map of how this type nests alongside Product, Review, and Organization, start with the pillar guide on review schema and structured data and treat this post as the deep dive on SoftwareApplication itself.

The properties Google actually uses

Here are the properties worth your attention, in rough order of how much they affect a rich result.

name is the only property that is always required. Everything else earns its place by enabling something specific. To get anything richer than a plain blue link, Google wants at least one of offers, aggregateRating, or review present and valid on the item. That is what "conditional" means in the table: the property is not required to be valid schema, but it is required if you want the result it powers.

applicationCategory should come from schema.org's enumerated values (BusinessApplication, DeveloperApplication, SecurityApplication, GameApplication, and a handful of others) rather than a free-text label you invented, because Google matches against known values. operatingSystem is where a lot of web-native SaaS stalls, since "it runs in a browser" feels like a non-answer. "Any" is valid, "Web" is commonly used, and if you also ship native apps you can list platforms comma-separated.

offers is where Google gets strict

The price has to live inside a nested Offer, and both price and priceCurrency need to be present and machine-readable. Use "29.00", not "$29/mo", and use an ISO 4217 currency code like "USD". For a free tier, "price": "0" is valid and honest. If your pricing is genuinely custom or quote-based, don't invent a number to satisfy the validator, because a wrong price is worse than a missing one: Google's policies treat a price that doesn't match the page as a reason to drop the result entirely.

If you have tiers rather than a single price, you have two correct options. List multiple Offer objects in an array, or express the span with a single AggregateOffer that carries lowPrice, highPrice, priceCurrency, and offerCount. Whichever you pick, the numbers have to match what a visitor sees on the pricing page. This is the property that most often passes validation and still fails in practice, because the markup was hardcoded during a redesign and the pricing changed three sprints later.

aggregateRating, and the self-serving ceiling

aggregateRating is the property everyone wants, because it is the one that can put stars under your result. It needs a ratingValue within the declared scale (default 1 to 5) and at least one of ratingCount or reviewCount, and that count has to be a real, non-zero number. A reviewCount of zero invalidates the whole block, so omit the markup until you actually have ratings.

The gap between what schema.org permits and what Google rewards is widest here. Schema.org lets you attach an aggregateRating to your own SoftwareApplication, and it is syntactically valid to do so. Google's review-snippet guidelines are the constraint. For Organization and LocalBusiness, self-serving ratings (an entity publishing rating markup about itself, on its own domain) are not eligible for stars at all, and that has been policy since 2019. For SoftwareApplication and Product, first-party ratings are technically permitted, but they sit under Google's quality filters, and self-published software ratings frequently never render as stars even when the markup validates cleanly. The reliable path to stars runs through pages an independent party controls.

That independence is the reason we built TheWebRatings around verified third-party reviews rather than first-party testimonials. We publish your reviews on an independent public profile with SoftwareApplication, AggregateRating, and Review markup generated from live data, which sidesteps the self-serving problem by not being self-serving. It's free for one website. Whatever source you use, keep ratingValue inside the bestRating scale and make sure the count reflects real reviews, because those are the two checks Google rejects most often.

A complete, valid example

Putting the pieces together, here is a SoftwareApplication block that validates and carries everything Google reads:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "ExampleApp",
  "description": "Time tracking for freelance teams.",
  "url": "https://example.com",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Any",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "89",
    "bestRating": "5",
    "worstRating": "1"
  }
}
</script>

You can build and validate this without hand-writing a character of it. Our review schema generator produces the block from a short form, validates it inline, and hands off to Google's Rich Results Test. For the conceptual background on how star eligibility works, see review schema markup: how to get star ratings in Google, and for the property-level walkthrough of the rating block specifically, how to add AggregateRating schema.

The mistakes that quietly cost you the result

None of these throw an error. That is what makes them expensive.

• Self-serving rating markup. Valid schema, no stars, no warning. The single most common reason a passing SoftwareApplication earns nothing.
• A price that doesn't match the page. The markup says 29.00, the pricing page says 39, and Google drops the result rather than show a stale number.
• reviewCount of zero or a missing count. An aggregateRating with no real count behind it invalidates the block.
• A free-text applicationCategory. Inventing "SaaS platform" instead of using a schema.org value means Google can't classify the item.
• Hardcoded markup that drifted. The block was correct at launch and silently wrong within weeks because it isn't generated from the same data as the visible page.

The through-line is that valid and eligible are different tests. The Rich Results Test checks structure, and it will happily pass markup that Google's ranking and quality systems then decline to reward. Generate the block from live data, keep the numbers honest against the visible page, and route your ratings through a source Google trusts, and the properties above do the rest.