Rich Results: What They Are and How to Earn Them

The distinction that trips people up most is rich results versus rich snippets. Rich snippets is Google's older, narrower term for text-based enhancements like star ratings or review counts sitting inside an otherwise normal listing. Rich results is the current, broader term that covers those plus interactive and visual formats: FAQ accordions, product carousels, recipe cards with images, how-to steps, and job postings with apply buttons. Google now uses "rich results" as the umbrella term in its own documentation and testing tools, and treats "rich snippets" as one subtype within it. For practical purposes, if you're auditing a site or reading Search Console reports today, the terms you'll encounter are Rich Results Test and Rich Results status report — both use the newer, broader label.

Why rich results matter beyond a nicer-looking snippet

The real payoff of a rich result is attention capture on a results page that's increasingly crowded with AI overviews, ads, and other enhanced listings. A plain blue link competes for a click on visual merit alone — a title, a URL, and two lines of description. A rich result adds a star rating, a price, an image thumbnail, or an expandable answer that occupies more vertical space and draws the eye before a searcher even reads the title. That's the mechanism, not a vague promise of "more traffic": structured markup changes what physically renders on the page, and what renders changes which listing a scanning eye lands on first.

A second reason to get this right has nothing to do with the traditional results page: 87% of the sources AI answer engines cited for KinetixSEO's tracked prompts over a 90-day window were vendor or marketing pages, according to KinetixSEO GEO citation tracking, measured across 422 observations and 216 cited source links, each classified as a community forum, reference wiki, product documentation, or vendor/marketing page. That figure describes what these engines are already pulling from today, not a claim about what markup changes tomorrow. But it does mean the field an answer engine is drawing citations from is dominated by loosely-labeled prose rather than pages with explicit, bounded facts — fields like ratingValue, price, or datePublished that don't need to be parsed and interpreted the way a paragraph does. Structured, well-labeled pages stand out in that field, which is a second, compounding reason to get the markup right beyond the classic search results page. AI Citation Tracking: How It Actually Works explains how this kind of tracking works if you want the mechanics behind the figure.

How rich results actually behave

Rich results aren't a fixed reward for correct markup — they're a rendering decision Google's systems remake for every query, every page, and every device, and that decision can change without any change to your page. A page can be fully eligible, pass validation, and still not show a rich result for a given search because Google judged a different format more useful for that specific query, or because a competing page's enhancement was ranked ahead of it. The same page can show a rich result on mobile and not on desktop, or show one type of enhancement for one query variant and a different one for another. This is why "why did my rich result disappear" is one of the most common technical SEO questions, and why the answer is rarely a broken schema — it's usually query-level or policy-level, not markup-level.

Eight schema types account for most real-world rich result implementations, each keyed to a distinct @type and its own required fields:

• FAQ — question-and-answer pairs rendered as an expandable list directly in search results, using the FAQPage type.
• How-to — numbered steps with optional images and time estimates, using the HowTo type.
• Review/Rating — star ratings and review counts attached to products, recipes, or local businesses, using Review or AggregateRating nested in the relevant type.
• Product — price, availability, and rating shown together, typically through Product and Offer.
• Recipe — cook time, ratings, and a photo shown in a card format, using Recipe.
• Article — headline, image, and publish date shown in article carousels and top-stories placements, using Article or NewsArticle.
• Event — date, location, and ticket availability, using Event.
• Breadcrumb — a page's site hierarchy shown in place of its raw URL, using BreadcrumbList.

Google retired a handful of rich result types over the years — including some review-snippet eligibility for certain categories — as part of ongoing policy tightening aimed at preventing markup that doesn't match visible page content. That history is a useful reminder that eligibility rules shift, and a type that worked two years ago isn't guaranteed to work identically today.

What actually determines eligibility

Four things determine whether a rich result appears: valid markup, a content match, crawlability, and Google's own query-level judgment — and markup alone only covers the first one.

