Which Schema Markup Does a SaaS Website Actually Need?

Most SaaS websites need four or five schema types, not forty. Put Organization and WebSite markup on the homepage. Add SoftwareApplication to your main product or pricing page, but only with facts that are visibly on that page. Put BlogPosting (or Article) on each blog post, with real dates. Add BreadcrumbList on deeper pages if you show breadcrumbs. That covers what Google can actually use for a typical software company in 2026, and everything you add has to match what a visitor can see on the page.

This guide is for founders who keep hearing "add schema" and want to know which bits matter, what to paste, and what to skip. It's not written for SEO specialists, so there's no deep vocabulary here, just the pages most startup sites have and the markup each one needs. The Google documentation quoted below was read on 5 November 2026.

Last checked: Nov 5, 2026

What does structured data actually do?

Structured data is a small block of machine-readable facts about a page: this is a company, this is its logo, this is an app and what it costs, this article was published on this date. Search engines read it to understand the page with less guessing.

The honest version of the benefit is narrower than most "add schema for SEO" posts suggest. Google's structured data general guidelines say plainly that "Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly." Markup makes a page eligible for richer search features. It doesn't push the page up the rankings. The same page notes that a structured data manual action removes a page's eligibility for rich results and "doesn't affect how the page ranks in Google web search."

So think of schema as labelling, not as a growth lever. Good labels help Google show your logo, your site name, your article dates and your breadcrumbs correctly. Bad or fake labels get ignored at best. That's worth an hour of work, not a month.

Which rich results can a SaaS site still get in 2026?

A lot of older advice is out of date, because Google has cut several rich result types. Two that SaaS sites used to chase are gone:

• FAQ rich results. In August 2023 Google limited them to "well-known, authoritative government and health websites." Then, according to the Search Central documentation changelog, the feature would "no longer appear in Google Search starting May 7, 2026," and the FAQ documentation was later removed entirely.

• How-to rich results. Google's 2023 HowTo and FAQ announcement was updated in September 2023 to say How-to results were no longer shown on desktop either, "which means this result type is now deprecated."

Here's what's left that a normal software company can realistically use:

The breadcrumb point comes from Google's own changelog: in January 2025 it added a note that breadcrumbs "only appear on desktop search results, not mobile." Still worth doing, just don't expect it to change much.

Which schema goes on which page?

This is the table I'd use for a typical startup site with a homepage, a pricing page, a blog and some docs or feature pages:

If a page type isn't in that table, the default answer is "no schema needed." You can always add more later. Removing wrong markup across a whole site is the annoying part.

Should you use JSON-LD or microdata?

Use JSON-LD. Google's introduction to structured data says all three supported formats are "equally fine for Google," but also that "in general, Google recommends using JSON-LD for structured data if your site's setup allows it," because it's the easiest to implement and maintain.

The practical reason is that JSON-LD sits in its own script tag, separate from your visible HTML. Your designer can change a pricing card without breaking the markup, and you can see every fact in one place. Microdata is woven into the HTML attributes, which is fine for a static page and painful on a site that changes weekly.

What should the homepage markup look like?

One Organization block and one WebSite block, on the homepage only. Here's a made-up example for an invented meeting-notes app called Ferrowink. Swap in your own details:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://www.example.com/#organization",
    "name": "Ferrowink",
    "url": "https://www.example.com/",
    "logo": "https://www.example.com/logo-512.png",
    "sameAs": [
      "https://www.linkedin.com/company/example",
      "https://github.com/example"
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "WebSite",
    "name": "Ferrowink",
    "url": "https://www.example.com/",
    "publisher": { "@id": "https://www.example.com/#organization" }
  }
]
</script>

A few notes. Google's Organization documentation says there are no required properties, so add the ones that are true and skip the rest. The logo must be at least 112x112 pixels and crawlable. Only list sameAs profiles you actually control and keep active.

I've already written a longer guide on getting Google to show your brand properly, including site name markup and sameAs, so I won't repeat it here. If your startup doesn't appear for its own name, read how to rank for your own startup name on Google first. Schema is one small part of that fix.

How do you mark up your product or pricing page?

