Schema Markup·4 min read

SoftwareApplication Schema Explained: Ratings and OS

You built the app, shipped the landing page, and search results still describe it like a generic website. SoftwareApplication schema explained in one sentence: it's the spec sheet search engines read, declaring your product's category, operating systems, price, and rating in a format that can power richer listings. This guide covers the required software fields, how star ratings actually appear, a worked example, and the mistakes that keep app pages looking plain.

Open the tool All insights

SoftwareApplication schema explained: the app card problem

Why landing pages undersell products.

App stores solve discovery with enforced metadata: every listing has a category, a platform list, a price, and reviews. The open web has no such enforcement, so an indie developer's landing page and a Fortune 500 SaaS page both default to title-plus-snippet in results. SoftwareApplication markup is the voluntary version of the store listing, and Google's software rich results are built from it.

The moment this matters is launch week. A new utility or SaaS tool with markup can surface with its price and rating attached, while the unmarked competitor next to it shows two lines of meta description. Same effort to build, very different shelf presence.

App rating rich results: how SoftwareApplication earns stars

The AggregateRating contract.

Stars come from an aggregateRating node holding ratingValue and ratingCount, and app rating rich results only render when Google trusts the numbers. Trust means the reviews are real, visible on or reachable from the page, and collected by you rather than copied from an app store you don't control.

The eligibility rule is worth memorizing: a SoftwareApplication needs an aggregate rating or an offer with a price to qualify for rich treatment at all. Ship both when you honestly can. A 4.6 from 212 ratings next to a price of 0 is a compelling result for a free tool, and every field of it is checkable.

A worked SoftwareApplication example with OS and rating

A free bookkeeping app, marked up.

Suppose LedgerLite is a free desktop bookkeeping tool for Windows and macOS with 212 reviews averaging 4.6. The core markup: {"@type": "SoftwareApplication", "name": "LedgerLite", "applicationCategory": "BusinessApplication", "operatingSystem": "Windows, macOS", "offers": {"@type": "Offer", "price": "0", "priceCurrency": "USD"}, "aggregateRating": {"@type": "AggregateRating", "ratingValue": "4.6", "ratingCount": 212}}.

Two details deserve attention. The price is the string 0 inside a full Offer node, which is how free is declared, not by omitting the offer. And operatingSystem is a single comma-joined value covering both platforms, exactly what the SoftwareApplication Schema tool produces when you tick two OS boxes.

The required software fields, from Google's side and yours

Minimum viable versus actually useful.

Formally, the required software fields for rich results are name plus rating-or-offer. Practically, thin blocks waste the opportunity: applicationCategory tells Google which vertical you compete in, operatingSystem powers platform filtering, and screenshot URLs give crawlers visual evidence as ImageObject entries.

softwareVersion and datePublished matter more than they look, too. Software results skew fresh, and a version string that updates with your releases is a cheap, honest freshness signal that most competitors never bother emitting.

Round the block out with downloadUrl when users install directly from you, and a provider Organization inside the offer's seller so the company behind the software is named. None of these are gating requirements, but together they turn a minimum viable block into a listing that answers every question a store page would.

SoftwareApplication mistakes that undermine the markup

Patterns from failed validations.

The classic failure is inventing ratings, either fabricated counts or numbers imported from an app store page. Google cross-checks against visible content, and fake review data is squarely in manual action territory. Nearly as common is the missing offer on free products; developers assume no price means free, but absent Offer means ineligible.

Watch also for categories chosen by vibe rather than the enum list, since applicationCategory must be a value like DeveloperApplication, not a marketing phrase. And keep one product per block: marking up a suite page with a single SoftwareApplication describing five tools produces markup that matches nothing users actually download.

Maintenance habits for SoftwareApplication markup

Maintenance beats perfection.

Wire the rating numbers to your real review source so they update together; a page showing 4.8 while the markup says 4.2 is the kind of mismatch that erodes eligibility. And regenerate the block whenever pricing changes, since priceValidUntil quietly expiring or an old price lingering in markup misleads both crawlers and the customers who click through expecting the number they saw.

A third habit: keep the screenshots current. The ImageObject entries should show the interface users will actually meet, and a block referencing images from two redesigns ago is a small credibility leak. Refresh the screenshot URLs and the softwareVersion string together whenever a major release ships, and the markup stays a living document instead of a launch artifact.

SoftwareApplication Schema against the neighboring generators

Software, product, or company.

If you sell a physical or non-software product, the Product Schema Generator is the right builder; SoftwareApplication is specifically for things people install or run. The company behind the app is its own entity, built once with the Organization Schema Generator and referenced consistently as your provider.

For pages mixing several needs, or types outside this family, the Schema Markup Generator covers the general case.

Try it now

Open SoftwareApplication Schema

The tool is one click away. No sign up, no upload, no payment.

Open SoftwareApplication Schema

Write a review