Which schema.org types do AI answer engines actually read?

One property, from one engine, is documented: Apple's Applebot consumes isAccessibleForFree to determine whether page content sits behind a paywall. No other answer engine publishes a schema.org type or property it consumes for AI answer generation. The case for Article, Organization, Product and BreadcrumbList is transitive: Google states that AI Overviews eligibility is Search eligibility, so markup that governs the search surface governs the input to the answers.

Should I remove FAQPage or HowTo markup after Google's 2023 changes?

Google says there is no need. Its announcement states: "While you can drop this structured data from your site, there's no need to proactively remove it. Structured data that's not being used does not cause problems for Search, but also has no visible effects in Google Search." Removing it costs engineering time for no documented benefit. Leaving it costs bytes.

Does FAQPage markup make me more likely to be cited in an AI answer?

Unverified. No vendor publishes whether FAQPage JSON-LD is parsed during answer generation. What is documented is adjacent but different: Microsoft recommends "clear headings, tables, and FAQ sections" to help AI systems reference content accurately, which is guidance about visible page structure rather than markup. The defensible position is that question-shaped visible content has one vendor's endorsement and FAQPage markup has none.

What happens if my structured data does not match the visible page?

It is a policy violation, not a quality suggestion. Google's single structured-data instruction in its AI features documentation is "making sure your structured data matches the visible text on the page", and it links to the structured data general policies. Marking up a price, rating, author or date that a reader cannot see on the page is the specific failure that policy exists to catch.

Does declaring a license or citation property affect AI usage of my content?

Unverified in both cases. No engine documents consuming schema.org license or citation for AI usage rights or attribution. Crawl Census scores an explicit license as a small signal because unstated terms leave reuse conditions to be inferred, and some pipelines default to more restrictive handling, but we do not claim any engine reads the property.

Guide · 7 min read · updated 2026-08-22

Structured data for AI answers: what is actually evidenced

One property is documented as read by an answer engine for AI output; everything else rests on a transitive argument that is worth making honestly.

Here is the honest finding, before the caveats: exactly one schema.org property is publicly documented as consumed by an answer engine for AI output. It belongs to Apple, it is isAccessibleForFree, and it is a suppression signal rather than a promotion signal. Everything else recommended as "structured data for AI" rests on a transitive argument, which is worth making, but is worth labelling as what it is.

The one documented property

From Apple's Applebot documentation:

"Applebot supports the schema.org isAccessibleForFree property to identify pages that are behind a paywall, metered access, or subscription. […] Pages marked isAccessibleForFree: false are eligible to appear in search results, but Applebot will not use that content as additional context when AI models are used to generate output for display in Apple products and services. This signal applies at the page level. Section-level markup using hasPart is not supported."

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "isAccessibleForFree": false
}
</script>

The unsupported hasPart is a real, checkable gotcha with real consequences. The standard paywall pattern from Google's own subscription guidance marks the section that sits behind the wall, using hasPart with a cssSelector. Publishers who did that and assumed it covered Apple have not opted that content out of Apple's AI answers. Apple reads the page-level flag or nothing.

Everything else rests on a transitive argument

The argument is sound, and it comes from Google's own words. Because Google states that AI Overviews and AI Mode eligibility is Search eligibility with a snippet, with "no additional technical requirements", anything that improves standing on the search surface is relevant to the answers drawn from it. That makes the classic types worth auditing, not because an engine says it reads them for answers, but because they govern the surface that feeds the answers.

Type or property	Status	Note
Article, NewsArticle	Live Google rich result	Headline, image, `datePublished`, `dateModified`.
Product, Offer, AggregateRating	Live Google rich result	Also feeds Merchant Center, which Google's AI features documentation explicitly tells site owners to keep current.
Organization	Live	Google's AI features documentation names Business Profile and business details as a checklist item.
BreadcrumbList	Live	Affects how the result is presented, which affects what a fan-out query surfaces.
WebSite, SearchAction	Sitelinks searchbox	Long-standing, unrelated to AI features.
author	Supported, not an AI signal	Supported on Article-family types. No engine documents it as a citation signal.
datePublished, dateModified	Supported, not an AI signal	Microsoft's freshness guidance is prose about content, not about markup.
license	Unverified	No engine documents consuming it for AI usage rights.
citation	Unverified	No engine documents consuming it.
isAccessibleForFree	Documented, Apple	Page level only. `hasPart` unsupported.

Google's one instruction: match the visible text

Google's entire structured-data statement in its AI features documentation is a single line: "Making sure your structured data matches the visible text on the page." It links to the structured data general policies. That framing matters. A mismatch between markup and rendered text is a policy violation, with manual-action consequences, not a quality suggestion you can trade off against ambition.

The practical rule follows directly. Every value in your JSON-LD should be readable somewhere on the rendered page: the author's name in a byline, the modified date in a visible time element, the price where a customer sees it, the rating next to the reviews it aggregates. Markup that describes a page a reader does not get is the one structured-data mistake with a real downside.

