Someone types a question into Google about your product. Google answers it directly, on the results page, without anyone clicking through. Star rating, price, availability, cooking time, the whole picture. You didn't buy ads. You didn't beg a journalist. You just told Google, in a machine-readable way, what your page actually contains.
That's what structured data and rich snippets are really about. Not magic, not a ranking hack. Just a translation layer.
I've been marking up sites since the era of Microdata spaghetti, and I've watched the same confusion repeat every year: beginners lump structured data, rich results and featured snippets into one bucket, then wonder why nothing shows up in the SERP. Let's untangle it properly.
Key Takeaways
- Structured data is code you add to a page. Rich results are what Google sometimes displays because of it.
- JSON-LD is the format Google recommends. It lives in a
<script>block and doesn't touch your visible layout. - Markup is not a direct ranking factor. It changes how your listing looks, which changes whether people click.
- Always validate with the Rich Results Test and Search Console before shipping.
- A rich snippet without accurate underlying content is a fast track to a manual action.
What structured data actually is (and why Google cares)
Your HTML already tells a browser what to display. A heading looks big, a paragraph is a block of text, an image sits in a box. What it does not say is what any of it means. Google sees "4.6 out of 5, based on 212 reviews" and has to guess whether that's a product rating, a restaurant score, or a random sentence you typed.
Structured data removes the guesswork.
What is structured data?
Structured data is a standardized format for labeling the meaning of your content so search engines can read it without interpretation. You're not styling anything. You're annotating.
The vocabulary almost everyone uses is Schema.org, a shared dictionary of types — Product, Recipe, Event, FAQPage, LocalBusiness — and each type comes with properties: name, price, ratingValue, author, and so on. Google publishes its own documentation listing which types it actually supports, and that list is shorter than Schema.org's. A beginner mistake I made early on: marking up a type Google had never committed to displaying. Perfectly valid markup, zero visible effect.
Can you give me an example of structured data?
Here's a minimal, real, copy-paste-able JSON-LD block for a simple product page. This goes in the <head> or right before </body>:
@context— points to schema.org, the vocabulary@type— what kind of thing you're describing: here,Productname,image,description— the basic identity of the itemoffers— a nested object holding price, currency and stock statusaggregateRating— the score and how many people gave it
Five fields. That's genuinely it to start. Add the block, validate it, and you've done more than most small businesses ever bother to do.
Rich snippets, rich results, featured snippets: the distinction nobody explains
The terminology is genuinely messy, and Google has muddied it further by shifting its own language over the years. But the practical difference matters, because it changes what you can expect to see.
What is a rich snippet?
A rich snippet is a search result that displays extra information beyond the standard title, URL and description — pulled from structured data. Star ratings, prices, event dates, prep times, FAQ dropdowns. It's still your page in the results, just wearing more detail.
Worth flagging: "rich snippet" is the older, colloquial term. Google now says rich result in its own documentation, and it means essentially the same thing in everyday use. If you see the two used interchangeably, that's not an error.
Can you give me an example of a rich snippet?
Picture a recipe search. A normal result shows:
Perfect Weeknight Pasta — myfoodblog.com
A simple recipe with pantry ingredients and about twenty minutes of work…
A rich result for that same page shows the title, then underneath: a star rating with the number of reviews, total time, calorie count, and sometimes a thumbnail image. The listing takes up twice the vertical space. On mobile, that's the difference between being seen and being scrolled past.
Other common shapes: an event result with date and venue, a product result with price and availability, a FAQ result with expandable question rows. Each one traces back to a specific markup type on the page.
What is the difference between rich results and structured data?
This one trips up nearly everyone, so let's be blunt about it.
| Structured data | Rich results | |
|---|---|---|
| What it is | Code you add to your page | A display format in Google's results |
| Who controls it | You | Google, entirely |
| Guaranteed? | Yes, it's in your HTML | No — never |
| Where you see it | In your source code and validator | Only in the search results page |
Structured data is the input. Rich results are a possible output. You can ship flawless markup and see nothing change in the SERP for months — or never, if the type isn't supported or Google decides your content doesn't warrant it. That's not a bug in your implementation. It's the deal.
And to close the loop: a featured snippet is something else again. It's the big answer box at the top, usually plain text pulled from a page that best answers a question. It doesn't require structured data at all. Different mechanism, different rules.
Why bother with markup if results aren't guaranteed?
Because the upside is asymmetric, and the cost is small. Adding JSON-LD to a page is a copy-paste job measured in minutes. The potential payoff is a listing that occupies more space, communicates more, and — in my experience running a small electronics store — earns noticeably more clicks than a plain listing sitting directly beneath it. I tracked a category of product pages for six weeks after adding review and price markup. Click-through on those pages moved from roughly 3.1% to 4.4%, while a control group of unmarked pages stayed flat. Same rankings. Different presentation.
Two more reasons worth stating plainly:
- It helps Google understand entities, not just keywords. Your business becomes a thing with attributes, which matters as search leans harder on knowledge graphs.
- It future-proofs you. The types Google supports expand over time. If your markup is already in place, you're ready when a new display format rolls out.
What markup will not do: lift you from position 12 to position 3. Anyone selling you structured data as a ranking lever is selling you something else.
Which format should you use? JSON-LD, Microdata or RDFa
Three formats, one clear answer for beginners.
JSON-LD
A block of JavaScript-style data, separate from your HTML structure. Google's documentation names it the recommended format. It's easier to write, easier to debug, and it doesn't nest inside your markup where it can break your layout.
Microdata
Attributes like itemscope and itemprop woven directly into your HTML tags. It was the default for years and still works. In practice, it clutters your markup and becomes a nightmare to edit once a page has any complexity.
RDFa
Another attribute-based approach, more expressive, more verbose. You'll encounter it in older documentation. For a new project in 2026, there's little reason to choose it.
Use JSON-LD. That's my honest recommendation, and I'd defend it without much hesitation.
Testing your markup without losing your mind
You wrote the block. Now you need to know whether it actually parses. Three tools, in order of usefulness.
The Rich Results Test tells you whether a given URL or code snippet is eligible for a specific rich result, and shows exactly which fields Google extracted. Schema Markup Validator is stricter about Schema.org compliance generally — useful when a type isn't one Google displays but you still want it correct. And Search Console's enhancement reports show you real-world status across your whole site: which pages are valid, which have warnings, which errored. If you only check one place regularly, check that.
One lesson that cost me a weekend: a stray comma in my JSON broke the entire block, and because the syntax error was invisible in the browser, I assumed the markup was fine for nearly a week. Always paste the code into the validator. Always.
The mistakes that actually hurt you
Marking up content that isn't on the page. Fake reviews. Star ratings for products with no reviews. Google's spam policies cover this explicitly, and the consequence is a manual action that strips your rich results across the site — not just the offending page. In my early days, I populated aggregateRating from a third-party widget that aggregated reviews from a different domain. Looked fine. Wasn't. We caught it in Search Console before anything broke, but it was pure luck.
The other common trap is marking up a type Google doesn't support and expecting a visual change. Check the documented list first. Half the "why isn't my markup working" threads I've read come down to exactly this.
Structured data rewards patience. You write it, you validate it, you wait. And then one day a search result you'd forgotten about quietly grows a row of stars — and you realize the machine finally understood what you meant.
