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 and that Google uses it as a ranking signal. Where schema.org documents Article's headline as a Text property, the reference tells you that Google rejects headlines longer than 110 characters from the rich result. 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 the side-by-side comparison of related types (Recipe vs HowTo, Course vs CourseInstance) helps narrow the decision.

Disambiguating between two close types. A bakery is a LocalBusiness, a FoodEstablishment, and a Bakery. Which to use? The reference's hierarchy view makes the inheritance chain explicit and the rich-result column shows which level unlocks the bakery-specific snippet. The right answer is almost always "the most specific type that exists" — but you have to know what exists to apply that rule.

Discovering rich-result-eligible types you are not using. If your site has FAQ sections rendered in HTML but no FAQPage schema, you are leaving rich results on the table. Browsing the rich-result-eligible filter surfaces every type Google will reward, so you can spot the gaps in your current implementation.

Learning the property surface before generating markup. The Generator tool can produce a schema for any of these types, but knowing the property landscape first means you can pre-collect the right metadata from your CMS rather than discovering halfway through the generation that you are missing the publisher's logo dimensions.

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."

Use the search box to filter for "exercise" and ExerciseGym appears. Open its type page and the inheritance chain looks like:

Thing
  └── Place
        └── LocalBusiness        // properties: address, telephone, openingHours, priceRange, ...
              └── HealthAndBeautyBusiness
                    └── 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). The reference flags abstract-feeling types that you can technically use but probably should not, in favor of a more specific subtype.

Rich-result-eligible versus metadata-only types. A subset of types — Article, Product, FAQPage, Recipe, HowTo, JobPosting, Event, Course, LocalBusiness, Review, BreadcrumbList, VideoObject, and a handful of others — are eligible to trigger Google rich results. 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 blog post as Article when it is actually a How-To loses the HowTo 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. The reference flags these so you do not accidentally adopt a type that Google does not yet support or that is on its way out.

FAQ

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

Curated rather than auto-generated. Every type in the reference has been reviewed for usefulness in real-world implementations, with property recommendations beyond what schema.org documents. The list tracks new schema.org releases on a quarterly cadence and adds new types when they begin to see real adoption rather than the moment they ship in pending.

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

A curated subset of the types that matter for typical web implementations — about 40 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?

Pending types are excluded by default — they have weaker tooling support and Google does not generate rich results from them. When a pending type graduates to the core vocabulary and accumulates real adoption, it gets added to the reference. The exception is when a pending type is the only available representation of an important entity, in which case it appears with a "Pending" label.

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

MedicalBusiness, MedicalCondition, MedicalProcedure, JobPosting, EducationalOrganization, and Course are all in the reference because they have well-established Google rich-result support. 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 is pre-configured for every type in the reference.
• Schema Markup Validator — paste your generated or hand-authored JSON-LD to confirm it parses, validates against schema.org, and qualifies for the rich result you targeted.
• Schema Audit — when you want to know which schemas are missing across an existing template, the audit walks the page and flags the types you should 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.