JSON-LD schema for SaaS: Organization, SoftwareApplication, FAQ

Schema markup for SaaS is a set of JSON-LD blocks that tell search engines and AI systems who you are (Organization), what your site is (WebSite), what you sell (SoftwareApplication with offers), and what each page contains (FAQPage, BreadcrumbList, BlogPosting). Put Organization and WebSite on the homepage, SoftwareApplication on pricing, and page-level types where they match visible content. Link them with @id and serve them in the initial HTML, not only through JavaScript.

• Use JSON-LD. It is the format Google recommends and the easiest to maintain.
• SoftwareApplication (or its subtype WebApplication) is the right type for a SaaS product. Add offers with price and priceCurrency.
• Only add aggregateRating if you show genuine reviews on the page. Fake or borrowed ratings risk a manual action.
• Every fact in your markup must match what visitors see on the page.
• Test with Google's Rich Results Test and the Schema.org validator, then confirm the JSON-LD appears in View Page Source.

What is JSON-LD schema and why does a SaaS site need it?

JSON-LD (JavaScript Object Notation for Linked Data) is a script block in your HTML that describes the page using the shared Schema.org vocabulary. Visitors never see it. Machines read it to understand facts that are otherwise buried in layout: your company name, logo, social profiles, product category, prices, and the questions answered on a page.

For Google, structured data powers rich results and helps it understand entities. Google documents which types it supports in its structured data introduction. For AI answer engines, the picture is less documented. No major engine publishes a rule that schema increases citations. What schema does reliably is make your core facts explicit, consistent, and easy to parse, which supports the broader goal of being the clearest source. Treat it as one part of AEO alongside direct answers, TL;DR blocks, and FAQs, as covered in FAQ schema and TL;DR for AI search.

Which schema goes on which SaaS page?

The examples below use a fictional product, Acme Metrics, at example.com. Replace every value with your own.

How do I write Organization schema?

Organization identifies your company. The most useful properties are logo (Google asks for an image at least 112 by 112 pixels) and sameAs, a list of official profiles that confirm which entity you are. Include only profiles you control.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme Metrics",
  "url": "https://example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo-512.png",
    "width": 512,
    "height": 512
  },
  "description": "Acme Metrics is product analytics software for B2B SaaS teams.",
  "sameAs": [
    "https://www.linkedin.com/company/acme-metrics",
    "https://x.com/acmemetrics",
    "https://github.com/acme-metrics"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer support",
    "email": "support@example.com"
  }
}
</script>

Do I still need WebSite schema?

Yes, but keep it short. Google uses WebSite markup on the homepage, especially name and alternateName, as a signal for the site name shown in search results. You can skip the old SearchAction block: Google retired the sitelinks search box in late 2024.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "url": "https://example.com/",
  "name": "Acme Metrics",
  "alternateName": "Acme",
  "publisher": { "@id": "https://example.com/#organization" }
}

How do I add SoftwareApplication schema for a SaaS product?

SoftwareApplication describes the product itself. For a browser-based SaaS you can also use the subtype WebApplication; both are valid. Key properties:

• applicationCategory: a broad category such as BusinessApplication, DeveloperApplication, FinanceApplication, or CommunicationApplication.
• operatingSystem: "Web" for browser-based SaaS, or list desktop and mobile platforms if you ship apps.
• offers: one Offer per plan with price and priceCurrency. A free plan uses a price of 0. If you prefer one summary, an AggregateOffer with lowPrice, highPrice, and offerCount works too.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "@id": "https://example.com/#software",
  "name": "Acme Metrics",
  "url": "https://example.com/",
  "description": "Product analytics for B2B SaaS teams: funnels, retention, and feature adoption.",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "publisher": { "@id": "https://example.com/#organization" },
  "offers": [
    {
      "@type": "Offer",
      "name": "Free",
      "price": "0",
      "priceCurrency": "USD",
      "url": "https://example.com/pricing"
    },
    {
      "@type": "Offer",
      "name": "Team",
      "price": "29.00",
      "priceCurrency": "USD",
      "url": "https://example.com/pricing",
      "priceSpecification": {
        "@type": "UnitPriceSpecification",
        "price": "29.00",
        "priceCurrency": "USD",
        "referenceQuantity": {
          "@type": "QuantitativeValue",
          "value": 1,
          "unitCode": "MON"
        }
      }
    }
  ]
}

