Software application schema tells search engines that a page is about a piece of software: what it is called, what platforms it runs on, what kind of software it is and what it costs. For SaaS companies and app developers, it is the structured data type that fits the product page best, and it is often added carelessly, with an invented rating and a price that no longer matches the pricing table.
There are two sources to read together. Schema.org defines the vocabulary. Google decides which parts of it produce a rich result. They overlap, but they are not the same list. If structured data is new to you, our primer on schema markup covers the basics first.
What schema.org defines
The schema.org SoftwareApplication page describes the type in four words: “A software application”. It has three subtypes: MobileApplication, VideoGame and WebApplication. A browser-based SaaS product is a WebApplication; an app in the phone stores is a MobileApplication; a game is a VideoGame. Using the most specific subtype that is true is the sensible default.
The properties most relevant to a product page are few. applicationCategory is the “Type of software application, e.g. ‘Game, Multimedia’.” operatingSystem covers “Operating systems supported (Windows 7, OS X 10.6, Android 1.6)”. softwareVersion gives the version number, and downloadUrl points to where the software can be downloaded, if it can. A web app that runs in the browser has no download, so leave that property out rather than pointing it at a sign-up page.
What Google requires for software application schema markup
Google’s Search Central documentation for software apps sets a narrower bar for the rich result. It requires name, an offer with a price, and one of aggregateRating or review. On price, it is explicit: “If the app is available without payment, set offers.price to 0”. A free tier or a free app is not a reason to leave the offer out.
Google also recommends applicationCategory and operatingSystem. Unlike schema.org’s free-text example, Google accepts a fixed list of category values. The table pulls the requirements together.
| Property | schema.org | Google rich result |
|---|---|---|
name | Inherited from Thing | Required |
offers.price | Via offers | Required; “set offers.price to 0” if free |
aggregateRating or review | Available | One of the two is required |
applicationCategory | “Type of software application” | Recommended, from a fixed list |
operatingSystem | “Operating systems supported” | Recommended |
softwareVersion | Available | Not listed as required |
downloadUrl | Available | Not listed as required |
The accepted category values include BusinessApplication, DeveloperApplication, FinanceApplication, GameApplication and UtilitiesApplication, among others. Pick the one a user would recognise. A project management tool is a BusinessApplication; an API monitoring service is a DeveloperApplication; a budgeting app is a FinanceApplication. Check Google’s current list before you ship rather than inventing a category of your own, because a value outside the list does nothing.
A software application schema example
Here is a minimal JSON-LD block for a hypothetical web app with a free plan. Every value should match what a visitor sees on the page.
The version, rating and count are placeholders. If the product has paid plans only, put the entry price in the offer and keep it in step with the pricing page; a stale price in the markup is the most common mismatch on SaaS sites. Products sold as physical goods or with merchant details are a different case, covered in our guide to product schema.
The rating rule is where SaaS sites slip
The requirement for a rating or a review is what makes this type awkward. Many SaaS homepages have no reviews on them, so the temptation is to hard-code a ratingValue taken from a review platform or, worse, made up. Ratings in the markup have to be genuine and visible on the page, and Google’s rules on self-serving reviews apply. Our guide to review schema sets those rules out in detail.
The practical answer is to earn the rating before you mark it up. Collect reviews on your own site, show them on the product page, and let the aggregate reflect them. If you have no reviews yet, publish the rest of the markup without a rating and accept that the page is not eligible for the rich result until you do. That is a better position than markup that misrepresents the page.
Where it fits in SaaS SEO
SoftwareApplication markup belongs on the page that is about the product: the homepage for a single-product company, or each product page for a company with several. It does not belong on blog posts, documentation pages or comparison articles. Those pages are about the product, but they are not the product, and marking them all up dilutes the signal.
Companies with several apps should give each one its own page and its own markup. A mobile app and its web counterpart can be marked up separately, as a MobileApplication with an operatingSystem such as Android or iOS, and a WebApplication that runs in the browser, each with its own offer and its own ratings. Merging them into one block blurs which rating belongs to which product, and those ratings rarely match across platforms anyway.
The markup is also only as current as the process behind it. Pricing changes, version numbers and new platforms are routine for software, so the cleanest setup generates the JSON-LD from the same source as the visible page: the pricing table, the release notes, the list of supported systems. Hand-written blocks pasted into a template are where stale prices and outdated version numbers come from.
For the wider picture, from feature pages to integration pages, our guide to SaaS SEO covers how product pages and content pages should divide the work. Schema is a small part of it.
One limitation to be clear about. Valid markup makes a page eligible for a software rich result; it does not guarantee one. Google decides what to show, and passing the Rich Results Test only confirms that the markup is readable and complete. Some properties schema.org defines, such as softwareVersion and downloadUrl, may never show up in the results at all, though they still describe the page accurately for any system that reads the markup. Judge the implementation by whether it is correct, current and honest: the right subtype, a category from Google’s list, a price that matches the pricing page and a rating that real users gave. Then check it again whenever the pricing changes, because that is the field that drifts first. Release cycles move the version number too, so either generate it from the build or leave it out.
Frequently asked questions
What does Google require for SoftwareApplication schema?
The name, an offer with a price, and either an aggregateRating or a review. applicationCategory and operatingSystem are recommended.
How do I mark up a free app?
Keep the offer and set the price to zero. Google’s documentation says: “If the app is available without payment, set offers.price to 0”.
Which subtype should a SaaS product use?
A browser-based product is a WebApplication. Phone apps are MobileApplication and games are VideoGame, all subtypes of SoftwareApplication.
Can I use ratings from a review platform?
Ratings must be genuine and shown on the page, and self-serving review rules apply. Do not hard-code a rating visitors cannot see.
The takeaway Use the most specific subtype, a category from Google’s list and a price that matches the pricing page, set free apps to 0, and only add a rating your real users gave and your page displays.
