Breadcrumb, FAQ, and Review Schema: Which Rich Results Are Worth It?

Three schema types show up in almost every "add structured data" checklist: BreadcrumbList, FAQPage, and review markup (Review plus AggregateRating). As of July 2026 they pay out very differently. One still renders in Google, one stopped rendering on May 7, 2026, and one is gated by a rule about who owns the reviews that most SaaS sites trip over without noticing.

We crawled 985 reachable SaaS and indie-software homepages in July 2026 and validated every JSON-LD block with our own parser. That data (published in full at /research/saas-review-schema-2026) lets us say what SaaS teams actually ship rather than what the checklists recommend, so this post ranks the three by payoff and shows the failure rate for each.

What each one produces in search results right now

Breadcrumb markup still renders. Google's breadcrumb documentation carries no deprecation notice and describes the feature as available on desktop in every region and language where Search runs. A valid BreadcrumbList replaces the raw URL path above your title with a readable trail. Requirements are small: an itemListElement array of at least two ListItem objects, each with position, name, and item.

FAQ rich results are gone. Google restricted them to well-known government and health sites in September 2023, then retired the feature outright. FAQ rich results stopped appearing in Google Search on May 7, 2026, the Search Console appearance filter and Rich Results Test support were removed in June 2026, and Search Console API support goes away in August 2026. Google's guidance is that the markup can stay: it will not cause problems and it will not produce visible results in Search.

Review markup renders stars, when you qualify. Google supports review snippets on types including Book, Course, Event, LocalBusiness, Movie, Product, Recipe, Software App, and Organization. The catch is the self-serving rule, covered below in its own section, and it is the reason most SaaS homepages with rating markup never see a star.

The implementation failure rate is the real story

Adoption is thin across all four types, and 742 of the 985 sites we reached (75.3%) shipped none of them. What surprised me more was the error rate among the sites that did bother. Our validator flags an outright error when a required property is missing or malformed, the kind of problem that can disqualify a rich result rather than just leave value on the table:

• Review: 17 of 38 sites (44.7%) had validation errors.
• AggregateRating: 28 of 111 sites (25.2%) had errors.
• BreadcrumbList: 18 of 92 sites (19.6%) had errors.
• FAQPage: 12 of 92 sites (13.0%) had errors.

The ordering tracks complexity almost exactly. FAQPage is a flat list of Question and Answer pairs, and all 92 sites that shipped it emitted both child types correctly. Review markup carries nested objects, required numeric properties, and a hard dependency on real data flowing from somewhere, so it breaks most often. Across the whole crawl, only 57 of 531 JSON-LD deployments (10.7%) validated with no errors and no warnings.

There is a second pattern in the rating data worth naming. Of the 111 sites with AggregateRating, 82 shipped no Review markup at all, meaning they published an average score with nothing behind it on the page. Google's review snippet guidelines require that the review content you mark up is readily available to users from the marked-up page, and that it is immediately obvious the page has review content. A bare average with no visible reviews fails that test even when the syntax validates. The step-by-step version of getting this right is in how to add AggregateRating schema.

The self-serving rule is what actually blocks star ratings

Google's review snippet documentation is direct about this: if the entity being reviewed controls the reviews about itself, pages using LocalBusiness or any other Organization type are ineligible for the star review feature. That applies whether the reviews sit in your own HTML or arrive through an embedded third-party widget.

This is where the crawl gets uncomfortable. Of the 111 SaaS homepages carrying AggregateRating, 103 also emit Organization markup on the same page. If the rating attaches to that Organization node, or if Google reads the page as a company publishing ratings of itself, the markup is ineligible no matter how clean it validates. Teams in that position often conclude their schema is broken and spend a week debugging syntax. The syntax is usually fine. The eligibility is not.

Two routes stay open. First, attach ratings to a Product or SoftwareApplication node rather than your Organization, which is what our crawl found on 100 of the 111 rating sites and what Google's Software App documentation describes (either aggregateRating or review is required there). Second, earn the stars on a page you do not control, because a third-party review platform reviewing your product is not the same entity reviewing itself. That is the structural reason review platform pages show stars while vendor homepages usually do not. We build one of them, so weigh that accordingly: our public profiles at /apps carry the rating markup for each listed product, and the underlying reviews come from verified users rather than the vendor.

For the mechanics of what Google renders once you do qualify, review schema markup and star ratings in Google walks through the SERP side.

What to do about FAQ markup you already ship

Keeping it is the reasonable default, and Google explicitly says it causes no problems. FAQPage remains a valid schema.org type, and the same question-and-answer structure that used to earn an accordion in the SERP is now doing quieter work: it gives language models a clean, unambiguous mapping from question to answer when they parse your page, and it forces you to write direct answers instead of burying them in a paragraph.

What I would stop doing is treating new FAQ blocks as an SEO deliverable with a measurable SERP outcome. There is no rich result to win and no Search Console report to check after August 2026. Write the FAQ because readers ask the question, mark it up because the markup is cheap, and measure it as content rather than as structured data. Our own posts still emit FAQPage JSON-LD for exactly that reason.

The order I would ship them in

1. Fix what you already ship. With 17.1% of JSON-LD deployments in our crawl carrying outright errors, validating existing markup usually beats adding more. Paste a page into our JSON-LD validator or Google's Rich Results Test and clear the errors before writing anything new.
2. Breadcrumbs. Cheapest real win on the list, still rendering, and on most frameworks you can generate the trail from the route you already have.
3. Product or SoftwareApplication for the entity itself. This is the node ratings can legitimately attach to later, and it feeds the Software App rich result independently.
4. Ratings, on the pages that qualify. Visible reviews on the page, ratingValue plus at least one of ratingCount or reviewCount, attached to the product rather than your company. The AggregateRating schema generator produces a valid block if you want a reference to diff against.
5. FAQ markup, last and cheap. Ship it with the FAQ schema generator if you want the machine-readable version, and expect nothing in the SERP.

The broader hierarchy of which types matter for a review-driven site, and how they fit together in one graph, is laid out in our structured data guide.

The honest summary of the three: breadcrumbs are a small, safe win, FAQ markup is now hygiene rather than a growth lever, and review markup is the one with real SERP value and the one where eligibility, not syntax, decides whether you get it.