SEO
SoftwareApplication schema generator (JSON-LD)
By Charles Summers · Updated · Free, no signup
Short answer
The software app rich result requires a name, an offers node and an aggregateRating, and that third requirement is the one that matters, because it means a tool with no genuine visible ratings structurally cannot qualify no matter how complete the rest of the block is. There is no workaround and inventing a rating is the exact behaviour the spammy structured data manual action exists for. Google also documents this feature as having limited support. Emit the block for entity clarity, set price to 0 with a currency for free software, and expect nothing visible.
Use the schema markup generator
Why software apps need a different approach
This type has a trap built into its requirements. Unlike every other type here, where the mandatory properties are facts about the thing itself, SoftwareApplication requires a property that most software pages have no legitimate way to supply. aggregateRating is part of the requirement for the app rich result, so a genuinely useful free tool with no review system on the page fails the check permanently. Not because the markup is incomplete, but because the underlying fact does not exist.
What happens next is predictable. The validator says aggregateRating is missing, somebody types a plausible 4.8 from 1,240 ratings, and the page now asserts a fact that is nowhere visible on it. That is not a grey area. It is the textbook case for a site-level manual action, and it is trivially detectable because a rating with no reviews behind it has nothing to corroborate it. The correct move is to emit the block without the rating, accept ineligibility, and be clear that you are doing this for parsing value rather than for a result.
It runs entirely in your browser. Nothing you type is sent to a server, no account is required, and there is no usage limit, because there is no cost per run to control.
The rating requirement, and why there is no way around it
Google's software app documentation lists name, offers and aggregateRating as the required properties. Two of those are things any product page can supply honestly. The third is a summary of user ratings, and it is only legitimate if real ratings are collected and shown to visitors on that page. If you do not run a review system, you do not have the data, and the requirement is not satisfiable by trying harder at the markup.
People reach for three workarounds and all three are worse than accepting the outcome. Copying the rating from your app store listing onto your marketing site asserts on-page content that is not on the page, since the ratings live somewhere else entirely. Copying a rating from a software review directory has the same problem plus an attribution one. And building a five-star widget nobody uses, purely so that a number exists to mark up, produces a rating derived from a handful of internal clicks that is technically visible and substantively meaningless.
The reason this attracts enforcement rather than a shrug is the same reason product ratings do. A star rating is the single most persuasive element that can appear in a result, it is cheap to fabricate, and the person harmed is a user who clicked based on a number that was invented. Manual actions for spammy structured data are applied at site level, and the recovery path involves removing the markup and requesting reconsideration, which is a slow and public way to lose weeks.
So the honest position for most software pages is this: emit a complete, accurate block with no aggregateRating, know that you are not eligible for the app rich result, and treat the markup as a clean machine-readable description of the product rather than as a SERP tactic. If you do run a genuine review system with visible ratings, mark up what it actually says, including when what it actually says is 3.9.
Where app rich results actually come from, and what offers means for free software
The second thing worth knowing before you invest effort is that Google documents software app rich results as having limited support, and that most of the app-style results people have in mind are driven by app store listings rather than by markup on a vendor site. An install button, a rating and a screenshot in a result for a mobile app is usually the store's data. Marking up your own marketing page does not reproduce it, and no amount of completeness in your JSON-LD substitutes for a store presence.
The offers node has its own quirk for free software. price should be the string 0 and priceCurrency still has to be present alongside it, which reads strangely until you realise that omitting offers entirely means unknown pricing rather than free. Stating zero is a positive claim. For freemium products this gets more interesting, because the honest answer is often that the application has several offers: a free tier and paid tiers. An array of Offer objects is more accurate than picking one, and if you do pick one, price 0 for the free tier is defensible where quoting the enterprise price is not.
A few properties do real work here and are usually left off.
- applicationCategory. Use one of the documented values such as BusinessApplication, DeveloperApplication, GameApplication or SecurityApplication rather than inventing a descriptive phrase. This is the property that says what kind of software this is at all.
- operatingSystem. Specific and honest: iOS 16+, Android 12+, Windows 11, or "Any" for something that runs in a browser. Listing every platform you vaguely support is how a Linux user ends up disappointed.
- softwareVersion and datePublished. Cheap, factual, and the only signal in the block that the product is actively maintained rather than abandoned in 2019.
- screenshot. An actual screenshot of the interface, not your logo and not a marketing hero image with a laptop in it.
- featureList and softwareRequirements. Useful for anything with real system requirements, and they answer the question a technical buyer asks before they answer the one your headline answers.
Choosing the subtype, and what this markup is genuinely for
SoftwareApplication has three subtypes worth knowing. WebApplication is for anything that runs in a browser with no install, and it carries browserRequirements, which is where you say a modern browser with JavaScript enabled if that is a real constraint. MobileApplication is for a native app distributed through a store. VideoGame sits under the game side of the hierarchy. Picking the accurate subtype is a small precision gain and costs nothing, and the generic SoftwareApplication is a perfectly reasonable default when the product spans several.
For a SaaS product the modelling question is more interesting than the subtype. Is the thing on the page an application, or is it a service you sell? Plenty of B2B software is better described by Product or Service markup, particularly where the commercial story is a subscription with tiers rather than a downloadable artefact. SoftwareApplication fits best where there is an identifiable piece of software with a version, a platform and a way to obtain it. A consultancy-heavy platform sold by demo is stretching the type.
Which brings us to what this block is actually for, given the rich result is largely out of reach. It is a clean statement of category, platform, publisher and price for anything trying to understand what your product is. That audience has changed a lot recently. Software gets recommended by systems summarising the web, and those systems need to establish that a thing is a business application, that it runs on the platforms someone asked about, and that it has a free tier. Those facts are recoverable from your marketing copy, expensively and with a decent error rate, or they are stated once in JSON-LD.
That is a modest, defensible reason to spend twenty minutes on it. It is not a reason to spend a sprint, and it is certainly not a reason to invent a rating in order to unlock a result that Google itself describes as limited support.
Numbers worth knowing
| Metric | Typical | What it means |
|---|---|---|
| Required properties | name, offers, aggregateRating | The rating is the blocker. It is the only required property on any type in this tool that a legitimate, well-built page can be structurally unable to supply, because the underlying data may simply not exist. |
| Feature support level | documented as limited | Google flags software app results as limited support, meaning they may not appear even when you are eligible. That caveat should set your expectations before you spend time on the block. |
| Price for free software | 0, with a currency alongside | Stating zero is a positive claim that the software is free. Omitting the offers node entirely reads as unknown pricing, which is a different and less useful thing to assert. |
| Where app-style results usually originate | the app store listing | Install buttons, ratings and screenshots in results for mobile apps are generally store data. Markup on your own marketing site does not reproduce that and is not a substitute for a store presence. |
Mistakes that quietly cost you results
- Copying the App Store or G2 rating onto your marketing page markup
- That rating is visible somewhere else, not on the page carrying the markup, which is exactly the mismatch the visible-content rule exists to prevent. If you want the rating on the page, put the reviews on the page properly, with attribution, and then mark up what is genuinely displayed.
- Adding a star widget purely so a number exists to mark up
- A rating built from a handful of internal clicks is technically visible and substantively meaningless, and it will show a number your product has not earned. Either build a real review system you intend to maintain, or accept ineligibility and ship the block without the rating.
- Listing every operating system you loosely support
- Be specific, including the minimum versions. Naming Linux because it technically runs under a compatibility layer earns you a support ticket and a bad review from someone who read the property as a promise rather than an aspiration.
- Using SoftwareApplication for a service sold by demo
- This type fits software with a version, a platform and a way to obtain it. A subscription platform sold through a sales process is often better described by Product or Service markup, and forcing it into an application shape leaves half the required properties inapplicable.
What does the output look like?
This is the exact output the tool produces from the example inputs. It is generated by the same code that runs when you click the button, so what you see here is what you get.
Frequently asked questions
Is it worth adding this markup at all if I cannot meet the rating requirement?
Yes, on a modest and clearly stated basis. Without a rating you will not get the app rich result, and you should not expect one. What the block still does is state category, platform, publisher and pricing model unambiguously, which matters more than it used to now that software gets summarised and recommended by systems reading the open web. Budget twenty minutes for it, put it in the template, and do not report it as a growth initiative.
Which applicationCategory should a niche tool use?
The closest documented value rather than an invented phrase, because the point of the property is to place you in a known set. BusinessApplication covers a great deal of B2B software, DeveloperApplication suits developer tooling, and there are values for security, finance, health, design and games. If two fit, pick the one your buyers would use to describe you and stay consistent with it across every page rather than varying it per product.
How should a freemium product express pricing?
An array of Offer objects, one per tier, is the most accurate representation, because the product genuinely has more than one price. If you are going to emit a single offer, the free tier at price 0 is the defensible choice, since it is the price at which anyone can start. What causes trouble is quoting a single enterprise figure that only applies after a negotiation, because it becomes a price the page asserts and the checkout never charges.
WebApplication or SoftwareApplication for a browser-based tool?
WebApplication is the more precise type and it carries browserRequirements, which is worth setting if your tool genuinely needs something specific. The gain is small, so if your product spans a web app, a desktop client and a mobile app, the parent SoftwareApplication type with an honest operatingSystem value is a reasonable single choice rather than emitting three near-duplicate blocks that describe one product.
Can I mark up an open source project with this type?
Yes, and it is a good fit, since an open source project has a version, a platform and a clear way to obtain it. Set price to 0 with a currency, use softwareVersion and datePublished so the block shows the project is alive, and point downloadUrl at the release rather than at the repository root. The licence is worth stating on the page, and the rating requirement is as unmeetable here as anywhere else, which is fine.
Related free tools
- Schema Markup Generator SEO
- Schema Markup Generator for article pages SEO
- Schema Markup Generator for product pages SEO
- Schema Markup Generator for faq pages SEO
- Schema Markup Generator for local business SEO
- Schema Markup Generator for events SEO
- Schema Markup Generator for breadcrumbs SEO
- SEO Meta Tag Generator for ecommerce product pages SEO
- SEO Meta Tag Generator for local business SEO
- SEO Meta Tag Generator for blog posts SEO
- AI LinkedIn Hook Optimizer for recruiters Social
- AI LinkedIn Hook Optimizer for creators Social
Some links on this site are affiliate links, which means Hacking Demand may earn a commission if you buy through them at no extra cost to you. This does not influence which tools are listed. The tools on this page are free and have no affiliate relationship of any kind.