Rich results are enhanced search listings that display extra information beyond the standard blue title, URL and description, such as star ratings, prices, availability, event dates, recipe times or breadcrumb trails. In SEO, and specifically in structured data, rich results are the visible payoff of marking up a page with machine-readable vocabulary, usually Schema.org types expressed in JSON-LD.
Eligibility is never guaranteed. Valid markup makes a page eligible for a rich result, but the search engine decides whether and when to show it, based on query type, device, page quality and its own presentation policies.
How rich results are generated
Rich results come from a three-stage pipeline. The crawler fetches the page and extracts structured data; the indexing system validates the markup against the engine’s feature requirements; and the serving system decides, query by query, whether an enhanced presentation helps the searcher more than a plain listing.
Each rich result feature has its own required and recommended properties. A product snippet, for example, needs a product name plus at least one of offers, review or aggregate rating. Missing required properties make the page ineligible; missing recommended properties reduce how much detail can be shown.
The markup must describe content visible on the page. Structured data that claims ratings, prices or questions that users cannot see is treated as misleading markup and can lead to a manual action that removes rich result eligibility for the whole site.
Main types of rich results
Search engines support a catalog of rich result features, and the list changes over time as features are added, restricted or retired. The table below groups the most widely used types with their core Schema.org vocabulary.
| Rich result type | Typical Schema.org type | What appears in results |
|---|---|---|
| Product snippet | Product, Offer, AggregateRating | Price, availability, rating stars |
| Review snippet | Review, AggregateRating | Star rating and review count |
| Breadcrumb | BreadcrumbList | Site hierarchy path instead of the raw URL |
| Recipe | Recipe | Image, cooking time, calories, rating |
| Event | Event | Dates, venue and ticket information |
| Article | Article, NewsArticle | Headline, image and date in news surfaces |
| Video | VideoObject | Thumbnail, duration and key moments |
| Job posting | JobPosting | Listing in a dedicated job search experience |
Some features have been restricted significantly. FAQ rich results are now shown mainly for well-known authoritative government and health sites, and how-to rich results have been retired on major engines. Markup for such features remains valid vocabulary but no longer produces the enhanced display for most sites.
Rich results compared with other search features
Rich results are one of several search result enhancements, and they differ in how they are triggered and how much the site owner can influence them. Confusing them leads to wrong expectations about what structured data can achieve.
| Feature | Source of the information | Site owner influence |
|---|---|---|
| Rich results | Structured data on the page | High, through valid and complete markup |
| Featured snippet | Extracted passage of page text | Indirect, through clear answers and formatting |
| Knowledge panel | Knowledge graph entities | Low, partly through entity and organization data |
| Sitelinks | Site structure and internal links | Indirect, through clear navigation |
| AI-generated answers | Synthesis of multiple sources | Indirect, through citable content |
Unlike a featured snippet, a rich result does not replace the listing; it decorates the page’s own position. Rich results are therefore not a ranking factor in themselves, although the extra space and information can raise click-through rate at an unchanged position.
Implementing and testing rich results
JSON-LD is the recommended format for rich result markup, because it sits in a separate script block and does not entangle markup with the visible HTML. Microdata and RDFa are also accepted but are harder to maintain when templates change.
A reliable workflow combines validation before release with monitoring after release. The following table shows the tools and checks used at each stage.
| Stage | Check | What it catches |
|---|---|---|
| Development | Rich result testing tool on a staging URL or code | Syntax errors, missing required properties |
| Release | Schema validator and crawl of templates | Template-wide gaps and wrong data types |
| Monitoring | Enhancement reports in a search console | New errors, warnings and valid item counts |
| Performance | Search appearance filters in search analytics | Impressions and clicks per rich result type |
Data should be generated from the same source as the visible page, for example the product database that fills the price field. Hand-maintained markup tends to drift out of sync, which produces prices or availability in search results that contradict the page.
Limitations and common mistakes
The most common misconception is that valid markup guarantees display. In practice, rich results appear for a subset of eligible pages and queries, and a page may show them on mobile but not on desktop, or for one query but not another.
- Self-serving reviews: review stars for a business marked up on its own pages are no longer shown for LocalBusiness and Organization types.
- Invisible content: marking up ratings or prices that do not appear on the page violates structured data guidelines.
- Wrong page type: placing product markup on category pages that list many products confuses eligibility.
- Stale values: expired events, old prices or out-of-stock items left in markup erode trust in the data.
- Plugin conflicts: two plugins outputting overlapping markup can create duplicate or contradictory entities.
Rich results are best treated as a presentation layer earned by accurate data, not as a shortcut. Sites that keep markup complete, truthful and current tend to retain enhancements through algorithm and policy changes.
Explained without jargon
A normal search result is like a plain business card with a name and a short line. A rich result is the same card with a photo, a price tag and a few stars printed on it. It helps searchers decide faster whether the page has what they want.
To get the richer card, a website adds a hidden data label to its page. The label tells the search engine exactly what the page contains. The search engine then chooses whether to print the extras. A good label makes it possible, but never certain.
A typical use case
A regional cooking magazine publishes around 600 recipes. Its listings appear as plain text, while competing recipe pages show photos, cooking times and ratings in the same results. The editors know their recipes rank in similar positions but receive fewer clicks.
The development team adds Recipe markup in JSON-LD to the recipe template, filled automatically from the content management system: name, image, preparation and cooking time, ingredients, steps, nutrition and the aggregate reader rating. Every field corresponds to text visible on the page. The testing tool reports all recipes as valid, and after recrawling, the enhancement report in the search console counts them as valid items.
Over the next two months, the search appearance filter shows that recipes displayed as rich results earn a clearly higher click-through rate than the same recipes shown as plain listings, while average positions stay roughly unchanged.