The Complete Guide to Schema.org Structured Data

Search engines read your page as text. They are extremely good at inferring meaning from that text, but inference is still guesswork — a string like "4.5" might be a rating, a price, a version number, or a shoe size. Structured data removes the guessing. It is a standardised layer of machine-readable annotation that says, explicitly, this page is a recipe, this number is its rating, this string is the author's name.

That explicitness is what makes rich results possible: star ratings, breadcrumb trails, event dates, product prices, recipe cook times. It also increasingly feeds AI-generated summaries and shopping surfaces, which parse entity data rather than re-reading prose. This guide covers the vocabulary, the syntax, the types that actually earn features, and how to validate what you ship.

What structured data actually is

Two things are commonly conflated and worth separating.

Schema.org is the vocabulary — a shared set of types (Article, Product, Recipe, LocalBusiness) and properties (name, author, price) maintained collaboratively by Google, Microsoft, Yahoo and Yandex since 2011. It defines what words exist and what they mean.

JSON-LD, Microdata and RDFa are the syntaxes — three different ways of writing that vocabulary into a web page. The vocabulary is identical across all three; only the encoding differs.

So "adding schema markup" means picking a Schema.org type that describes your page, filling in its properties with your real content, and encoding it in one of the three syntaxes. Everything else is detail.

Why bother: what structured data buys you

Be clear-eyed about the payoff, because a lot of SEO writing overstates it.

Structured data is not a ranking factor. Google has said this repeatedly and directly. Marking up a page does not move it up the results.

What it does do:

• Makes the page eligible for rich results. Review stars, FAQ dropdowns, product prices, event listings, recipe cards, sitelinks search boxes — none of these render without markup. Eligibility is not a guarantee of display, but without markup the probability is zero.
• Improves click-through rate when a rich result does appear. A listing with a star rating and a price occupies more vertical space and communicates more before the click. The CTR effect is where the real commercial value sits.
• Clarifies entities. Organization and Person markup with sameAs links helps search engines connect your site to the right knowledge graph entity rather than a similarly-named one.
• Feeds non-SERP surfaces. Google Shopping, Google Images badges, and AI overview citations all consume structured data. As search fragments across surfaces, having machine-readable facts on the page matters more, not less.

The honest summary: structured data is a presentation and disambiguation tool with strong indirect returns, not a ranking lever.

Choosing a syntax: JSON-LD is the default answer

All three syntaxes are valid and all three are parsed by Google. But Google's own documentation names JSON-LD as the recommended format, and there are good engineering reasons behind that recommendation.

JSON-LD sits in a self-contained <script type="application/ld+json"> block, in either the head or the body:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "The Complete Guide to Schema.org Structured Data",
  "datePublished": "2026-08-06",
  "author": {
    "@type": "Person",
    "name": "Jane Doe"
  }
}
</script>

Microdata, by contrast, requires itemscope, itemtype and itemprop attributes threaded through the HTML that displays the content. That coupling is the problem: a designer restructuring a template can break the markup without touching anything that looks like data, and the same data cannot be reused across templates.

Because JSON-LD is decoupled, it can be generated server-side from the same objects your page already renders, injected by a tag manager, diffed in code review, and validated as standalone JSON. The JSON-LD Markup Generator produces the block for common types directly in your browser, with no data leaving the machine.

Microdata is not deprecated and does not need ripping out of a working site. If you have inherited it and it validates, leave it. The full trade-off is covered in JSON-LD vs Microdata.

Anatomy of a JSON-LD block

Four things carry the structure.

@context declares the vocabulary in use. For virtually all SEO work it is the literal string https://schema.org. Omit it and parsers have no idea what Product means.

@type declares what the thing is. It must be an exact Schema.org type name, case-sensitive: BlogPosting, not blogposting or BlogPost. Getting this wrong is one of the most common silent failures — a typo'd type is simply an unrecognised entity, not an error you'll notice by eye.

Properties are the key-value pairs. Values can be plain strings, numbers, arrays, or nested objects that themselves have an @type.

Nesting and references. Objects nest naturally:

"offers": {
  "@type": "Offer",
  "price": "29.99",
  "priceCurrency": "USD",
  "availability": "https://schema.org/InStock"
}

For multiple entities on one page, either use several script blocks or a single @graph array with @id values to cross-reference entities without duplicating them:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#org", "name": "Example Co" },
    { "@type": "WebSite", "publisher": { "@id": "https://example.com/#org" } }
  ]
}

Both approaches are valid. @graph scales better on complex templates; separate blocks are easier to reason about on simple ones.

The types worth implementing first

Schema.org defines over 800 types. A handful account for nearly all practical SEO value.

Article / NewsArticle / BlogPosting — for editorial content. Key properties: headline (keep it under 110 characters), image, datePublished, dateModified, author as a nested Person or Organization. Note that Google no longer requires publisher for non-AMP articles, though including it does no harm.

Product — the highest-value type for commerce. Requires name, and for rich result eligibility Google needs either an offers block with price and availability, or review / aggregateRating. The details, including the review policy traps, are in the product schema field guide.

BreadcrumbList — replaces the raw URL in the search result with a readable hierarchy. Cheap to add, template-level, and one of the few markup types that near-always renders.

Organization — site-wide identity: name, logo, url, sameAs array pointing at official social and Wikipedia profiles. This is what feeds knowledge panel association.

