SoftwareApplication Schema for Apps and SaaS Pages

Short answer: SoftwareApplication is a schema.org type that describes an app or software product: its name, category, operating system, price and ratings. Use the more specific MobileApplication or WebApplication type when it fits, fill in name, applicationCategory, operatingSystem and offers, and add ratings or reviews only when they are real and visible on the page. Markup must match the page, and Google’s software app rich result has its own eligibility requirements, so test before you expect results.

Software companies spend a great deal of effort on landing pages, pricing tables and store listings, but often leave the machine-readable description of the product empty. Search engines and AI systems then have to guess whether a page is about an app, a service, a blog post or a download, what it costs and which platforms it supports. Structured data gives them a precise statement. This guide explains the SoftwareApplication family of types, the fields worth filling, how it relates to rich results and the mistakes that cause warnings or wasted work.

What SoftwareApplication describes

SoftwareApplication is a type in the schema.org vocabulary for software of any kind. It inherits general properties from CreativeWork and Thing, such as name, description, image and url, and adds properties specific to software, such as applicationCategory, operatingSystem, softwareVersion and downloadUrl. Two subtypes exist for common cases. MobileApplication describes an app for phones and tablets, and WebApplication describes software that runs in a browser. If your product is a SaaS tool used in a browser, WebApplication is usually the closest match; if it also has a phone app, describe the app on its own page with MobileApplication.

Structured data does not replace good content. It is a label for what the page already says, and it works best when the page is clear and the data agrees with it. For the general picture of how markup helps modern search, see does structured data help in AI search.

Choose the right type and the right page

Add the markup to the page that is about the product: a product landing page, a download page or a features overview. Do not paste the same markup into every page of the site. A blog post that mentions your app is not the app. Each distinct product needs its own page and its own description, and the page should be the main place where people learn about that product.

If you offer one product on several platforms, decide whether you have one page or several. A single page can list operating systems in one property. Separate pages make sense when the products really differ in features, price or audience. The page design advice in feature page SEO for software helps you decide how to structure it.

The fields that matter most

Many properties exist, but a short list covers most needs.

name: the product name as it appears on the page. Do not stuff keywords into it.
description: one or two plain sentences that match the page.
applicationCategory: a general category such as a business, productivity, game or education application. Use values that make sense for the type and are recognised by the search engines you target.
operatingSystem: the platforms the software supports, such as Windows, macOS, Android, iOS or “Any” for a browser-based product. Only list systems that you truly support.
offers: the price, currency and availability, with a price of zero for a free product. The price must match what visitors can actually buy.
aggregateRating and review: real ratings and reviews that visitors can see on the page. See the section below before using them.
image, screenshot and url: a representative picture, screenshots that show the real interface and the canonical address of the page.
softwareVersion, datePublished and downloadUrl: optional details that help when they are accurate and maintained.

Use a publisher or author property where it fits, and connect it to your organisation markup so that systems link the product to the company. The company side is explained in organization schema for AI systems.

A simple example

The following description shows the idea in words rather than code. A browser-based invoicing tool would be typed as WebApplication, named with its brand name, described in a sentence, given the category of business application, the operating system set to any, and one offer with a price in euros and the availability marked as in stock. The URL points to the product page, and an image shows the dashboard. If a free plan exists, a second offer with a price of zero can be listed. Everything in that description should be readable on the page by a visitor, in the pricing section or near the top.

Format the data as JSON-LD in the page head or body, which is the format Google recommends and the easiest to maintain. The comparison in JSON-LD vs Microdata vs RDFa explains the options. Keep the markup in your template, not hand-written on each page, so that changes in price or version reach all places.

Rich results and eligibility

Google has a documented rich result for software applications, which can show details such as rating and price directly in the search result. It has its own requirements: Google’s documentation lists required properties, which typically include the name, an offer with a price, and a rating or review, along with guidelines about which pages qualify. Requirements change, so read the current documentation before you build. Meeting the technical requirements does not guarantee a rich result, because Google decides whether to show it.

The type is valid in schema.org even when no rich result is shown, and it can still help machines understand the page. So treat rich results as a possible bonus, not as the goal. If your product page has no real ratings, do not invent them to qualify; a missing property is far better than a false one.

Ratings, reviews and honesty

Rating markup is the area where most problems occur. The rules are strict and sensible: ratings must come from real users, they must be visible on the page, they must be about the product on that page and they must not be written or selected by the company to look better. Self-serving reviews of your own product, ratings copied from a store without context and made-up numbers can trigger manual actions or loss of eligibility. If you display a rating from an app store, say where it comes from, and make sure the numbers match.

The same caution applies to review markup in general; the discussion in review schema and star ratings lists the typical mistakes. If the page has no reviews, simply leave the properties out.

Common mistakes to avoid

Wrong type: using SoftwareApplication for a blog post or a company homepage, or Article markup for a product page.
Mismatched data: a price in the markup that differs from the price on the page, or platforms listed that you do not support.
Missing visible content: markup for features or ratings that visitors cannot see.
Duplicated markup: several conflicting blocks from a theme, a plugin and a manual snippet, which produce contradictory statements.
Stale details: an old version number, a discontinued plan or an expired offer that nobody updates.
Invalid syntax: a missing comma or bracket makes the whole block unreadable. Tools that read it may report errors or ignore it silently.

The error patterns and fixes are covered in how to find and fix invalid schema.

Test and maintain the markup

After adding the markup, test the page in Google’s Rich Results Test, which checks eligibility for Google features, and in the Schema Markup Validator, which checks against the general vocabulary. Use both because they answer different questions. Then watch Search Console, which reports enhancements and errors for the types it understands. Repeat the checks whenever you change the template, the price, the platforms or the design.

Build maintenance into the release process. When you launch a new version, a new plan or a new platform, update the page and the markup in the same change. Assign an owner, so that the data does not drift away from the page.

Check structured data across the whole site

Structured data errors tend to spread through templates, so one mistake appears on hundreds of pages. A crawl finds invalid JSON-LD, missing fields and mismatches in bulk. Site SEO AI Audit checks structured data on each page, scores your site across seven areas and ranks the fixes by impact. The first audit of up to 200 pages is free, and the pricing page shows how to re-check after each release.

The bottom line

SoftwareApplication markup tells machines what your app is, what it costs and where it runs. Pick the most specific type, add the page that is truly about the product, fill name, category, system and offers accurately, add ratings only if real and visible, validate it and keep it current. Accurate, modest markup beats ambitious markup that does not match the page.

SSS

Should I use WebApplication or SoftwareApplication?

Use WebApplication for software that runs in a browser and MobileApplication for phone apps. Use SoftwareApplication when neither subtype fits.

Do I need ratings to use the markup?

No. The type is valid without ratings. Rich result eligibility has extra requirements, but you should never invent ratings to meet them.

Where should the markup go?

On the page that is about the product, such as the landing or download page. Do not copy it into unrelated pages or blog posts.

How do I mark up a free plan?

Add an offer with a price of zero and the correct currency, and make sure the page clearly shows that a free plan exists.

Which tools should I use to test it?

Use Google’s Rich Results Test for Google features and the Schema Markup Validator for general vocabulary, then watch the enhancement reports in Search Console.