SoftwareApplication schema: the JSON-LD your app page needs

SoftwareApplication is the schema.org type for a piece of software: an app, a SaaS product, a browser extension, a CLI. Written as JSON-LD and placed on your product page, it is the one statement about your app that a machine can read without guessing. Google uses it to decide whether your page qualifies for a software rich result. AI answer engines use it as the cleanest description of what you are when somebody asks them what to use.

Most product pages do not have it. The ones that do usually have it wrong. Both are fixable in an afternoon.

The short answer

Put one JSON-LD block on your product's main page, inside a script tag with the type application/ld+json. Give it a name, a one-sentence description, the URL, an application category, the operating systems it runs on, and an offer with a price and a currency. A free app has a price of 0. Add a rating only if real people have left real reviews that are visible on that page. Validate it, ship it, and use the exact same name and sentence everywhere else your app is listed. The template below does all of that.

What Google does with it

Google's software app rich result is the search listing that shows a star rating and a price under your app's name. To be eligible, the page needs SoftwareApplication markup with a name, an offer carrying a price and a currency, and a genuine rating or review. Without the rating you do not get stars, and that is fine: the markup still tells Google what kind of page this is, which category the product belongs to, and that the thing being described is software rather than an article about software.

That last part matters more than the stars. A page about a product with no structured data is a page Google has to classify from its prose. One with SoftwareApplication markup has said what it is in the vocabulary Google already understands. Structured data is not a ranking signal on its own, and anybody who tells you it is has something to sell. It is an eligibility signal and a clarity signal, and clarity is where most product pages lose.

What AI answer engines do with it

When somebody asks ChatGPT, Perplexity, Claude or an AI Overview what to use for a job, the answer is built from pages the model has read or can fetch at that moment. A home page made of components, animated headlines and a pricing toggle reads badly to a model. A JSON-LD block reads perfectly: name, what it is, who makes it, what it runs on, what it costs, in a shape every model was trained on millions of times.

There is a second effect, and it is the bigger one. Models recommend entities, and an entity is only as solid as the agreement between the places that describe it. If your site says one name, your App Store page says another, and a directory listing carries a third tagline, you are three weak signals instead of one strong one. SoftwareApplication markup is where you write the canonical version. Every other listing should copy it word for word.

A template

Paste this into your product page, replace the brackets, and delete any line you cannot fill in honestly. An empty property is better than a made-up one.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "[Product name]",
  "description": "[Product] is a [what it is] for [who it is for]. [One thing that makes it different.]",
  "url": "https://yourapp.com/",
  "applicationCategory": "[BusinessApplication]",
  "operatingSystem": "[Web, macOS, Windows, iOS, Android]",
  "offers": {
    "@type": "Offer",
    "price": "[0]",
    "priceCurrency": "USD"
  },
  "image": "https://yourapp.com/og.png",
  "screenshot": "https://yourapp.com/screenshot.png",
  "softwareVersion": "[2.4.0]",
  "datePublished": "[2026-01-15]",
  "author": {
    "@type": "Organization",
    "name": "[Your company]",
    "url": "https://yourcompany.com/"
  },
  "sameAs": [
    "https://apps.apple.com/app/[id]",
    "https://github.com/[org]/[repo]",
    "https://spacerrapps.com/apps/[your-slug]"
  ]
}
</script>

Property by property

name. The product's name and nothing else. Not "Kettle: the timer for makers". The tagline has its own field.

description. One sentence, sometimes two. What it is, who it is for, what makes it different. This is the sentence a model will quote, so write it the way you would want to be quoted, and then reuse it as the short description on every directory and store. How to write that sentence is its own guide.

url. The canonical URL of the product page, with the trailing slash you actually use.

applicationCategory. One of schema.org's own values, not a phrase you like. The list is short: BusinessApplication, DeveloperApplication, UtilitiesApplication, MultimediaApplication, DesignApplication, EducationalApplication, HealthApplication, FinanceApplication, LifestyleApplication, SocialNetworkingApplication, TravelApplication, GameApplication, SecurityApplication, CommunicationApplication and a few more. "AI tool" is not one of them. An AI writing assistant is a BusinessApplication or a DesignApplication, and the AI part belongs in the description.

operatingSystem. Plain names, comma separated: "Web", "macOS", "iOS", "Android", "Windows", "Linux". A web app says Web. A browser extension says the browsers.

offers. The one property people skip and the one Google requires. A free product has a price of 0, which is a price. A freemium product lists its lowest paid tier, or two offers, one at 0 and one at the paid figure. Use a string for the price, a three-letter code for the currency, and keep it in step with your pricing page: a mismatch here is a reason to distrust everything else in the block.

