SoftwareApplication Schema

TL;DR — SoftwareApplication schema is code you add to a page about an app or software tool that labels the details for search engines — “this is the app’s name,” “this is what it costs,” “this is the operating system it runs on,” “these are its star ratings.” Adding it correctly makes the page eligible for Google’s Software App rich result, which can show the rating, review count, price, and OS right in the search listing. It’s a different schema type from Product, and the ratings you mark up have to be real.

What SoftwareApplication schema is

When you look at an app’s page, you can read the name, the price, “works on Windows,” and the ⭐ ratings without thinking about it. A search engine sees plain text and has to guess what each bit means. SoftwareApplication schema spells it out in code, using the shared schema.org vocabulary — it tags the name, the category, the operatingSystem, the price, and any user ratings so Google knows exactly what it’s looking at.

It’s almost always written as JSON-LD — a small block of code that sits in the page without changing how the page looks.

Why it’s worth doing

The payoff is the Software App rich result: when a page qualifies, Google can show the star rating, the number of reviews, the price, and the operating system directly in the search snippet. A listing that shows “4.6 ★ · 8,864 reviews · Free · Android” is more eye-catching than a plain blue link, and that can earn more clicks.

The three things you almost always need

To be eligible for the Software App rich result, Google asks for the app’s name, an offer (its price — use 0 if it’s free), and at least one of a review score (aggregateRating) or a single review. Two more are strongly recommended:

• applicationCategory — the type of app, like BusinessApplication or GameApplication (Google only accepts values from its own fixed list).
• operatingSystem — what it runs on, like Windows, Android, or a browser.

The thing most people get wrong

SoftwareApplication is not “Product schema for software.” They’re two different schema.org types with different required fields and different search results. If your app is a SaaS tool or a downloadable program, SoftwareApplication is usually the right one — reaching for Product schema (built for physical, purchasable goods) misses the fields Google actually checks for the Software App result. More on that in the Advanced tab.

Two more beginner traps:

• Valid markup ≠ guaranteed rich result. It makes you eligible; Google still decides whether to display it — and eligibility doesn’t promise more downloads, higher rankings, more clicks, or AI-search citations either.
• The ratings have to be real. Genuine, user-sourced ratings only — fabricated or paid-for stars can trigger a manual action, not just a failed validation.

Want the full version — the required-vs-recommended split, the applicationCategory enum, choosing the right subtype, the Product-schema comparison, and the ratings rules? Switch to the Advanced tab.

TL;DR — schema.org/SoftwareApplication markup (usually JSON-LD) makes an app or software page eligible for Google’s Software App rich result (rating, review count, price, OS in the snippet). Google’s required fields are narrow: name, offers (with price; 0 for free apps, priceCurrency recommended once price

0), and at least one of aggregateRating or review. applicationCategory (from a fixed enum) and operatingSystem are recommended. The rest of the large schema.org property list (downloadUrl, fileSize, screenshot, permissions…) is spec-valid but SEO-inert for this result. Prefer the most specific subtype (WebApplication, MobileApplication, VideoGame) over generic SoftwareApplication. It’s a separate type from Product with a separate rich-result surface — a paid SaaS/web app should generally use SoftwareApplication, not Product. Ratings must be genuine and user-sourced; fabricated or misleading review markup violates Google’s structured-data policies.

What SoftwareApplication schema unlocks

The concrete payoff is the Software App rich result — Google’s enhanced listing for app and software pages that can surface the star rating, review count, price, and supported operating system in the snippet. schema.org describes the type itself in a single line — “A software application.” — and Google’s Search Central docs turn that into a specific eligibility spec for the rich result. The whole point of getting this markup right is to be eligible for that snippet; valid markup only puts you in the running, it doesn’t guarantee display — and it doesn’t promise downloads, rankings, CTR, star visibility, or AI-search citations either. Google says it plainly: “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly.”

Required and recommended properties

Google’s requirements here are refreshingly narrow — narrower than most third-party guides make them look. Here’s the actual split from Google’s Software App docs:

That’s the entire eligibility surface. name + offers + one-of-rating/review, with applicationCategory and operatingSystem as the two recommendations worth adding every time.

Handling free apps vs. paid apps

