WebApplication schema

Where to use it

Browser-based tools.

A complete example

Valid as written, with every required property and the recommended ones that carry real information.

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Acme Reference",
  "applicationCategory": "DeveloperApplication",
  "browserRequirements": "Requires JavaScript",
  "offers": {
    "@type": "Offer",
    "price": "249.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://www.seoforsolos.com/pricing"
  },
  "permissions": "No special permissions required",
  "featureList": [
    "Generates JSON-LD",
    "Validates required properties"
  ]
}

Generate a WebApplication node with your own values in the schema generator, and lint what your page actually ships with the schema validator.

Properties

The three mistakes this type attracts

1. 01Using SoftwareApplication when WebApplication is more specific.
2. 02Omitting browserRequirements on a tool with real constraints.
3. 03Duplicating both types in one graph for the same thing.

Related types

• DefinedTerm
• DefinedTermSet
• Dataset
• Table
• Course
• Book

Where this appears in the playbook

• Structured data: what each type is for and which ones earned their place.
• The schema graph: composing types into one graph with stable identifiers.
• One JSON-LD script per page, holding one @graph
• Stable @id anchors that cross-reference rather than duplicate
• Optional fields are omitted, never emitted as empty strings
• Does schema markup work? What 42 types on one site actually did: which of these types measurably did anything in production.