Google documents a SoftwareApplication type for apps, and says it also supports the WebApplication subtype, which is the honest fit for most browser-based SaaS. The required properties are a name, an offer with a price (use 0 if the app is free), and a rating or review.

That last requirement matters. Without a real rating or review, you won't get the app rich result. You can still add the markup for clarity, but don't invent a rating to fill the gap. Here's the made-up Ferrowink example without one:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Ferrowink",
  "url": "https://www.example.com/",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web browser",
  "offers": {
    "@type": "Offer",
    "price": "12.00",
    "priceCurrency": "USD"
  },
  "publisher": { "@id": "https://www.example.com/#organization" }
}
</script>

If you do show real reviews on the page, collected from real users, you can add an aggregateRating with the actual average and count. Two rules from Google's review snippet guidelines are worth knowing before you do. Don't "include fake or undisclosed incentivized reviews," which includes reviews given in exchange for money, discounts or free products without a clear disclosure. And Google says that if an organization "controls the reviews about itself," its pages using Organization markup are ineligible for star reviews. Stars about your own company, on your own site, are a dead end.

The price has to match the price on the page. If you change your pricing, the markup must change the same day. A hard-coded price in a template is the most common way schema quietly goes wrong.

What should a blog post carry?

BlogPosting is a subtype of Article, and Google's Article documentation says there are no required properties. The useful ones are headline, image, datePublished, dateModified and author. Here's an example:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How We Cut Our Meeting Notes in Half",
  "image": ["https://www.example.com/blog/notes-cover-1600x900.jpg"],
  "datePublished": "2026-11-05T09:00:00+05:30",
  "dateModified": "2026-11-05T09:00:00+05:30",
  "author": {
    "@type": "Person",
    "name": "Jane Founder",
    "url": "https://www.example.com/about"
  },
  "publisher": { "@id": "https://www.example.com/#organization" }
}
</script>

Google asks for dates in ISO 8601 format and recommends including a timezone, otherwise it falls back to Googlebot's timezone.

Now the bug I see constantly: placeholder dates. A developer builds the blog template, types a sample date like 2024-01-01 into the JSON-LD so the validator stops complaining, and that date ships on every post forever. Or the field gets a JavaScript object instead of a string and prints something useless. Every post on the site then claims the same publish date, which is wrong and makes your markup look careless. Open three of your posts, view source, search for datePublished, and check the dates are different and true. It takes two minutes.

The other date trap is the reverse: bumping dateModified on every deploy so posts look fresh. Only change it when the content really changed.

Do you need BreadcrumbList?

Only if you show breadcrumbs on the page. If your docs show "Docs > Integrations > Slack," mark up that same trail:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Docs", "item": "https://www.example.com/docs" },
    { "@type": "ListItem", "position": 2, "name": "Integrations", "item": "https://www.example.com/docs/integrations" },
    { "@type": "ListItem", "position": 3, "name": "Slack" }
  ]
}
</script>

If your site has no visible breadcrumbs, don't add the markup just for Google. Remember the general rule: don't mark up content that isn't visible to readers.

How do you add schema in Next.js, WordPress or Webflow?

Next.js. The Next.js JSON-LD guide recommends rendering structured data "as a <script> tag in your layout.js or page.js components." It also warns that plain JSON.stringify doesn't sanitize strings, and suggests replacing the < character with its unicode escape. A minimal version:

const jsonLd = { "@context": "https://schema.org", "@type": "WebApplication", name: "Ferrowink" }

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c") }}
/>

Put the homepage Organization block in the homepage's page file, not the root layout. Anything in the root layout lands on every page, the same way a canonical in the root layout quietly breaks things, which I covered in this DEV post on canonicals in a Next.js root layout. Pull prices and dates from the same data that renders the page, so they can't drift apart.

WordPress. Use the SEO plugin you probably already have. Yoast, for example, says it adds structured data "automatically using JSON-LD" and builds a single connected graph for the site. Fill in the organization name and logo in its settings, then check the output before adding a second schema plugin. Two plugins writing schema is a classic source of duplicate Organization blocks.

