Schema.org Type Reference

What this tool does

Schema.org defines more than 800 types organized into a deep inheritance tree, and the official documentation is technically accurate but pragmatically overwhelming. This reference is the opinionated, navigable layer on top: a curated set of the types that real sites use most often, each with the property surface that matters in practice, the rich-result families it qualifies for, the common mistakes that slip through validation, and a copyable JSON-LD example. The search and category filters let you converge on the right type in under a minute, even if you started from "I think there is a schema for this, but I am not sure what it is called."

Each type page goes deeper than the schema.org docs in the directions that matter. Where schema.org tells you that LocalBusiness has a priceRange property whose expected type is Text, the reference tells you the convention is one to four dollar signs. Where schema.org lists the properties an Article can have, the reference marks the ones that matter most and explains why. The reference is not a replacement for the spec; it is the operational guide that sits next to it.

When to use the Type Reference

Picking a type for a new content template. A new template is going up — a recipe page, a course landing, an event listing — and the first question is "which schema applies here?" The reference's category navigation surfaces the relevant family in seconds, and each type page links to related types (Recipe and HowTo, for example) so you can compare them.

Disambiguating between two close types. A restaurant is a LocalBusiness and a Restaurant. Which to use? Each type page names the type it extends, so you can walk up the inheritance chain. The right answer is almost always "the most specific type that exists" — but you have to know what exists to apply that rule.

Discovering types you are not using. Browsing the categories is a quick way to spot content your templates don't mark up yet — recipes, events, job postings, or products — and read what each type is for.

Learning the property surface before generating markup. The Generator has forms for 20 of these types, and knowing the property landscape first means you can pre-collect the right metadata from your CMS rather than discovering halfway through that you are missing a value you need.

Walkthrough with a real example

Suppose you are marking up the homepage of a small yoga studio in Brooklyn. The instinct is "this is a business," which lands on LocalBusiness — a perfectly valid choice that gets you address, telephone, opening hours, and the local-business rich result. But schema.org has subtypes underneath LocalBusiness, and the more specific you can be, the more relevant your entity is to queries like "yoga studio near me" instead of just "business in Brooklyn."

Search this reference for "gym" and it finds LocalBusiness, and points to the subtype that fits: ExerciseGym. ExerciseGym isn't in this reference, but its schema.org page shows the inheritance chain:

Thing
  └── Place
        └── LocalBusiness        // properties: address, telephone, openingHours, priceRange, ...
              └── SportsActivityLocation
                    └── ExerciseGym  // inherits everything above; no extra properties of its own

ExerciseGym adds no properties of its own — it is a pure type refinement that says "this is specifically a gym, not just a generic local business." Google's local-business rich result still triggers, but search results that filter for fitness-specific intent now see your studio as a match. The contrast between a generic LocalBusiness markup and the more specific ExerciseGym version:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Sun Salutations Studio",
  "address": { "@type": "PostalAddress", "streetAddress": "...", "addressLocality": "Brooklyn" }
}

versus the same studio with a more specific type and the optional but high-value properties populated:

{
  "@context": "https://schema.org",
  "@type": "ExerciseGym",
  "name": "Sun Salutations Studio",
  "address": { "@type": "PostalAddress", "streetAddress": "...", "addressLocality": "Brooklyn" },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Wednesday", "Friday"],
      "opens": "06:00",
      "closes": "21:00"
    }
  ],
  "priceRange": "$$",
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "Showers", "value": true }
  ]
}

The properties beyond name and address — opening hours, price range, amenities — are inherited from LocalBusiness and Place. They are not new to ExerciseGym; they just get more useful when paired with the more specific type. This is the canonical pattern for using the type reference: start from the broad type your content fits, walk down the inheritance tree to the most specific type that still fits, then populate the inherited properties that matter for the rich result you want.

Schema.org type concepts you should know

The type tree rooted at Thing. Every schema.org type descends from Thing. The first level under Thing splits into broad categories: CreativeWork, Event, Intangible, MedicalEntity, Organization, Person, Place, Product, and Action. Below each is a deep tree of refinements. Knowing where in the tree your content lives is the first navigational skill — you cannot find the right type without understanding the rough region.

Inheritance: children get parent properties. When a type extends a parent, it gains every property the parent defines without redeclaring them. A NewsArticle inherits from Article (which adds wordCount, articleSection, articleBody) which inherits from CreativeWork (which adds author, datePublished, publisher) which inherits from Thing (which adds name, description, url, image). To populate a NewsArticle properly you need to think across the whole inheritance chain, not just the leaf type.

