SoftwareApplication Schema: Rich Results for Apps

SoftwareApplication schema is the structured data type that describes an app or piece of software to search engines: its name, its price, its category, the platforms it runs on and how users rate it. Google can use that markup to show a software app rich result, typically a star rating, a price or "Free" label and a category under the blue link. The markup is simple to write and surprisingly easy to get wrong, because Google attaches eligibility conditions to it that the schema.org vocabulary itself does not enforce.

This guide covers the part most SaaS and app SEO advice skips: the exact properties Google treats as required, the rules that decide whether a page is allowed to carry the markup at all, and the validation messages and manual actions that show up when it goes wrong. Everything here is about the markup itself, not about how to rank a software site in general.

What SoftwareApplication Schema Actually Is

SoftwareApplication is a type in the schema.org vocabulary, a subtype of CreativeWork. It has two commonly used children that matter for search: MobileApplication, for apps installed on a phone or tablet, and WebApplication, for software that runs in a browser. You can use the parent type for anything that does not fit, such as desktop software, but Google's documentation names all three as valid types for its software app feature, so picking the most specific one is sensible.

The type describes the product, not the page. That distinction drives most of the eligibility rules later in this article. A page about a project-management tool can carry WebApplication markup because the page is about that tool. A blog post that merely mentions the tool cannot, and neither can a comparison page listing fifteen tools, even though each one is technically a piece of software.

Markup is recommended in JSON-LD, placed in a script tag in the head or body of the page. Google also reads Microdata and RDFa, but JSON-LD is the format its documentation uses in examples and the easiest to maintain, because it is separate from the visible HTML and can be generated from the same data your product pages already render.

The Properties Google Requires

Google's software app guidelines split properties into required and recommended. A page missing a required property can still be valid schema.org, and the Rich Results Test will still parse it, but it will not qualify for the rich result. The required set is short.

In practice, the requirement has three parts: an identity, a price and a rating signal. The rating signal is where most teams get stuck, because it forces you to have real user ratings to mark up.

Note the asymmetry: the offer requirement means you cannot earn the feature with a product that has no price information at all. A sales-led enterprise tool with a "Contact us" page has no honest price to declare, and inventing one to satisfy the validator is exactly the kind of mismatch between markup and visible content that gets structured data ignored.

• name: the name of the application as users know it. It should match the name visible on the page.
• offers: an Offer object containing a price. A free app uses a price of 0. Add priceCurrency with an ISO 4217 code such as USD or EUR whenever the price is above zero, and add it for free apps as well so the object is complete.
• aggregateRating, or review: at least one of the two. An aggregateRating needs ratingValue plus either ratingCount or reviewCount. A single review needs an author and a reviewRating with a ratingValue.
• applicationCategory and operatingSystem: Google lists these as recommended rather than required, but you should treat them as mandatory in practice. They are what makes the snippet informative, and they are the properties reviewers look for when a page is flagged.

A Working JSON-LD Example

Here is a minimal, valid block for a web-based tool with a free tier. Every value in it must also be true and visible on the page: the name in the heading, the price near the call to action, the rating in a review section.

