Adding structured data to a page does not improve where it ranks. It describes what the page contains in a form a machine can read, which makes the page eligible for a richer-looking result — stars, prices, a recipe time, a set of breadcrumbs.
Eligibility is the operative word. Search engines decide whether to show a rich result, and the same markup can produce one for months and then stop.
What does the markup look like?
A block of JSON in the page head, separate from the visible content. That separation is why it is the recommended format: nothing about the layout has to change, and the description can be generated alongside the page rather than woven into it.
Three keys do the structural work. One names the vocabulary being used, one names the type of thing being described, and one optionally gives the thing an identifier so other blocks can refer to it rather than repeating it.
Everything else is properties of that type, and the vocabulary defines what they are. It is a shared vocabulary published jointly by the major search engines, which is why one description serves all of them.
Which types still produce a rich result?
Fewer than a few years ago, and the reductions were significant.
| Type | Status |
|---|---|
| Product, with price and availability | widely shown |
| Recipe | widely shown |
| Event | widely shown |
| Breadcrumb | widely shown |
| Local business | shown, tied to a listing |
| FAQ | restricted to a narrow set of sites |
| How-to | withdrawn |
The last two changed in 2023. FAQ results were narrowed to authoritative government and health sources, and the how-to result was dropped entirely — so pages carrying that markup lost their enhanced listing without doing anything wrong.
The markup is still worth keeping in both cases. It describes the page accurately, it costs nothing, and eligibility rules change in both directions.
What makes markup invalid?
A missing required property, most often. Each type has properties that must be present for a rich result, and one absent field means the whole thing is ineligible rather than partially shown.
The second cause is describing something the page does not contain. Markup must reflect content visible to a reader — marking up a review that does not appear, or a price that is not shown, is a policy violation rather than a technical error, and it can cost the site its eligibility across the board.
Self-serving reviews are the specific case worth naming. A business marking up reviews of itself on its own site is explicitly excluded, which is why review stars appear for products and not for the company selling them.
How should several types be combined?
One block per page describing the main thing, with related types nested inside it or referenced by identifier. A page describing a product does not need a separate block repeating the organisation details that appear site-wide.
Nesting is simpler to write and duplicates data. Identifiers let one definition be referenced from several blocks, which keeps a large site consistent at the cost of being harder to read.
Breadcrumbs are the exception that belongs on nearly every page, because the result they produce replaces the URL in a listing with something readable.
What should you check?
That it parses, that the required properties are present, and that the values match the page. The first two are mechanical and the third is the one that gets sites into trouble.
Generating the block from the page data rather than writing it by hand removes an entire class of drift, where a price changes in the template and not in the markup.
After that, the honest expectation is patience. A rich result appears when the page is recrawled and the engine decides to show it, which is days rather than minutes and is never guaranteed.
Does it help anything other than search?
Increasingly, yes. Anything that reads a page programmatically benefits from a description of what the page is — including the systems that summarise pages rather than link to them, which have no layout to interpret and only the text and the markup to work from.
That shifts the calculation. Markup used to be worth adding only where a rich result existed to win; now it is worth adding wherever a machine might need to know unambiguously what a page describes, whether or not a listing changes.
It also makes the accuracy requirement matter more rather than less. A description that disagrees with the page is now wrong in more places at once.
Questions people ask
Where do I put the block? In the head or the body, either works. Keeping it in the head makes it easier to find and to generate from the same data the page uses.
Does it need to be one block per page? No. Several blocks are valid, and splitting by concern is often easier to maintain than one large nested object.
Does more markup help more? No. Accurate markup for what the page is beats extensive markup for what it partly contains.
Will it hurt if the rich result never appears? No. It stays as an accurate description of the page.
Do I need it on every page? Breadcrumbs, generally. The content types only where the page genuinely is that thing.
Is any of this a ranking factor? Not directly. It changes how a listing looks, which changes how often it is clicked.
Generate it from the page rather than by hand. The schema markup generator covers the general case, and the type-specific ones handle articles, products, recipes, events, local businesses, breadcrumbs, FAQs and how-tos.