Software Application Schema: What SaaS Can Mark Up

TL;DR Any SaaS product page can carry valid SoftwareApplication markup with a name, a category, an operating system and a price that matches the page. Google's software app rich result also requires a rating or a review, and almost no early-stage SaaS has honest, on-page review data that qualifies. Ship the minimal, truthful version, validate it, and don't invent stars to chase a snippet Google never promised you.

Picture a founder who pastes his homepage source into a chat and asks why his "schema isn't working." Inside the JSON-LD there is an aggregateRating of 4.9 from 127 ratings. The product launched six weeks ago and has 31 paying users. The number came from a generator that pre-filled it, or from a template copied from a competitor. Either way, the page contains no reviews at all.

That block is broken, but not in the way he thinks. It passes a syntax check. It might even pass Google's Rich Results Test. What's wrong with it is that it describes a page that doesn't exist, and Google's structured data guidelines name that exact pattern as grounds for a manual action.

This post covers what a small SaaS product page can honestly mark up, the gap between valid Schema.org and Google feature eligibility, and a checklist to run before you ship.

Software application schema: valid markup vs rich result eligibility

Most bad advice about schema markup for SaaS mixes up two questions.

Is it valid Schema.org? Schema.org's SoftwareApplication type is a vocabulary. It inherits from CreativeWork and Thing, defines properties like applicationCategory, operatingSystem, offers, featureList, softwareVersion and screenshot, and has subtypes including WebApplication and MobileApplication. Schema.org has no required properties. If your JSON-LD uses real types and real properties in the right shape, it's valid.

Is it eligible for a Google rich result? That's a separate, stricter test. Google's Software App structured data docs list three required properties:

Property	Google status	What it means for a SaaS page
name	Required	Your product name, as shown on the page
offers.price	Required	The price; Google says to set it to 0 if the app is available without payment
aggregateRating or review	One required	A real rating or review, following the review snippet guidelines
applicationCategory	Recommended	Must be a supported value, such as BusinessApplication or DeveloperApplication
operatingSystem	Recommended	The OS needed to use the app

The same docs say Google also supports the MobileApplication and WebApplication subtypes, and that a page typed only as VideoGame won't get a rich result. Google's wording on eligibility: "You must include the required properties for your content to be eligible for display as a rich result."

So software application schema with name, price and category but no rating is perfectly valid Schema.org and also not eligible for the Google feature. Both are true at once. Most SaaS pages in their first year should be in exactly that state.

Why the rating requirement is the whole story

The rating requirement is where honest markup and rich-result chasing split.

Google's review snippet guidelines apply to whatever rating you add, and three of them rule out almost every shortcut I see:

"Make sure the review content you mark up are readily available to users from the marked-up page." If the stars are only in the JSON-LD, they don't count.
"Don't aggregate reviews or ratings from other websites." Your G2 or Capterra average doesn't belong in your own markup.
"Don't include fake or undisclosed incentivized reviews on your page or in your structured data markup."

Google's general structured data guidelines back this up: "Don't mark up content that is not visible to readers of the page," and "Don't mark up irrelevant or misleading content, such as fake reviews." The same page says misleading markup can lead to a manual action that removes rich result eligibility. It also says a structured data manual action "doesn't affect how the page ranks in Google web search." That isn't permission. It just means the penalty lands on the feature you were trying to win.

Here's my contrarian position: for a sub-DR-20 SaaS, the software app rich result isn't worth building for. You'd need a real review system on the product page, collecting reviews from actual users, displayed visibly, with an honest count. That's a product feature, not an SEO task. If you already have it, mark it up. If you don't, the markup is a description of your product, not a ranking lever, and should be treated that way.

Even perfect markup comes with no promise. Google is explicit: "Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test."

What a SaaS product page can honestly mark up

Strip out the rating and you're left with what's true and visible on almost any product or pricing page:

name: the product name in your H1 or logo text.
description: a sentence that matches the copy on the page.
url: the canonical URL of the page.
applicationCategory: one of Google's supported values. Most B2B tools fit BusinessApplication, and dev tools fit DeveloperApplication.
operatingSystem: for a browser-based SaaS, "Web" is the plain-language answer. Google's examples use strings like "Windows 7" and "Android 1.6", so list real platforms if you ship desktop or mobile apps.
offers: only if the price is on the page. A free plan with a visible price of zero can go in as price 0. A paid starting price can go in with priceCurrency, which Google recommends whenever the price is above 0.
featureList and screenshot: optional Schema.org properties. Use them only if the features and screenshots are actually on the page.

