A new product needs a page that explains it, and its owners usually hope that page will appear in search with some extra detail: a price, a rating, a category. Google has a structured data type for that, documented on its page for software app (SoftwareApplication) structured data. It is short, and some of its requirements surprise people. This article sets out what it says, in our own words, and what follows for anyone building a software product page.
What the markup is for
Google describes the markup as a way to mark up software application information in the body of a web page, to better display app details in search results. Two things in that sentence matter. The information is in the page body, which means it describes what a visitor can see, and the aim is better display, not a ranking change. Google adds that the appearance in search may differ from what a preview shows.
Structured data of any kind is a standardised format that describes and classifies page content. If you are new to it, our article on what Google supports and what it does not promise covers the general principles first.
The properties Google requires
The documentation separates required from recommended properties. To be eligible for a rich result, a software app needs three things:
- name, the name of the app.
- offers.price, an offer to sell the app. If the app is available without payment, the documentation says to set the price to 0. If the price is above 0, it recommends also giving the currency.
- A rating or a review. You must include either an aggregate rating, which is the average review score, or a single review. Google says to follow its review snippet guidelines for those.
The third requirement is the one that catches new products. A brand-new tool or plugin has no ratings. On the documentation as written, a page without a rating or review does not meet the required properties for this rich result. Google’s general structured data guidelines say that items missing required properties are not eligible for rich results, and that fake reviews must not be marked up. We read that as a reason not to invent ratings, and to accept that the rich result may have to wait.
The documentation adds a note on who is describing the price. For developers, the offer can indicate the marketplaces that carry the application; for marketplaces, it indicates the price of the app for a specific app instance. A developer’s own product page and a marketplace listing for the same app therefore describe the offer from different positions, and each should say what is true for its own page.
The properties Google recommends
Two recommended properties add information. applicationCategory gives the type of app and must be one of Google’s supported values; the list includes GameApplication, BusinessApplication, DeveloperApplication, UtilitiesApplication, SecurityApplication, HealthApplication, FinanceApplication and others. operatingSystem names the operating systems required, with examples such as Windows 7, OSX 10.6 or Android 1.6. For mobile applications and web applications, Google also supports the MobileApplication and WebApplication types, and says a type VideoGame on its own does not produce a rich result, so it should be paired with another type.
Notice what is missing: there is nothing about features, screenshots, plans or feature lists. Google’s documented markup is deliberately narrow, so most of what makes a product page persuasive lives in ordinary page content.
Formats, plugins and scripts
Google’s documentation gives the same worked example, an app with a name, an operating system, a category, an aggregate rating and a price, in three formats: JSON-LD, RDFa and Microdata. Its general guidelines list JSON-LD as the recommended one. For sites on a content management system, the page notes that a plugin integrated with the CMS may be easier, and for sites that generate markup with JavaScript it links to separate guidance on doing that.
The example is a useful reminder of scale. A complete software markup block is a handful of values, and every one of them has to be true of the page it sits on. The work is in the content model behind the page, not in the syntax.
The rules around the markup
The guidelines page carries a warning: if a site violates them, Google may take manual action, and after a structured data manual action the markup on the page is ignored, although the page can still appear in results. Google also says the problem can be spammy content or spammy markup, which a syntax checker will not catch. Google’s general rule of thumb applies: mark up what is on the page, accurately.
Finally, Google says it does not guarantee that features using structured data will appear in search results, and points to the general structured data guidelines for the common reasons a result may not show. Valid markup is a condition of eligibility, not a promise of display.
A sensible release routine
The documentation describes the steps for any structured data. Add the required properties, in JSON-LD, RDFa or Microdata (it gives an example of each). Follow the guidelines. Validate with the Rich Results Test and fix critical errors. Deploy a few pages and use URL Inspection to see how Google reads them, making sure the pages are not blocked by robots.txt, noindex or a login. Allow time: it may take several days for Google to find and crawl a published page, and a sitemap helps Google learn about later changes. Our article on launching a product site covers the wider checklist.
Where this fits at Cultured Digital: digital products
Cultured Digital builds digital products, from MVP development to custom tools, and describes structured data as designed with the content model, not added at the end. Our structured data and entities guide covers schema design and validation. For a product page the practical consequences of this documentation are modest and honest: choose the right type, mark up only what is visible, expect the rating requirement to matter, and treat any rich result as a bonus. The web development service page describes how search requirements are decided before the first template.