Google is explicit about free apps: “If the app is available without payment, set offers.price to 0.” Don’t drop offers entirely because the app is free — offers is on the required list; a free app should include it with price: 0, not omit it. And for paid apps: “If the app has a price greater than 0, we recommend also including the offers.priceCurrency property (or Google will try to find the right currency).” So set priceCurrency to a valid ISO 4217 code like USD once you’re charging anything.

The applicationCategory enum — and the quiet mistake it causes

applicationCategory only accepts values from Google’s documented list. The accepted values are:

GameApplication · SocialNetworkingApplication · TravelApplication · ShoppingApplication · SportsApplication · LifestyleApplication · BusinessApplication · DesignApplication · DeveloperApplication · DriverApplication · EducationalApplication · HealthApplication · FinanceApplication · SecurityApplication · BrowserApplication · CommunicationApplication · DesktopEnhancementApplication · EntertainmentApplication · MultimediaApplication · HomeApplication · UtilitiesApplication · ReferenceApplication

You can also use the schema.org URL form (e.g. https://schema.org/GameApplication), but the plain text string is standard practice. Here’s the trap: a value outside that list — say a descriptive "Productivity Software" — isn’t a hard error. Google just silently ignores it, so the rest of your markup validates and you never see a warning, but the field isn’t doing anything. That quiet no-op is one of the most common mistakes I’d expect to find auditing app pages.

Choose the most specific subtype

SoftwareApplication has several more specific subtypes in schema.org — its “More specific Types” are MobileApplication, WebApplication, VideoGame, OperatingSystem, and RuntimePlatform. Where one fits, use it instead of the generic type:

• WebApplication — a browser-based SaaS tool (this is the common case for the audience I write for).
• MobileApplication — a native iOS/Android app.
• VideoGame — a game, but see the caveat below — VideoGame alone isn’t enough for the rich result.

Google’s Software App eligibility docs treat SoftwareApplication, MobileApplication, and WebApplication interchangeably, so specificity costs you nothing in eligibility for those three and adds precision. VideoGame is the one exception: Google is explicit that “Google doesn’t show a rich result for Software Apps that only have the VideoGame type. To make sure that your Software App is eligible for display as a rich result, co-type the VideoGame type with another type” — Google’s own example co-types it with MobileApplication, e.g. "@type": ["VideoGame", "MobileApplication"]. So a game page needs VideoGame plus another eligible application type in the same @type array, not VideoGame on its own. If you run a SaaS product, WebApplication is usually the honest, precise choice.

SoftwareApplication vs. Product schema — the disambiguation that matters

This is the confusion I most want to clear up, because SaaS marketers reach for Product schema reflexively — the app is “a thing you buy,” so Product feels right. It usually isn’t the right pick. The right call follows what the page’s entity actually is and which Google feature you’re targeting — not a blanket rule that every SaaS, boxed-software, subscription, or app-marketplace page defaults to one type.

SoftwareApplication and Product are separate schema.org types with separate required/recommended fields and separate Google rich-result surfaces:

• SoftwareApplication cares about operatingSystem and applicationCategory, and feeds the Software App rich result.
• Product cares about gtin/mpn/sku/brand, availability, shipping and returns, and feeds product snippets and merchant listings — surfaces built around physical, purchasable goods and (optionally) a Google Merchant Center feed.

Those Product-side conventions — GTIN/MPN catalog matching, shipping details, merchant feeds — don’t map cleanly onto software. A downloadable app or a SaaS subscription doesn’t have a UPC or a shipping policy. So for installable or runnable software with an OS and a category, use SoftwareApplication (or a subtype). Reach for Product schema only when the item genuinely behaves like a generic sellable good — for instance boxed software sold like a retail SKU, or a subscription you’re deliberately modeling as a plain purchasable product rather than as the application itself. Picking the wrong type means Google checks for fields your markup doesn’t have and misses the ones that actually drive the result you want. (The Product schema article on this site goes deep on that side; this is the app-native counterpart to it.)

These aren’t always forced either/or nodes, either. Google’s own worked example for VideoGame co-types it with MobileApplication in the same @type array rather than picking one — proof that a single entity can carry more than one type when it genuinely is more than one thing. The same logic applies here: if a page’s entity truthfully is both an application and a generically sellable good, co-typing (or a @graph with both nodes) can be the honest answer. Don’t reach for that as a default hedge — do it because the entity actually supports both, and document why.

Reviews and ratings — the eligibility rules that actually matter

Because aggregateRating/review is part of the required set, the ratings rules are load-bearing here, and Google incorporates its general Review snippet guidelines by reference: the aggregateRating and review docs both say to “Follow the Review snippet guidelines and list of required and recommended” properties. The rules that bite:

• Ratings must come from real users. Google: “Ratings must be sourced directly from users.”
• Don’t pull in other sites’ ratings. Google: “Don’t aggregate reviews or ratings from other websites.”
• If you show individual reviews, also show an aggregate. Google: “If you include multiple individual reviews, also include an aggregate rating of the individual reviews.”

One nuance worth getting right, because it’s easy to over-state. There’s a self-serving-reviews ineligibility rule that gets quoted a lot — “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” Note what it’s scoped to: LocalBusiness/Organization markup. Google’s review-snippet docs list SoftwareApplication among the normal reviewable item types (alongside Product, Book, Course, Game, Movie, Recipe, and others), and it is not swept into that specific LocalBusiness/Organization ban. So app schema ratings on your own page are eligible — but that’s not a loophole. They still have to be genuine and user-sourced, and Google’s broader fake-review enforcement (removal at scale, spam policies, manual actions) applies to app ratings just like everything else.

Which leads to the warning I want to make loudly, because most competitor guides skip it entirely: fabricated, incentivized, or editorially-curated ratings are a manual action risk, not just a validation problem. Google’s own guidelines section on the Software App page ties back to Search Essentials and the general structured-data policies: “If your site violates one or more of these guidelines, then Google may take manual action against it. Once you have remedied the problem, you can submit your site for reconsideration.” And it’s worth understanding how much a rich-result manual action can escalate — see the Quotes tab for Danny Sullivan’s general statement that a rich-result manual action can lead to your rich results being removed and can widen into a broader spam manual action that affects ranking. That’s general rich-result policy, not a SoftwareApplication-specific ruling — but it’s exactly why casually faking app stars is a bad trade.

Other schema.org properties worth knowing — but not required

schema.org gives SoftwareApplication a big property list beyond the required set: downloadUrl, installUrl, fileSize, screenshot, featureList, softwareVersion, permissions, memoryRequirements, storageRequirements, operatingSystem, applicationSubCategory, applicationSuite, and more. A few, with schema.org’s own descriptions:

• downloadUrl — “If the file can be downloaded, URL to download the binary.”
• fileSize — “Size of the application / package (e.g. 18MB). In the absence of a unit (MB, KB etc.), KB will be assumed.”
• permissions — “Permission(s) required to run the app (for example, a mobile app may require full internet access or may run only on wifi).”
• screenshot — “A link to a screenshot image of the app.”

These are all valid and can help other consumers (AI agents, aggregators, your own tooling) understand the app — but none of them are required or recommended by Google’s Software App rich-result docs, and none of them affect rich-result eligibility. I’m calling this out because third-party guides routinely pad their “requirements” lists with downloadUrl, screenshot, and fileSize to look comprehensive, leaving readers polishing fields that do nothing for the snippet they’re chasing. Add them if they’re useful for other reasons; don’t add them thinking they’ll earn or improve the rich result.

Bing and other engines

Bing supports schema.org and JSON-LD broadly and validates markup through its Markup Validator, but it doesn’t publish a dedicated “Software App” required/recommended property table or a distinct app rich-result surface the way Google does. So schema.org/SoftwareApplication is valid, generically-supported markup on Bing — there’s just no bespoke Bing app rich result to target. Bing recognizing the same vocabulary isn’t feature parity with Google’s Software App result: don’t assume the same markup earns you an equivalent rating/price/OS snippet on Bing, since Bing hasn’t documented that it builds one.

Where this sits in the bigger picture

SoftwareApplication is one type in the wider structured data / schema markup world, and the ratings mechanics it leans on are shared with the review and aggregateRating vocabularies. For a paid app, the Product schema article is its closest neighbor and the place to go when you decide the item really is a generic sellable good rather than the application itself. And if your implementer is a SaaS marketing team, this markup usually lives on the same pricing and landing pages that the broader SaaS SEO work covers.

AI summary

A condensed take on the Advanced version:

• What it is: schema.org/SoftwareApplication markup (usually JSON-LD) that labels an app/software page’s name, category, OS, price, and ratings so Google can show a Software App rich result (rating, review count, price, OS in the snippet).
• Required for eligibility: name, offers (with price; 0 for free apps, priceCurrency recommended once price > 0), and at least one of aggregateRating or review.
• Recommended: applicationCategory (from Google’s fixed enum) and operatingSystem. An out-of-list applicationCategory value is silently ignored, not flagged — a common quiet mistake.
• Subtypes: prefer the most specific — WebApplication (SaaS/browser tools), MobileApplication (native apps), VideoGame (games) — over generic SoftwareApplication. Specificity costs nothing in eligibility except for VideoGame: Google won’t show the rich result for VideoGame alone — co-type it with another application type (Google’s own example: ["VideoGame", "MobileApplication"]).
• vs. Product schema (the key confusion): separate types, separate required fields, separate rich-result surfaces. SoftwareApplication cares about operatingSystem/ applicationCategory; Product cares about gtin/mpn/shipping/merchant feeds. Use SoftwareApplication for installable/runnable software with an OS and category; use Product only when it’s genuinely a generic sellable good (e.g. boxed software as a retail SKU).
• Ratings: must be genuine and user-sourced; don’t aggregate other sites’ ratings; if you show individual reviews, include an aggregate. The self-serving-reviews ineligibility rule is scoped to LocalBusiness/Organization, not SoftwareApplication — app ratings on your own page are eligible, but must be real. Fake/incentivized ratings risk a manual action, and a rich-result manual action can escalate into a broader ranking-affecting one (general Google policy, not app-specific).
• Spec-valid but SEO-inert: downloadUrl, fileSize, screenshot, permissions, featureList, softwareVersion — fine to add for other consumers, but they don’t affect the Software App rich result.
• Bing: supports schema.org/JSON-LD generically; no dedicated app rich-result spec.
• Eligibility ≠ display: valid markup only makes the page eligible — not guaranteed downloads, rankings, CTR, or AI-search citations.
• VideoGame exception: Google won’t show the rich result for VideoGame alone — co-type it with another eligible application type (e.g. MobileApplication).

Official documentation

Primary-source documentation from the search engines and the spec.

Google — the Software App rich result

• Software App (SoftwareApplication) structured data — the required/recommended property list, the applicationCategory enum, the free-app price: 0 rule, the VideoGame co-typing requirement, and the worked example.
• Review snippet (Review, AggregateRating) structured data — the rating rules incorporated by reference: user-sourced ratings, no cross-site aggregation, and the self-serving-reviews scope (LocalBusiness/Organization).
• General Structured Data Guidelines — the spam-policy backbone; no guarantee of display even with correct markup, and the prohibited practices behind manual actions.
• Rich Results Test — validate the markup and check rich-result eligibility.

Spec — schema.org

• schema.org/SoftwareApplication — the type definition, subtypes (MobileApplication, WebApplication, VideoGame, OperatingSystem, RuntimePlatform), and the full property list.
• schema.org/applicationCategory and schema.org/operatingSystem — the two recommended properties.

Bing / Microsoft

• Marking up your site with structured data — Bing’s general schema.org/JSON-LD support.

Quotes from the source

On-the-record statements from Google and the spec. Where a source page exposes the text, the link is a deep link that jumps to the quoted passage.

Google docs — required and recommended fields

• “The name of the app.” — Google Search Central, Software App structured data (name). Jump to quote
• “An offer to sell the app. For developers, offers can indicate the marketplaces that carry the application.” — Google Search Central (offers). Jump to quote
• “If the app is available without payment, set offers.price to 0.” — Google Search Central. Jump to quote
• “The type of app (for example, BusinessApplication or GameApplication).” — Google Search Central (applicationCategory). Jump to quote
• “The operating system(s) required to use the app (for example, Windows 7, OSX 10.6, Android 1.6).” — Google Search Central (operatingSystem). Jump to quote

Google docs — the VideoGame co-typing rule

• “Google doesn’t show a rich result for Software Apps that only have the VideoGame type. To make sure that your Software App is eligible for display as a rich result, co-type the VideoGame type with another type.” — Google Search Central, Software App structured data. Jump to quote

Google docs — reviews and ratings (incorporated by reference)

• “Ratings must be sourced directly from users.” — Google Search Central, Review snippet docs. Review snippet docs
• “Don’t aggregate reviews or ratings from other websites.” — Google Search Central, Review snippet docs. Review snippet docs
• On self-serving reviews (scoped to LocalBusiness/Organization, not SoftwareApplication): “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” Review snippet docs

Google docs — no guarantee of display

• “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly.” — Google Search Central, General Structured Data Guidelines. Jump to quote

Danny Sullivan, Google (general rich-result manual-action policy, via Search Engine Roundtable — not SoftwareApplication-specific)

• A rich-result manual action can lead to the removal of your rich results from displaying in Google Search, and can also escalate into a broader spam manual action that involves ranking. Read the coverage

SoftwareApplication schema cheat sheet

The minimum for the Software App rich result

name + offers (with price; 0 for free apps) + at least one of aggregateRating / review.

Recommended (add every time)

Pick the most specific type

SoftwareApplication vs. Product — which one?

applicationCategory enum values

GameApplication · SocialNetworkingApplication · TravelApplication · ShoppingApplication · SportsApplication · LifestyleApplication · BusinessApplication · DesignApplication · DeveloperApplication · DriverApplication · EducationalApplication · HealthApplication · FinanceApplication · SecurityApplication · BrowserApplication · CommunicationApplication · DesktopEnhancementApplication · EntertainmentApplication · MultimediaApplication · HomeApplication · UtilitiesApplication · ReferenceApplication

Spec-valid but SEO-inert (don’t affect the rich result): downloadUrl, installUrl, fileSize, screenshot, featureList, softwareVersion, permissions, memoryRequirements, storageRequirements.

Fast facts

• Format: JSON-LD (Google’s recommended format).
• Valid markup = eligible, not guaranteed to show.
• Ratings must be genuine + user-sourced; fabricated stars = manual-action risk.
• Self-serving-review ban = LocalBusiness/Organization only, not SoftwareApplication.

SoftwareApplication vs. Product schema — which one for my app or SaaS page?

Work down the questions to land on the right type for the page you’re marking up.

SoftwareApplication schema myths and mistakes to avoid

Myth: “Any star-rating markup on an app page qualifies for the Software App rich result.” Ratings must be genuine and user-sourced per the Review snippet guidelines that the Software App docs incorporate by reference. Fabricated, incentivized, or editorially-curated ratings aren’t just a rendering failure — they’re a manual-action risk. Google’s guidelines section warns that “Google may take manual action” against sites that violate them, and a rich-result manual action can escalate into a broader, ranking-affecting one.

Myth: “SoftwareApplication is just Product schema for a paid app.” They’re distinct schema.org types with different required/recommended fields (operatingSystem and applicationCategory vs. gtin/mpn/brand/shipping) and different Google rich-result surfaces. Marking up a SaaS product as Product means Google checks for fields your page doesn’t have and skips the ones the Software App result actually reads.

Myth: “You need every schema.org/SoftwareApplication property (downloadUrl, fileSize, screenshot, permissions…) to get the rich result.” Google’s eligibility set is narrow — name, offers, one of aggregateRating/review, with applicationCategory/operatingSystem recommended. The rest of the big property list is spec-valid but SEO-inert for this result. Don’t burn time polishing fields that don’t move the snippet.

Myth: “applicationCategory accepts any descriptive text like ‘Productivity Software’.” Google only recognizes its fixed enum (BusinessApplication, UtilitiesApplication, and so on). Anything outside the list is silently ignored, not flagged — so the field looks fine and does nothing. Pick the closest enum value.

Myth: “SoftwareApplication ratings are exempt from the self-serving-reviews rule, so anything goes.” True that SoftwareApplication isn’t swept into the LocalBusiness/Organization-scoped ineligibility rule — but it’s still bound by the general genuine-rating, user-sourced, no-aggregation requirements and by Google’s broader fake-review enforcement. “Eligible” is not “unpoliced.”

Myth: “Free apps don’t need offers.” offers is on Google’s required list. A free app should include it with price: 0 — omitting offers entirely because the app costs nothing breaks eligibility. Google literally says “set offers.price to 0,” not “drop it.”

Mistake: aggregating ratings from app stores or review sites into your own markup. Google’s rule is a flat “Don’t aggregate reviews or ratings from other websites.” The ratings in your markup have to be the ones you collected from your own users.

Clean vs. broken SoftwareApplication JSON-LD

A minimal free web app (WebApplication subtype)

Free SaaS tool, price: 0, a real applicationCategory enum value, operatingSystem, and a genuine aggregate rating:

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Acme Invoice Builder",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web browser",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "ratingCount": "1284"
  }
}