The priceSpecification block is optional. It states that the price is per month, which is useful context for machines but not required by Google. The prices in markup must match the visible pricing table exactly. For what the rest of the pricing page should contain, see AEO for SaaS pricing pages.

What about aggregateRating?

Google's software app rich result requires either a rating or a review in addition to name and price. That tempts people to invent one. Do not. Add aggregateRating only when the page displays genuine reviews from real users and the numbers in markup match what is shown. Google's review guidelines also say not to aggregate ratings from other websites, so copying your score from a review platform into your own markup is not allowed. Without ratings, the markup is still valid and still describes your product clearly; you just will not get star snippets.

"aggregateRating": {
  "@type": "AggregateRating",
  "ratingValue": "REPLACE_WITH_REAL_AVERAGE",
  "ratingCount": "REPLACE_WITH_REAL_COUNT"
}

How do I mark up FAQs?

FAQPage wraps a list of Question items, each with an acceptedAnswer. Since 2023, Google only shows FAQ rich results for a small set of well-known authoritative sites, so most SaaS sites will not get the expanded snippet. The markup is still worth adding because it labels question and answer pairs explicitly, which mirrors exactly the format answer engines like to quote. The visible FAQ on the page must contain the same questions and answers.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does Acme Metrics have a free plan?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. The Free plan includes one project and 10,000 tracked events per month."
      }
    },
    {
      "@type": "Question",
      "name": "Can I cancel anytime?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Paid plans are billed monthly and you can cancel from your account settings."
      }
    }
  ]
}

How do I add BreadcrumbList?

BreadcrumbList describes where a page sits in your site hierarchy. Google can show it in place of the raw URL. Positions start at 1; the last item can omit item because it is the current page.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "How to measure feature adoption" }
  ]
}

What schema should blog posts use?

Use BlogPosting (a subtype of Article) for blog content. Include headline, dates, a real author with a profile URL, an image, and a publisher reference. Update dateModified only when you make meaningful changes.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to measure feature adoption in B2B SaaS",
  "description": "A practical framework for tracking which features customers actually use.",
  "image": "https://example.com/blog/feature-adoption/cover.png",
  "datePublished": "2026-10-01",
  "dateModified": "2026-10-15",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/team/jane-doe"
  },
  "publisher": { "@id": "https://example.com/#organization" },
  "mainEntityOfPage": "https://example.com/blog/feature-adoption"
}

How do @graph and @id link everything together?

Instead of several disconnected script blocks, you can put all entities for a page in one @graph array and connect them with @id references. An @id is just a stable URL-like identifier; the common convention is your URL plus a hash fragment, such as https://example.com/#organization. Define each entity once and reference it everywhere else. That way the publisher of your blog post, the publisher of your software, and the owner of your website are unambiguously the same company.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Acme Metrics",
      "url": "https://example.com/",
      "logo": "https://example.com/logo-512.png",
      "sameAs": ["https://www.linkedin.com/company/acme-metrics"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Acme Metrics",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/#webpage",
      "url": "https://example.com/",
      "name": "Acme Metrics: product analytics for B2B SaaS",
      "isPartOf": { "@id": "https://example.com/#website" },
      "about": { "@id": "https://example.com/#software" }
    },
    {
      "@type": "SoftwareApplication",
      "@id": "https://example.com/#software",
      "name": "Acme Metrics",
      "applicationCategory": "BusinessApplication",
      "operatingSystem": "Web",
      "publisher": { "@id": "https://example.com/#organization" },
      "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
    }
  ]
}
</script>

What are the most common schema mistakes on SaaS sites?

