Schema.org is a shared vocabulary of types, properties and values that websites use to describe the meaning of their content in machine-readable structured data. It tells a search engine not only that a page contains the text 49.99, but that this text is the price of a specific product offer in a specific currency.
Schema.org was launched in June 2011 by Google, Microsoft and Yahoo, with Yandex joining later that year, and it is developed openly through a W3C community group. In SEO, it is the dominant vocabulary for structured data, and it underpins rich results, knowledge panels and much of the entity understanding that search and AI systems apply to web pages.
How the Schema.org vocabulary is organized
The Schema.org vocabulary is organized as a hierarchy of types with inheritable properties. Every type descends from the root type Thing, so a Restaurant is a FoodEstablishment, which is a LocalBusiness, which is both an Organization and a Place. A subtype inherits all properties of its parents and adds its own.
| Component | Role | Example |
|---|---|---|
| Type | A class of things being described | Product, Event, Person |
| Property | An attribute or relationship of a type | offers, startDate, author |
| Expected type | What kind of value a property should hold | offers expects an Offer |
| Enumeration | A fixed list of allowed values | ItemAvailability with InStock |
| Data type | A primitive value format | Text, Number, Date, Boolean |
In recent releases the core vocabulary contains roughly 800 types and about 1,500 properties, plus pending terms that are still under discussion and hosted extensions for domains such as health and life sciences. Type names use upper camel case, as in BreadcrumbList, while property names use lower camel case, as in datePublished. The vocabulary is descriptive rather than prescriptive: it says what can be expressed, not which properties a given consumer requires.
Syntaxes for expressing Schema.org
Schema.org is a vocabulary, not a file format, so it must be expressed in one of three syntaxes. All three are understood by the major search engines, but they differ greatly in maintainability.
| Syntax | Where it lives | Strength | Weakness |
|---|---|---|---|
| JSON-LD | A separate script block in the page | Decoupled from the HTML layout and easy to generate | Can drift from visible content if not synchronized |
| Microdata | Attributes on visible HTML elements | Markup is tied directly to displayed content | Fragile when templates change |
| RDFa | Attributes on HTML elements | Supports several vocabularies on one page | Verbose and less common in practice |
Google recommends JSON-LD where the site setup allows it, and it has become the default in content management systems and SEO plugins. A JSON-LD block declares the vocabulary with the @context property, names the type with @type, and can assign a stable identifier with @id so that separate entities on a page link into one graph, for example an Article whose publisher is the Organization described elsewhere in the markup.
Schema.org compared with search engine requirements
The most important practical distinction is that valid Schema.org markup does not guarantee a search feature. Schema.org defines what may be described; each search engine decides which types it supports and which properties it requires for a particular result type.
| Aspect | Schema.org | Search engine guidelines |
|---|---|---|
| Scope | Hundreds of types for any domain | A limited set of supported features |
| Required properties | None are formally required | Specific required and recommended fields |
| Validation tool | Schema Markup Validator checks syntax and vocabulary | Rich Results Test checks feature eligibility |
| Content policies | No quality rules | Markup must match visible, policy-compliant content |
| Stability | Terms are rarely removed | Features are added, restricted and retired |
Search features change more often than the vocabulary. Google, for instance, removed HowTo rich results and restricted FAQ rich results to well-known government and health websites in 2023, although the underlying Schema.org types remain valid. Teams should therefore follow the current documentation of each search engine and treat rich result eligibility as conditional.
Schema.org types most used in SEO
A small group of types covers most structured data needs in SEO. The table links each type to its typical use and the kind of search feature it can support.
| Type | Typical use | Possible search feature |
|---|---|---|
| Organization | Company identity, logo and profiles | Logo and details in knowledge panels |
| Product with Offer | E-commerce product pages | Price, availability and review snippets |
| Article | News and blog content | Better understanding of title, date and author |
| BreadcrumbList | Site hierarchy for a page | Breadcrumb trail in search results |
| LocalBusiness | Physical locations and opening hours | Supporting local business information |
| Event | Concerts, conferences and classes | Event listings with dates and venues |
| Recipe | Cooking instructions | Images, ratings and cooking times |
| JobPosting | Open positions | Inclusion in job search experiences |
Neighboring concepts such as Article schema, BreadcrumbList markup and rich results each deserve detailed treatment of their own. For Schema.org as a whole, the essential practice is to mark up the primary entity of each page accurately, connect it to the site’s Organization with @id references, and use the sameAs property to point to authoritative profiles that disambiguate the entity.
Common Schema.org mistakes
Errors with Schema.org markup usually fall into three groups: invalid structure, wrong semantics and policy violations. The last group is the most serious, because it can lead to a manual action that removes rich results for the whole site.
| Mistake | Consequence | Fix |
|---|---|---|
| Markup describing invisible content | Possible manual action for spammy structured data | Mark up only what users can see |
| Price or rating not matching the page | Lost eligibility and loss of trust | Generate markup from the same data source |
| Wrong type for the content | Ignored markup | Choose the most specific accurate type |
| Self-serving reviews on Organization pages | No review stars shown | Use reviews only where they are eligible |
| Missing required properties | No rich result for that page | Check each feature in the Rich Results Test |
A frequent misconception is that structured data is a direct ranking factor. Search engines state that it helps them understand content and enables enhanced displays, which can raise click-through rates, but markup alone does not improve rankings or guarantee citations in AI answers.
The idea in brief
Schema.org is a shared dictionary for describing web content to machines. People can read a product page and instantly see the price, the rating and whether the item is in stock. A computer only sees text and numbers.
Schema.org gives website owners agreed labels, such as product, price and rating, to attach to that information. Because the big search engines agreed on the same dictionary, one set of labels works for all of them. The result can be a richer search listing, for example one that shows stars and a price.
A practical scenario
An online retailer of hiking boots had 1,800 product pages with no structured data. Its search listings showed only a title and a short description, while competitors displayed prices and review stars. The development team added a JSON-LD block to the product template with a Product type, a nested Offer with price, currency and availability, and an AggregateRating built from the site’s own review system.
The markup was generated from the same database fields that filled the visible page, so prices and stock levels could never disagree. The team also added Organization markup on the home page and BreadcrumbList markup on every product and category page, then validated sample templates in the Schema Markup Validator and the Rich Results Test.
Within eight weeks, most product pages showed price, availability and rating in search results. Over the same period, the average click-through rate of those pages rose from 2.1% to 2.9%, a relative increase of about 38%, while their average positions stayed roughly unchanged.