Structured data, precisely
You already know the search engine reads your page's words and links. Structured data is a third channel: explicit, machine-readable labels that name the things on the page - "this is an Article, its author is a Person named Vadim, it was published on this date" - instead of leaving the engine to infer it from prose. It does not change what a reader sees; it changes what a machine is certain of.
The vocabulary is schema.org, a shared standard maintained by Google, Microsoft, Yahoo, and Yandex. It defines hundreds of types - Article, Product, Recipe, Event, Organization - each with a set of properties. You mark up a page by declaring which type it represents and filling in the properties from the content already there.
This sits one level past SEO basics: that article is about being findable and relevant at all; this one is about how a page that already ranks can claim a richer, more clickable slot once it is there.
Three syntaxes, one winner
schema.org can be expressed three ways, and the choice is not neutral:
- JSON-LD - a
<script>block of JSON, separate from your markup. Google recommends it, and it is what the rest of this article uses. - Microdata -
itemscope/itempropattributes woven into your existing HTML tags. - RDFa - similar attribute-based approach, from the linked-data world.
The reason JSON-LD won in practice is decoupling. Microdata and RDFa entangle the data with the visible markup, so every template refactor risks breaking your structured data, and generating it means threading attributes through presentation code. JSON-LD is one self-contained block you can build server-side from the same data that renders the page, drop in the <head>, and test in isolation. The tradeoff: because it is separate, nothing structurally stops it from drifting out of sync with the visible page - which is exactly the failure the rules in section 05 police.
A worked example
Here is the kind of block a StackNova article carries - Article with the properties Google actually uses. Note that every value mirrors something visible on the page:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured data and rich results",
"datePublished": "2026-07-02",
"author": {
"@type": "Person",
"name": "Vadim Osovitny",
"url": "https://stacknova.dev/authors/vadim-osovitny"
},
"publisher": {
"@type": "Organization",
"name": "StackNova"
}
}
</script>
Two keys are structural. @context points at the schema.org vocabulary so terms like headline have an agreed meaning; @type declares what this thing is. Everything else is a property of that type. Nested objects get their own @type - the author is not a string, it is a Person, which is what lets the engine connect it to an author entity rather than treat it as loose text.
From markup to rich result
The SERP features mentioned in how internet search works - the elements around a plain blue link - are what structured data unlocks. The mapping is type-to-feature:
BreadcrumbList- the trail shown in place of a raw URL. Low effort, widely honored, a good first move.Product+AggregateRating- the review stars and price under a shopping result.Recipe- cook time, rating, and photo in the recipe carousel.Event,JobPosting,Video- date, location, and thumbnail treatments for each.
The payoff is not (directly) ranking. A rich result rarely moves your position; it makes the slot you already hold bigger, more informative, and more clickable - which lifts click-through even at the same rank. That is the honest case for the work: better real estate, not a higher spot.
The rules that bite
This is where teams waste effort, so it is the part to internalize:
- Eligibility is not a guarantee. Valid markup makes a page eligible for a rich result. Whether one shows is the engine's call, per query, and it can decline. Correct code with no visible feature is normal, not a bug.
- Markup must match visible content. Marking up a rating no reader can see, or a price that differs from the page, is a structured-data spam violation and can trigger a manual penalty. Structured data describes the page; it does not get to invent it.
- Feature support changes. Google retired the FAQ and HowTo rich results for most sites in 2023 - the markup still validates, but the feature is gone for nearly everyone. Chasing a deprecated type is pure wasted effort, which is why this is a 201 topic: knowing what no longer pays is as valuable as knowing what does.
The throughline: structured data is a description under oath. Keep it true to the page and current with what the engine still rewards, or it is at best inert and at worst a liability.
Testing and monitoring
You never ship structured data blind - three tools close the loop:
- Rich Results Test - paste a URL or snippet; it reports which rich-result types the page is eligible for, and why any failed.
- Schema Markup Validator - checks the markup against the schema.org vocabulary itself, independent of any one engine's feature list.
- Search Console's enhancement reports - the production view: which pages the engine actually parsed structured data on, and errors seen at scale across the site.
The pattern mirrors the Search Console loop from SEO basics: validate the snippet before you ship, then watch the enhancement reports for what happens once real crawls pick it up.
When it is worth it
The intermediate judgment call, not a blanket "always add it":
- Clear yes: e-commerce (
Product), recipes, events, job listings, and site-wideBreadcrumbList- types with live, valuable rich results and direct click-through gains. - Modest but cheap:
ArticleandOrganizationon a content site - low effort, helps the engine model your authorship and brand even where the visible payoff is small. - Skip: deprecated types, and elaborate markup on a page whose type has no supported rich result. Validating is not the same as earning anything.
Structured data is the most technical lever in the search series, and the one with the clearest ceiling: it will not rescue a page that does not rank, but for a page that does, it is often the cheapest win left. Match the type to a live feature, keep the markup honest, and check the reports - that is the whole discipline.