SoftwareApplication schema: a copyable block and the properties that matter

SoftwareApplication is the schema.org type for a piece of software, and the properties that do the work are name, description, applicationCategory, operatingSystem, url, offers with a price and currency, and a publisher or author linked to your Organization markup. WebApplication and MobileApplication are its subtypes: use WebApplication for a browser based product and add browserRequirements, use MobileApplication for an app in a store and add the store URL as downloadUrl. Put the block in JSON-LD inside a script tag on the product page, not the home page, and mark up only what the page actually shows a visitor. The most common mistakes are adding an aggregateRating that is not displayed anywhere on the page, marking a paid product as free because there is a trial, and putting the markup on every page of the site rather than the one page that describes the product.

This page covers the correct block, each property, the subtypes, and how to validate. For a company wide block describing the business itself rather than the product, Organization markup is the right type and the two work together.

A complete, copyable block

{ "@context": "https://schema.org", "@type": "SoftwareApplication", "name": "Example Invoicing", "description": "Invoicing and expense tracking for freelancers and small studios.", "applicationCategory": "BusinessApplication", "applicationSubCategory": "Accounting", "operatingSystem": "Web, iOS 15 or later, Android 10 or later", "url": "https://example.com/invoicing", "softwareVersion": "4.2", "datePublished": "2024-03-11", "softwareHelp": { "@type": "CreativeWork", "url": "https://example.com/docs" }, "featureList": [ "Recurring invoices", "Expense capture", "VAT reports" ], "offers": { "@type": "Offer", "price": "12.00", "priceCurrency": "GBP", "availability": "https://schema.org/InStock", "url": "https://example.com/pricing" }, "publisher": { "@type": "Organization", "name": "Example Software Ltd", "url": "https://example.com" }, "screenshot": "https://example.com/images/invoicing-screen.png"
}

The properties, one by one

Property	What to put in it	Notes
name	The product name exactly as you brand it	Not your company name, unless they are the same
description	One or two sentences on what it does and who for	Match the visible description on the page
applicationCategory	One of schema.org's category values	BusinessApplication, DeveloperApplication, DesignApplication, FinanceApplication, GameApplication, HealthApplication, SecurityApplication and others
applicationSubCategory	A free text narrower category	Useful for distinguishing a product in a crowded category
operatingSystem	The platforms it runs on	Use "Web" for browser based products, and name minimum versions where they matter
url	The canonical product page	One URL, matching the page's canonical tag
offers	An Offer with price and priceCurrency	Use "0" for a genuinely free product. For a range, use AggregateOffer
softwareVersion	The current version	Keep it current or leave it out
featureList	The main capabilities	An array of short strings, or one string
screenshot	An image URL of the product in use	A real screenshot, not a marketing graphic
downloadUrl	Where the app is obtained	The store listing for a mobile app
publisher or author	Your Organization	Connect it to your Organization block with the same URL
aggregateRating	Ratings shown on the page	Only when the ratings are visible to a visitor on that page
review	Individual reviews shown on the page	Same rule, with an author for each

Pricing, trials and tiers

This is where most blocks become inaccurate. Mark up what is true of the page.

• A single price: one Offer with price and priceCurrency. Use the number a buyer pays, and state the currency explicitly.
• Several tiers: use AggregateOffer with lowPrice, highPrice, priceCurrency and offerCount, or list separate Offer objects for each plan.
• Free trial on a paid product: the product is paid, so give the real price. A trial is not a price of zero.
• Free plan plus paid plans: AggregateOffer with lowPrice of 0 and the highest paid price as highPrice is the accurate description.
• Per seat or per month pricing: add priceSpecification with a UnitPriceSpecification so the unit is explicit.

"offers": { "@type": "AggregateOffer", "lowPrice": "0", "highPrice": "49.00", "priceCurrency": "GBP", "offerCount": "3", "url": "https://example.com/pricing"
}

Choosing the subtype

• WebApplication for anything used in a browser. Add browserRequirements, for example "Requires a current version of Chrome, Firefox, Safari or Edge".
• MobileApplication for an app distributed through a store. Add downloadUrl pointing at the store listing, operatingSystem, and fileSize where it is useful.
• VideoGame for a game, which is its own subtype with gameplay specific properties.
• SoftwareApplication itself when the product spans several of these, or for desktop software.

Using a subtype inherits every property of SoftwareApplication, so nothing is lost by being more specific, and the type is a clearer description of what the product is.

Ratings, honestly

aggregateRating and review are the properties most often misused. Two rules keep you right. First, mark up only ratings that a visitor can see on that same page: markup describing content that is not there is a structured data policy breach and it can cost you eligibility for rich results. Second, Google's guidance treats reviews written or collected by the business about itself as self serving, and those are not eligible for review snippets. Where your ratings come from a third party platform, show them on the page with the source named and mark up what is shown.

Where to put the block and how to validate

1. Put one SoftwareApplication block on the product page, in JSON-LD, inside <script type="application/ld+json">. Server rendered is safest.
2. Keep one Organization block, usually on the home page, and reference it from the product block by the same URL so the two are connected.
3. Do not repeat the product block site wide. One page, one description.
4. Validate with the Schema Markup Validator at validator.schema.org for schema correctness, and with Google's Rich Results Test for Google specific checks.
5. Check the Enhancements and the Unparsable structured data reports in Google Search Console after deployment, and again after any template change.
6. Re-run the validation whenever the price, the version or the plan structure changes, because stale markup is worse than none.

Does SoftwareApplication markup improve rankings?

Structured data is not a ranking factor in itself. What it does is state your product's facts in a form machines read without interpretation: the name, the category, the platforms, the price and the publisher. That clarity is what makes a product correctly described wherever its data is reused.

Should I use Product or SoftwareApplication?

Use SoftwareApplication for software, because its properties fit: operating system, version, category, download URL. Product is the right type for physical goods. Where a page sells a boxed physical copy of software, Product with SoftwareApplication detail is a reasonable combination, and most SaaS products need SoftwareApplication alone.

Can I include a free trial in the markup?

Describe the product's real price in offers, and describe the trial in the page content and in the description property. Marking a paid product as free because a trial exists misstates the product.

What applicationCategory should a SaaS tool use?

Pick the closest value from schema.org's list, which for most business software is BusinessApplication, then narrow it with applicationSubCategory in your own words. An invented applicationCategory value is less useful than a correct broad one plus a precise subcategory.

Do I need markup on every page of the product?

No. One block on the page that describes the product, plus Organization on the site, covers it. Duplicating the product block across features pages and blog posts creates conflicting descriptions of the same product.

How do I handle several products on one site?

One SoftwareApplication block per product, each on its own product page, each with its own name, description and offers, all referencing the same publisher Organization. That is how the relationship between the company and its products is expressed.

One audience reading this markup now

Structured data was built for search engines, and it has a second audience. When somebody asks ChatGPT, Gemini, Perplexity, Claude or Google's AI Overviews which software to use for a job, the answer is assembled from whatever can be read quickly and unambiguously about each product: the category, the platforms, the price and who makes it. Clear markup and a consistent description across your site give those answers one version of your facts to work from. Each of the five assistants answers differently and cites different sources, so the companies named vary.

It is worth checking what they currently say when somebody asks for software like yours, without naming your own product in the prompt so the answer is not steered. AI Knows Us runs that check and shows which sources each answer is drawn from.