LocalBusiness — for anything with a physical location. address as a nested PostalAddress, geo, openingHoursSpecification, telephone. Consistency between this markup and your Google Business Profile matters more than the markup itself.

FAQPage — a mainEntity array of Question objects, each with a name and an acceptedAnswer containing text. Worth adding for machine readability, but set expectations: Google narrowed FAQ rich result eligibility in 2023 to mostly well-known, authoritative government and health sites. The FAQ schema guide explains what that means in practice.

HowTo, Recipe, Event, JobPosting, VideoObject — vertical-specific, high value when they apply, irrelevant when they don't.

Pick types by what the page genuinely is. A blog post about a product is an Article, not a Product. The Schema.org Structured Data Generator covers the common types with the required fields already scaffolded, which removes most of the guesswork about what a type needs.

Four misconceptions worth clearing up

"More markup is better." It isn't. Declaring Product on a blog post, or stacking six types onto a thin page, produces errors at best and policy problems at worst. Markup should be a faithful description of the page, and a faithful description of a simple page is short.

"Rich results are automatic once it validates." Validation establishes eligibility. Display is a separate decision Google makes per query, and it factors in page quality, query intent, and whether a rich result is useful for that search. A page can validate perfectly for months and never show a rich result, usually because the underlying content isn't competitive.

"Schema markup replaces good HTML." It doesn't. Structured data is an annotation layer over content that already exists. A page with immaculate Recipe markup and no actual recipe text ranks for nothing. Semantic HTML, headings, and real content still do the ranking work.

"You need a plugin for this." Plugins are convenient but they are also the most common source of duplicate and conflicting markup — two plugins each emitting an Organization block with different logos is a routine audit finding. If you use one, check what it actually outputs rather than assuming it's correct.

Rules that keep markup compliant

Google publishes structured data policies alongside the technical documentation, and the policies are where sites get penalised.

Marked-up content must be visible on the page. This is the big one. If your aggregateRating says 4.8 from 240 reviews, those reviews must be on that page and visible to a user. Marking up content that only exists in the JSON is a spam policy violation, and it is the single most common reason for a manual action on structured data.

The markup must describe the page it is on. Product markup belongs on a product page, not on a category listing that shows twenty products. Mark up the primary entity of the page.

No self-serving reviews without disclosure. Google's policy prohibits review markup for reviews the business writes about itself, and fabricated or undisclosed incentivised reviews violate policy outright. This is enforced, and the penalty is loss of rich result eligibility across the site.

Be complete and accurate. Prices in the markup must match prices on the page. Stale availability values that say InStock on a sold-out product are both a policy issue and a user-trust issue.

Don't block the resources. If the markup is injected by JavaScript and the script is disallowed in robots.txt, Google never sees it.

Testing and validating

Three tools, three jobs.

Google's Rich Results Test answers the only question that matters commercially: can Google generate a rich result from this page? It reports errors that block eligibility and warnings for recommended-but-missing fields. It tests live URLs and pasted code, and it renders JavaScript, so it catches client-side injection issues.

The Schema Markup Validator (validator.schema.org) checks markup against the full Schema.org vocabulary rather than Google's subset. Use it when you are marking up something Google has no rich result for, or to catch invalid property names the Rich Results Test ignores.

Search Console's Enhancements reports are the production monitor. They show, per feature type, how many valid items Google has detected, how many have errors, and which URLs are affected — across the whole site, on Google's own crawl schedule. A local test tells you a template is correct; Search Console tells you whether the 40,000 pages built from it are.

Before any of that, check that the JSON is syntactically valid. A single trailing comma or an unescaped quote inside a string invalidates the entire script block, and search engines discard the whole thing rather than parsing around the error. The Structured Data & JSON-LD Validator parses and checks the block client-side, which is the fastest way to catch a syntax break before it reaches a crawler. Common structured data errors walks through the failure modes that recur most often.

An implementation workflow

A sequence that works on real sites:

1. Inventory your templates. Structured data is a template-level concern, not a page-level one. Identify each distinct page type: article, product, category, location, homepage.
2. Assign one primary type per template, plus universal additions like BreadcrumbList and Organization.
3. Map properties to existing data. If a field isn't in your CMS or database, either add it properly or leave the property out. Never hardcode a value that varies per page.
4. Generate the block from server-side data, so it cannot drift from what the page renders.
5. Validate one representative URL per template in the Rich Results Test before rollout.
6. Deploy, then watch Search Console Enhancements for two to four weeks. Errors surface at scale that never appear on a single test URL.
7. Re-audit after any template change. Redesigns break markup routinely, and nothing on the page looks wrong when they do.

Structured data pairs naturally with the rest of your head-level SEO work; if you are auditing templates anyway, the SEO Meta Tag Generator and the complete guide to meta tags cover the title, description and canonical layer that sits alongside it.

Conclusion

Structured data is one of the few technical SEO investments with a clear, mechanical payoff: it is the only way to become eligible for rich results, and rich results are the only way to change what your listing looks like in a search result you don't otherwise control.

Use JSON-LD. Generate it from real page data. Mark up only what the page genuinely is and what a user can genuinely see. Validate before shipping, and monitor Search Console after. Done at the template level, it is a few days of work that keeps paying out across every page the template produces — and it survives redesigns, algorithm updates, and the steady migration of search onto surfaces that read entities rather than prose.