• Markup that does not match visible content. FAQ answers that appear only in JSON-LD, old prices after a pricing change, or a product description that differs from the page. Google treats this as a guideline violation, and it sends mixed signals to every machine reader.
• Fake or borrowed reviews. Invented ratings, or ratings copied from a review site, can trigger a manual action that removes rich results.
• Multiple conflicting Organization blocks. A theme, an SEO plugin, and a hand-written snippet each declaring a slightly different company name or logo. Pick one source and remove the rest.
• Schema injected only client-side. Tools like React Helmet or tag managers add JSON-LD after JavaScript runs. Google can usually render it, but many AI crawlers read only the raw HTML and never see it. Read why AI bots see empty React pages and the React SPA SEO checklist.
• Using Product instead of SoftwareApplication. Product markup is designed for physical and retail goods. SoftwareApplication describes a SaaS product more accurately.
• Invalid JSON. A trailing comma or an unescaped quote inside a CMS field silently breaks the whole block.
• Marking up every page as FAQPage. Only use it where there is a real, visible FAQ.

Where should JSON-LD live in my HTML?

Google accepts JSON-LD in either the head or the body. What matters more is that it is in the server response. On WordPress, Webflow, and Shopify, that means using the SEO plugin, page custom code, or theme template rather than a client-side tag manager; the CMS fixes guide shows where. On Next.js, Astro, or other frameworks, render the script on the server or at build time.

How do I keep schema accurate as the product changes?

Most schema problems are not written wrong on day one. They drift. Pricing changes, a plan gets renamed, an FAQ answer is edited on the page but not in the script, or a rebrand swaps the logo everywhere except the Organization block. A few habits prevent this:

• Generate from one source of truth. If your pricing table and FAQs come from a CMS or a config file, build the JSON-LD from the same data so the two cannot disagree.
• Define site-wide entities once. Organization, WebSite, and SoftwareApplication should live in a single shared template or component, with every other page referencing them by @id.
• Add schema to your release checklist. Any change to pricing, plan names, logos, or social profiles should include a schema check.
• Re-test after redesigns and CMS migrations. These are the moments when theme code, plugins, or custom snippets silently disappear.

How do I test my schema markup?

1. View Page Source on the live URL and search for application/ld+json. If it only appears in Inspect, it is client-side.
2. Run the URL through Google's Rich Results Test. It shows which Google rich result types the page is eligible for and flags errors in those types.
3. Run it through the Schema Markup Validator (validator.schema.org). It checks all Schema.org types, including ones Google does not use for rich results, such as Organization details or TechArticle.
4. After a few days, check the enhancement reports in Google Search Console for errors across many pages.
5. Use the AI crawler checker to confirm GPTBot, ClaudeBot, and PerplexityBot receive the same HTML your browser does.

SEOSync writes JSON-LD for a page as part of its fixes, alongside titles, meta descriptions, TL;DR blocks, and FAQs, and re-scores the URL after you publish. To see where a page stands before you start, run the free SEO and AEO score check.

FAQ

What schema markup should a SaaS website use?

At minimum, Organization and WebSite on the homepage and SoftwareApplication with offers on the pricing page. Add FAQPage where you have visible FAQs, BreadcrumbList on inner pages, BlogPosting on blog articles, and TechArticle on docs. Link entities with @id so every page refers to the same company and product.

Should a SaaS product use SoftwareApplication or Product schema?

SoftwareApplication, or its subtype WebApplication for browser-based tools. Product markup is designed for physical and retail goods. SoftwareApplication supports applicationCategory, operatingSystem, and offers, which describe a SaaS product and its plans more accurately. Define it once with an @id and reference it from your homepage and pricing page.

Can I add aggregateRating to my SaaS schema without reviews on the page?

No. Only add aggregateRating when the page shows genuine reviews from real users and the numbers in the markup match what is displayed. Google's guidelines also prohibit aggregating ratings from other websites. Invented or borrowed ratings can lead to a manual action that removes rich results.

Does schema markup help with ChatGPT and AI search?

No major AI engine publishes a rule that schema increases citations. Schema does make your company, product, prices, and FAQs explicit and machine-readable, which supports being a clear source. It works best combined with direct answers and FAQs in visible, server-rendered HTML.

How do I test JSON-LD schema?

Check View Page Source on the live URL to confirm the script is in the raw HTML, then run Google's Rich Results Test for rich result eligibility and the Schema Markup Validator at validator.schema.org for general Schema.org correctness. Monitor Search Console enhancement reports for errors across pages.

Get JSON-LD written for your pages

Audit a URL for SEO and AEO. SEOSync writes the schema, titles, TL;DR, and FAQs to ship.