Types and properties as a duality. A property's "expected type" can be another schema.org type, which is how you build nested objects. Article.author expects a Person or Organization, so the value is itself a typed object with its own properties. Product.offers expects an Offer, and the offer has a priceCurrency property whose expected type is Text but whose value should be an ISO 4217 code. The reference flags these typed-property relationships explicitly.

Abstract versus concrete types. Some types in the hierarchy are intermediate organizational nodes (CreativeWork, MedicalEntity) that you would not typically use as a leaf @type directly. Others are concrete and fully specified (Recipe, JobPosting, LocalBusiness). Where a more specific subtype fits, use it instead of an abstract-feeling type.

Rich-result-eligible versus metadata-only types. A subset of types — Article, Product, Recipe, JobPosting, Event, Course, LocalBusiness, Review, BreadcrumbList, VideoObject, and a handful of others — are eligible to trigger Google rich results. Google stopped showing How-to rich results in 2023 and FAQ rich results on May 7, 2026. The rest are still useful: they help search engines understand your content and can improve relevance, and they often qualify for AI search citations even when no rich result fires.

The sameAs property as the entity-graph hook. Most types inherit a sameAs property from Thing. Populating it with URLs to authoritative external pages — Wikipedia, Wikidata, LinkedIn, official government registries — is how you connect your entity to the broader web of identity. This is the single highest-leverage property for AI search readiness because it disambiguates "which Sam Patel?" or "which Example Co?" against the rest of the web.

Common mistakes

Picking too generic a type. Marking a recipe as CreativeWork instead of Recipe validates but leaves the recipe rich result unreachable. Always descend the tree to the most specific concrete type that fits.

Picking a type that does not match the content. Marking a recipe as Article loses the recipe rich result. The type should describe what the content is, not what feels closest.

Using Person or Organization where LocalBusiness fits. A coffee shop is not just an Organization — LocalBusiness is the right base type because it carries opening hours, address, and the local-business rich result eligibility. Organization is for entities without a physical premises (a national chain's parent company, a remote-only consultancy, a non-profit).

Ignoring properties inherited from parent types. A Restaurant is a LocalBusiness is a Place. The most useful properties — address, geo, openingHoursSpecification — come from the parent layers. Populating only the leaf-type properties leaves the schema thin.

Using deprecated or pending types in production. Schema.org occasionally deprecates types or holds new ones in pending. Check a type's status on schema.org before adopting one from outside this reference, so you do not pick a type that Google does not support or that is on its way out.

FAQ

How often is the type list updated against the upstream schema.org vocabulary?

It isn't generated from the schema.org vocabulary, so it doesn't change automatically when schema.org publishes a release. The reference is curated by hand: every type in it was chosen for real-world usefulness, with property guidance beyond what schema.org documents.

Is this every schema.org type, or a curated subset?

A curated subset of the types that matter for typical web implementations — 37 of the most-used types out of schema.org's 800+. The full vocabulary is documented at schema.org/docs/full.html, but the long tail covers domain-specific types (Bioschemas, GS1) that most sites will never use. The reference focuses on the types where a clear, opinionated guide adds value.

Does the reference include types from schema.org's pending vocabulary?

No. Every type in the reference is part of schema.org's core vocabulary. Pending types have weaker tooling support, and a type is only worth adding once it graduates to the core vocabulary and sees real adoption.

What about vertical-specific types like medical or job-board schemas?

MedicalBusiness, JobPosting, EducationalOrganization, and Course are in the reference because they are widely used. More specialized medical and scientific types from Bioschemas and SPAR are not — those communities maintain their own documentation and tooling that goes beyond what a general reference can usefully provide.

Where is the canonical specification when I need authoritative wording?

schema.org itself is canonical for the type and property definitions. Google's structured data documentation at developers.google.com/search/docs/appearance/structured-data is canonical for rich-result requirements. The reference here is opinionated guidance built on top of both — when authoritative wording matters (compliance, contracts), cite the upstream source rather than the reference.

Related tools and guides

• JSON-LD Generator — once you have settled on a type from the reference, generate valid markup for it from a form. The generator has forms for 12 common types plus subtypes such as NewsArticle and Restaurant, which covers 20 of the 37 types in this reference.
• Schema Markup Validator — paste your generated or hand-authored JSON-LD to confirm it parses and has the properties the rich result you targeted needs.
• Schema Audit — paste a page's HTML to check all of its JSON-LD at once and see which types it could also be emitting.
• Schema Markup Beginner's Guide — the foundational concepts the reference assumes: what JSON-LD is, how Google reads it, and which rich-result families exist.
• JSON-LD vs Microdata vs RDFa — when an existing site uses Microdata or RDFa, this guide covers how to migrate to JSON-LD without losing data.