SoftwareApplication Schema for SaaS: Build and Validate It
Start with a public page that actually describes your software. Choose a suitable application type, map approved visible facts into JSON-LD, and test the exact HTML. Keep three decisions separate: whether the vocabulary is accepted, whether the markup represents the page, and whether it meets a search feature's requirements. Our fictional paid SaaS example has no reviews: Schema.org reports zero errors, while Google's documented software rich-result requirements remain incomplete.
Copy the complete SaaS HTML example
LedgerNest Web is fictional. Save this as an HTML file, inspect the visible offer and JSON-LD together, then replace every example fact and URL with approved information before using it on a real page.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>LedgerNest Web — fictional SaaS example</title>
<link rel="canonical" href="https://example.com/ledgernest">
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebApplication",
"@id": "https://example.com/ledgernest#app",
"name": "LedgerNest Web",
"url": "https://example.com/ledgernest",
"description": "A shared invoice checklist for small bookkeeping teams.",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Windows, macOS, Linux",
"browserRequirements": "JavaScript and cookies enabled",
"offers": {
"@type": "Offer",
"name": "Team monthly subscription",
"url": "https://example.com/ledgernest",
"price": "24.00",
"priceCurrency": "USD",
"description": "USD 24 per workspace per month, billed monthly. A 14-day trial precedes the paid subscription."
}
}
</script>
</head>
<body>
<main>
<h1>LedgerNest Web</h1>
<p>Fictional teaching example. This is not a real product offer.</p>
<p>A shared invoice checklist for small bookkeeping teams.</p>
<p>This business application runs in a browser on Windows, macOS or Linux.
JavaScript and cookies must be enabled.</p>
<h2>Team monthly subscription</h2>
<p>USD 24 per workspace per month, billed monthly.
A 14-day trial precedes the paid subscription.</p>
<p>No customer ratings or reviews have been published.</p>
</main>
</body>
</html>
Which page and application type should you use?
Use a maintained product detail or landing page whose visible content explains the application, intended users, operating conditions and offer. A public marketing page can describe software whose working interface requires an account. That does not mean private customer screens should become public or receive a new indexing policy.
WebApplication is the Schema.org subtype for a web app; browserRequirements describes its browser prerequisites. Use SoftwareApplication for an appropriate broader application description, or MobileApplication for a mobile app. Choose based on the actual software, rather than attaching every possible type in pursuit of additional features.
A general invoice-advice article is a different task. If it does not describe an application, omit the application node. Do not change the article's visible purpose to justify a template's default markup. If your difficulty is an ambiguous brand or a stale emitter, follow the existing identity or mismatch workflow first.
What does Google require for software rich results?
Google currently requires name, offers.price, and either aggregateRating or review. It recommends currency for a paid offer, applicationCategory and operatingSystem, and supports WebApplication and MobileApplication. A zero price is appropriate when the app is available without payment. Read the linked requirements and review guidelines before targeting the feature.
For LedgerNest, the approved facts contain no published reviews. Leave those fields absent and record the missing requirement. Do not copy another product's rating, convert a testimonial into an invented score, or add a placeholder review to clear an error. Truthful markup can be retained without representing it as feature-ready.
Eligibility and display are separate. Google's documentation does not guarantee a rich result, and a code test cannot establish that a deployed URL is accessible and indexed. This implementation also provides no evidence of improved AI citations, rankings, referrals or sales.
How should you map the SaaS facts into JSON-LD?
Start a short implementation record with the page URL, application identity, visible source for each field, responsible editor and proposed emitter. Copy approved facts into the node. Keep the application identifier stable across revisions; a plan change should not accidentally create a second product identity.
The example has one browser application and one Team monthly offer. Its 24.00 amount and USD currency accompany a visible per-workspace monthly charge. The offer description repeats the billing basis and 14-day trial. That description preserves context; it is not a promise that a search feature will display a monthly billing label.
The free trial does not make the recurring subscription a free plan. Keep annual commitments, seat minimums, usage charges and distinct plans explicit in the real source facts before choosing how to model them. This single-offer teaching snippet is not a universal subscription catalog. If an accurate public price is unavailable, do not invent one to satisfy a feature requirement.
| Input | Example field | Check before release |
|---|---|---|
| Application identity | @id, name, url | One intended app, correct public destination and consistent visible name. |
| Application behavior | description, applicationCategory | Describes the actual buyer task and appropriate category. |
| Supported environment | operatingSystem, browserRequirements | Replace the fictional compatibility claims with tested product facts. |
| Paid Team offer | offers.price, priceCurrency, description | 24.00 USD per workspace/month; trial and billing context remain visible. |
| No published reviews | No rating or review field | Keep the missing feature requirement in the handoff. |
How do you test the exact implementation?
Save the complete proposed HTML. Parse its JSON-LD to catch broken syntax, then paste the HTML into Schema.org's Code snippet test and inspect the detected node and nested offer. The validator accepts supplied markup; a successful code submission is not a fetch of your production URL.
Next compare the visible page with the extracted graph and inspect the applicable search-feature requirements. Use Google's Rich Results Test for its supported feature diagnostics when available, recording the input, date, mode and actual outcome. An unavailable test stays unavailable. Keep it separate from a manual requirements review.
Before deployment, review every active JSON-LD emitter on the destination page. Adding a second snippet beside an old plugin output can recreate conflicting facts. Preserve the before version and identify the one source that will change. After deployment, repeat the checks against the served page and preserve its response and test record.
What did the four validator tests show?
On September 12, 2026, we submitted four fictional HTML inputs through Schema.org's Code snippet interface. The paid-app input is the complete copyable example above. Each variation changes only the stated part so the result can be inspected without treating it as a real product test.
For the unsupported-property case, insert aiVisibilityScore: 99 into the JSON object with the required quotation marks and comma. The validator identifies that property as unrecognized for WebApplication. Removing it returns to the original input; there is no need to create an alternative AI score field.
For the ineligible-page case, replace the main body with an invoice-meeting advice article that describes no app, while retaining the application node. The validator still reports zero errors. Our manual review rejects that node because the visible page does not support it. The correction replaces it with an Article node containing the article's headline and description.
| Submitted case | Schema.org result | Implementation decision |
|---|---|---|
| Paid WebApplication, no reviews | 1 WebApplication; 0 errors, 0 warnings | Vocabulary accepted. Required review/rating still absent for Google's software feature. |
| Same app plus aiVisibilityScore | 1 WebApplication; 1 error, 0 warnings | Remove the unrecognized property. |
| Unrelated article with unchanged app node | 1 WebApplication; 0 errors, 0 warnings | Reject on page relevance despite the clean tool output. |
| Article corrected to Article markup | 1 Article; 0 errors, 0 warnings | Retain article semantics; no software-feature claim. |
What do these results leave unverified?
The Google code submission returned a sign-in request and no result. We did not complete an authenticated test. The missing-review conclusion comes from comparing the example with the current documentation, not from a Google validator verdict. Re-run the exact input in your available test session before calling that check complete.
The Schema.org results concern four pasted inputs. They do not verify LedgerNest's fictional compatibility, real customer reviews, production rendering, crawler access or indexing. The zero-error unrelated article is a useful counterexample: vocabulary acceptance does not replace editorial review. Google's policies require markup that represents the page.
For a real implementation, retain unresolved requirements in the release record. A failed or unavailable check must remain visible to the person deciding whether the change is ready. Later search observations are separate measurements and cannot prove that the markup caused them.
What should the implementation handoff say?
Completed fictional handoff: implement one LedgerNest Web node from the approved product page, with a 24.00 USD monthly Team offer and explicit trial context. Keep reviews absent. Schema.org accepted the exact copyable HTML. Google code testing remains unavailable, and the documented review requirement is unmet. Do not describe the app as eligible for software rich results.
Assign the real page owner, emitter, proposed diff and rollback version before shipping. Have the product owner confirm identity and compatibility, the pricing owner confirm the offer, and the implementer capture served output. Where markup is already present, use the mismatch guide's field-to-emitter record rather than adding an unreviewed duplicate.
RankEcho's Fix Engine can support the reviewed page-change workflow and its handoff. Preview that workflow if your team needs a repeatable process for supported changes. This guide does not describe native Schema.org certification, Google eligibility approval or automatic deployment; those checks and decisions remain explicit.
Frequently asked questions
WebApplication is an application subtype suited to a browser app. Select a type that describes the actual software and review the intended search feature separately.
Leave unsupported ratings and reviews out. Record the missing requirement instead of manufacturing evidence or copying the fictional values from another example.
No. In our executed example, an unrelated article carrying valid app markup also produced zero Schema.org errors. Page relevance and feature requirements still needed separate review.
No. The HTML is an escaped teaching artifact. This guide is an Article; the fictional application node belongs only inside the copied example.
Sources reviewed
Material technical claims below were checked against primary provider documentation. The sources support the documented control or signal, not a guarantee of indexing, ranking, an AI impression, or a citation.
4 claim-level source records
| Claim reviewed | Official source | Review record |
|---|---|---|
| Google documents software-app rich-result requirements separately from the Schema.org vocabulary. | Google: software app structured data | Checked 2026-09-12 · Primary source checked September 12, 2026 · Documentation-based eligibility review. The Rich Results Test requested sign-in and returned no result for our code submission. · Confidence: High |
| WebApplication is a SoftwareApplication subtype and includes browserRequirements. | Schema.org: WebApplication | Checked 2026-09-12 · Primary source checked September 12, 2026 · The current vocabulary page identifies itself as a development view. The example was separately submitted to the public validator; no fixed validator vocabulary version is inferred. · Confidence: High |
| Google requires markup to represent page content and use applicable types. | Google: structured data policies | Checked 2026-09-12 · Primary source checked September 12, 2026 · Manual page-relevance review remains separate from syntax and vocabulary checks. · Confidence: High |
| The Schema.org validator accepts pasted markup and displays the extracted graph and syntax issues. | Schema.org: validator documentation | Checked 2026-09-12 · Primary source checked September 12, 2026 · Four fictional HTML snippets were submitted through its browser UI: a paid app, an unsupported property, an unrelated article with app markup, and its Article correction. · Confidence: High |