1. Valid, complete structured data. The JSON-LD must use a supported schema type, include all required properties for that type, and pass validation. A missing required field — like ratingValue on a Review, or image on a Recipe — disqualifies the whole block, not just that field.
2. Markup that matches visible content. Google's structured data policies require that marked-up data reflect what a user actually sees on the page. Marking up a rating value that doesn't appear anywhere in the visible page content is a policy violation, not a technical error, and can result in manual action rather than just a missed rich result.
3. Crawlability and indexing. A page with perfect markup that Google can't crawl or won't index never gets evaluated for rich results at all. Pages buried deep in a large site's architecture, or blocked by inefficient crawling patterns, may simply never get re-crawled often enough for Google to pick up markup changes — an issue covered in more depth in Crawl Budget Optimization: What Actually Matters.
4. Google's query-level judgment. Even fully eligible, policy-compliant pages are shown or withheld based on what Google's systems decide serves a specific search best — which is why eligibility and actual display are two different things, and why a page can lose a rich result with no change on your end.

Confusing eligibility with guaranteed display is the single most common misunderstanding site owners bring to a technical SEO audit, and it's worth separating cleanly before doing any markup work.

How to check whether a page is eligible

Rich results eligibility checklist

• Run the page through Google's Rich Results Test

• Read every warning, not just errors

• Check the Rich Results status report in Search Console

• Fix errors first, then warnings, then re-test

• Confirm the markup matches what's visibly on the page

• Re-crawl and monitor after fixes ship

Checking eligibility means running the page through Google's own validator, then cross-checking it against the site-wide Search Console report before treating anything as fixed. Skipping either step is the most common reason teams miss a live problem:

1. Run the page through Google's Rich Results Test. Paste the URL or raw code and the tool reports which rich result types it detected and whether each is valid, invalid, or has warnings.
2. Read every warning, not just errors. Warnings mark optional-but-recommended fields; adding them often improves how an enhancement renders even when the page is technically already "valid."
3. Check the Rich Results status report in Search Console for the property. It groups pages by type (FAQ, Product, and so on) and flags valid items, items with warnings, and items with errors across the whole site, not just one URL.
4. Fix errors first, then warnings, then re-test. Errors block eligibility outright; warnings degrade what's shown or leave optional enhancements out.
5. Confirm the markup matches what's visibly on the page. A page that passes the validator but marks up content a user can't see risks a policy action, not just a missed rich result.
6. Re-crawl and monitor. After fixing markup, eligibility only updates once Google re-crawls and re-evaluates the page — which can take days, and longer on sites with crawl budget constraints.

Common reasons rich results fail or disappear

Most rich result failures trace back to a handful of repeat causes, and almost none of them are exotic.

Markup and content problems

• Missing required properties — the single most common validator error, usually a required field left out of a nested type (like author inside Review).
• Markup-content mismatch — data marked up that isn't visibly present on the page, which is a policy issue rather than a syntax one.
• Multiple conflicting schema blocks — two different JSON-LD blocks describing the same entity with contradictory values, which can cause Google to ignore both.

Site- and policy-level problems

• Thin or duplicate content — Google can suppress rich results on pages it considers low-value even when markup is technically valid.
• Site-wide policy actions — manual actions related to structured data spam apply across a whole site or section, not just one page, and can silently disable rich results everywhere until resolved.
• Recent Google policy changes — Google periodically narrows which content types or categories qualify for a given rich result, independent of anything on your page.
• Crawl delays — a fix that's live on the page but not yet re-crawled will keep showing the old (or no) rich result in results.

Anyone who has watched a rich result vanish overnight without a code change has usually run into one of the last three: a policy shift, a site-wide action, or simply a crawl lag before the last recrawl catches up.

Implementation without breaking anything else

