SoftwareApplication schema has a long list of possible properties in the schema.org vocabulary, and most implementations either mark up far too little to qualify for anything, or copy a bloated example from a random blog post and include properties that do nothing for search visibility. Neither extreme is useful. Here's which fields Google's rich result system actually consumes, and which ones are safe to leave out without losing anything.
The Fields That Actually Gate Eligibility
Google's software app structured data guidelines specify a required set for the rich result — a star rating and metadata shown directly in search results. Skip any of these and the markup validates but produces no visible enhancement:
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "PNG to WebP Converter",
"operatingSystem": "Web",
"applicationCategory": "MultimediaApplication",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"ratingCount": "128"
},
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
}
}
name— required, obviously, but must match what's actually on the page. A name that doesn't match visible page content is a common cause of manual structured data actions.operatingSystem— required. For a web app this is legitimately"Web"; don't invent a platform list the tool doesn't actually target.applicationCategory— required, and should use one of schema.org's recognized category values rather than a made-up string, since some consumers pattern-match against the known list.aggregateRating— this is the field that actually produces the star rating in the SERP. Without it, nothing else in this list matters for the rich result — the markup is complete but invisible. Critically, the rating and count must reflect real, verifiable ratings actually displayed on the page; fabricating this data is an explicit structured data policy violation and is aggressively enforced by manual action.
Fields That Add Detail But Don't Gate Anything
These are legitimate schema.org properties that some tools include, and they don't hurt, but they aren't what determines rich-result eligibility:
softwareVersion— useful for downloadable software with meaningful version history; largely irrelevant for a web tool that has no user-facing version number.fileSize— meaningful for installable apps; skip entirely for a browser-based tool since there's no file being downloaded.datePublished/dateModified— genuinely useful signals for freshness in general, but not something the software rich result specifically checks.screenshot— can support image-based enhancements in some surfaces, but isn't a documented requirement for the star-rating rich result itself.downloadUrl/installUrl— relevant only if the software is actually downloaded or installed somewhere; a web tool has no download URL and including a fabricated one is worse than omitting the field.
Including these adds descriptive completeness for anything that parses the JSON-LD (not just Google — other consumers of structured data exist), but padding markup with properties that don't apply to a web tool just to make the schema look more thorough doesn't move rich-result eligibility.
The Decision Point: SoftwareApplication vs. WebApplication vs. Product
This trips up a lot of implementations. WebApplication is a more specific subtype of SoftwareApplication intended for apps that run in a browser without installation — which describes most free browser-based dev tools exactly. Using the more specific type where it genuinely applies is preferable to the generic parent type, though Google's documentation treats both as eligible for the same rich result category, so this is more about semantic correctness than a hard ranking requirement.
Product schema is a different vocabulary branch meant for general commerce — physical goods, or sometimes SaaS subscriptions marketed primarily as a purchasable plan. If your tool is genuinely free with no purchase flow, SoftwareApplication/WebApplication is the correct type; reach for Product only if the primary framing is a paid subscription being sold, not a software tool being used.
{
"@context": "https://schema.org",
"@type": "WebApplication",
"name": "JSON Formatter",
"applicationCategory": "DeveloperApplication",
"operatingSystem": "Any (Web Browser)",
"browserRequirements": "Requires JavaScript"
}
What Not to Fake
The most damaging mistake isn't a missing field — it's an invented one. Aggregate ratings that don't correspond to real, visible reviews on the page, review counts pulled from nowhere, or pricing that doesn't match the actual offer are structured data spam under Google's policy, and this category gets manually reviewed and actioned more aggressively than most other structured data violations because it directly manipulates what users see as social proof before they click.
If a free tool genuinely has no rating mechanism, the correct move is to omit aggregateRating entirely and accept no star rich result, not to backfill a plausible-looking number. The rich result is a bonus for tools with real review data, not an entitlement every page needs to claim.
Validating Before Deployment
JSON-LD errors are almost always structural — a missing closing brace, a string where a number belongs, a nested object where the spec wants a flat value — and these fail silently in the sense that the page still renders fine; only a structured data testing pass reveals the break. Run generated markup through the JSON Validator to catch structural issues before it ships, and use the JSON Formatter to keep hand-edited JSON-LD readable as the schema grows past a few properties.
A Minimal, Honest Baseline
For a typical free browser-based tool with no review mechanism yet, the defensible minimum is @type, name, operatingSystem, applicationCategory, and an offers block with price: "0". That's valid, accurate, and won't trigger a policy problem. Add aggregateRating only once there's a real rating source to back it — a review widget, an app store listing being mirrored, or genuine user feedback data — not before.