Schema markup for AI search: which types are still live

Schema markup for AI search is worth adding for a narrower reason than most guides claim: it states plainly who published a page, when, and what it is about, in a format that needs no interpretation. Two of the types most often recommended for this — HowTo and FAQPage — no longer produce rich results in Google at all. Knowing which types are actually live saves you from marking up things nobody reads.

Read this first

Add markup after your content is reachable and readable. Structured data describes a page; it does not rescue one. If a crawler receives a shell, see can AI crawl JavaScript first, because JSON-LD injected by script has the same problem as everything else injected by script.

What Google actually supports now

Google's current gallery lists 25 structured data features, including Article, Breadcrumb, Dataset, Organization, Product, Profile page, Q&A, Video and Review snippet. Two long-recommended types are not on it.

Most schema advice on the web was written before those two were withdrawn. Check the gallery before you implement anything.

Does schema markup for AI search change whether you get cited?

We do not know, and neither does anyone quoting a percentage at you. No engine publishes how it weighs structured data, and we have not run a controlled test on our own sites. What is defensible is weaker and still worth acting on: markup removes ambiguity about authorship, dates and entity identity, and those are exactly the facts an engine needs to attribute a claim.

So the honest case is not "add schema, get cited". It is "if something does read this, it costs you an hour and it cannot be misread".

Four blocks you can paste

Each goes in a <script type="application/ld+json"> tag in the page head. Replace the values; do not keep the placeholder text.

An article or blog post:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "The exact visible title of the page",
  "datePublished": "2026-08-15",
  "dateModified": "2026-08-15",
  "author": { "@type": "Person", "name": "Author Name" },
  "publisher": {
    "@type": "Organization",
    "name": "Your Company",
    "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
  },
  "mainEntityOfPage": "https://example.com/the-page"
}

Who you are, on your homepage or about page:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "description": "One sentence stating what you do.",
  "sameAs": [
    "https://github.com/yourcompany",
    "https://www.linkedin.com/company/yourcompany"
  ]
}

Breadcrumbs, so the hierarchy is explicit:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Handbook",
      "item": "https://example.com/handbook" },
    { "@type": "ListItem", "position": 2, "name": "This chapter",
      "item": "https://example.com/handbook/this-chapter" }
  ]
}

A page that publishes data, which is rarer and therefore worth more:

{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "name": "What we measured",
  "description": "Sample, method and time window in one sentence.",
  "creator": { "@type": "Organization", "name": "Your Company" },
  "dateModified": "2026-08-15",
  "distribution": {
    "@type": "DataDownload",
    "encodingFormat": "application/json",
    "contentUrl": "https://example.com/data/results.json"
  }
}

The rule that gets sites penalised

Google's structured data policy is short and the important line is unambiguous: "your structured data must be a true representation of the page content", and "Don't mark up content that is not visible to readers of the page."

Violations "can result in a manual action", and the documented effect is specific: the page "loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search". So the downside is losing the feature you were trying to win, not a ranking collapse — but it is checked by people, and it is reported in the Manual Actions report in Search Console.

The practical version: if a value in your JSON-LD does not appear somewhere on the page a reader can see, take it out.

Where to put it, and what to do when a page has several types

One <script type="application/ld+json"> tag per block, in the head, is the simplest arrangement and the easiest to keep true. You can also put several types in one array, which some frameworks prefer; both parse fine.

What matters more is deciding what the page primarily is. An article that also lists a product is still an article, and marking it as both invites the two blocks to drift apart as the page changes. Pick the type that describes the main content, add BreadcrumbList because it describes position rather than content, and stop there unless a second type is genuinely load-bearing.

For a site-wide baseline, the arrangement that covers most cases is Organization on the homepage, Article on every post, and BreadcrumbList anywhere with a hierarchy. That is three templates, not a per-page job.

How to validate it

Three checks, in this order. The first catches most mistakes and takes seconds.

1. Fetch the page as a crawler and confirm the JSON-LD is in the delivered HTML. If your framework injects it client-side, it is not there for anything that does not render.
2. Run it through Google's Rich Results Test to confirm the syntax parses and Google recognises the type.
3. Re-read every value against the visible page. This is the step that keeps you out of the policy above, and it is the one no tool does for you.

curl -s -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot)" \
  https://example.com/your-page | grep -o 'application/ld+json' | wc -l

Zero means the markup is not being delivered, whatever your CMS preview shows.

How common is it, actually

When we fetched 15 well-known homepages on 15 August 2026, most carried no JSON-LD block at all in the delivered HTML. A handful carried one to three. That is a small and crude sample — homepages only, presence not correctness — but it is a useful corrective to the impression that everyone else has this handled.

Three ways this goes wrong

The first two waste effort; the third creates risk.

1. Implementing HowTo or FAQPage because a guide said to. Neither produces a rich result any more. If you add FAQPage anyway on the theory that an engine reads it, do it knowing that is a bet, not a documented benefit.
2. Injecting JSON-LD with JavaScript. Same failure as any other client-rendered content: it is absent for clients that do not render.
3. Marking up values that are not on the page. Ratings nobody left, authors who did not write it, dates that do not match. This is the specific thing the policy names.

Keeping the values true

Structured data rots differently from prose. Nobody notices a wrong dateModified or an author who left two years ago, because none of it renders on the page — which is exactly why it drifts, and exactly why the policy above is enforced by review rather than by a validator.

The cheapest guard is to generate the values from the same source the visible page uses, rather than hand-writing them into a template. If the byline on screen and the author in JSON-LD come from one field, they cannot disagree. Where that is not possible, re-read the block whenever you touch the template.

Common questions

Should I remove the HowTo markup I already have?

There is no documented penalty for leaving it, and Google's notice does not ask anyone to remove it. It simply does nothing in Search now. Remove it when you next touch the template rather than making a project of it.

Is FAQPage worth adding for AI engines even though Google dropped it?

It might be, and we cannot show you evidence either way. What we would not do is present it as an SEO win, because in Google it is not one any more.

Which single type should I add first?

Organization on the homepage, with sameAs pointing at your other verified profiles. It is the block that states who you are, and entity identity is the thing engines most need pinned down.

Does more markup mean better results?

No. Every additional type is another set of values that must stay true as the page changes. Two accurate blocks beat six that have drifted.

Next step

With the machine-readable facts in place, the remaining work in this part of the handbook is on the prose itself — making the passages quotable, which is the part no markup can do for you.

Adding the blocks takes an hour. Keeping them true as pages change, and pushing updates for indexing when they do, is the part that stalls.