What Is Schema.org? Types, Properties, and Common Mistakes

Schema.org is the shared vocabulary that gives machines consistent names for entities, relationships, and actions across web pages, email, and other digital surfaces. Types such as Organization and Article, properties such as name and author, and defined values form the dictionary. JSON-LD, Microdata, and RDFa carry those terms; consuming products decide which ones they use. Keeping those jobs separate is the key to implementing structured data without confusing vocabulary, syntax, and search outcomes.

Schema.org solves a naming problem. A publisher may know that a page is about an organization, that a person wrote an article, or that an offer has a price. Machines need stable terms for those entities and relationships. The Schema.org project maintains that shared dictionary and the definitions behind it.

It does not supply a mathematical formula. There is also no accepted target for how many types or properties a page should contain, no universal validation score, and no dependable equation that turns markup into rankings, traffic, rich results, or AI citations. Those outcomes depend on the consuming system, the underlying content, and the accuracy and eligibility of the implementation.

Schema.org defines and maintains a shared collection of types, properties, and enumerated values for structured data. Schema.org’s How we work and FAQ explain that its vocabulary covers entities, relationships, and actions, and it is developed through an open community process.

Schema.org’s own FAQ says it is not a formal standards body like the W3C or IETF. It is a collaborative vocabulary project with a documented community process. That governance explains how the dictionary evolves; it does not turn the project into the product owner for every system that reads the terms.

Trace one page fact across six layers#

Several related terms are routinely compressed into the word “schema.” The table assigns each layer one question, from the fact a publisher can verify to the output a consumer may produce.

This distinction explains why Schema.org and JSON-LD are not synonyms. Schema.org supplies vocabulary. The W3C JSON-LD specification defines a JSON-based serialization for linked data; it can carry Schema.org terms, terms from another vocabulary, or a combination. Microdata and RDFa can carry the same Schema.org vocabulary in different syntax.

Here is a deliberately small illustration based on this article:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "What Is Schema.org? Vocabulary, Types, Properties, and Common Misconceptions"
}

In that JSON-LD block, @context identifies how compact terms should be interpreted, Article is a Schema.org type, and headline is a Schema.org property. The braces, quotes, and @ keywords belong to JSON-LD syntax. The example’s job is to locate each token in the layer map; a consumer still applies its own product contract before producing any special result.

Schema.org vocabulary can be expressed with JSON-LD, Microdata, or RDFa. According to Google’s structured-data guide, JSON-LD is a serialization for linked data, while Schema.org supplies terms that can be used within that serialization.

The phrase schema markup usually means the page-level implementation of Schema.org terms. Structured data is broader: it is the machine-readable representation. A rich result is a possible presentation chosen by a consumer such as Google. In other technical contexts, “schema” can mean a database schema, JSON Schema, or XML Schema; those are separate systems with different purposes.

Build semantic claims with types and properties#

A type says what kind of entity is being described. Person, Organization, Article, Product, and Event are types. Schema.org writes type names in TitleCase and arranges them in a hierarchy rooted at Thing. A more specific type inherits properties associated with its supertypes, and the model permits more than one supertype.

A property says something about an entity or connects it to another value. name, author, datePublished, and address are properties. Property names normally use lowerCamelCase. A property may accept a simple value such as text, a URL, a date, an enumerated value, or another typed entity.

Schema.org term pages show two associations that are useful when reading a property:

• Used on these types, represented in the data model by domainIncludes, identifies the kinds of entity for which the property is commonly applicable.
• Expected types, represented by rangeIncludes, identifies the kinds of value normally supplied for that property.

Those associations can be plural. A property may be useful on several types, and its value may accept more than one type. Schema.org also allows properties to have multiple values. This is why a real description behaves more like a graph than a flat spreadsheet row: an Article can link through author to a Person, and that person can have their own properties and identifiers.