Adding structured data is additive by design — it should never touch what a user sees, and any implementation that does introduces the exact markup-content mismatch that gets pages penalized. The safest path is to build the JSON-LD block to describe content that already exists on the page verbatim: if a Review block claims a star rating, that rating needs to be visible, in that value, somewhere a user actually reads it. For teams building this from scratch, Structured Data SEO Guide: JSON-LD That Actually Works walks through implementation patterns that stay policy-compliant, and Article Schema: A Step-by-Step Setup Guide covers the specific fields and nesting Google expects for article-type rich results, which is one of the more finicky types to get fully valid on the first try.

Two rules keep implementation clean regardless of the type in play: use one JSON-LD block per entity per page, and treat validation as a release gate rather than a one-time task. Stacking multiple conflicting blocks describing the same product or article is a frequent cause of silent validator confusion, not a way to hedge your bets, so each entity on a page should get exactly one block. And because a price update, a removed FAQ, or an edited review can silently break the match between markup and page, re-running the Rich Results Test any time visible content changes catches the mismatch immediately instead of days later when Search Console flags it.

FAQ eligibility as a special case worth understanding

FAQ rich results deserve their own note because Google narrowed eligibility for this type specifically, and a lot of published advice online still describes the older, broader rules. FAQPage markup is now generally eligible to produce a visible rich result mainly for well-known, authoritative sites — government and health organization pages are the categories Google has named — while most other sites can still use the markup for machine-readability without it necessarily rendering the expandable snippet in results. That doesn't make FAQ markup pointless outside those categories: it still gives search engines and AI answer systems an explicit, labeled question-and-answer structure to work from, which supports the same citation-friendliness discussed earlier, even on sites where the visible accordion snippet itself won't display.

Structured data isn't the whole picture

Rich results sit downstream of two more basic technical requirements that have to be in place before any markup work pays off: the page has to be crawled and indexed, and it has to load well enough that Google's evaluation systems treat it as a quality candidate in the first place. A page with flawless FAQ markup that's rarely recrawled because of poor crawl budget allocation on a large site won't show updated rich results promptly even after a fix ships, and a page with slow, unstable rendering can affect how Google's systems assess overall quality signals, which factor into eligibility indirectly. Core Web Vitals 2026: Current Metrics and Fixes covers the current thresholds worth checking alongside any structured data audit, since the two workstreams tend to surface in the same technical review and fixing one without the other leaves easy gains on the table.

Frequently asked questions

What is the difference between rich results and rich snippets?

Rich snippets is Google's older term for text-based enhancements like star ratings inside a standard listing, while rich results is the current, broader term covering those plus interactive formats such as FAQ accordions, product carousels, and recipe cards with images. Google's own tools — the Rich Results Test and the Rich Results status report in Search Console — use the newer, broader label, and treat rich snippets as one subtype within it rather than a separate category.

Does adding structured data guarantee a rich result?

No — valid structured data is a prerequisite, not a guarantee, because Google separately judges whether an enhancement serves a specific query well before deciding to display it. A page can pass every validation check in the Rich Results Test and still not show the enhancement if Google's systems favor a different format for that search, or if a competing page's version is ranked ahead of it for that query.

Why did my rich result disappear without any change to my page?

The most common causes are a Google policy change narrowing eligibility for that type, a site-wide manual action tied to structured data spam, or simply a crawl delay before Google re-evaluates the page. Because display is a query-level decision remade continuously rather than a one-time reward, a rich result can stop appearing even when the underlying markup on the page hasn't changed at all.

Can I mark up content that isn't visible on the page to get a rich result?

No — Google's structured data policies require marked-up data to match what a user actually sees on the page, and mismatched markup is treated as a policy violation, not a technical error. This can trigger a manual action affecting the whole site's structured data eligibility, not just a missed enhancement on one page, so it's a far more serious failure mode than a validator warning.

How long does it take for a rich result to appear after fixing structured data errors?

There's no fixed timeline — a rich result appears only after Google re-crawls the page and re-evaluates its eligibility, which depends on how frequently that page gets crawled. On large sites with crawl budget constraints, that recrawl can lag well behind the fix going live, which is why checking the Rich Results status report days later, rather than expecting an immediate change, is the more reliable way to confirm a fix worked.