FAQPage and HowTo after August 2023

Primary source: Google's 2023-08-08 announcement.

FAQPage. "Going forward, FAQ rich results will only be shown for well-known, authoritative government and health websites. For all other sites, this rich result will no longer be shown regularly."
HowTo. "How-To rich results will only be shown for desktop users, and not for users on mobile devices." Because Google indexes the mobile version of a page, the mobile page must still carry the markup for the desktop rich result to appear.
On removal. "While you can drop this structured data from your site, there's no need to proactively remove it. Structured data that's not being used does not cause problems for Search, but also has no visible effects in Google Search."
Google states the change "should not be considered a ranking change."

Does FAQPage markup still help with LLM extraction? Unverified. No vendor publishes whether that JSON-LD is parsed during answer generation. What is documented sits next to the question without answering it: Microsoft recommends "clear headings, tables, and FAQ sections" to "help surface key information and make content easier for AI systems to reference accurately" (Bing Webmaster Blog, 2026-02-10). That is guidance about visible page structure, not about markup. So: question-shaped visible content has one vendor's endorsement, and FAQPage markup has none. Write the visible FAQ. Add the markup if you want, and do not claim it earns citations.

The three blocks worth shipping

These are correct, minimal and defensible. Every value in them should also appear in the rendered page.

Article, with author, dates and publisher

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/guides/edge-caching#article",
  "headline": "How edge caching changes origin load",
  "description": "A measured account of what moving cache decisions to the edge does to origin request volume.",
  "url": "https://example.com/guides/edge-caching",
  "datePublished": "2026-06-04T09:00:00-04:00",
  "dateModified": "2026-08-19T16:40:00-04:00",
  "isAccessibleForFree": true,
  "author": {
    "@type": "Person",
    "name": "Dana Reyes",
    "url": "https://example.com/authors/dana-reyes",
    "jobTitle": "Infrastructure Engineer",
    "sameAs": ["https://github.com/danareyes"]
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Systems",
    "url": "https://example.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/static/logo-600x60.png",
      "width": 600,
      "height": 60
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/guides/edge-caching"
  }
}

Use ISO 8601 with a timezone offset for both dates, and update dateModified only when the content actually changes. Bumping it on every deploy teaches crawlers to ignore it, which costs you the one freshness signal you control. Give the author a stable @id and reuse it so the entity consolidates across posts.

Organization, with sameAs

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Systems",
  "url": "https://example.com",
  "logo": "https://example.com/static/logo-600x60.png",
  "description": "Infrastructure tooling for high-volume origins.",
  "email": "hello@example.com",
  "sameAs": [
    "https://www.linkedin.com/company/example-systems",
    "https://github.com/example-systems",
    "https://x.com/examplesystems"
  ]
}

The point of sameAs is entity resolution: it turns your publisher name from an ambiguous string into a node that matches the same node in other graphs. List only profiles you control or that genuinely describe you. A wrong sameAs merges you with somebody else.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Guides",
      "item": "https://example.com/guides/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Edge caching"
    }
  ]
}

The final item deliberately omits item, because it is the current page. The visible breadcrumb trail should match this list exactly, in the same order.

Serialise these from real objects rather than string concatenation, so quoting and escaping are handled for you. One trailing comma or unquoted key discards the whole block, and the page then scores as having no structured data at all. Inside an inline script element, escape < as \u003c in string values so the block cannot terminate the element early. Render server-side: fetchers that do not execute JavaScript will not see markup injected by a tag manager.

How Crawl Census scores this

Structured data lands across two of our four dimensions, worth 35 of 100 points combined. The Structure dimension (20 points) asks whether the page states its own type and facts in machine-readable form: JSON-LD presence carries 7 points, a block that parses cleanly with recognised schema.org terms 3, a type that actually fits the page purpose 4, a canonical URL 3, a declared and reachable sitemap 2, and discrete extractable blocks such as real tables and lists 1. A generic WebPage node on an article or product page passes the presence check and fails the fit check, which is the intended distinction: it carries none of the fields an engine routes on.

The Attribute dimension (15 points) asks who is responsible for the page and under what terms: an llms.txt index 4 points, machine-readable author 3, published and modified dates 3, an Organization node with sameAs 3, and explicit reuse terms 2. Two of those are evidence-thin by our own account, and we say so rather than inflating them: no engine documents reading author or license for AI purposes. They are scored because the alternative is leaving a fact to be guessed, and low-confidence guesses get dropped during extraction. Every weight, the reasoning behind it, and the cases where the method is known to be wrong are on the methodology page.

Scan your site to see which JSON-LD blocks your pages actually serve to a non-JavaScript fetcher, whether they parse, whether the type fits the page, and which of the author, date, publisher and licence facts an answer engine would have to guess.