Schema.org types are arranged in a multiple-inheritance hierarchy and take associated properties from supertypes. Schema.org’s Data model and Style guide state that properties identify common subject types and expected value types, can accept multiple expected types, and can have multiple values.

The vocabulary’s building blocks divide the modeling work more precisely:

The current Schema.org development site reports 823 types and 1,529 properties in version 30.0, alongside datatypes and enumeration terms. Those counts describe the vocabulary at one release. They are not a goal for a page, and they will change as the project evolves.

Interpret the vocabulary with open-world rules#

Schema.org is not a closed form schema in the database sense. Its data-model documentation describes type-property associations as pragmatic guidance rather than rigid formal constraints. It also says the vocabulary is not intended to be a universal ontology of everything.

Three reading rules explain how that flexibility works inside the vocabulary itself.

First, Schema.org itself has no notion of a mandatory property. Different pages contain different facts, and different consumers need different subsets. The project’s governance documentation leaves required fields to consuming services rather than declaring them globally.

Second, Schema.org follows an open-world interpretation. If a property is absent, the safe meaning is “unknown,” not “false.” A page that omits petsAllowed, for example, has not asserted that pets are prohibited. It has supplied no claim about the subject.

Third, expected types are guidance about useful combinations, not permission to ignore semantics. A parser may tolerate text where a more specific entity would be richer, but a loose parser does not make an inaccurate claim correct. The term’s definition still matters.

The vocabulary owns meaning. The publisher owns the claim. The consumer owns acceptance and use.

Apply those ownership boundaries to the recurring property question. Start with facts the page can support, express only the properties that accurately describe them, and then consult the intended consumer for its required or recommended subset. Schema.org itself does not require every property; a Google feature guide can impose requirements for the feature Google operates.

The vocabulary documentation establishes that properties are not globally mandatory and that omission means unknown rather than false. Google’s documentation, as Schema.org’s Data model, How we work, and Style guide document, separately demonstrates how a consumer can classify fields as required, recommended, or optional for its own feature.

Open a separate contract for each consumer feature#

Schema.org and Google Search have overlapping but different contracts. Schema.org documents a broad vocabulary. Google says most of its Search structured data uses that vocabulary, but directs publishers to Google Search Central—not the Schema.org reference—for definitive Google behavior.

For Google Search, the vocabulary-to-product handoff requires two independent checks:

1. Is the structured data meaningful according to Schema.org? Check whether the types, properties, values, and relationships express the intended facts.
2. Is the page eligible for a specific consumer feature? Check that consumer’s supported types, required fields, quality policies, access rules, and content rules.

Google maintains a bounded gallery of supported structured-data features. The complete Schema.org vocabulary is much larger. A legitimate Schema.org type can therefore be meaningful to other consumers or internal systems without corresponding to a Google rich result.

Even supported and correctly implemented markup only creates eligibility. Google’s general structured-data guidelines explicitly say that a valid implementation does not guarantee display. The system may choose another presentation, and content can remain ineligible when the markup is misleading, does not represent the main page content, describes hidden information, or violates feature-specific guidance.

According to Google’s Structured Data Markup guide, its feature gallery and policies establish a bounded supported subset, feature-specific requirements, and a selection decision that remains separate from technical correctness.

This also puts ranking claims in their proper place. Schema.org can make a page’s explicit statements easier for compatible systems to parse. That is a useful capability, but it is not evidence of a guaranteed ranking increase. Google recommends measuring effects on a site’s own pages rather than importing a universal lift estimate.

Assign every validation tool a specific receipt#

“The markup validates” is incomplete unless the tool and the claim are named. The validation table is a receipt map: each row states what a check may certify and what still needs a different owner.

The Schema Markup Validator checks Schema.org-based structured data without Google feature-specific warnings. Google’s Rich Results Test asks which Google rich-result features the detected markup may generate. URL Inspection then helps verify what Google retrieved from a deployed page.

These tools cover different layers:

Automated validation cannot know whether a price is current, an author identity is correct, or a marked-up fact is misleading in context. Preserve the passing result, but attach it to its row in the receipt map rather than treating it as a certificate for the whole implementation.

The Schema Markup Validator and Rich Results Test evaluate different contracts, and Google cautions that automated tests cannot catch every content-quality, accuracy, or eligibility problem.

Govern semantic debt instead of property volume#

The vocabulary catalog creates a maintenance decision, not a completion target. Choosing every type that sounds plausible and populating every available property increases maintenance cost and semantic risk without creating a universal benefit.

A smaller description is often stronger when it preserves the page’s important entities and relationships accurately. Use the most specific type whose documented meaning fits. Prefer identifiers and nested entities when they remove real ambiguity. Add properties that a consumer or downstream decision actually uses. Leave unsupported facts out rather than guessing.

Take extra care with terms in Schema.org’s pending section. The project describes that section as a staging area where terminology may still change. Pending vocabulary can be appropriate for experimentation, but it carries a different stability expectation from the core vocabulary and demands deliberate monitoring.

The same caution applies to term names that look familiar. Schema.org’s style guide notes that a type has a specific semantic definition beyond its everyday label. Selecting a term because its name “sounds right” can encode the wrong entity even when the JSON is flawless.

Keep AI visibility outside the markup contract#

This section sets an outcome boundary for AI reporting. Structured descriptions may be useful to systems that consume them, but public documentation does not support a universal promise that Schema.org markup earns an AI citation. Each product can choose whether, how, and which vocabulary terms it processes.

For Google’s AI Overviews and AI Mode, the current site-owner guidance is unusually direct: there is no special Schema.org markup or additional technical requirement for those features. Pages need normal Search eligibility, important information should remain available in visible text, and any structured data should agree with that text.

That statement is bounded to Google Search. It does not prove that every answer engine ignores structured data, nor does it prove that any other engine rewards it. The defensible practice is to publish accurate visible content, use structured data where a documented consumer or interoperability need justifies it, and treat AI visibility as an outcome to observe rather than a promise embedded in the markup.

Google states that AI Overviews and AI Mode require no special Schema.org markup or additional technical requirement, while recommending that any structured data match visible page text.

Run one term from plain-language claim to maintenance#

When a type or property looks useful, use the six questions as an implementation workflow. They move from the real-world claim through vocabulary fit and consumer requirements to deployment ownership:

1. What real entity or relationship are you describing? — Write the claim in plain language first.
2. Does the term’s definition match that claim? — Read the definition, hierarchy, and examples rather than relying on the label alone.
3. Is the term stable enough for the use? — Check whether it is core, pending, or superseded and plan maintenance accordingly.
4. Do the property and value fit? — Review the associated subject types and expected value types, then use a nested entity or identifier where that conveys a real relationship.
5. What does the intended consumer require? — Check its own supported-feature documentation; do not infer support from Schema.org’s catalog.
6. Can you keep the claim synchronized? — Validate the encoding and consumer eligibility, compare it with visible content, deploy it, and monitor the rendered result.

This workflow is more durable than memorizing a list of popular types. The vocabulary will evolve, consumer support will change, and each page will expose different facts. Its final deliverable is a maintained claim: modeled with the clearest shared terms, justified by an actual consumer or interoperability need, and kept synchronized with the page.

Use interoperability as the final decision test#

The final decision is broader than any validator or search feature. Schema.org is most valuable when several systems need a common way to refer to the same entities and relationships. It gives publishers a maintained vocabulary, examples, identifiers, and an extensible data model. Encodings such as JSON-LD carry that vocabulary, while consumers decide which parts they recognize and what they do with them.

Approve a term when the page can support the claim, its definition fits, an actual consumer or interoperability need justifies it, and an owner can keep it synchronized. The resulting value is a clearer language agreement: a machine that understands the vocabulary can read a more explicit account of what the page already says. It is not a performance strategy based on vocabulary size, a green validator, or the mere presence of an @type.

Frequently asked questions#