You paste validated JSON-LD into your page, run it through the Rich Results Test, see green checkmarks everywhere — and three weeks later your product pages still show as plain blue links in search. I've watched this happen on four different client sites, and every single time the diagnosis was the same: the markup was valid, but it was eligible for nothing. Nobody had bothered to check what Google actually rewards in 2026.
That gap between "technically correct" and "actually rendered as a rich snippet" is where most of the advice online falls apart. It treats structured data as a syntax problem. It isn't. It's a negotiation with a machine that has grown pickier every year, and the terms of that negotiation changed considerably over the last eighteen months.
Key Takeaways
- JSON-LD is the only format worth your time in 2026. Microdata and RDFa still work, but every current Google feature is documented around JSON-LD first.
- Valid markup ≠ eligible markup. Google only renders rich results for a defined list of types, each with its own required properties.
- FAQ and HowTo rich results are effectively gone from general search. Building a strategy around them now is wasted effort.
- Google Search Console's "Enhancements" reports are where you find real errors — the standalone testing tools only tell you about syntax.
- Structured data now feeds AI answer surfaces, not just traditional snippets. That's the biggest shift since schema.org launched.
- Marking up content the user cannot see is the fastest route to a manual action.
What are rich snippets, and how does structured data actually produce them?
Structured data is a vocabulary you attach to your HTML so a crawler can tell the difference between "this page mentions a price of $49" and "this page sells a product for $49." Rich snippets — or, in Google's current language, rich results — are what appear when the search engine decides that distinction is worth showing.
The vocabulary itself is schema.org, a shared project between Google, Microsoft, Yahoo and Yandex that has been running since 2011. It defines several hundred types: Person, Recipe, Event, Product, Organization, MedicalCondition, and so on. What Google does with those types is a separate matter, documented in its own search gallery. Confusing the two is the single most common mistake I see.
The three markup formats, and why only one matters
Schema.org can be expressed in three syntaxes. JSON-LD goes in a <script> block in the head or body. Microdata wraps your existing HTML attributes. RDFa does something similar with a different attribute set.
- JSON-LD — separate from your markup, easy to template, doesn't touch your rendered HTML. Google's documentation is built around it.
- Microdata — inline attributes like
itemscopeanditemprop. Historically popular. Painful to maintain across a CMS. - RDFa — mostly a legacy choice. I've seen it in older Drupal setups and nowhere else recently.
My honest position: if you're starting today, write JSON-LD and stop reading about the other two. I've migrated sites from Microdata to JSON-LD and the maintenance burden drops immediately — one template file instead of attributes scattered across a theme.
What a rich snippet looks like in practice
On a recipe page, it might add cooking time, calorie count, a star rating and a photo. On an e-commerce listing, price, availability and review count. For an event, the date, venue and ticket status. Local business pages can surface opening hours and a price range.
The mechanism is always the same: you declare the facts in structured data, the crawler cross-references them against the visible page content, and if everything lines up and the page is eligible, a richer presentation is generated. If the declared facts contradict what a human sees, nothing renders — and you may get a warning.
Which schema types still earn rich results in 2026?
Google maintains a search gallery listing every supported feature. Roughly twenty types are documented. Several of them are now effectively dead in general search, which is why so much older advice leads people astray.
| Type | What it can render | Worth prioritizing? |
|---|---|---|
| Product | Price, availability, ratings, shipping, return policy | Yes — highest commercial impact |
| Article / NewsArticle | Headline, image, date, author in top stories and Discover | Yes for publishers |
| BreadcrumbList | Path replacing the raw URL in results | Yes — cheap and near-universal |
| LocalBusiness | Hours, price range, maps integration | Yes for physical locations |
| Event | Dates, venue, ticket availability | Yes, if the event is real and dated |
| FAQPage | Formerly expandable Q&A blocks | Largely deprecated for general search |
| HowTo | Formerly step-by-step instructions | Deprecated |
| Review / AggregateRating | Star ratings | Only where reviews are genuine and on-site |
I'll be blunt about FAQ and HowTo: I spent the better part of a week in early 2025 building FAQ markup across a 400-page support site. The rich results never materialized at scale, and the effort produced no measurable change in click-through rate. That was a lesson in checking the current feature list before writing a single line of code.
Structured data documentation: where to actually read
Two sources matter and the rest is noise. Google Search Central's structured data documentation gives you the required, recommended and optional properties per type — read the "required" column carefully, because a missing required property invalidates the whole item. Schema.org itself gives you the full vocabulary when you need to describe something Google doesn't have a feature for.
Everything else — agency blog posts, YouTube tutorials, that one thread from 2019 — is a secondary interpretation. I've lost count of the number of times a client forwarded me a "best schema practices" article whose advice directly contradicted the official requirements.
How do you implement JSON-LD without breaking things?
Placement is flexible. Google reads JSON-LD from the head or the body, and it doesn't need to sit next to the content it describes — which is a blessing for anyone working with a template system.
- Define the entity first. What is this page? An article, a product, an event? One primary type per page, then supporting types.
- Pull values from your CMS fields, not from hardcoded strings. Hardcoded prices rot within weeks.
- Include only properties you can actually back with visible content.
- Validate before deploying, then verify again in Search Console after Google recrawls.
- Re-check after any template change. I've broken Product markup twice by refactoring a theme file.
The single most useful discipline here: build a small internal checklist per type and treat it like a form. Required properties, recommended properties, optional ones you'll add later. It turns an abstract spec into something a developer who has never heard of schema.org can implement correctly.
What are the tools for testing structured data?
There are three you'll actually use, and they do different jobs.
- Rich Results Test — tells you which Google features the page is eligible for. This is the one that answers the question you care about.
- Schema Markup Validator — checks the markup against schema.org itself, independent of Google's feature list. Useful for types Google doesn't render.
- Search Console Enhancements reports — the only tool that reflects what Google actually found on your live site at scale, with error counts per type.
Here's the thing most people get wrong: passing the Rich Results Test means the page could be eligible. It says nothing about whether Google will choose to show the enhancement. That decision factors in page quality, query context, competition and a dozen signals nobody outside Google can enumerate. I've had perfectly marked-up pages sit as plain results for months because the content itself wasn't competitive.
What are the risks of getting structured data wrong?
Google treats misleading structured data as spam, and it enforces that with manual actions. The line is not complicated: whatever you declare must be visible to a human on the page.
Marking up a rating that no user ever submitted. Declaring a price that doesn't appear anywhere in the rendered content. Adding FAQ markup to a page with no questions on it. All three of these have resulted in manual actions on sites I've audited, and recovery means fixing the markup, documenting the fix, and waiting through a reconsideration process that takes weeks.
The quieter risk is decay. Required properties change. Features get deprecated. A markup implementation that was perfect in 2023 might be generating warnings today and you'd never know unless you're watching the Enhancements reports. I check ours monthly — it takes ten minutes and has caught two deprecations before they cost anything.
How does structured data affect AI search in 2026?
This is where the ground has genuinely shifted, and most guides haven't caught up.
AI-generated answer panels now sit above traditional results for a large share of informational queries. When those panels assemble an answer, they pull from sources the system can parse confidently. Clean structured data makes your facts machine-readable in exactly the way that helps — an unambiguous price, an unambiguous date, an unambiguous author.
I ran a rough comparison across two client sites in the same vertical last year. The one with thorough Product and Organization markup appeared in AI-generated shopping summaries noticeably more often than the one with sparse markup, despite similar domain authority. Small sample, no controlled methodology, so treat it as a directional signal rather than proof. But the mechanism makes sense: structured data removes ambiguity, and ambiguity is the enemy of automated summarization.
The practical implication is that schema markup has quietly become an AI visibility tactic as much as an SEO one. If your content is the source rather than the summary, you get the citation.
Which type should you implement first?
Depends entirely on what you sell or publish.
- E-commerce: Product with price, availability, and genuine AggregateRating. Nothing else comes close on ROI.
- Local services: LocalBusiness plus BreadcrumbList. Hours and price range do real work in map-adjacent results.
- Publishers and blogs: Article, with author and date properly filled in. It matters for Discover and for AI attribution.
- SaaS and B2B: Organization, SoftwareApplication where relevant, and BreadcrumbList. Modest impact, low effort.
- Events and venues: Event with accurate dates. Stale event markup is worse than none.
Start with one. Get it right, watch the Enhancements report for a month, then add the next. The sites that fail at structured data are almost always the ones that tried to mark up everything in a single sprint and ended up with forty warnings and no idea which template caused them.
And if you take nothing else from this: the markup is the easy part. Deciding what your page actually is, and being honest about it in the code, is the work.
