What Is Schema.org? Vocabulary, Types, Properties, and Common Misconceptions

Schema.org is a collaborative, community-maintained vocabulary for describing entities, relationships, and actions in structured data on web pages, email, and other digital surfaces. It supplies standardized types such as Organization and Article, properties such as name and author, and enumerated values. Publishers express those terms through encodings including JSON-LD, Microdata, or RDFa so compatible systems can interpret the same facts consistently.

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’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 distinction matters: Schema.org defines terms, while consuming platforms decide which terms they support and how they use them.

Schema.org is the vocabulary layer#

Several related terms are routinely compressed into the word “schema.” Separating their jobs makes the whole subject easier to reason about.

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. None of those lines by itself promises that a search product will show a special result.

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.

Types classify entities; properties make claims about them#

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.

The vocabulary includes a few other building blocks:

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.

The vocabulary is intentionally flexible#

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.

That flexibility appears in three places.

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.

This three-part rule resolves the recurring question, “Do I have to mark up every property?” No. Add properties that accurately describe available content, then consult the intended consumer’s documentation for any required or recommended subset. In Google’s case, a feature guide can impose requirements that Schema.org itself does not.

A valid Schema.org term is not automatically a Google 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.

That means two questions must be tested independently:

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.

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.

Validation answers different questions#

“The markup validates” is incomplete unless the tool and the claim are named.

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. That is why passing a tool is evidence about one layer, not a certificate for the whole implementation.

More markup is useful only when it carries better facts#

Vocabulary size can encourage completionism: choose every type that sounds plausible and populate every available property. That approach 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.

Schema.org is not an AI-citation switch#

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.

A practical way to read any Schema.org term#

When a type or property looks useful, walk through six questions before adding it:

This sequence 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. The decision rule remains stable: model true claims with the clearest shared terms that an actual consumer or interoperability need can justify.

Use Schema.org as a language agreement#

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.