The Complete Beginner’s Guide to Schema.org Vocabulary

This Schema.org tutorial will teach you everything you need to know about structured data vocabulary, from the foundational concepts to practical implementation. Schema.org is the standardized vocabulary that powers how search engines understand your website content. Created collaboratively by Google, Microsoft, Yahoo, and Yandex in 2011, it provides a shared language for marking up web pages so machines can interpret them accurately.

In this Schema.org Tutorial, we will explore how to utilize the structured data vocabulary effectively.

Schema.org Tutorial

This comprehensive Schema.org Tutorial also covers the importance of each schema type for improving SEO.

With schema types explained clearly, you will understand how to describe products, articles, events, organizations, and hundreds of other entities in ways that Google Structured Data systems can process. As of 2024, over 45 million web domains use Schema.org markup to enhance their search visibility, and the vocabulary now contains 827 types, 1,528 properties, and hundreds of enumeration values. This guide breaks down this extensive vocabulary into manageable, actionable knowledge.

Throughout this Schema.org Tutorial, we will dissect key properties for optimal implementation.

Understanding the basics as outlined in this Schema.org Tutorial is crucial for effective markup.

What Is Schema.org and Why Was It Created?

Schema.org is a collaborative vocabulary project that provides a standardized set of schemas (types and properties) for marking up web content in ways search engines can understand. It was created in 2011 by four competing search engines Google, Microsoft (Bing), Yahoo, and Yandex who recognized that a unified markup vocabulary would benefit both webmasters and search quality.

Before Schema.org, multiple competing vocabularies existed for structured data, including Microformats and various RDF-based standards. This fragmentation meant webmasters had to choose which vocabulary to implement, often without knowing which search engines would recognize their markup. The founding companies collaborated to create a single, comprehensive vocabulary that all major search engines would support equally.

The project operates as an open community initiative, with development discussions hosted on the W3C Schema.org Community Group and GitHub. Anyone can propose new types or properties, and the vocabulary is updated regularly the current version (as of late 2025) is 29.4. This open governance model has allowed Schema.org to expand from its original focus on local business and product information to cover virtually any domain, from medical entities to creative works to financial products.

How Is the Schema.org Vocabulary Structured?

Schema.org is organized as two interconnected hierarchies: one for types (classes of things) and one for data types (primitive values like text, numbers, and dates). As explained in this Schema.org Tutorial, understanding this structure is fundamental to using the vocabulary effectively.

The vocabulary currently consists of 827 types, 1,528 properties, 14 data types, 94 enumerations, and 522 enumeration members. Types represent categories of things you can describe (like Person, Product, or Event), while properties are the attributes you use to describe those things (like name, description, or price). Data types define the format of property values—whether something should be text, a number, a date, or a URL an important concept covered in this Schema.org Tutorial.

Schema.org also includes several organizational sections. The core vocabulary contains the most widely-used and stable terms. The pending section serves as a staging area for new terms under discussion, allowing community feedback before terms become official. The meta section contains internal vocabulary for schema.org’s own functionality. Finally, the attic archives deprecated terms that are no longer recommended but may still appear in older implementations, reinforcing the evolving nature of the vocabulary highlighted in this Schema.org Tutorial.

What Are Types and Properties in Schema.org?

Types categorize entities as specific kinds of things, while properties describe characteristics of those entities or define relationships between them. Together, they form the building blocks of all Schema.org markup.

Understanding Types

A type (also called a class) defines what category of entity you are describing. For example, the Person type represents individuals, the Product type represents items for sale, and the Event type represents occurrences happening at specific times and places. In Schema.org notation, types always begin with a capital letter (Person, LocalBusiness, CreativeWork). When you mark up content, you specify which type applies to the entity you are describing.

Understanding Properties

Properties are attributes that provide additional information about an entity. Properties always begin with a lowercase letter (name, description, image, price). Each type has a defined set of applicable properties. For example, a Person can have properties like birthDate, jobTitle, and worksFor, while a Product can have properties like brand, price, and availability. Some properties expect text values, while others expect structured values that are themselves typed entities.

Expected Types for Properties

