Which schema markup types actually matter
Structured data is one of those topics where the gap between what gets written and what actually works is enormous. Audits regularly turn up sites stuffed with every schema type in the vocabulary, most of it doing absolutely nothing visible, while the two or three types that would actually earn rich results sit unimplemented or broken.
So it is worth cutting through the noise. Schema.org has hundreds of types. Google supports rich results for a shrinking handful. And a few types carry quiet value beyond the search results page. Here is how to prioritize markup in 2026, what to skip, and where the traps are.
Two different reasons to add markup
Before picking types, be clear about why you are adding them. There are two distinct benefits, and people constantly conflate them.
The first is rich result eligibility. Certain types can change how your listing looks in Google: star ratings, prices, event dates, job details. This is measurable and directly tied to a documented feature list. If a type is not on Google's supported list, it will not change your snippet, full stop.
The second is entity understanding. Markup like Organization, Person, and consistent identifiers help search engines and, increasingly, AI systems disambiguate who you are, what you sell, and how your pages relate. You will never see this in a SERP screenshot, but it feeds knowledge panels, brand recognition, and how confidently machines can restate facts about you. It is real value, just slower and harder to attribute.
The types that still earn visible rich results
If you have the content to justify them, these are the workhorses to implement first.
Product: the single highest-impact type for ecommerce. Price, availability, and review stars in the snippet, plus eligibility for merchant experiences. Pair it with accurate Offer and AggregateRating data.
Review and AggregateRating: stars in the SERP measurably lift clickthrough. But only mark up reviews that actually exist on the page, about the thing the page is about.
Article: signals headline, author, and publish date. It matters most for Top Stories eligibility and for helping machines attribute content to a real byline.
BreadcrumbList: cheap to implement, replaces the raw URL in your snippet with a readable path, and reinforces site structure. Worth adding to almost every site.
JobPosting: mandatory if you want listings in Google's jobs experience. Strict requirements, actively policed, worth doing properly.
Event: dates, venues, and ticket info surfaced directly. Great for anyone running recurring events.
Recipe: still one of the richest treatments in search, with images, ratings, and cook times. If you publish recipes without it, you are invisible in that vertical.
The types that died, and what to do about it
Google giveth and Google taketh away. HowTo rich results are gone entirely, deprecated in September 2023 and never resurrected. FAQ rich results are functionally gone too: since August 2023 they have been limited to a small set of authoritative government and health sites, which means for almost everyone reading this, FAQ markup will not produce the expandable questions it used to.
Should you rip the old markup out? Leaving valid FAQ and HowTo markup in place is a reasonable default if it is already there and accurate. It costs nothing, it still describes the content honestly, and machine readers beyond Google can consume it. But do not spend a single sprint adding it for rich result reasons. That ship sailed.
The entity layer of Organization and Person
Organization markup on your homepage, with a logo, legal name, and sameAs links to your official profiles, is the closest thing to a business card for machines. Person markup for your authors, linked consistently from every article, builds the kind of entity graph that makes expertise legible to algorithms.
Neither will change a snippet tomorrow. Both matter more every year as AI systems assemble answers from sources they can identify and trust. When a language model retrieves your page, unambiguous entity data is one of the few machine-readable trust signals you fully control. Treat this layer as foundational now, not optional.
Use JSON-LD, and only JSON-LD
The format question was settled years ago. JSON-LD is Google's recommended format, it lives in a single script block in the head or body, it does not tangle with your HTML, and it is trivially easy to template, test, and diff. Microdata and RDFa still parse, but they weld your structured data to your HTML, and every redesign breaks them.
One practical note: JSON-LD injected by JavaScript does get processed once Google renders the page, but server-side rendering it removes a whole category of timing risk. If your framework can emit it in the initial HTML, do that.
Validate like you mean it
The Rich Results Test is the tool that matters, because it tests against Google's actual feature requirements rather than generic vocabulary compliance. The Schema.org validator is fine for syntax, but passing it does not mean you are eligible for anything.
Then watch Search Console. The enhancement reports show you errors and warnings at scale across the real crawled site, which is where template bugs surface: the product variant with a null price, the review markup that lost its rating field after a CMS update. Most audits turn up at least one schema regression nobody noticed because validation happened once at launch and never again.
The spam traps that get sites burned
Structured data has manual actions attached to it, and they are among the easier ones to earn. The classic offenses:
Marking up content that is not visible on the page.
Self-serving reviews: rating your own organization with reviews you wrote or curated.
Fake or inflated AggregateRating values that do not match displayed reviews.
Applying Product or Review markup to category pages listing many items.
Marking up sitewide content, like putting the same rating on every page.
The rule worth drilling into every team: markup describes what is on the page, truthfully, and nothing else. If you would be uncomfortable showing a Google engineer the markup next to the rendered page, fix it.
Where this is heading
AI answers have not made structured data obsolete. If anything, they raised the value of being machine-legible. Clean entity markup, accurate product data, and honest article attribution all make it easier for retrieval systems to quote you correctly and cite you as the source.
So the priority list is simple: Product, Review, and Breadcrumb where they apply, Article with real authors, Organization and Person as the entity foundation, JobPosting, Event, and Recipe when the content exists. Everything else is a nice-to-have at best. Implement less, validate more, and keep it honest.