Structured Data and Rich Snippets Explained for Better SEO

Structured data and rich snippets explained: what actually changes in the SERP

Open two tabs side by side. In the first, search for your own brand name. In the second, search for a competitor with the same kind of content but a few dozen review stars under the link. Same blue link, same description length. One of them looks like a business. The other looks like a page. That gap, more often than not, comes down to one thing: structured data.

I've audited enough sites to know this isn't a small detail. On a client's recipe blog two years ago, adding Recipe markup moved his average click-through rate from roughly 2.8% to well over 4% on the same set of queries, same rankings. Nothing else changed that month. No new content, no links, no redesign. Just JSON-LD and a Google Search Console validation pass. That's the whole pitch.

What structured data is not

Structured data is not a ranking factor. I'll repeat that because it's the single most common misconception I run into: Google does not reward you with higher positions for adding markup. What you get is presentation. The page becomes eligible to show extra information in the SERP — stars, prices, availability, cooking time, FAQ accordions.

Think of it as a translator. Your HTML tells a browser how to render a page. Structured data tells a search engine what the page is, in a vocabulary the machine already knows. A recipe is a recipe. A product is a product with a price and a stock status. Without markup, the crawler has to infer. With markup, it's told.

So what is the difference between rich results and structured data?

Structured data is the code you write. Rich results are what Google chooses to render from it. One lives in your <head> or <body>, the other lives only in the search results page.

The distinction matters more than it sounds, because a lot of people write markup, see nothing in the SERP, and conclude it's broken. It usually isn't. Google has documentation listing which features it currently supports, and it can pull a rich result for one query and not another. It also drops features over time — the FAQ rich result that used to be everywhere for every site is now restricted to a handful of authoritative domains. Your markup can be perfectly valid and simply not displayed.

That's not failure. That's eligibility without selection.

What is a rich snippet, exactly?

A rich snippet is a search result that shows more than the classic three-line format. Review stars. A price range and an "in stock" label. A recipe card with a photo, total time and calorie count. A video thumbnail. A sitelinks block. A breadcrumb trail under the URL instead of the raw path.

The term itself is a bit of a relic. Google's own documentation uses rich result, and has for years. "Rich snippet" stuck around because it's shorter and because that's what everyone called it in the early 2010s, when it was new. In practice, people use both interchangeably. If you're writing documentation or talking to a client, "rich result" is the accurate term. If you're searching for help, search both.

Can you give me an example of a rich snippet?

Picture a search for a specific restaurant. The plain result would show the name, the URL and a meta description. The rich version — built from Restaurant and LocalBusiness markup — can display the star rating with a review count, the price bracket (€€), the opening hours for today, and sometimes a link to reserve a table.

Or take a product page. Base result: title, description, nothing else. With Product markup and valid review data, you might see the price, a "Low stock" badge, a return policy line, and stars. On a query where five competitors all show plain results, the sixth one with stars is the one your eye lands on first. Not because it ranks better — because it looks like more.

Does a rich result replace the classic snippet?

Usually it adds to it rather than replacing it. The blue title and the URL stay. What changes is the layer underneath: extra lines, images, structured attributes. In some formats — a recipe card, for instance — the visual result looks quite different from a standard listing, with the image taking a large share of the space. But the underlying link is still a link.

One thing I've noticed across projects: rich results tend to cannibalise the meta description. When Google has structured data to display, it often builds the snippet from that data rather than from the description you wrote by hand. So don't over-invest in crafting the perfect meta description for pages where you've added heavy markup. Your effort goes somewhere else.

What are three types of structured data?

Careful — this question gets answered two different ways, and both are useful. Some people mean the three formats you can write markup in. Others mean three vocabularies or schema types. Let me cover both, because in my experience the confusion comes from exactly this ambiguity.

The three formats: JSON-LD, Microdata, RDFa

These are syntaxes. Same idea, different packaging.