Many properties have “expected types” the kind of value they should contain. As highlighted in this Schema.org Tutorial, for example, the author property of an Article expects a Person or Organization as its value. This creates nested structures where one entity references another. However, Schema.org is flexible: you can often provide simple text instead of a fully structured entity when detailed information is not available. The vocabulary encourages being as specific as possible while accommodating practical limitations.

How Does the Type Hierarchy Work?

Schema.org types are arranged in a hierarchical tree structure with “Thing” as the root, where more specific types inherit all properties from their parent types. This inheritance model is essential to understanding how schema types work and which properties are available.

Thing is the most generic type in Schema.org. It has four basic properties that apply to everything: name, description, url, and image. Every other type in the vocabulary ultimately descends from Thing and inherits these fundamental properties. Below Thing, the hierarchy branches into major categories like CreativeWork (for books, movies, articles), Organization (for companies, schools, NGOs), Person, Place, Product, Event, and Action.

Inheritance means that a specific type receives all properties from its parent types. Consider LocalBusiness: it is a subtype of both Organization and Place. This means LocalBusiness inherits organization properties (like foundingDate and employee) and place properties (like geo and address), in addition to its own specific properties (like openingHours and priceRange). When you use LocalBusiness schema, you can use any property from any of its parent types.

The practical implication is that you should always use the most specific type that accurately describes your content. A Restaurant is more specific than LocalBusiness, which is more specific than Organization. Using Restaurant gives you access to restaurant-specific properties (like menu and servesCuisine) while still inheriting all general business and organization properties. More specific types communicate more precise meaning to search engines.

What Are the Most Important Schema Types for Beginners?

Beginners should focus on the schema types most commonly supported by Google for rich results and most applicable to typical website content. As explained in this Schema.org Tutorial, mastering these foundational types provides immediate SEO value while building familiarity with how Schema.org works.

Organization and LocalBusiness

Organization describes companies, institutions, and formal groups. LocalBusiness and its many subtypes (Restaurant, Dentist, Store, etc.) add location-specific properties. Key properties include name, logo, address, telephone, and openingHours. These types help establish your entity in Google’s Knowledge Graph and improve local search visibility.

Person

Person describes individuals authors, employees, speakers, or anyone mentioned on your site. Important properties include name, jobTitle, worksFor, and sameAs (for linking to social profiles). Person schema is particularly valuable for establishing author credentials on content sites, supporting E-E-A-T signals.

Product

Product represents items available for purchase, with the Offer type used to describe availability, price, and purchase conditions. Essential properties include name, image, description, brand, offers, and aggregateRating. Product schema enables rich results showing price, availability, and review ratings directly in search listings.

Article, NewsArticle, and BlogPosting

These types describe written content. Article is the general type, while NewsArticle and BlogPosting are more specific subtypes. Key properties include headline, author, datePublished, dateModified, and image. Article schema improves eligibility for Google Discover, Top Stories, and other content-focused search features.

Event

Event describes occurrences at specific times and places, from concerts to conferences to webinars. Important properties include name, startDate, endDate, location, and offers (for ticket information). Event schema enables rich results showing dates, venues, and ticket availability.

BreadcrumbList

BreadcrumbList describes your site’s navigational hierarchy. It uses an ItemList structure containing ListItem entries, each with a position and either an item reference or name. Breadcrumb schema helps Google understand site structure and displays breadcrumb trails in search results.

WebPage and WebSite

WebPage describes individual pages with properties like name, description, and dateModified. WebSite describes your overall site and is often used to enable sitelinks search box in search results. These are foundational types that provide context for other schema on your pages.

How Do You Navigate the Schema.org Website?

The Schema.org website (schema.org) provides comprehensive documentation of all types and properties, and learning to navigate it efficiently is an essential skill for anyone working with structured data. As covered in this Schema.org Tutorial, understanding how to explore the site helps you implement schema more accurately.

The full type hierarchy is available at schema.org/docs/full.html, which displays the complete tree of types in a collapsible format. You can expand any type to see its subtypes. This view is useful when you need to find the most specific type for your content you can drill down from broad categories (like CreativeWork) to specific types (like Recipe or NewsArticle), a process explained in this Schema.org Tutorial.

