Structured data for a software product

Google describes structured data as a standardised format for providing information about a page and classifying its content (source). Most of it uses the schema.org vocabulary, and some types make a page eligible for a richer search result: stars, a price, a breadcrumb trail.

Three things from Google’s documentation set expectations:

• Google’s docs decide, not schema.org. schema.org defines many more types and properties than Google uses. Google says to rely on Search Central as definitive for Google Search behaviour. Its search gallery lists the features it currently supports.
• JSON-LD is the recommended format. It goes in a <script> tag in the head or body. Google can read JSON-LD injected by JavaScript, but putting it in the server’s HTML avoids depending on rendering.
• Nothing is guaranteed. Google does not guarantee that your structured data will show up in results, even when it passes Google’s own test (source).

SoftwareApplication

The type for the product itself. schema.org defines it simply as a software application, with WebApplication and MobileApplication among its more specific types (schema.org). Google supports both subtypes for its software app feature (source), and its general guideline is to use the most specific type that applies, so a browser-based product is a WebApplication.

Organization

Describes the company or maker behind the product. Google says it uses this to understand your organisation’s details and tell it apart from others, and that the logo property can influence which logo appears in results and in a knowledge panel. There are no required properties. Google recommends putting it on the home page or an about page, not on every page (source).

WebSite

Google builds the site name shown in results automatically, and says WebSite structured data on the home page is the most important way to state a preference (source).

BreadcrumbList

For pages below the homepage: docs, blog posts, feature and comparison pages. It needs at least two ListItem entries, each with a position, a name and an item URL, which the last entry may omit. Google documents the feature as available on desktop (source). A homepage doesn’t need one.

What to leave out

FAQPage. Google’s documentation changelog records that the FAQ rich result stopped appearing in Google Search from 7 May 2026, and that its documentation was removed on 15 June 2026 (source). The same changelog shows several other types retired during 2025, so check the gallery before adding a type an older article recommends.

Product, for the company. Google’s list of structured data manual actions includes “Company marked as product” (source). Describe the company as an Organization and the software as a SoftwareApplication.

From Google’s software app documentation, as of November 2026. Required:

• name.
• offers.price. If the app is available without payment, set it to 0. For a price above zero, Google recommends adding offers.priceCurrency.
• Either aggregateRating or review.

Recommended:

• applicationCategory, which must be one of the values Google lists, such as BusinessApplication, DeveloperApplication, DesignApplication, FinanceApplication or UtilitiesApplication.
• operatingSystem, the operating systems required to use the app.

The third requirement is the one a newly launched product usually can’t meet. An item missing a required property isn’t eligible for a rich result (source), so a product with no ratings can’t get the software app result. Leave the rating out until you have one.

Star ratings come with more conditions than anything else here. From Google’s review snippet documentation:

• Ratings must come directly from users. Don’t write the number yourself.
• They must be on the page. If you mark up an AggregateRating, a visitor should be able to see that rating on the same page, and it must be obvious that the page has review content.
• Don’t aggregate from other websites. Copying your score from a review site or an app store into your own markup is against the guidelines.
• An AggregateRating needs a ratingValue and at least one of ratingCount or reviewCount. A Review needs an author with a valid name and a reviewRating.

Then there is the self-serving reviews rule. If the entity being reviewed controls the reviews about itself, pages using LocalBusiness or any other Organization type are ineligible for the star feature. Google’s example is a review of entity A placed on entity A’s own website, whether directly in the markup or through an embedded third-party widget. So putting testimonials about your company inside your Organization markup earns no stars.

SoftwareApplication is a separate entry on the list of types eligible for review snippets, so ratings of the app itself can qualify. The other conditions still apply, and Google’s manual actions list includes “Review written by the site or person providing the service” and “No mechanism for submitting a new review” (source). That leaves one safe setup: ratings collected from your users, displayed on the page, with a way to leave one.

For a homepage. Two separate blocks, one for the company and one for the product:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Invoices",
  "url": "https://yoursite.com",
  "logo": "https://yoursite.com/logo.png",
  "description": "Recurring invoicing software for freelancers.",
  "sameAs": [
    "https://github.com/acme-invoices",
    "https://www.linkedin.com/company/acme-invoices"
  ]
}
</script>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Acme Invoices",
  "url": "https://yoursite.com",
  "description": "Send recurring invoices and see who still owes you.",
  "applicationCategory": "BusinessApplication",
  "offers": {
    "@type": "Offer",
    "price": 9.00,
    "priceCurrency": "USD"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "ratingCount": 87
  }
}
</script>

Before you use it:

• Delete the aggregateRating block unless that exact rating and count appear on the page and come from your own users. Keep it in step with the page as the numbers change.
• The price must match the price a visitor sees. Google’s documentation shows a single offers.price and doesn’t describe how to mark up several subscription tiers, so we haven’t shown that here.
• The logo must be at least 112 × 112 pixels, at a crawlable and indexable URL (source).
• Generate the JSON from the same data that renders the visible price and rating, and render it on the server so it’s in the HTML.

Google points to two tools (source):

1. Rich Results Test. Google recommends starting here. It shows which Google rich results a page’s markup can generate. Test the live URL once it’s deployed, not only a pasted snippet, so you’re testing what your server actually sends.
2. Schema Markup Validator. At validator.schema.org. It validates all schema.org markup without Google-specific warnings, which is useful for types Google has no rich result for, such as a plain Organization.
3. URL Inspection in Search Console. After Google has crawled the page, this confirms that it found the structured data (source).

A pass means the page is eligible. Whether a rich result appears is Google’s decision.

Google’s structured data guidelines say a violation can bring a manual action, which makes the page ineligible for rich results. Google adds that this kind of action doesn’t affect how the page ranks in web search. The rules that software sites break most easily:

• Marking up content that isn’t visible. “Don’t mark up content that is not visible to readers of the page.” A rating, price or review that exists only in the JSON is the standard case, and “Structured data found on hidden content” is a named manual action.
• Fake or self-written ratings. The guidelines call out fake reviews by name.
• Markup that doesn’t match the page. Structured data must be a true representation of the page’s content. Stale prices and review counts drift into this.
• Blocking the page. The guidelines say not to block pages that carry structured data from Googlebot with robots.txt, noindex or other access controls. The indexability checker tests for both.

If you do receive a structured data manual action, it appears in Search Console. Google’s process is to fix or remove the markup and then request a review (source).

Structured data sits beside the rest of the head, not in place of it. The title, description and canonical are covered in meta tags that matter.