What Is Schema Markup?

Last updated:

Schema markup is a standardized vocabulary that you add to your web pages to help machines understand your content. It defines a common set of types (like Product, Person, Event) and properties (like name, price, startDate) that search engines, AI systems, and other software all recognize.

The Origin of Schema.org

Schema.org launched in June 2011 as a collaboration between Google, Microsoft (Bing), Yahoo, and Yandex. These four competing search engines agreed on a shared vocabulary so that web developers could write structured data once and have it understood by all major search platforms.

Before Schema.org, each search engine had its own preferred vocabulary and format. This fragmentation made structured data adoption difficult. Schema.org unified the landscape.

Today, Schema.org is maintained as an open community project. Anyone can propose new types and properties through the Schema.org GitHub repository. The W3C Schema.org Community Group oversees the process.

What the Vocabulary Contains

Schema.org defines three core building blocks:

Types

A type represents a category of thing. Person, Organization, Product, Article, Event, Recipe — these are all types. Each type has a specific set of properties that describe it.

As of early 2026, Schema.org defines over 800 types. You will use a small fraction of them. The most common types for web content include:

  • Article — blog posts, news articles, opinion pieces
  • Product — items for sale
  • LocalBusiness — physical business locations
  • Organization — companies, nonprofits, institutions
  • Person — individuals
  • Event — concerts, conferences, meetups
  • FAQPage — frequently asked questions
  • HowTo — step-by-step instructions
  • Recipe — cooking recipes
  • Review — user or critic reviews

Properties

Properties are the attributes of a type. The Product type has properties like name, description, price, brand, and image. The Event type has startDate, endDate, location, and performer.

Some properties accept simple values (text, numbers, dates). Others accept nested types. For example, the author property of an Article expects a Person or Organization type, not just a plain string.

The Type Hierarchy

Schema.org types are organized in an inheritance hierarchy. Every type inherits from a parent type, and all types ultimately inherit from Thing — the root type.

Here is a simplified branch:

Thing
└── CreativeWork
    ├── Article
    │   ├── NewsArticle
    │   ├── BlogPosting
    │   └── TechArticle
    ├── Book
    ├── Recipe
    └── WebPage
        ├── FAQPage
        ├── AboutPage
        └── ContactPage

This hierarchy matters because child types inherit all properties from their parents. Article inherits every property defined on CreativeWork, which in turn inherits every property defined on Thing. So an Article has access to name and description (from Thing), author and datePublished (from CreativeWork), plus its own specific properties like articleBody and wordCount.

When choosing a type, use the most specific one that fits. Use BlogPosting instead of Article for blog posts. Use NewsArticle instead of Article for news content. More specific types give search engines more precise signals.

Schema.org vs. JSON-LD

This is a common point of confusion. Schema.org and JSON-LD are different things that work together.

Schema.org is the vocabulary — the dictionary of types and properties. It defines what you can describe.

JSON-LD is the syntax — the format you use to write it. It defines how you express it in code.

An analogy: Schema.org is the English language (the words and grammar). JSON-LD is the act of writing a document in English. You need both the language and a way to write it.

You can also express Schema.org vocabulary using Microdata or RDFa syntax. But JSON-LD is the most common format and the one Google recommends.

Here is Schema.org vocabulary expressed in JSON-LD syntax:

{
  "@context": "https://schema.org",
  "@type": "Book",
  "name": "Designing Data-Intensive Applications",
  "author": {
    "@type": "Person",
    "name": "Martin Kleppmann"
  },
  "isbn": "978-1449373320",
  "numberOfPages": 616,
  "publisher": {
    "@type": "Organization",
    "name": "O'Reilly Media"
  }
}

The @context line tells the parser to interpret the properties using Schema.org definitions. The @type says this is a Book. Everything else maps to Schema.org properties defined for the Book type.

How to Explore Schema.org

The full vocabulary is documented at schema.org. Here is how to navigate it:

  1. Start with the type page. Go to schema.org/Product or schema.org/Event to see all properties for that type.
  2. Check the property descriptions. Each property page explains what values it accepts and shows examples.
  3. Look at the hierarchy. The type page shows parent types. Check those for inherited properties you might need.
  4. Use the “More specific types” section. This shows child types that might be a better fit for your content.

The Schema.org documentation is comprehensive but dense. This site (Structured Context) provides focused guides for the most commonly used types.

Commonly Used Types in Practice

For Content Sites

  • Article, BlogPosting, NewsArticle — editorial content
  • FAQPage — question and answer pages
  • HowTo — tutorials and instructional content
  • BreadcrumbList — navigation breadcrumbs

For E-Commerce

  • Product — product pages
  • Offer — pricing and availability
  • Review, AggregateRating — customer reviews
  • Organization — the business entity

For Local Businesses

  • LocalBusiness (and subtypes like Restaurant, Store) — business information
  • PostalAddress — physical address
  • OpeningHoursSpecification — business hours
  • GeoCoordinates — map location

For Events

  • Event — concerts, conferences, meetups
  • Place — venue information
  • VirtualLocation — online event URLs
  • Offer — ticket pricing

Putting It Together

A typical implementation looks like this:

  1. Identify the primary content type on your page (a product, an article, a business listing).
  2. Find the matching Schema.org type.
  3. Fill in the required and recommended properties.
  4. Write it as a JSON-LD block.
  5. Add the block to your page’s <head> section.
  6. Test with the Google Rich Results Test.

The next page in this section covers JSON-LD syntax in detail — how to write, nest, and structure your Schema.org data.