Individual type pages (like schema.org/Person or schema.org/Product) provide detailed documentation. Each type page shows the type’s definition, its parent types, all available properties (including inherited ones), the expected types for each property, and multiple code examples in Microdata, RDFa, and JSON-LD formats. The examples are particularly valuable for understanding how to structure real-world implementations.

The Getting Started guide at schema.org/docs/gs.html provides beginner-friendly explanations of core concepts. The schemas overview at schema.org/docs/schemas.html lists common types by category. For developers, schema.org/docs/developers.html provides downloadable vocabulary files in various formats. The releases page documents all version changes, which is helpful for tracking new additions to the vocabulary, reinforcing concepts introduced throughout this Schema.org Tutorial.

What Formats Can You Use to Implement Schema.org?

Schema.org vocabulary can be implemented using three formats: JSON-LD, Microdata, and RDFa. Google officially recommends JSON-LD as the preferred format.

JSON-LD (Recommended)

JSON-LD (JavaScript Object Notation for Linked Data) places structured data in a separate <script type=”application/ld+json”> tag, keeping it completely separate from your HTML content. This separation makes JSON-LD easier to implement, maintain, and debug. You can add or modify structured data without touching your HTML templates, and content management systems can dynamically generate JSON-LD without complex DOM manipulation. Google has stated that new structured data features typically launch for JSON-LD first.

Microdata

Microdata embeds structured data directly within HTML using itemscope, itemtype, and itemprop attributes. This inline approach means your markup is tightly coupled with your content, ensuring they stay synchronized. However, Microdata requires modifying HTML templates and can make markup more verbose and harder to maintain. It remains a valid option but is generally less practical than JSON-LD for most implementations.

RDFa

RDFa (Resource Description Framework in Attributes) is another inline format that uses different attributes (vocab, typeof, property) to embed structured data in HTML. Like Microdata, it modifies your HTML and requires template changes. RDFa is less common in Schema.org implementations but remains fully supported. All three formats are equally valid from Google’s perspective, though JSON-LD’s practical advantages make it the standard choice for most projects.

How Do You Write Your First JSON-LD Markup?

Writing JSON-LD markup involves creating a script block with specific properties that describe your content using Schema.org vocabulary. The structure follows consistent patterns that, once learned, apply to any type.

Every JSON-LD block starts with two required elements: @context (set to “https://schema.org”) and @type (specifying which Schema.org type you are using). The @context tells parsers that you are using Schema.org vocabulary. The @type declares what kind of entity you are describing. After these, you add properties relevant to that type.

Example – Basic Organization Schema:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company Name",
  "url": "https://www.example.com",
  "logo": "https://www.example.com/logo.png"
}
</script>

This section of the Schema.org Tutorial will help you determine which types to implement for your website.

For a deeper understanding, refer to the examples in this Schema.org Tutorial.

For nested entities, you embed another object with its own @type. For example, an Article with an author would include a Person object as the author value. Place your JSON-LD in the <head> section of your HTML or anywhere in the <body>—placement does not affect how search engines parse it.

Validation in this Schema.org Tutorial emphasizes the need for accuracy in implementation.

Which Schema Types Does Google Support for Rich Results?

Google supports a specific subset of Schema.org types for displaying rich results in search, documented in Google Search Central’s Search Gallery. As explained in this Schema.org Tutorial, while Schema.org contains over 800 types, only some trigger enhanced search appearances.

Currently supported rich result types include: Article (for news, blog posts), BreadcrumbList (for navigation trails), Event (for ticketed occurrences), FAQ (for question-answer content), How-To (for instructional content on general sites), LocalBusiness (for location-based businesses), Organization (for company information), Product (for items for sale), Recipe (for cooking content), Review (for evaluations), Video (for video content), and several others. Each type has specific requirements documented on Google Search Central.

It is important to understand that Google’s supported types differ from the full Schema.org vocabulary. You should implement Schema.org types following the specification from schema.org, but consult Google Search Central documentation to understand which implementations qualify for rich results and what specific properties Google requires. As emphasized in this Schema.org Tutorial, some types Google previously supported (like FAQ for general websites) have been deprecated over time, so staying current with Google’s documentation is essential.

