Rich results: what they are and how to earn them
Rich results are enhanced Google Search results that go beyond a standard blue link with extra details such as ratings, price, availability, images, breadcrumbs, or event dates.
Structured data can make a page eligible for rich results, but Google still decides whether to show the richer appearance for each query, device, and context.
The short version: rich results are search enhancements earned by clear, valid, visible structured facts.
What are rich results?
Rich results are enhanced results on Google surfaces that go beyond a standard blue link. Google can use structured data to understand the content on a page and show that content in a richer search appearance, which Google calls a rich result in its Search Gallery.
The simplest example is a product result that shows an image, price, availability, rating, shipping, or return information before the shopper clicks. Recipes, videos, events, job postings, breadcrumbs, local businesses, and review snippets can also qualify when the page and markup match Google's requirements.
The terminology gets messy because older SEO content often uses similar phrases interchangeably.
| Term | What it means | Example |
|---|---|---|
| Rich result | Google's name for a richer organic result powered by eligible structured data | A product result with price and availability |
| Rich snippet | Common older name for the same broad idea | A review star snippet |
| SERP feature | Any non-standard search feature, whether or not your page markup powers it | People Also Ask, image packs, knowledge panels, AI Overviews |
| Featured snippet | A selected answer pulled from a page for a query | A paragraph answer at the top of Search |
Rich results are not a shortcut around ranking, content quality, or product data quality. They make a page eligible for a richer display when Google decides that display helps the searcher.
How rich results work
A rich result starts with the same page a visitor sees. Structured data labels the important facts on that page in a machine-readable format. Google crawls the page, parses the markup, checks it against the rules for that rich result type, and decides whether to show a richer treatment for a specific query, device, and context.
The working sequence looks like this:
- The page contains visible facts. A product page shows the product name, image, offer, price, stock status, shipping, returns, reviews, or variant options.
- Structured data labels those facts. Most Search structured data uses Schema.org vocabulary, while Google Search Central defines which properties matter for Google Search behavior.
- Google crawls and renders the page. The page, resources, and structured data need to be accessible to Google.
- Google validates eligibility. Required fields and policy rules decide whether the page is eligible for a rich result type.
- Google chooses the appearance. Eligibility does not guarantee display. Google's structured data guidelines say the algorithm may choose another feature or a normal text result instead.
At Catalog, we treat rich results as one output of the product data layer. A product detail page, JSON-LD markup, Merchant Center feed, AI shopping surface, and internal merchandising tool should draw from the same source of truth. If each channel has its own price, variant logic, or availability value, the markup only exposes the drift.
That is why clean structured data is a commerce operations problem before it is an SEO implementation task. Rich results reward the pages that make facts easy for machines to read, compare, and trust.
Rich result types worth targeting now
Start with the rich result type that matches the page. Adding every possible schema type to every template creates noise and policy risk. Google also changes which rich results it shows, so stale advice can waste engineering time.
| Page or content type | Rich result target | What can appear | Practical note |
|---|---|---|---|
| Buyable ecommerce product pages | Merchant listings and product-related results | Price, availability, shipping, returns, images, ratings, variants | Best fit for brands that sell products directly |
| Editorial product reviews | Product snippets and review snippets | Rating, pros and cons, reviewer context | Best for review content, buying guides, and non-transactional product pages |
| Site navigation | Breadcrumbs | A clean hierarchy path | Useful on most ecommerce, glossary, blog, and category pages |
| Articles and blog posts | Article result features | Larger image, headline, publisher, date context | Useful for editorial content, especially news-like posts |
| Videos | Video result features | Thumbnail, duration, key moments | Mark up pages where the video is a main page element |
| Events, jobs, courses, recipes, software apps, datasets, local businesses | Vertical rich result types | Type-specific details such as dates, salary, steps, ratings, or business info | Use only when the page genuinely fits that vertical |
| Organization, shipping, and return policy pages | Entity and policy structured data | Brand, logo, contact, shipping, and return information | Helps define the business and policies that support product results |
| FAQPage and HowTo pages | Deprecated or effectively retired for Google rich results | No dependable Google rich result display | Google's update log says FAQ rich results no longer appear in Search as of May 7, 2026, and How-to rich results are no longer shown in Search |
The current source of truth is Google's Search Gallery, not a generic Schema.org list. Schema.org defines a broad vocabulary. Google decides which types it uses for Search features and which required or recommended properties each feature needs.
How to get rich results
Pick one rich result target per page template
The page type should choose the markup. A buyable product detail page should usually start with Product and Offer data for merchant listings. A category page may need breadcrumbs and item lists, but it should not pretend to be one product. A blog post should start with article and breadcrumb markup before chasing less relevant types.
For ecommerce, separate these two cases:
| Page type | Use this product path | Why |
|---|---|---|
| The visitor can buy the product from the page | Merchant listing Product and Offer structured data | Google can understand live commercial details such as price, stock, shipping, and returns |
| The page reviews, compares, or describes a product the visitor cannot buy directly | Product snippet or review-related markup | The page is editorial, so review and content context matter more than merchant offer data |
Google's Product structured data docs draw this distinction. Merchant listings fit pages where customers can purchase from you. Product snippets fit pages where customers cannot directly purchase the product.
Make the visible page support the markup
Structured data should describe the main content of the page. Do not add ratings that do not appear to users. Do not add return policy fields that conflict with the policy page. Do not mark up a product offer if the page only contains a blog mention.
Google's structured data introduction is explicit about this: do not add structured data about information that is not visible to the user, even if the information is accurate. The safest rule is simple. If a person cannot find the fact on the page or in the linked policy experience, do not use markup to smuggle it into Search.
Add structured data in a format Google supports
Google supports JSON-LD, Microdata, and RDFa for rich result eligibility. The same structured data introduction recommends JSON-LD when a site's setup allows it because it is easier to implement and maintain at scale.
For a product page, the markup usually needs a Product entity connected to an Offer. The exact fields depend on the target result and product category, but the operating model is consistent:
| Data group | Examples to keep aligned |
|---|---|
| Product identity | Name, image, brand, SKU, GTIN, MPN, canonical URL |
| Offer | Price, currency, availability, condition, sale timing |
| Policies | Shipping destination, delivery timing, return window, return fees |
| Variant logic | Parent product, sizes, colors, packs, bundles, regional versions |
| Trust signals | Review count, rating value, reviewer content where supported and visible |
| Category attributes | Material, fit, dimensions, compatibility, ingredients, use case |
Google's minimum fields make the page eligible. Richer product data makes the page more useful. That distinction matters for merchants because the same facts increasingly feed Google, marketplace submissions, ads, on-site search, and AI shopping answers.
Generate markup from the product record, not by hand
Hand-coded JSON-LD is manageable for a few static pages. It breaks when thousands of SKUs change price, stock, variants, shipping rules, and return policies.
The durable setup is a governed product record that publishes to every channel:
- the product detail page;
- JSON-LD markup;
- Google Merchant Center;
- marketplace and retailer feeds;
- product APIs;
- AI shopping surfaces;
- internal search and merchandising tools.
This is where Catalog fits. We structure, enrich, sync, and publish product data so the facts behind search markup are the same facts agents, feeds, and storefronts use. Our work on product data enrichment is directly related to rich results because thin or inconsistent product attributes limit what any machine can understand.
Validate, then monitor over time
The Rich Results Test shows which supported rich result types it finds on a URL or code snippet, plus errors and suggestions. A valid result means the detected markup is eligible for that feature. It does not mean the feature will appear for every query.
Search Console is the ongoing view. Its rich result reports show valid and invalid structured data items found on the site, with separate reports for supported result types. For product snippets and merchant listings, Search Console places reports under Shopping. Google also notes that these reports show samples, not a comprehensive list of every detected item.
For performance, use Search Console's Performance report and filter by URL, page type, or search appearance where available. Compare similar pages before and after markup changes. The goal is not just a green validation state. The goal is more qualified impressions, stronger click-through rate, and fewer mismatches between the search result and the page.
Ecommerce rich results need more than product schema
For merchants, the most useful rich results are usually product-related. The visible result can include commercial facts a shopper uses to decide whether to click: price, availability, ratings, shipping, returns, and product images. Google's merchant listing documentation says Product markup can make pages eligible for shopping knowledge panels, Google Images, popular product results, and product snippets, with richer details such as shipping and return information.
That visibility depends on live data quality. A product page can pass a structured data test and still be weak commercially if the underlying catalog has gaps.
| Common product data gap | Rich result or AI shopping impact | Better operating fix |
|---|---|---|
| Price differs between PDP, feed, and markup | The offer looks stale or unreliable | Use one price source and publish it everywhere |
| Availability changes faster than markup updates | Search can show an item that is gone or suppress the result | Sync stock status continuously |
| Variants are treated as unrelated products | Google and AI systems can confuse color, size, pack, or region | Model parent-child and variant attributes clearly |
| Product images are inconsistent or low quality | Product result eligibility and click appeal suffer | Maintain image standards at the product record level |
| Shipping and returns are missing | Merchant listings lose useful commercial context | Store policies as structured fields, not buried copy |
| Category attributes are thin | Search and AI systems cannot match specific buying intent | Enrich the record with material, fit, compatibility, dimensions, or use case |
Search markup is one expression of the data. It should not become a parallel product database. If SEO, merchandising, ecommerce operations, and feed management each maintain their own version, rich results become fragile.
Why valid markup still may not show as a rich result
This is the most common source of frustration. A page can pass the Rich Results Test and still show as a plain result.
There are several normal reasons:
- Eligibility is not display. Google's algorithm chooses the result appearance by query, device, location, and other context.
- The page does not meet a feature policy. A required field can be present, while the page still fails a quality or content guideline.
- The structured data does not represent the main page content. Markup that describes hidden, secondary, or misleading content can be ignored.
- Google cannot access the page or key resources. Robots rules, noindex, blocked resources, authentication, or rendering problems can interfere.
- The feature is no longer shown. FAQPage and HowTo are the clearest examples. Old posts still recommend them, but they are not current Google rich result targets.
- Search Console has not sampled the item. A missing report row does not prove Google never saw the markup.
- The result type is eligible but not useful for the query. A product page may show rich details for one query and a normal listing for another.
Treat the Rich Results Test as a technical gate. Treat Search Console and real search performance as the operating signal.
Rich results and AI shopping use the same foundation
Rich results belong to Google Search, but the underlying pattern is bigger than Google. Machines trust clear, current, structured facts more than persuasive page copy alone.
AI shopping surfaces ask a different version of the same question: can the system understand what the product is, who sells it, which variant fits, whether it is in stock, what it costs, and why it matches the shopper's prompt?
That requires more than the minimum Product markup. It requires a product data layer that can answer questions such as:
- Which SKU is the canonical product?
- Which variants are actually the same parent product?
- What are the current price, stock, shipping, and return terms?
- Which attributes matter for category-specific comparison?
- Which claims are supported by source data, reviews, manuals, or policy pages?
- Which channels received the latest version of the product record?
We see rich results as the search-facing part of the same product-data work that supports AI product visibility. When the product record is complete and synchronized, the same facts can support Google rich results, merchant feeds, AI shopping agents, onsite search, and analytics.
Rich results FAQ
Are rich results a ranking factor?
Rich results are a search appearance feature. Structured data helps Google understand a page and can improve how the result appears, but valid markup does not guarantee a higher organic position. The measurable benefit is usually better qualification and click-through when Google shows the richer result.
Are rich results and rich snippets the same thing?
In everyday SEO usage, yes. Google now uses rich results as the main term. Rich snippets is an older and still common phrase for enhanced listings such as ratings, prices, images, and other extra details.
What is the Rich Results Test?
The Rich Results Test is Google's tool for testing a URL or code snippet against the rich result types Google supports. It reports detected items, errors, warnings, crawl status, and preview options for some features.
Is the Schema.org Validator enough for Google rich results?
No. Schema.org validation checks whether markup uses the vocabulary correctly. Google rich result eligibility depends on Google's Search documentation, required fields, feature-specific policies, and quality guidelines.
Should ecommerce sites still add FAQ schema?
Add FAQ content only when it helps shoppers on the page or another system uses it. Do not add FAQPage schema as a Google rich result tactic. Google's update log says FAQ rich results no longer appear in Google Search as of May 7, 2026.
If your rich results problem is really a product data problem, book a demo to see how we structure, sync, and publish product data for search and AI shopping surfaces.
