Which schema markup types still earn rich results

Structured data changes how a page looks in Google only when it maps to a feature in Google's search gallery, and that list has been shrinking since 2023. For most sites the types to implement are Product, Review snippet, Breadcrumb, Article and Organization, plus Recipe, Event, JobPosting and LocalBusiness where the content exists; other schema.org types can describe a page accurately but produce nothing visible in Google Search.

Two caveats before the list. Types outside the gallery can still be read by other consumers, so they are not useless everywhere. And the supported types come with no promise: Google does not guarantee that valid markup will produce a rich result. What the gallery does give you is a priority order, which most structured data backlogs lack.

Pick markup by page type

Start from your templates, not from the schema.org vocabulary. Each row below is a template most sites have, the markup that fits it, what that markup can produce in Google, and the eligibility rule that most often trips sites up.

A few of those rules deserve a sentence each.

Google's product snippet documentation recommends adding markup to product pages rather than to pages that list products or a category of products, and its review guidelines ask for ratings about a specific item, not a category. A category page carrying a Product block with one aggregate rating for the whole range breaks both. Category and filter pages raise enough crawl and indexing questions of their own, covered in the guide to taming faceted navigation; for markup, BreadcrumbList is the safe default there.

Google's Article documentation says there is no markup requirement for Google News features like Top stories. Article markup can help Google understand the headline, images, dates and author, and show better title, image and date information in results.

Breadcrumbs still work, but only on desktop. In January 2025 Google stopped showing them in mobile results, where the visible URL is now just the domain, and kept supporting the markup for desktop. If you report on breadcrumb impressions, that change explains a drop.

The Event change dates from June 2025: events now have to be bookable by the general public and take place at a physical location, and virtual-only events are not supported.

The LocalBusiness and Organization rule is the self-serving review guideline: a business marking up reviews of itself on its own site is not eligible for review stars. Sites that collect reviews about other businesses can use the markup.

What Google retired, and what to do with old markup

A lot of legacy structured data was added for features that have since disappeared or shrunk. The timeline below covers the changes that matter for cleanup decisions.

The FAQ row needs care. When Google cut FAQ rich results back in August 2023, every site outside that small group of government and health publishers lost them. There has been nothing to gain in Google from adding FAQPage markup since then.

For markup that is already on your pages, Google's guidance in its 2023 HowTo and FAQ announcement still applies: there is no need to remove it proactively, because structured data that is not used causes no problems for Search, though it also has no visible effect. When Google phased out the 2025 batch it added that use of those types outside Google Search is not affected. A sensible policy follows from that.

• Leave accurate legacy markup in place if it costs nothing to maintain.

• Remove it when it has drifted out of sync with the page, because inaccurate markup is a guideline problem whatever type it is.

• Never schedule new work for a retired feature.

• Delete it during a template rebuild rather than porting it, unless another consumer you care about reads it.

Organization, Person and the AI question

Entity markup earns less visible reward but helps Google get basic facts right. Organization markup on the homepage, with a logo, url, legal name and sameAs links to your official profiles, can influence which logo Google shows and the details in a knowledge panel. Google lists no required properties for it, so it is easy to ship a half-filled block. Merchants can go further: Google's Organization documentation covers store-wide return and shipping policies, and since 2025 it has documented loyalty programs and organization-level policies as markup, so those details do not have to be repeated on every product.

For articles, Google's author markup best practices ask for each author in a separate author field, with a type of Person or Organization and a url or sameAs that points to a page about that author. A byline that links to an author page, mirrored by Person markup on that page, is the setup Google describes. Google's image documentation also lets you nominate the preview image through the image property on the main entity, or through og:image, and asks you not to use a logo for it.

Here is a BlogPosting block that follows those practices, using placeholder URLs.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to size a heat pump for an older house",
  "mainEntityOfPage": "https://www.example.com/blog/size-a-heat-pump",
  "image": "https://www.example.com/images/heat-pump-sizing.jpg",
  "datePublished": "2026-03-02T09:00:00+00:00",
  "dateModified": "2026-03-09T14:30:00+00:00",
  "author": [{
    "@type": "Person",
    "name": "Dana Levi",
    "url": "https://www.example.com/authors/dana-levi"
  }],
  "publisher": {
    "@type": "Organization",
    "name": "Example Home Energy",
    "logo": "https://www.example.com/images/logo.png"
  }
}
</script>

The AI question comes up in every structured data discussion now. For Google, the answer is documented: its page on AI features and your website says there is no special schema.org markup needed to appear in AI Overviews or AI Mode, and asks that any structured data you use matches the visible text. For other AI assistants, no operator has documented a citation benefit from markup, so a business case that rests on one has nothing to stand on. Implement entity markup because it describes you accurately to Google Search, and treat anything beyond that as unproven.

JSON-LD, JavaScript and the Product caveat

Use JSON-LD. Google recommends it, it lives in one script block instead of being woven through the HTML, and it is easy to template, test and compare between releases.

Google can read JSON-LD that JavaScript adds to the page, and its guide to generating structured data with JavaScript documents both custom scripts and Google Tag Manager. If your markup is injected through a tag manager, the trade-offs in gtag.js versus Google Tag Manager apply here too, and the main risk is markup that duplicates page content instead of reading it from the page, which lets the two drift apart.

There is one clear exception. For Product markup, Google warns that dynamically generated markup can make Shopping crawls less frequent and less reliable, which matters for prices and stock that change daily. Merchants should put Product markup in the server-rendered HTML. The JavaScript SEO guide explains how to check what the initial HTML contains before rendering.

A release checklist for structured data

Markup that passed testing at launch can break in any later release. A template change drops a field, a plugin adds a second Organization block, or a price starts rendering as an empty string. A short checklist run against staging catches most of it.

1. Test one URL per template, not one URL per site. Markup bugs are template bugs.

2. Run the Rich Results Test on each, because it checks Google's feature requirements. A schema.org validator checks syntax only.

3. Compare the marked-up values with what the page shows: price, rating, review count, author, dates.

4. Look for empty or placeholder values, such as a blank price, a rating of zero, or an author called admin.

5. Search the rendered HTML for duplicate blocks of the same type with conflicting values, a common result of a theme and a plugin both emitting markup.

6. Confirm dates use ISO 8601 with a time zone.

7. Check whether the markup is in the initial HTML or only after rendering, and whether that matters for the type.

8. After release, watch the rich result reports in Search Console for new errors or a fall in valid items, and annotate the release date.

Structured data deserves a line on any larger change list too. The site migration checklist covers where it fits in pre-launch and post-launch checks.

Where markup gets a site in trouble

Breaking Google's structured data guidelines can lead to a manual action, and a structured data manual action removes the page's eligibility for rich results rather than its rankings. The patterns that lead there are consistent.

• Marking up content readers cannot see on the page.

• Fake reviews, or ratings that do not match the reviews shown.

• Self-serving reviews on LocalBusiness or Organization pages.

• Product or review markup applied to category pages as if they were one item.

• Job postings left marked up after the job has closed.

Most of that list comes down to one mistake: markup that claims something the page does not support. Markup that matches what a visitor sees avoids nearly all of it.

The next step is mechanical. List your templates, map each to a row in the first table, and remove or fix anything that does not belong there before adding a single new type.