Rich results can show a price, stock status, a rating or recipe details alongside a listing in Google Search. They rely on a defined list of features, and that list keeps changing. In 2026, any serious project has to take account of the removal of the FAQ and HowTo displays, and of the specific rules that apply to reviews.
The right objective is to describe eligible content accurately, then verify that Google can read it. There is no universal uplift in click-through rate or conversion that can be promised in return for adding markup.
Most of the work is unglamorous: separating concepts that are routinely confused, checking the current feature list, matching a type to what a page actually contains, and keeping the declared data accurate once the site changes.
Rich snippet, featured snippet and structured data: three different things
The term rich snippet is commonly used to mean a rich result. Structured data is the code that describes information on the page in a vocabulary machines can process. A featured snippet is a different display again: Google selects a passage from a page to answer a query.
Adding JSON-LD therefore does not command a "position zero". Google states that a site cannot mark up a page to force its selection as a featured snippet. The documentation on featured snippets explains how that selection works.
Two reference sets also need to be kept apart. Schema.org defines a broad vocabulary; Google uses only part of that vocabulary for its documented displays. A type that is perfectly valid in Schema.org is not necessarily attached to an active Google rich result.
What changed before you reuse old markup
| Feature | Documented status | Practical consequence |
|---|---|---|
| HowTo | Rich results removed since 13 September 2023. | Keep tutorials that help readers, but stop selling the display. |
| Several specialised displays | Simplification announced in June 2025, including Course Info, Claim Review and Vehicle Listing. | Check the exact type instead of applying an old list. |
| FAQ | Rich results removed from 7 May 2026. | Write the answers for visitors. |
These reference points come from the HowTo announcement updated in September 2023, from the 2025 simplification of search results and from Google's search update log. The removal of Course Info does not mean that every use of Course has gone: the gallery keeps a separate course list feature.
The current starting point is still the gallery of supported features. From there, open the page matching your real content and read its required properties, recommendations and restrictions.
Choose markup by page, not by ticking boxes
On a shop, a product page presents one specific item, its offer and possibly reviews of that item. A category page organises several items. A corporate page describes the business. These pages can share elements, but they should not automatically receive the same main entity.
| Actual content | Type to examine | What to check |
|---|---|---|
| Product page | Product and its offer properties | Item, price, currency, availability and reviews genuinely attached to it. |
| Recipe | Recipe | Ingredients, steps and the data actually shown on the page. |
| Event | Event | Current date, location, status and conditions. |
| Article | Article or an appropriate subtype | Headline, a real author and accurate dates. |
| Company or venue | Organization or LocalBusiness, depending on the case | Identity and contact details consistent with the page. |
| Navigation hierarchy | BreadcrumbList | A logical path to the pages concerned. |
That table is a direction of travel, not an exhaustive list of sufficient properties. An Offer property is not a standalone promise that a promotion will appear, and a breadcrumb describes a path without guaranteeing it will be shown on every device and for every query.
Reviews: the rule is not a universal third-party certification
Google's general guidance for review rich results does not oblige you to buy certification from a list of providers. It does require genuine reviews about a specific item, content a reader can actually see, and the use of eligible types. Collecting reviews through an external tool does not make every page eligible on its own.
For LocalBusiness and Organization, reviews about the entity that controls their publication are excluded from the corresponding star feature. The restriction applies just as much to a third-party widget embedded on that entity's own site. Reviews of products, by contrast, fall under their own rules. The Review and AggregateRating guidance sets out that distinction.
Before implementing a rating, identify what is being rated, where the contributions come from and how the total is calculated. An average should not mix several products without justification. If a review is withdrawn or a score corrected in the visible content, the markup has to follow from the same data source.
A testimonial on a service page can still be useful to a prospective client. Its editorial value is a separate question from its eligibility for stars. Presenting a real experience properly is better than inventing a fictitious product to work around a restriction, and the same honesty test applies across your SEO content: it has to earn its place with readers first.
Implement JSON-LD from reliable data
Google supports JSON-LD, Microdata and RDFa, and generally recommends JSON-LD. It keeps the description separate from the presentation, although it still adds code to the page. The choice should take account of your CMS, your plugins and who maintains them. Google Search Central: introduction to structured data describes the three formats.
Start by identifying what the site already generates. A theme, an SEO plugin and an e-commerce module can each publish objects of their own. The number of objects is not the problem in itself; the problem is contradiction between them, missing relationships, or a mismatch with the content.
The sketch below is a teaching example of an offer for a fictitious product. The price and URLs exist only to show the structure. It should not be copied as a real description, nor treated as a complete eligibility template.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Demo product",
"image": "https://example.com/product.jpg",
"offers": {
"@type": "Offer",
"url": "https://example.com/product",
"priceCurrency": "GBP",
"price": "29.99",
"availability": "https://schema.org/InStock"
}
}
In a shop, those values have to come from the real catalogue. Do not retype a price into a second system if stock and offer updates are likely to leave it stale. Requirements also differ between product snippets and merchant experiences, so check the Product documentation that matches your use case.
Test the published page, not just a code generator
- Pick a representative page. Choose a product, article or event that carries the expected information along with a few awkward cases.
- Compare what is visible with what is declared. Check identity, price, date, availability and ratings against the page actually served.
- Check syntax and properties. The validator has to read the same code the site produces, not a draft pasted from a generator.
- Test access to the URL. A login requirement or a crawl restriction can stop Google using the page at all, which makes this part of your wider indexing checks.
- Review the rendering after deployment. Check several pages, including one with no rating, one out of stock and one with an optional field missing.
The Google Rich Results Test checks supported features. Technical validation is not a promise of display. For the syntax of the wider vocabulary, Schema.org remains the reference.
The general structured data policies ask for information that is representative, current and consistent with the content. An error can prevent eligibility; a policy breach can lead to a manual action against rich results. A missing optional field should not be read as a threat of deindexing. Where markup problems sit alongside crawling or rendering problems, a technical SEO audit is the right container for the work.
Measuring usefulness and organising maintenance
Record the starting position by family of pages: impressions, clicks, the display types available and the enquiries or sales attached to them. After a fix, use comparable periods and note everything else that changed. A better click-through rate can come from a title, a price, an improved position or simply the season.
Keep a short register: the templates involved, the data source, the owner and a reference test. Re-examine the markup whenever the theme, a plugin, the catalogue or commercial policy changes. A removed price or a cancelled event is a concrete reason to intervene; an artificial review calendar does not replace those triggers.
If you outsource the work, ask for a scope you can verify: page types, fixes, tests and follow-up. Setting that out in advance, as you would when planning an audit, makes proposals comparable. Judge them on deliverables rather than on a promise of stars or automatic progress, which is the same standard to apply when choosing an SEO provider.
The priority is markup that is accurate, useful and maintainable on the pages that matter to your business. A precise tutorial, exact product information and clear answers keep their value even when Google changes the way it presents its results.
Common questions
Can an FAQ still produce a rich result in Google?
Google removed that display from 7 May 2026. Keep an FAQ where it answers the questions visitors really ask; its value does not depend on an accordion appearing in the results.
Is HowTo still a rich result feature?
No. Google removed HowTo rich results in September 2023. The Schema.org vocabulary and a visible, well-written tutorial are separate things from that retired display.
Do you need paid certification to show stars?
There is no general third-party certification requirement in the Google guidance cited here. Check what is being rated, whether the reviews are genuine and whether the type is eligible. A third-party widget does not get around the restriction on a business publishing reviews about itself.
Does a passing Google test guarantee the display?
No. The test checks the technical structure. Selection also depends on the page, the applicable policies and the query. Use the test to fix defects, then observe the results without assuming a guaranteed timescale.
How do you avoid contradictory prices or stock levels?
Generate the visible content and the markup from the same data source. Test a price change, an out-of-stock case and the relevant variants, then check the values actually published on the live page.
Should you remove every old Schema.org type?
Not automatically. Distinguish between a retired Google display, a vocabulary that is still valid, and code that has become useless or misleading. Decide on the basis of who consumes the data and what the markup costs to maintain.