What to leave out: aggregateRating, review, softwareVersion if you deploy continuously and the page doesn't show a version, and any price that only appears behind a login or a "contact sales" form.

A minimal software application schema example

Below is a software application schema example for a fictional web app. Everything in it is illustrative. The product name, URL, description and price are placeholders. Replace each value with what's actually on your page, and delete any line you can't back up.

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "ExampleApp",
  "url": "https://www.example.com/",
  "description": "ExampleApp turns support tickets into a weekly bug report for small product teams.",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": 0,
    "priceCurrency": "USD"
  }
}

Some notes on the choices:

WebApplication instead of SoftwareApplication. It's a Schema.org subtype, and Google lists it as supported. If your product is a desktop app or ships on several platforms, plain SoftwareApplication is fine.
price 0 only if there's a visible free plan. If your cheapest plan is 19 dollars a month and the page says so, use that number. If the page has no prices, drop the offers block. You lose rich result eligibility, but you already lost it by not having a rating.
No aggregateRating. This block is valid Schema.org and won't produce Google's software app rich result. That's on purpose.

Put it in a script tag of type application/ld+json in the page head or body. Google's general guidelines list JSON-LD as the recommended format. For a framework site, render it from the same data that renders the visible pricing table, so the two can't drift apart.

About software application schema generators

Search for a software application schema generator and you'll find dozens of form-based tools. They're fine for getting the JSON shape right. The problem is their defaults. Many show rating and review fields next to name and price, so it looks like every field should be filled in. A founder who wants the rich result fills them in.

My advice: use a generator to get the structure, then go through the output line by line against the live page. For every value, point to where a visitor can see it. If you can't, delete the line. Ten minutes of that matters more than which generator you picked.

Verification checklist before you ship

Run this on every page that carries SoftwareApplication markup:

Every value is visible on the page. Name, description, price, features. If a visitor can't see it, it doesn't go in the markup, per Google's general structured data guidelines.
No borrowed or invented ratings. No third-party averages, no placeholder numbers, no review markup without visible reviews.
Price matches the pricing table. Including currency. Update the markup in the same commit that changes prices.
applicationCategory is on Google's supported list. "SaaS" and "Productivity" aren't supported values; the software app docs list the accepted ones.
Validate against Schema.org. The Schema Markup Validator checks vocabulary and syntax, regardless of Google features.
Test Google eligibility separately. The Rich Results Test shows whether Google sees a supported feature. If it says the page isn't eligible because the rating is missing, that's the correct result for the honest example above, not a bug.
Check the rendered page. After deploying, use URL Inspection in Search Console to confirm Google sees the markup on the live URL, which Google recommends in the software app docs.
The page is indexable. Google's structured data guidelines say not to block structured data pages to Googlebot with robots.txt, noindex, or any other access control. Markup on a page Google can't crawl does nothing.

Steps 5 and 6 are the ones people merge. One tool tells you the markup is correct. The other tells you whether Google offers a feature for it. You need both answers, and they can disagree.

Where this fits in your technical hygiene

Structured data is a small task, and it should stay small. Put it in your template once, generate it from real page data, and add a line to your blog post SEO pre-publish checklist so new landing pages and pricing changes don't ship with stale markup. If you're still working through the bigger list, the SaaS SEO checklist for your first six months puts schema where it belongs: after indexing, URLs and internal links, not before.

Those come first because they decide whether you rank at all. A product page with tidy URLs (see my notes on SEO-friendly URLs for a SaaS blog) and real internal links from your content (worth checking with an internal link audit of your content clusters) does more for a low-authority site than any JSON-LD block. Markup describes the page. It doesn't make Google rank it.

That's the same idea behind how I build Boomranq. A small SaaS site doesn't win by copying what incumbents have, whether that's star ratings, backlinks, or 2,000-word guides on head terms. It wins by picking the queries it can actually rank for and keeping the basics clean. Software application schema is one of those basics: valid, honest, five minutes of work, and nothing more.