# Schema markup for SaaS > Which structured data types still earn something for SaaS, with copy ready JSON-LD for organization, product and FAQ markup, plus validation and monitoring. Source: https://saas-marketing.net/guides/schema-markup-for-saas/ Topic: SaaS SEO Type: guide Published: 2026-09-11 Last updated: 2026-09-11 Publisher: SaaS Marketing (saas-marketing.net) License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/schema-markup-for-saas/ ## Short answer Mark up six types on a SaaS site: Organization with sameAs, SoftwareApplication with offers, Article with author and dateModified, BreadcrumbList, FAQPage and Person for authors. Schema is not a ranking factor. It exists to make your product, price, publisher and author machine readable for Google's entity graph and for the retrieval layers inside ChatGPT, Perplexity and Gemini. Never publish an aggregateRating you cannot show on the page. ## Key takeaways - Schema is not a ranking factor. It reduces ambiguity for parsers, which is a different and more durable benefit. - Organization markup with a complete sameAs array is the highest value block on a SaaS site and takes two hours. - Google cut FAQ rich results to government and health sites in August 2023, but FAQPage markup still parses cleanly for extraction. - Publishing an aggregateRating you cannot show on the page invites a spammy structured data manual action. - Most schema breaks during a CMS or framework migration, so monitoring matters more than the original implementation. - SoftwareApplication rarely produces a visual rich result for B2B, and it is still worth shipping on pricing and product pages. --- Schema markup does not make a page rank. Google has said so repeatedly, and the correlation studies claiming otherwise are mostly measuring sites that happen to employ good engineers. What structured data does is remove ambiguity, and ambiguity got expensive the moment a retrieval layer inside ChatGPT or Gemini started deciding, in a few hundred milliseconds, whether your pricing page answers a buying question. So the useful question isn't whether to mark up. It's which types still return something, in what order you ship them, and how you stop a framework migration from silently deleting the lot six months later. ## Which schema types still return something for a SaaS site Six types earn their engineering time on a B2B SaaS site: Organization, SoftwareApplication, Article or BlogPosting, BreadcrumbList, FAQPage, and Person for your named authors. Everything else on schema.org is optional, and several types recommended in 2021 blog posts no longer render anything at all. Google has been shrinking the rich result surface since 2023. FAQ rich results were cut back to well known government and health sites in August 2023. HowTo results came out of desktop and mobile a month later. A further batch of low-usage types was retired in 2025. The direction is consistent and nothing suggests it reverses. Note the pattern. The types with the best return are the ones that describe entities rather than the ones that decorate results. That flip happened quietly between 2023 and 2025, and most SaaS schema implementations still reflect the older priority order, which is why so many sites have elaborate FAQ markup on nine blog posts and no Organization node anywhere. If you only have one afternoon, spend it on Organization and BreadcrumbList across the whole site. Both are template level, both apply to every URL, and neither requires anyone to write new copy. Skip the per-page work until the sitewide layer exists. That ordering matters more on large sites, and it matters most on the templated page sets covered in [programmatic SEO for SaaS](/guides/programmatic-seo-for-saas/), where one template fix propagates to a few thousand URLs. ## Organization markup is the highest value block on your site Ship one Organization node, sitewide, with a stable `@id`, and reference it from everything else. This is the block that tells Google and every AI crawler which company published the page and which real world entity that company is. ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://example.com/#organization", "name": "Acme Analytics", "legalName": "Acme Analytics, Inc.", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo-512.png", "width": 512, "height": 512 }, "foundingDate": "2019-04-02", "numberOfEmployees": { "@type": "QuantitativeValue", "value": 140 }, "description": "Product analytics for B2B software teams.", "sameAs": [ "https://www.linkedin.com/company/acme-analytics/", "https://www.crunchbase.com/organization/acme-analytics", "https://www.g2.com/products/acme-analytics/reviews", "https://github.com/acme-analytics", "https://www.youtube.com/@acmeanalytics", "https://www.wikidata.org/wiki/Q00000000" ], "contactPoint": [{ "@type": "ContactPoint", "contactType": "sales", "email": "sales@example.com", "areaServed": "US" }] } ``` Two details people get wrong. First, `logo` should be a square image of at least 112 by 112 pixels, and the URL has to be crawlable, which rules out anything behind an auth wall or a signed CDN URL that expires. Second, one Organization node per site. Sites that repeat a slightly different Organization block on 40 landing pages, each with a different description, are actively making the entity harder to resolve. The most common SaaS schema bug I find on audits is a legacy Organization block in the site footer template and a second one injected by an SEO plugin, disagreeing about the company name or logo. Parsers do not average them. Delete one. ## sameAs is how you stop being confused with the other company called Linear The `sameAs` array is an entity reconciliation instruction. You are telling a machine that the thing described on this page is the same thing described on LinkedIn, on Crunchbase, on G2 and, if it exists, on Wikidata. For a SaaS brand with a common noun for a name, this is the difference between showing up as a software company and showing up as a geometry term. Put these in, in roughly this priority order: - LinkedIn company page, because it is the most consistently trusted B2B identity source - Crunchbase profile, which carries funding, founding date and category - G2 or Capterra product profile, which carries category and reviews - GitHub organisation, if you ship developer facing software - YouTube channel and X profile, if they are actually maintained - Wikidata item, if one legitimately exists Wikidata deserves a warning. You cannot simply create an item for your seed stage company and expect it to hold. Wikidata has notability requirements, and self-created items for non-notable companies get deleted, sometimes along with a note about the account that created them. If you have press coverage, a Wikipedia article or a funding record in reliable sources, an item is defensible. If you don't, leave it out and revisit at Series B. Keep the array honest and current. A `sameAs` pointing at a dead Twitter account or a Crunchbase profile with the old company name is worse than a shorter list, because it introduces exactly the contradiction you were trying to remove. This is the same entity consistency work described in the [AEO checklist for SaaS](/checklists/saas-aeo-checklist/), and the two jobs should be done in the same sprint by the same person. ## SoftwareApplication: what to claim, and the line you should not cross Use SoftwareApplication on your product page, your pricing page and your main feature pages. Be aware that for B2B software this rarely produces a visible rich result, since Google's software app results skew heavily toward consumer mobile apps. Ship it anyway, because it is the only place on your site where the category, platform and price of your product are stated in a form a machine can read without guessing. ```json { "@context": "https://schema.org", "@type": "SoftwareApplication", "@id": "https://example.com/#software", "name": "Acme Analytics", "applicationCategory": "BusinessApplication", "applicationSubCategory": "Product Analytics", "operatingSystem": "Web, iOS, Android", "url": "https://example.com/product/", "publisher": { "@id": "https://example.com/#organization" }, "softwareVersion": "4.2", "featureList": [ "Funnel analysis", "Session replay", "Warehouse sync" ], "offers": { "@type": "AggregateOffer", "lowPrice": "0", "highPrice": "499", "priceCurrency": "USD", "offerCount": 4, "url": "https://example.com/pricing/" } } ``` `AggregateOffer` is the right shape for tiered SaaS pricing. A single `Offer` with one price implies a single product at a single price, which is almost never true for a seat-based tool with a free tier and an enterprise plan. If your enterprise tier is quote-based, set `highPrice` to your highest published number and leave the quote tier out rather than inventing a figure. Now the line. Do not add `aggregateRating` unless the ratings are genuinely visible on that page and sourced honestly. Google's policy is that review content marked up on a page must be available to users on that page, and self-serving reviews about your own product, written by you, are not eligible. Pulling your 4.6 from G2 into JSON-LD while showing nothing on the page is one of the most reliable ways a software company earns a spammy structured data manual action. I've seen it cost a site its entire rich result eligibility for a quarter. If you want stars, embed a real review widget with real reviews and mark up what is on the screen. The second most common problem after fake ratings is a price in JSON-LD that no longer matches the pricing page after a repackaging. Bind the schema price to the same data source that renders the price, not to a hardcoded string in a template. ## What changed when Google cut FAQ rich results, and why you keep the markup In August 2023 Google limited FAQ rich results to well known government and health sites. Your B2B SaaS blog post will not get the expandable accordion in search results, and no amount of correct markup will change that. A lot of teams responded by ripping FAQPage out entirely. That was the wrong call. Question and answer pairs are the single cleanest structure a retrieval system can consume. When an LLM assembles an answer about your category, a page that exposes explicit `Question` and `acceptedAnswer` nodes is trivially easy to chunk and quote, while a page where the same content is buried in prose under an accordion built from unlabelled divs is not. The rich result went away. The extraction value went up. Two rules keep FAQPage useful. The questions must be real queries a buyer types, not keyword variations you invented for the markup, and the answers must be visible on the page rather than hidden behind a click that never fires without JavaScript. If you are writing questions purely to fill the schema block, you have built a liability rather than an asset. ## Article, author, and the dateModified trap Article or BlogPosting markup on editorial pages does three jobs: it names the author as a real Person, it names the publishing organisation, and it states when the piece was written and last changed. All three feed the experience and expertise signals Google's quality systems look for, and all three get extracted by AI systems trying to work out whether a source is credible. ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Schema markup for SaaS", "datePublished": "2026-02-18", "dateModified": "2026-09-11", "author": { "@type": "Person", "name": "Jordan Reyes", "jobTitle": "Head of SEO", "url": "https://example.com/authors/jordan-reyes/", "sameAs": ["https://www.linkedin.com/in/jordanreyes/"] }, "publisher": { "@id": "https://example.com/#organization" }, "mainEntityOfPage": "https://example.com/blog/schema-markup-for-saas/" } ``` The trap is `dateModified`. Plenty of SaaS sites bump it nightly on every URL in the hope of looking fresh. Google has explicitly warned against artificially updating dates without substantive change, and the practical result is that your date signal becomes noise. Set `dateModified` from your CMS field that only changes when an editor actually saves a meaningful revision. If you run a quarterly refresh cycle, that field will tell a true story, and true stories are the only ones that survive a quality review. Give each author a real page with a real bio, a real LinkedIn link, and a history of work. An author node pointing at `/author/admin/` does nothing. This matters more for a young domain than for an established one, which is why it appears early in the [seed stage SaaS SEO](/playbooks/seed-stage-saas-seo/) sequence rather than later. ## HowTo belongs in your docs, and Google stopped rendering it Google removed HowTo rich results in September 2023. The markup is still valid schema.org and still parses, which makes it worth emitting in one place: your product documentation. Docs pages are procedural by nature, they are the pages AI assistants quote most often when someone asks how to configure something in your product, and explicit `HowToStep` nodes make the procedure machine readable without relying on heading hierarchy. Do not put HowTo on marketing pages. A blog post called "How to build a content calendar" that wraps six loose paragraphs in HowToStep nodes is markup theatre. If the content is genuinely a sequence of discrete actions with a completion state, mark it up. If it isn't, don't. There's an adjacent decision here worth naming. If your docs live on a subdomain, the Organization node on that subdomain should use the same `@id` as the one on your marketing site, so both properties resolve to one entity. Split entities across `docs.` and `www.` are surprisingly common and quietly weaken both. ## BreadcrumbList is boring, and you should ship it anyway BreadcrumbList still renders in Google results, which already puts it ahead of most of this list. It also does real structural work on large sites by stating the hierarchy explicitly rather than making a crawler infer it from URL segments and nav links. ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Integrations", "item": "https://example.com/integrations/" }, { "@type": "ListItem", "position": 2, "name": "Salesforce", "item": "https://example.com/integrations/salesforce/" } ] } ``` This matters most on templated page sets. When you publish 800 integration pages, the breadcrumb is often the clearest signal that `/integrations/salesforce/` belongs to a coherent parent set rather than being an orphan. Our [programmatic page indexation study](/research/programmatic-page-indexation-study/) found hierarchy and internal link depth doing far more for indexation than any on-page content tweak, and breadcrumb markup is the cheapest way to state hierarchy unambiguously. Pair it with the linking rules in [internal linking for SaaS](/guides/saas-internal-linking/) and you have covered most of what a crawler needs to make sense of a large set. ## Validate once, then monitor for the regression Schema breaks. It breaks during CMS migrations, during design system refactors, when a developer removes a component that nobody realised was rendering the JSON-LD, and when a marketer edits a template in a visual builder. The implementation is a day of work. The monitoring is what keeps it alive. **Ship and keep schema working** The build time assertion is the part almost nobody does and the part that pays. On a Next.js or Astro site, a test that renders a representative page, parses every `application/ld+json` block, and asserts the presence of required keys takes an afternoon and prevents the class of failure where you discover in September that schema has been missing since June. Compare the cost of that afternoon against a quarter of lost rich result eligibility and the decision makes itself. ## What this actually costs, and when to skip it Honest accounting. A sitewide Organization plus BreadcrumbList plus Article implementation on a templated SaaS site takes two to four engineering days, including QA. Per-page SoftwareApplication and FAQPage work adds maybe a day. The monitoring setup is another half day. Then it costs a few hours a quarter to keep `sameAs`, pricing and author data accurate. What you will not get is a traffic graph that jumps. Schema rarely produces a visible before-and-after, which makes it genuinely hard to justify against a sprint that could ship five bottom of funnel pages instead. If you have fewer than 30 indexed pages and no product pages ranking, schema is the wrong priority: go write the pages first, using something like the [bottom of funnel page sprint](/courses/saas-seo-sprint/02-bofu-pages/), and come back to markup when there is something worth describing. That's the honest tradeoff, and it's the answer I give most seed stage teams who ask about this. Teams that should treat it as urgent: anyone with a name collision against a bigger entity, anyone whose knowledge panel shows wrong or missing information, anyone running a large templated page set, and anyone whose category is being answered by AI assistants that currently name three competitors and not them. ## What to do this week **Schema markup starting order** Do the sitewide layer first, the product layer second, the per-page layer last, and set up the monitoring before you tell anyone it's finished. If you want to see where this fits against everything else competing for the same engineering hours, the sequencing in the [SaaS SEO hub](/saas-seo/) puts it after technical foundations and page production, which is where it belongs for almost every company. And if your next argument is whether to spend those hours on templated pages at all, [programmatic versus editorial content](/comparisons/programmatic-vs-editorial-content/) is the decision to settle before you write a line of JSON-LD. ## Frequently asked questions ### Does schema markup improve SaaS rankings? No, not directly. Google has stated repeatedly that structured data is not a ranking signal. It affects eligibility for rich results and it makes your entity, pricing and authorship unambiguous to parsers. The measurable wins are click-through rate on breadcrumb and article results, knowledge panel accuracy, and cleaner extraction by AI answer engines. ### What schema type should a SaaS product page use? SoftwareApplication, with applicationCategory, operatingSystem and an offers block carrying price and priceCurrency. If you sell seats with tiered pricing, use an AggregateOffer with lowPrice and highPrice rather than inventing a single figure. Add Organization as the publisher and link the two nodes with an @id reference so parsers connect the product to the company. ### Is FAQ schema still worth adding in 2026? Yes, for extraction rather than for stars. Google restricted FAQ rich results to well known government and health sites in August 2023, so a B2B SaaS page will not get the accordion in search results. The markup still gives retrieval systems clean question and answer pairs, which is the format LLM answer engines quote most readily. ### Can I add aggregateRating using our G2 score? Only if the rating is visibly present on the same page and you are honest about the source. Google's policy requires that review content marked up on a page is available to users on that page. Pulling a G2 average into JSON-LD with nothing visible is a policy violation and a common cause of manual actions against software sites. ### What does sameAs do in Organization schema? It lists the authoritative profiles that describe the same entity, such as your LinkedIn company page, Crunchbase profile, G2 listing, GitHub organisation and Wikidata item. Search engines and AI systems use those links to reconcile your brand with the right entity, which matters enormously if another company shares your product name. ### How do you validate schema markup at scale? Use Google's Rich Results Test for eligibility and validator.schema.org for syntax, then crawl the whole site with Screaming Frog or Sitebulb with structured data validation switched on. Search Console's Enhancements reports catch site wide regressions but lag by days. For a large template driven site, add a build time test that fails the deploy when required properties disappear. ### Should schema be inline JSON-LD or injected by a tag manager? Inline JSON-LD in the page source, rendered server side. Google can execute JavaScript and will usually pick up tag manager injected markup, but it adds a render dependency and most AI crawlers do not run JavaScript at all. If your structured data only exists after hydration, a large share of the systems you are targeting will never see it.