A paid SaaS app (priceCurrency set, price greater than zero)

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Acme Analytics Pro",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web browser",
  "offers": {
    "@type": "Offer",
    "price": "29.00",
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "612"
  }
}

The same app, broken

Every line flagged below is a real, common failure:

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Acme Analytics Pro",
  "applicationCategory": "Productivity Software",
  "offers": {
    "@type": "Offer",
    "price": "$29.00",
    "priceCurrency": "dollars"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5"
  }
}

What’s wrong:

• applicationCategory: "Productivity Software" — not a Google enum value, so it’s silently ignored. Use "BusinessApplication" (or the closest listed value).
• price: "$29.00" — a currency symbol breaks the numeric parse. Use "29.00".
• priceCurrency: "dollars" — must be a valid ISO 4217 code: "USD".
• aggregateRating with no reviewCount/ratingCount — an aggregate rating needs a count to be valid.
• No operatingSystem — recommended; add it (e.g. "Web browser", "Android").

Common Search Console messages → fixes

Test yourself: SoftwareApplication Schema

Five quick questions on schema.org/SoftwareApplication, the Software App rich result, and how it differs from Product schema. Pick an answer for each, then check.

Resources worth your time

My writing on this topic

I haven’t published a standalone SoftwareApplication schema guide of my own — so rather than point you at something that doesn’t exist, the honest move is to send you to the primary sources below and to the related structured-data work on this site. For the broader vocabulary and where SoftwareApplication fits, see the Schema Markup and Structured Data hubs; for the app-adjacent-but-different case, the Product schema article; and for the AI angle, Schema Markup for AI.

