What is schema markup?

A block of structured data, written in the shared schema.org vocabulary, that states explicitly what a page contains — that this is a product, this is its price, this is its availability — instead of leaving a search engine to infer it from the text. It is normally added as JSON-LD in a script tag.

Does schema markup improve rankings?

It is not a ranking factor in the way a link or the content itself is. What it does is make a page eligible for richer result formats, and those formats can change how many people click a result that was already ranking. Engines describe eligibility, never entitlement, and frequently show a plain result anyway.

Should I use JSON-LD or microdata?

JSON-LD in nearly all cases. It lives in one script block rather than being threaded through your HTML attributes, so a layout change cannot break the data, and it is the format the major engines document first. Microdata mainly persists in older templates.

Where does schema markup go on a page?

Inside a script tag of type application/ld+json. It is valid anywhere in the document, and the head is the easier convention to audit because there is one place to look. One block per page covering that page's entities is cleaner than several scattered ones.

What are the most useful types of schema markup?

For most sites: Organization or Person and WebSite site-wide, BreadcrumbList on hierarchical templates, and then the single content type that matches the page — Article, Product with Offer, Recipe, Event or LocalBusiness. The remaining hundreds of types rarely repay the effort.

Why is my valid schema markup being ignored?

The most common reason is a mismatch between the markup and what a visitor actually sees — FAQ markup on a page with no visible questions, ratings that are not displayed, or a marked-up price that differs from the rendered one. A validator only checks syntax and required properties, so it cannot detect any of these.

How to Implement Schema Markup: The Types Worth Adding, and Where It Goes

What schema markup is, in one paragraph

A search engine reading your page sees text and tags. It can infer that a number is probably a price or that a block is probably a recipe, and it is quite good at inferring, but it is still inferring. Schema markup is a block of structured data, using the shared vocabulary at schema.org, that states it outright: this is a Product, this is its price, this is its availability. That certainty is what can make a page eligible for the richer result formats — review stars, FAQ dropdowns, recipe cards, event dates.

Eligible, not entitled. Every engine reserves the right to show a plain result anyway, and they routinely do. Markup removes ambiguity; it does not buy placement, and any tool promising a rich result in exchange for markup is selling the wrong thing.

Use JSON-LD, and put it in the head

There are three ways to express structured data: JSON-LD, microdata and RDFa. In practice, use JSON-LD unless you have a specific reason not to.

Microdata and RDFa interleave attributes through your visible HTML, so the markup and the layout are welded together and a template change breaks the data. JSON-LD sits in a single <script type="application/ld+json"> block, separate from the markup it describes. It can be generated, diffed, tested and moved without touching the layout, and it is the format the major engines document first.

Put the block in <head>. It is valid in <body> too, and head is easier to audit because there is exactly one place to look. One block per page covering everything on that page is cleaner than several scattered blocks, and the entities inside it can reference each other by @id.

The types that are worth your time

There are hundreds of schema types. A small handful do nearly all the work for a normal site.

Organization or Person — who publishes the site. One block, site-wide, carrying name, logo, URL and social profiles. This is the identity everything else hangs off.
WebSite — the site itself, and the place a site-search action is declared if you want one.
BreadcrumbList — the page's position in the hierarchy. Cheap to generate, and it changes how the URL line is displayed.
Article / BlogPosting — headline, author, dates published and modified. Content sites should treat this as the default.
Product with Offer — name, image, description, price, currency, availability. The one with the most direct commercial consequence.
FAQPage — questions and answers that are visibly on the page. See the failure below.
HowTo, Recipe, Event, LocalBusiness — worth it when the page genuinely is one of those things, and not otherwise.

Fill the required properties, then the recommended ones you can populate honestly, and stop. A sparse accurate block beats an elaborate one padded with plausible values.

The failure that undoes all of it

Structured data has to describe what a visitor actually sees on that page. Markup that is valid, parses cleanly and passes every test can still be disregarded — or worse, earn a manual action — when it does not match the visible content.

The common versions are all the same mistake:

An FAQPage block on a page with no questions visible on it.
Review or AggregateRating for reviews that are not shown on the page, or that the site owner wrote.
A Product price in the markup that differs from the price rendered on screen.
A datePublished that moves every night so the content looks fresh.

A validator checks syntax and required properties. It cannot see your rendered page, so it will happily approve every one of these. This is the gap that a human read or a crawl-based review catches and a validator never does.

Generate it, then validate it

Hand-writing JSON-LD per page is how prices go stale and dates drift. Generate it from the same data the page renders from — the template, the CMS record, the product object — so the markup cannot disagree with the page without the page itself being wrong. Generators and plugins are fine for exactly this reason; the thing to check is that the one you choose reads live data rather than asking you to retype it.

Then validate on two axes, because they answer different questions:

Is it well-formed? Schema.org's own validator checks the vocabulary broadly.
Is this engine eligible to do anything with it? Google's Rich Results Test and Search Console's enhancement reports answer for Google specifically; Bing's Webmaster Tools has an equivalent. A block can be perfectly valid and still not be a type that particular engine renders.

Test the rendered page, not the template. If the JSON-LD is injected by JavaScript, fetch the URL as the engine does and confirm the block is present in what comes back.

A sane order to do it in

Add Organization and WebSite once, site-wide.
Add BreadcrumbList to templates that have a hierarchy.
Add the one content type that matches your main template — Article, Product, Recipe, Event.
Validate the rendered output on one URL of each template before rolling out.
Roll out, then watch the enhancement reports for a few weeks and fix what is flagged.
Only then consider the optional extras.

Most sites get the entire available benefit from steps one to three. The long tail of exotic types is where a lot of effort goes and very little comes back.

Or review the whole site's markup in one pass The Forge SEO Skill Stack includes a schema review that walks every template, reports which types are present, which are malformed and which contradict the visible page — the third being the one a validator will not tell you about. $39 · instant download →

Common questions

What is schema markup?: A block of structured data, written in the shared schema.org vocabulary, that states explicitly what a page contains — that this is a product, this is its price, this is its availability — instead of leaving a search engine to infer it from the text. It is normally added as JSON-LD in a script tag.
Does schema markup improve rankings?: It is not a ranking factor in the way a link or the content itself is. What it does is make a page eligible for richer result formats, and those formats can change how many people click a result that was already ranking. Engines describe eligibility, never entitlement, and frequently show a plain result anyway.
Should I use JSON-LD or microdata?: JSON-LD in nearly all cases. It lives in one script block rather than being threaded through your HTML attributes, so a layout change cannot break the data, and it is the format the major engines document first. Microdata mainly persists in older templates.
Where does schema markup go on a page?: Inside a script tag of type application/ld+json. It is valid anywhere in the document, and the head is the easier convention to audit because there is one place to look. One block per page covering that page's entities is cleaner than several scattered ones.
What are the most useful types of schema markup?: For most sites: Organization or Person and WebSite site-wide, BreadcrumbList on hierarchical templates, and then the single content type that matches the page — Article, Product with Offer, Recipe, Event or LocalBusiness. The remaining hundreds of types rarely repay the effort.
Why is my valid schema markup being ignored?: The most common reason is a mismatch between the markup and what a visitor actually sees — FAQ markup on a page with no visible questions, ratings that are not displayed, or a marked-up price that differs from the rendered one. A validator only checks syntax and required properties, so it cannot detect any of these.

Independent guide. Not affiliated with or endorsed by Google, Microsoft, or Schema.org. Search engines change which structured-data types they support and how they display them without notice, and markup has never guaranteed any particular result — treat everything here as a starting point and confirm against current official documentation before relying on it.