Schema Markup: The Complete Guide

Schema markup is code you add to a page so search engines can understand its content in a structured, machine-readable way instead of guessing from plain text. Google supports it, uses it to power some search features, and publishes clear documentation on what it does and doesn’t do. This guide covers the fundamentals honestly, including the part most schema content skips: what schema actually changes in Search, and what it doesn’t.

What schema markup actually is

Schema markup is a shared vocabulary, schema.org, that describes entities on a page (an article, a product, an organization, an event) using standardized properties. You write that description in a format search engines can parse, and it sits alongside your normal HTML rather than replacing it.

The reason this matters is disambiguation. A page’s visible text is easy for a human to interpret but ambiguous for software: a page mentioning “Amazon” could be about the river, the company, or the rainforest, and a paragraph of prose doesn’t settle that on its own. Structured data settles it directly, by explicitly labeling the entity type and its properties (name, URL, logo, founding date, and so on) rather than leaving a machine to infer them from surrounding sentences. That’s the core job schema does: it removes ambiguity, it doesn’t add persuasive weight.

Here’s a minimal, complete example for an article, using Google’s recommended properties:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup: The Complete Guide",
  "image": ["https://example.com/images/schema-guide.jpg"],
  "datePublished": "2026-07-01T08:00:00-04:00",
  "author": {
    "@type": "Person",
    "name": "Author Name",
    "url": "https://example.com/about/author-name"
  }
}

Google’s Article documentation notes there are no strictly required properties, you add the ones that apply to your content, but headline, image, datePublished, and author are the properties Google specifically calls out as useful (Article structured data).

What it does and doesn’t do for SEO

This is the part worth stating plainly, because it’s the most common misconception about schema: structured data is not a direct ranking factor. Google’s own documentation states that a structured data problem (for example, a manual action) causes a page to lose eligibility for rich result display, not a ranking penalty. The inverse is also true: adding valid schema does not directly push a page up in rankings (General structured data guidelines).

What schema does do is help Google understand what a page is about, which can make it eligible for additional search features (rich results, like a review star rating or an event date shown directly in the result). Whether that eligibility ever translates into a visible rich result, and whether a rich result then improves click-through, depends on factors Google doesn’t fully control or publish, including the user’s device, location, and search history. Google is explicit that using structured data “enables” a feature to be present, it does not guarantee it will be (Intro to structured data).

In short: schema is a communication layer, not a ranking lever, and anyone promising a specific click-through-rate percentage from adding schema is guessing. Google has not published CTR lift figures for structured data, and none should be quoted as fact.

Two pages with identical content, one with correct Article schema and one without, will not rank differently because of that schema alone. What can differ between them is whether Google has enough structured signal to confidently show the one with schema in a richer format, if a matching rich result feature exists for that content type and Google decides the page qualifies at that moment. That’s a real, if modest and indirect, benefit. It’s just not the “foundational SEO ranking factor” framing that a lot of schema content, including earlier versions of this guide, has implied.

JSON-LD vs Microdata vs RDFa

There are three formats for writing structured data: JSON-LD, Microdata, and RDFa. Google recommends JSON-LD, and for practical reasons rather than a stated adoption percentage: it’s a self-contained script block that doesn’t need to be woven into your visible HTML, it’s easier to template and maintain at scale, and Google can read it even when it’s injected dynamically by JavaScript (Intro to structured data).

The practical difference shows up in how the markup sits in your page. Microdata and RDFa embed properties as attributes directly inside the HTML tags that already display the content, for example adding itemprop="name" onto the heading tag that already shows the article title. That keeps markup and content physically tied together, but it means every template edit touching that HTML risks breaking the schema too, and nested properties (an address inside an organization inside an event) get awkward to express in attributes. JSON-LD instead lives in one self-contained script block, separate from the HTML that renders the page, so a developer can edit visible content and structured data independently without one breaking the other. Unless you have an existing Microdata or RDFa implementation that’s working correctly, use JSON-LD for anything new.

How to implement your first schema type

The pattern is the same regardless of which schema type you use, so it’s worth learning once on a simple example rather than memorizing every type separately.

1. Pick the schema type that matches the content. For a blog post or news piece, that’s Article (or a subtype like NewsArticle or BlogPosting). Using the wrong type, or a type that doesn’t match what’s actually on the page, is a documented policy violation, not a minor technicality.
2. Fill in the properties Google documents for that type, not every property schema.org offers. For Article, that’s headline, image, datePublished, dateModified, and author at minimum. Google states there are no strictly required Article properties, but omitting the ones it highlights reduces the chance the page is treated as eligible for anything beyond plain-text indexing.
3. Write it as a JSON-LD <script> block with type="application/ld+json", placed in the page’s <head> or <body>. One block per entity is standard; you don’t need to split properties across multiple scripts.
4. Test it before publishing using Google’s Rich Results Test, covered in full in the validation guide linked below. This catches syntax errors and missing recommended fields before they reach a live page.
5. Keep the markup in sync with the visible page. Schema that describes content the page doesn’t actually show, a fabricated rating, an author who didn’t write the piece, is a policy violation, not just bad practice, and can cost you rich-result eligibility site-wide if Google issues a manual action.

That’s the whole pattern. Organization, Product, Event, and every other type follow the same shape: pick the type, populate the documented properties, validate, keep it accurate. The only thing that changes between types is which properties Google documents as relevant, not the process for adding them.

Where to go next

This guide is the starting point, not the whole picture. The same JSON-LD pattern above applies to every schema type, so instead of walking through each one here, use this as a lookup: match your content type to the schema type it needs, then go to the reference that covers that ground in depth.

Your content	Schema type to use	Covered in depth by
Blog post, news piece, guide	<!–INLINECODE17–> (or a subtype)	This guide (worked example above)
Company, brand, multi-location business	<!–INLINECODE18–> or <!–INLINECODE19–>	Organization, Person, and Brand schema
Author bio, executive bio, byline	<!–INLINECODE20–>	Organization, Person, and Brand schema
Site navigation trail	<!–INLINECODE21–>	Sitelinks and navigation schema
A "should I implement X" or "is Y still live" question	N/A	Rich results types overview
Any schema throwing an error or not showing as expected	N/A	Structured data troubleshooting and validation

If you’ve written your first JSON-LD block using the pattern in this guide and it isn’t validating, don’t guess at the fix here, the troubleshooting reference above has the actual error taxonomy and tool workflow, and duplicating a shortened version of it in this guide would just get out of date twice instead of once.

Conclusion

Schema markup is worth implementing because it helps Google understand your content correctly, not because it’s a ranking shortcut. Start with one type, use the properties Google actually documents, validate before you publish, and treat any specific stat about “CTR lift from schema” you encounter elsewhere with skepticism unless it links to a real source.