From around the industry

• Software App (SoftwareApplication) structured data (Google Search Central) — the authoritative required/recommended property list, the applicationCategory enum, and the free-app price: 0 rule.
• Review snippet structured data (Google) — the rating rules the Software App docs incorporate by reference (user-sourced ratings, no aggregation, self-serving-review scope).
• General Structured Data Guidelines (Google) — the spam-policy backbone and the “no guarantee of display” statement.
• schema.org/SoftwareApplication — the spec: type definition, subtypes, and the full property list.
• Google Says Rich Results Manual Actions Can Lead To Removal Of Rich Results & Broader Spam Penalties (Search Engine Roundtable) — Danny Sullivan’s general statement on how a rich-result manual action can escalate.
• Marking up your site with structured data (Bing Webmaster Tools) — Bing’s general schema.org/JSON-LD support.

SoftwareApplication Schema

SoftwareApplication schema (schema.org/SoftwareApplication) is structured data that tells search engines an app's name, category, operating system, price, and rating so it can appear in Google's Software App rich result. It's a distinct type from Product schema, with its own required and recommended fields.

Related: Structured Data, Product Schema

SoftwareApplication Schema

SoftwareApplication schema is the schema.org/SoftwareApplication structured-data vocabulary you add — usually as JSON-LD — to a page about a downloadable, installable, or web-based app, game, or software product. It tells search engines the app’s name, applicationCategory, operatingSystem, price (offers), and user ratings (aggregateRating or review) so that, if the page qualifies, Google can show a Software App rich result with the star rating, review count, price, and OS in the search snippet.

For Google’s Software App rich result the required fields are narrow: name, offers (with a price — set it to 0 for free apps), and at least one of aggregateRating or review. applicationCategory (from Google’s fixed enum, e.g. BusinessApplication or GameApplication) and operatingSystem are recommended. The larger schema.org property list (downloadUrl, fileSize, screenshot, softwareVersion, and so on) is spec-valid but not required or recommended for the rich result.

It’s a separate schema.org type from Product schema: SoftwareApplication has its own properties (operatingSystem, applicationCategory) and its own rich-result surface, so a paid SaaS or web app should generally use SoftwareApplication (or a subtype like WebApplication or MobileApplication) rather than reaching for Product because the app is “a thing you buy.” Ratings must be genuine and sourced directly from users; fabricated or incentivized ratings risk a manual action, not just a rendering failure.

Related: Structured Data, Product Schema

Changelog