Webflow. Paste the JSON-LD script into a Code Embed element on the page. Webflow's help center says Code Embed supports JS in script tags and can use CMS Collection fields, which is how you feed real post dates into blog markup. Google says it can read JSON-LD in the head or the body, and even when it's injected by JavaScript, so either spot works.

How do you test it before and after shipping?

1. Before deploy: paste your code or a preview URL into Google's Rich Results Test. It tells you which Google features the page is eligible for and flags missing required fields.

2. Check the vocabulary: run the same page through the Schema Markup Validator. It checks schema.org syntax generally, including types Google doesn't use for rich results.

3. After deploy: use URL Inspection in Search Console on one live page per template to see what Googlebot actually received.

4. Over the following weeks: watch the rich result reports under Enhancements in Search Console. Google notes the rich result reports show "a sample of detected items," not every page, so a report with 40 items on a 300-page blog isn't necessarily broken.

Test one page per template, not every page. If the blog template is right, every post is right. If it's wrong, every post is wrong, which is why the template is where you look.

Does schema help you show up in AI answers?

Be careful with anyone who says yes with confidence. Google's page on AI features and your website says "there's no special schema.org structured data that you need to add" to appear in AI Overviews or AI Mode. The same page lists "making sure your structured data matches the visible text on the page" as one of the normal SEO basics. That's it. I haven't seen any official confirmation from the big AI assistant companies that their models read JSON-LD when they answer questions.

My view: clean markup can't hurt, and it does state your entity facts (name, what the product is, price, who makes it) in one unambiguous place. But AI answers mostly pull from what pages say in plain text, on your site and on other sites. If you want to be cited, my playbook for getting your startup cited in AI search answers covers the parts that matter more than markup.

One of those parts is third-party pages that explain your product in context. A real editorial article, like a longer decision explainer on Piece Press, gives readers and assistants a description of what you do that you didn't write in your own schema. (Piece Press is run by the same team as Aura++.) That kind of coverage is earned or arranged outside your site, and no markup on your homepage replaces it.

What mistakes get markup ignored or penalized?

• Marking up hidden content. Google's guidelines say "don't mark up content that is not visible to readers of the page." No prices, ratings or FAQs that only exist in the script tag.

• Fake ratings. A 4.9 star rating with a count of 312, copied from nowhere, is an easy way to earn a manual action. Google also says reviews "not by actual users may result in manual action."

• FAQ spam. Adding FAQPage markup to every page hoping for extra space in results. That feature is gone, and it was never meant for sales copy.

• Mismatched or stale prices. The page says one price, the markup says last year's. Generate both from the same source.

• Duplicate Organization blocks. One from the theme, one from a plugin, one you pasted. Pick one source and delete the others.

• Organization markup on every page. Google's documentation talks about adding it to your home page. Sitewide copies add noise, not information.

• Placeholder dates. Every post published on the same sample date. Covered above, and very common.

• Blocking the page. Markup on a page blocked by robots.txt or noindex can't be used at all.

A 60-minute plan to get this right today

FAQ

What schema markup does a SaaS website need?

Organization and WebSite on the homepage, SoftwareApplication or WebApplication on the main product or pricing page, BlogPosting on posts, and BreadcrumbList where breadcrumbs are shown. Most small SaaS sites don't need more.

Does schema markup improve Google rankings?

No. Google says structured data makes pages eligible for rich results and doesn't guarantee they'll appear. Even a structured data manual action affects rich result eligibility, not ranking.

Should I still add FAQ schema?

Not for Google. FAQ rich results stopped appearing in Google Search in May 2026, and Google says structured data that isn't used causes no problems but has no visible effect. Keep the FAQ content on the page if it helps readers.

Can I add aggregateRating with my own testimonials?

Only if they're genuine reviews from real users shown on that page, and even then Google's review snippet rules restrict star reviews where a company controls reviews about itself. Never invent a rating or a review count.

Label what's true, then get back to the product

Schema markup for a SaaS site is a one-hour job: a few honest blocks that match the page, a template fix for dates, and a test. Do that, delete anything fake, and move on to the work that brings people to the site. If you're launching soon, Aura++ is one place to list the product so the first visitors have a way in.