How Do You Validate Your Schema.org Implementation?

In this Schema.org Tutorial, common mistakes are highlighted to guide beginners.

Validation is a critical step before deploying structured data, and two primary tools serve different purposes: the Schema Markup Validator for syntax checking and Google’s Rich Results Test for Google-specific eligibility.

Schema Markup Validator (validator.schema.org): This tool checks whether your markup follows Schema.org specifications correctly. It identifies syntax errors, incorrect property usage, and structural issues. Use this validator when you want to ensure your markup is technically correct regardless of how any particular search engine interprets it.

Google Rich Results Test (search.google.com/test/rich-results): This tool tests whether your structured data meets Google’s specific requirements for rich results. It shows which rich result types are detected, identifies errors and warnings, and previews how rich results might appear. Use this when you want to verify eligibility for Google search enhancements.

Google Search Console: After deployment, Search Console provides ongoing monitoring of structured data across your site. Rich result reports show valid items, items with errors, and items with warnings. The URL Inspection tool lets you check specific pages. Search Console is essential for tracking issues at scale.

Best practice is to validate with both the Schema Markup Validator (for general correctness) and the Rich Results Test (for Google eligibility) before deploying changes. Address critical errors before launch and monitor Search Console for ongoing issues.

What Are Common Mistakes Beginners Should Avoid?

Learning from common mistakes helps beginners avoid pitfalls that can waste effort or create problems with search engine interpretation.

FAQ sections in this Schema.org Tutorial clarify common queries regarding implementation.

Using overly generic types: Always use the most specific applicable type. Using LocalBusiness when Restaurant is more accurate provides less precise information to search engines. Drill down the type hierarchy to find the best match for your content.

Finally, this Schema.org Tutorial serves as a foundational guide for all users.

Marking up hidden or misleading content: Structured data must accurately represent visible page content. Adding schema for products not shown on the page, fake reviews, or misleading information violates Google’s guidelines and can result in manual actions.

Missing required properties: Google specifies required and recommended properties for each rich result type. Missing required properties disqualifies pages from rich results. Always check Google Search Central documentation for current requirements.

Incorrect nesting and syntax: JSON-LD requires proper syntax missing commas, incorrect brackets, or malformed objects cause parsing failures. Always validate before deployment. Common errors include trailing commas, unquoted property names, and missing closing brackets.

Confusing Schema.org with Google requirements: Schema.org defines the vocabulary; Google determines what triggers rich results. A type or property valid in Schema.org might not be supported by Google for rich results. Always verify against Google documentation when rich results are your goal.

Not updating deprecated markup: Google periodically deprecates support for certain schema types. Monitor Search Console warnings and Google announcements to keep your implementation current. Deprecated markup will not harm rankings but will lose rich result eligibility.

Frequently Asked Questions (FAQ)

Key Takeaways

Schema.org is a collaborative vocabulary project founded by Google, Microsoft, Yahoo, and Yandex that provides standardized terms for marking up web content. As explained in this Schema.org Tutorial, it currently contains 827 types and over 1,500 properties covering virtually any domain.

The vocabulary is organized hierarchically with “Thing” at the root. More specific types inherit properties from parent types, so always use the most specific type that accurately describes your content a core principle highlighted in this Schema.org Tutorial.

Types (capital letters) categorize entities; properties (lowercase) describe them. Understanding this distinction and how properties have expected types is fundamental to writing effective markup.

JSON-LD is the recommended format for implementing Schema.org because it separates structured data from HTML, making it easier to implement and maintain.

Google Structured Data systems support only a subset of Schema.org types for rich results. Always consult Google Search Central documentation for current requirements and supported types.

Validate all implementations using both the Schema Markup Validator (for syntax) and Google Rich Results Test (for Google eligibility). Monitor Search Console for ongoing issues after deployment.

Beginners should focus on mastering common types first: Organization, Person, Product, Article, Event, and BreadcrumbList cover most use cases and all support Google rich results an approach reinforced throughout this Schema.org Tutorial.