{ "@context": "https://schema.org", "@type": "WebApplication", "name": "Taskline", "url": "https://example.com/taskline", "applicationCategory": "BusinessApplication", "operatingSystem": "Any", "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "ratingCount": "812" } }

Three details in that block repay attention. First, ratingValue and ratingCount are written as numbers, not as "4.6 out of 5 stars" or "over 800". Parsers expect plain numerals. Second, applicationCategory uses a value from Google's list of supported categories, such as GameApplication, BusinessApplication, EducationalApplication, HealthApplication or FinanceApplication, rather than a free-text description. Third, operatingSystem is a plain string such as "Android 12", "iOS 16" or "Windows 11", and "Any" is a reasonable value for genuinely browser-based software.

If the rating scale is not one to five, declare it with bestRating and worstRating inside the aggregateRating object. Without them, parsers assume five and one, and a 9.2 out of 10 becomes an invalid value.

Eligibility Rules That Decide Whether It Shows

Passing the validator proves the syntax is acceptable. It does not prove you are eligible. Google's structured data policies, which apply to review and rating markup in general, add conditions that determine whether a rich result is actually shown, and they explain most of the "my markup is valid but nothing appears" complaints.

The first rule is that the markup must describe the main subject of the page. Put SoftwareApplication on the product page, the app's landing page or its store-style listing. Do not site-wide-apply it through a template to your homepage, pricing page and every blog post. A pattern that repeats one aggregateRating across unrelated pages is the classic way to lose trust in a whole domain's structured data.

The second rule concerns ratings. The values must reflect genuine user ratings that visitors can see on the page. Ratings you wrote yourself, ratings copied from another site, and ratings collected by asking only your happiest customers are all outside the spirit of the guidelines. Google's self-serving review policy also limits review markup on pages where the business reviews itself, which is why marking up a testimonial carousel you curated is risky.

The third rule is that markup must match visible content. If the markup says the price is 9.99 and the page says 12, or the markup shows a four-point-eight rating while the page shows no rating anywhere, that is a mismatch. Even when it does not trigger a penalty, it is a reason for the rich result to be withheld.

Finally, eligibility is never a guarantee. Google states that valid markup makes a page eligible, and that whether the enhancement is displayed is decided algorithmically. A page can be eligible for months and show no stars on some queries and show them on others.

Common Rejections and What They Mean

When markup fails, you usually see it in one of two places: the Rich Results Test, or the Software apps enhancement report in Search Console, which lists items as valid, valid with warnings or invalid. The wording is consistent enough to decode quickly.

Errors block the feature entirely, warnings do not, but warnings often point at the fields that make the snippet useful. Treat a warning as a to-do item, not as noise.

• Missing field "offers": the Offer object is absent or has no price. Add an offers object, with price 0 if the app is free.
• Missing field "aggregateRating" or "review": you have a name and a price but no rating signal. You need real ratings on the page before you can mark them up, which is a product and process question, not a markup one.
• Invalid numeric value in field "ratingValue": the value contains text, a comma as decimal separator or a range. Use a plain number with a dot.
• Missing field "ratingCount" or "reviewCount": an aggregate rating needs to say how many ratings it summarises. A rating with no count is meaningless to a parser.
• Missing field "operatingSystem" or "applicationCategory": usually reported as a warning. Adding them improves the snippet and is the quickest fix on the list.
• Item not eligible because the page is not about the application: this one is not a parser error at all. It appears when a listing, comparison or article page carries the type.

Choosing Between the Three Types

Use MobileApplication for apps whose primary home is a mobile store, and set operatingSystem to the real platforms, for example "Android" or "iOS". If the same app ships on both, you can list both in one string. Some teams publish one page per platform, each with its own block, which keeps the price and rating for each store listing accurate.

Use WebApplication for SaaS products that run in the browser. This is where many founders get confused, because SaaS sites are usually marketed as a company rather than an app. The product page for a specific tool is still a legitimate place for the markup. The company homepage is usually better described with Organization, so avoid stacking both types on one URL unless the page truly serves both purposes.

Use SoftwareApplication itself for desktop installers and everything else: a Windows utility, a Mac download, a command-line tool with a landing page. In all three cases the required properties are the same. The type only changes what the platform field is expected to say.

One practical note on duplicates: if the same app appears on several URLs, such as a localised page per language, each page should carry its own markup with a price in the local currency and the rating figure that page displays. Copying one block everywhere invites mismatches.

Implementation and Maintenance Checklist

Generate the JSON-LD from the same data source that renders the visible price and rating. The fastest way to create mismatches is to hardcode the block in a template and let the price change in a database. If ratings are pulled from a third party widget that loads with JavaScript, confirm that the markup is also in the rendered HTML Google sees, not only in the source before scripts run.

Test every change in the Rich Results Test, then watch the Software apps report in Search Console for a few weeks. Validation in a test tool is a snapshot, and the report reflects what Google crawled. A price change, a redesign that removes the rating block or a plugin update can quietly break markup that passed last month.

Keep an eye on the rating count. A count that stays frozen at the number you launched with, while the page shows hundreds more reviews, is a sign the block is hardcoded. Conversely, a count that jumps unexpectedly suggests a script is aggregating something it should not.

• Put the markup only on pages whose main subject is that one application.
• Declare a price, even if it is 0, and keep it equal to the visible price.
• Mark up only ratings that real users can see and that you did not write yourself.
• Use a supported applicationCategory and a real operatingSystem value.
• Re-test after any template, pricing or review-system change.