aggregateRating. Only if real reviews exist and are visible on the same page. It looks like this: a ratingValue, a ratingCount, and the rating scale. Google checks that the number on the page matches the number in the markup, and a rating with no reviews behind it is the fastest way to lose the rich result and be treated as spam. Most new apps should leave it out for the first year, and that is the honest answer rather than the cautious one.

image and screenshot. Absolute URLs to files you host. The image is the one search results and share cards use; the screenshot is what the product looks like in use. Both should exist and both should load without a login.

softwareVersion and datePublished. A model reading two pages about competing tools will prefer the one with a version number and a date, because a dated fact is easier to trust than an undated adjective. Update the version when you ship; a version from two years ago says more than no version at all, and not in your favour.

author. The organisation or person that makes it, with a URL. This is what links the app entity to the maker entity. If you are one person, a Person with a name and a URL is fine.

sameAs. Every other page on the web that is about this exact product: app store pages, the GitHub repository, your directory listings, the Wikipedia article if you ever get one. This is the property that turns scattered listings into one entity, and it is the most neglected line in the whole block. A listing in a directory that publishes its own structured data about you is a second, independent statement of the same entity, and sameAs is how you tell a machine the two are the same thing.

Which type to use

SoftwareApplication is the parent. Three subtypes exist and you should use one when it fits: WebApplication for anything used in a browser, MobileApplication for a phone app, VideoGame for a game. A product that is both a web app and a mobile app uses SoftwareApplication and lists every operating system. Do not use Product: that type is for things you can put in a box, and Google's product rich result expects a physical item with shipping details.

Where to put it

One block, on the page that is about the product. For a single-product company that is the home page. For a company with several products it is each product's own page, with a different block on each, and none on the home page. It goes inside the HTML, usually in the head, and it does not matter whether a framework renders it or you type it by hand, as long as it is in the HTML the server sends rather than injected by a script after the fact. Google runs JavaScript eventually; answer engines mostly do not.

Do not put it on every page. A pricing page describes an offer, a blog post describes an article, and a SoftwareApplication block on either is a page claiming to be something it is not. If you want the entity referenced from other pages, that is what the about property on a BlogPosting is for.

Mistakes that get it ignored

• A rating with no reviews on the page. The commonest one, and the one Google acts on.
• An invented category. "Productivity tool" is not a schema.org value and is read as nothing.
• The price in the description and not in offers. "Free forever" in a sentence is prose; a price of 0 in an Offer is data.
• JSON that does not parse. A trailing comma or a smart quote from a text editor and the whole block is discarded silently. Validate it.
• Different names in different places. The markup says one thing, the title tag says another, the App Store says a third. Pick one.
• Markup for a product the page does not describe. A landing page for a feature carrying the whole app's block is a mismatch a reviewer can see in a second.

How to check it works

Paste the page URL into Google's Rich Results Test and confirm it finds a SoftwareApplication with no errors. Paste the same URL into the Schema Markup Validator at validator.schema.org for anything Google does not care about but a model might. Then, a week later, open Search Console and look for the software app enhancement report; it appears once Google has indexed the marked-up page.

For the answer engines, ask one. Give ChatGPT or Perplexity your URL and ask what the product is, who it is for and what it costs. If the answer matches your description line word for word, the markup is doing its job. If it paraphrases your hero copy instead, the block is missing, invalid, or contradicted by the page around it.

Frequently asked questions

Does SoftwareApplication schema improve rankings? Not directly. It makes the page eligible for the software rich result, and it removes ambiguity about what the page is. Pages with rich results get more clicks at the same position, which is where the gain actually comes from.

Do I need it if my app is on the App Store or Google Play? Yes. The stores describe your app inside their walls. Your own page is what Google and every model read when the question is asked outside them, and it is the page you control.

Can I use it for a browser extension or a CLI? Yes. Both are software. A browser extension lists the browsers as its operating systems; a CLI lists the platforms it installs on.

How long until the rich result appears? Google has to recrawl the page first. Days to a few weeks, and only if the rating requirement is met. The entity effect on answer engines shows up whenever they next fetch the page, which is usually sooner.

Should the description match my llms.txt? Yes, exactly. The llms.txt blockquote and the description property should be the same sentence. Every place that sentence appears is another vote for the same entity, and getting cited by AI search is mostly a matter of how many of those votes agree.

Do this today

Write the one sentence. Fill the template. Validate it. Then copy that sentence into every listing you have, starting with the ones that publish structured data of their own. Twenty lines of JSON will not launch your app, but they are the difference between a product a machine can describe and one it has to guess at, and the machines are doing more of the recommending every month.