The schema tags AI engines actually read in 2026

There are over 800 schema types defined at schema.org. AI engines actively read about eight of them. The other 790-plus exist mostly as legacy markup, edge-case vocabulary, or coordination overhead. Here's the working set — what each one signals, what to put in each, and what's safe to skip.

Why schema matters more in the AI era, not less

Classical search engines used schema to render rich results in search listings — review stars, FAQ accordions, recipe cards. Those rich results still matter, but they're not why schema is rising in importance now. Schema matters now because AI engines use it during entity resolution — the process of figuring out what your page is about and how the entities on it (people, organisations, products, places) relate to other things they've already indexed.

For classical search, schema was a presentation layer. For AI search, schema is a comprehension layer. The difference is that the latter applies to every page, not just the ones eligible for special listings. A blog article without schema can still rank in classical search. An AI engine reading the same article without schema has to guess who wrote it, what organisation published it, and which other entities it relates to — and guesses tend to weight lower in citation algorithms than verified entity references.

The eight schema types AI engines actively read

What the working set looks like in practice

For a typical AU SMB blog article, the schema graph that covers the eight high-impact types is roughly 80–120 lines of JSON-LD. Here's a simplified skeleton showing how the entities link to each other through @id references:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/blog/post/#article",
      "author": { "@id": "https://example.com/author/name/#person" },
      "publisher": { "@id": "https://example.com/#organization" },
      "headline": "...",
      "datePublished": "2026-06-05T07:30:00+10:00"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/author/name/#person",
      "name": "...",
      "sameAs": [ "scholar URL", "LinkedIn URL" ]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization"
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [ "..." ]
    },
    {
      "@type": "FAQPage",
      "mainEntity": [ "..." ]
    }
  ]
}

The key pattern is the @id references that link entities together. Each entity has a stable, unique identifier. Article references Person and Organization through their @ids. The same Person and Organization schemas appear on every article — same @ids — so AI engines can resolve them to single entities across the whole site. This is what makes a coherent entity graph that AI engines can read; loose, disconnected schema blocks don't produce the same effect.

Five schema types most agencies use that AI engines mostly ignore

The most expensive schema work is the work that produces nothing. Five categories where I see AU agencies wasting effort:

The bottom line

Eight schema types — Article, Person, Organization, FAQPage, LocalBusiness, Product (if applicable), BreadcrumbList, Review/AggregateRating — do almost all of the work AI engines need from schema. Five common categories of schema markup do little or actively harm. The rest of the schema.org vocabulary is mostly edge cases that don't apply to typical Australian SMB content.

The discipline isn't about coverage — putting more schema everywhere doesn't help. The discipline is about correctness: making sure each schema accurately describes what's on the page, every entity has a stable @id, and the entities link to each other through references rather than existing as disconnected blocks. That's what makes the entity graph an AI engine can read.

For the conceptual frame underneath all of this, read your website now has two audiences — you see one. Schema is the cleanest way to serve the second audience without making the first audience's experience worse.