• JSON-LD — a single <script> block, separate from your visible HTML. Google's recommended format. Easiest to maintain, and it doesn't touch your markup structure.
• Microdata — attributes woven directly into your HTML tags (itemscope, itemprop). Works, but makes your templates noisy and is a pain to update at scale.
• RDFa — similar to Microdata in spirit, historically more common in academic and government publishing, rarely the right choice for a commercial site today.

If you only remember one thing from this section: use JSON-LD. It's the format Google documents as preferred, it's the one most CMS plugins generate by default, and it's the one you can debug without touching your rendered layout. I once inherited a site built entirely on Microdata, and migrating 400 templates to JSON-LD took the better part of a month — but it dropped our error count in Search Console to nearly zero.

Three schema types you'll use most

Now the vocabularies — different concepts altogether, each one describing a different kind of entity on the page.

Schema type	Used on	What it can unlock	Common mistake
Article	Blog posts, news, guides	Top stories carousel, better attribution	Forgetting author and datePublished
Product	E-commerce detail pages	Price, availability, review stars, shipping	Marking up a review you didn't collect
FAQPage	Q&A blocks, support pages	Previously rich coverage — now heavily restricted	Assuming it still shows for every site
BreadcrumbList	Nearly every page	A readable path in place of the raw URL	Skipping it entirely — free win, ignored

Notice the FAQPage line. That one bites people. Two or three years ago you could mark up a FAQ block on almost any page and see an accordion in the results. Today Google limits that feature significantly. Marking it up now is not wrong — it still helps the machine parse your content — but expecting a visual rich result from it is a mistake I've watched clients make repeatedly.

How to write, test and ship structured data without breaking things

Writing markup is easy. Writing markup that survives contact with Google is where most sites stumble, in my experience. Here's the sequence that's worked for me across a dozen projects.

Start with the Rich Results Test, not your own optimism

Paste the URL or the code. The tool tells you which rich result types the page is eligible for, and flags missing or malformed properties. It's not the same thing as the Schema Markup Validator, which checks against the full Schema.org vocabulary — the Rich Results Test only checks against what Google actually supports. Both have their place. Use the Rich Results Test to know whether you'll get a visual result. Use the validator to know whether your markup is technically sound.

Then look at Search Console. The enhancement reports list every structured data type detected on your site, with valid, warning and error counts. This is where you catch problems before they compound. I've seen sites with thousands of valid Product markups and a slow-drip error from a template change that went unnoticed for weeks, because nobody checked that report.

Keep the markup in sync with the page

The most dangerous markup is markup that used to be right. A price changes in the database but not in the JSON-LD block. A review count updates on the front-end but the markup still says 47. Google's guidance on this is clear: the structured data must match what the user sees. Mismatches can trigger manual actions, and they're the hardest kind of technical problem to notice because the page looks fine to a human.

My practical fix, and I'll defend this approach to anyone: generate JSON-LD from the same data source that renders the visible page. If your CMS pulls the price from one field, the markup should pull from that same field. Never hand-code structured data on a page whose values can change.

Treat structure as architecture, not decoration

Here's the part I wish more people understood. The point isn't the stars. Stars are the visible outcome of a deeper thing: your content is being described in a machine-readable way, which affects how it can be surfaced in AI-generated answers, in knowledge panels, in aggregators that scrape structured feeds. Whether that matters in five years, I can't say for certain — but the sites that did the boring work of marking up entities properly are the ones positioned better when the surface area of search expands.

I spent two weeks early in my career trying to game review stars with markup on pages that had no real reviews. It didn't work — Google ignored the markup and, in one case, sent a manual action notice. Lesson learned cheaply. The rule that's held up for me ever since: mark up what's true. Everything else is a losing bet.

The next time you search for something you own and see a plain blue link beside a competitor's listing with stars, a price and an availability badge, you'll know which lever to pull. And you'll know it wasn't a ranking signal that made the difference — it was a decision about how to describe a page. That decision cost nothing but attention.