Schema Type Hierarchy Explorer

The interface is a two-pane split. Left pane is a recursive tree rooted at Thing, the single ancestor of every schema.org type. Right pane is a detail card for the currently selected type. Everything updates client-side on selection changes, so navigation feels instant even though you’re walking a vocabulary of nearly a thousand entries.

1. 1

   Expand the tree

   Click any disclosure triangle to expand a branch. The tree uses native <details> elements under the hood, so you can also use keyboard navigation or the browser’s find-in-page feature without any custom focus handling getting in the way. There’s no max depth — expand all the way down to leaves if you want.
2. 2

   Filter by name

   The search field at the top of the tree filters by type label. Matches stay visible along with every ancestor on the way back to Thing, so context is preserved. Try filtering for Medical to see the entire medical hierarchy collapse to just its relevant branches.
3. 3

   Click a type to select it

   Selecting a type populates the right pane with its breadcrumb path from Thing, the raw schema.org description text, a button linking to the schema.org documentation, the list of direct children, and a card for the XooCode reference example when one exists.
4. 4

   Deep-link via URL hash

   Every selection updates the URL hash. Share /schema-type-hierarchy#CollegeOrUniversity and the person you send it to lands on the tree with that type pre-selected, its branch expanded, and its detail card ready. The hash also preserves state across page reloads.

Every schema.org type inherits from a more general parent. The vocabulary is a tree and every leaf knows its way back to the root. That structure is why the hierarchy matters: when you mark up a thing as a specific subtype, you get the subtype’s properties and every property inherited from every ancestor back to Thing. When you mark it up as the base type, you get the base type’s properties and nothing else.

The cost of using a base type where a specific subtype exists is silent but real. A university marked up as Organization gets the generic Organization rich result. The same university marked up as CollegeOrUniversity (a deeper descendant through EducationalOrganization) inherits properties like alumni, hasCredential, and educationalCredentialAwardedthat only make sense at that level. Google’s entity-recognition systems also understand the specificity: the more precise the type, the more confidently the page maps to a knowledge graph entity.

The same principle applies to every subtree. A Hospital is more specific than a MedicalBusiness which is more specific than a LocalBusiness which is more specific than an Organization which is more specific than a Thing. At each step down you pick up properties that make the markup more useful. Use the hierarchy explorer to find how deep you can go for any given subject and pick the deepest accurate match. That’s the single highest-impact SEO move you can make on your markup without adding a single new property.

The type data isn’t scraped from schema.org at runtime. It’s a static TypeScript file committed to the XooCode repository and regenerated from the canonical schema.org JSON-LD distribution whenever a new schema.org version ships. The generator script lives at scripts/generate-schema-tree.ts and runs as pnpm generate:schema-tree.

The generator walks the distribution file, extracts everyrdfs:Class entry, resolves its rdfs:subClassOfrelationships into a parent list, computes the inverse relationship to get each node’s children, and writes out a flat Record<string, SchemaTypeNode> keyed by label. Every entry keeps its description comment and its schema.org URL for the detail pane.

This approach is deliberate. Runtime fetching would bloat the page load, introduce a third-party dependency into a tool that’s supposed to run offline, and expose users to availability issues with schema.org’s CDN. Committing a static snapshot lets the whole tree render in milliseconds with zero network calls, and the price — remembering to rerun the generator when the vocabulary changes — is one command.

Schema.org releases new versions roughly once per quarter, so the snapshot is refreshed on that cadence. The current snapshot covers 911 types. The generator header comment in lib/schema-tree.ts records the exact date of the last refresh.

Schema.org is a single rooted tree. The root is Thing, the abstract ancestor of every concrete type. From Thing the vocabulary branches into eleven top-level subtypes:

• Action — things that happen (BuyAction, WatchAction, CookAction). Large subtree, limited Google rich result coverage.
• CreativeWork — authored content: Article, Book, Movie, Recipe, SoftwareApplication, Course, HowTo, Dataset, and more. The biggest and most SEO-relevant subtree.
• Event — dated occurrences: MusicEvent, BusinessEvent, SportsEvent, and so on. Powers the Events rich result.
• Intangible — non-physical concepts that have properties: Offer, Rating, Brand, JobPosting, ItemList, Service. Think “abstract but structured”.
• MedicalEntity — domain-specific medical vocabulary for diseases, drugs, procedures, and clinical studies.
• Organization — companies, governments, and similar groups. Includes the LocalBusiness subtree, which is where most small-business markup lives.
• Person — a single human. Used for author attribution on Articles and Recipes, and standalone for personal sites.
• Place — a physical location. A LocalBusiness is both an Organization and a Place; you’ll see the multi-parent relationship in the tree.
• Product — a physical or digital good. Powers the Product and Merchant Listing rich results.
• BioChemEntity and Taxon — scientific vocabulary for chemistry and biology. Added in recent schema.org versions; no direct Google search support.

Most SEO work on most sites touches three or four of those branches. Product, Organization, and CreativeWork dominate ecommerce and publishing. Event and JobPosting are narrow but high-value. Medical, BioChem, and Taxon are specialist. Knowing which branch your content belongs to is the first question, picking the deepest accurate subtype is the second.

The hierarchy explorer is a focused tool. It does one thing well and deliberately does not try to be more.

The hierarchy explorer pairs naturally with several other pages in the XooCode toolkit. These are the links that make the most sense in the same session.

The tree data comes from schema.org. These are the primary sources you’ll want to consult when you need more than the explorer shows.

• schema.org — the canonical vocabulary. Every type in the explorer links out to its schema.org documentation page for the full list of supported properties and worked examples.
• schema.org Full Hierarchy page — schema.org’s own flat list of every type. Less interactive than our tree but the authoritative source of record.
• Google Search Gallery — the index of every rich result Google supports. Use this alongside the tree to know which types actually produce visible SERP features.
• schema.org current JSON-LD distribution — the machine-readable source file our generator consumes. Refresh the XooCode snapshot by running pnpm generate:schema-tree against this URL.
• W3C schema.org community group — the governance body. Proposals for new types and property changes start here before they land in the published vocabulary.