--- title: "Structured data for AI answers: the schema.org types that matter" subtitle: "Which JSON-LD types tell a machine what a passage is — an answer, a definition, an author — and how to generate them so they never disagree with the page." canonical: https://citable.wiki/guides/structured-data-for-ai-answers category: structured-data author: "Endrit Krasniqi" date_published: 2026-02-16 date_modified: 2026-08-20 license: CC BY 4.0 --- # Structured data for AI answers: the schema.org types that matter *Which JSON-LD types tell a machine what a passage is — an answer, a definition, an author — and how to generate them so they never disagree with the page.* ## Short answer Structured data for AI answers is JSON-LD that labels what a page contains: Article or TechArticle for provenance (author, datePublished, dateModified, citation), FAQPage for question–answer pairs, DefinedTerm for definitions, Person with sameAs for authors, BreadcrumbList and WebSite for context, and SpeakableSpecification for the direct answer. Google requires no markup for AI features; its value is removing ambiguity, so generate it from the CMS fields that render the visible text. ## Key takeaways - Google states that no special schema.org markup is needed for AI Overviews or AI Mode; structured data clarifies content rather than ranking it. - TechArticle with author, datePublished, dateModified and citation gives a retrieval system provenance it can check without reading the page. - FAQPage no longer earns rich results for most sites, but it still exposes question–answer pairs in the exact shape answer engines extract. - DefinedTerm and DefinedTermSet make a glossary machine-readable: one term, one definition, one stable @id per entity. - Person with sameAs links an author to profiles elsewhere, which is how machines disambiguate names. - Generate every JSON-LD value from CMS fields so the markup can never disagree with the visible text. ## What structured data can and cannot do for an answer Google's documentation for AI features is unusually direct. The page *AI features and your website* says: "You don't need to create new machine readable files, AI text files, or markup to appear in these features. There's also no special schema.org structured data that you need to add." It adds that the existing best practices for SEO remain relevant. Structured data is therefore not a lever that ranks a page inside AI Overviews or AI Mode, and no other answer engine vendor has published anything that says otherwise. What structured data does is narrower and still worth doing. A crawler that reads a page sees text. It has to infer that a paragraph is a definition, that a name in the byline is the author, that a list at the foot of the page is the sources. JSON-LD states those things outright, in a vocabulary that search and AI companies already parse, and removes the inference step where machines make mistakes. Two constraints shape everything below. Google recommends JSON-LD over microdata and RDFa because it is "the easiest solution for website owners to implement and maintain at scale". And Google's structured data policies say: "Don't mark up content that is not visible to readers of the page." Markup describes the page; it never substitutes for it. > **Note: A labelling layer, not a ranking layer** > > Treat every type in this guide as a way of saying "this passage is an X" about text that is already on the page. If a passage is not good enough to be quoted, marking it up will not change that. ## Article and TechArticle: provenance a machine can check The guide [What is Answer Engine Optimization](/guides/what-is-answer-engine-optimization) argues that retrieval systems lean on the signals they can verify: who wrote a page, when, and on what basis. `Article` carries all three. `TechArticle` is the schema.org subtype for technical and how-to material, and it is what this site emits for guides. Google's Article documentation lists `author`, `author.name`, `author.url`, `datePublished`, `dateModified`, `headline` and `image` as recommended properties. It asks for dates "in ISO 8601 format" and recommends including a timezone; without one, Google falls back to "the timezone used by Googlebot". Two further properties matter for answers even though Google does not list them: - `citation` — schema.org defines it as "a citation or reference to another creative work, such as another publication, web page, scholarly article, etc." It accepts a `CreativeWork` or plain text. List the same sources you show at the foot of the page. - `about` — the entities the page is about, ideally as `DefinedTerm` references with stable `@id` values, covered below. ```json { "@context": "https://schema.org", "@type": "TechArticle", "@id": "https://example.com/guides/structured-data-for-ai-answers#article", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/guides/structured-data-for-ai-answers" }, "headline": "Structured data for AI answers: the schema.org types that matter", "description": "Structured data for AI answers is JSON-LD that labels what a page contains …", "datePublished": "2026-02-16T09:00:00+01:00", "dateModified": "2026-02-16T09:00:00+01:00", "inLanguage": "en", "author": { "@id": "https://example.com/authors/endrit-krasniqi#person" }, "publisher": { "@id": "https://example.com/#organization" }, "isPartOf": { "@id": "https://example.com/#website" }, "citation": [ { "@type": "CreativeWork", "name": "AI features and your website", "url": "https://developers.google.com/search/docs/appearance/ai-features", "publisher": { "@type": "Organization", "name": "Google Search Central" } } ], "about": [ { "@type": "DefinedTerm", "@id": "https://example.com/glossary/json-ld#term", "name": "JSON-LD" } ] } ``` Reference the author, publisher and website by `@id` rather than repeating their details in every article, so each node exists once. **up to 40%** — visibility boost reported in the GEO benchmark, with adding citations, quotations and statistics among the strongest methods (Source: [GEO: Generative Engine Optimization (arXiv)](https://arxiv.org/abs/2311.09735)) The GEO study measured citations visible in the text, not the `citation` property; the property makes the same list legible to a parser and does not replace it. ## FAQPage after Google retired the rich result In August 2023 Google's Search Central blog announced that "FAQ (from FAQPage structured data) rich results will only be shown for well-known, authoritative government and health websites", and added: "While you can drop this structured data from your site, there's no need to proactively remove it." For most sites, FAQPage stopped earning a search appearance on that day. On 8 May 2026 Google's documentation changelog added a deprecation notice saying the feature "will no longer appear in Google Search starting May 7, 2026", and the FAQ rich result documentation was removed in June 2026. The search appearance is now gone for every site. It is still worth emitting, for a different reason. A `Question` with an `acceptedAnswer` is the exact unit an answer engine extracts: one question, one self-contained answer, no surrounding context required. Keep the answer text identical to the visible FAQ, and keep each answer between roughly thirty and eighty words so it is quotable on its own. ```json { "@context": "https://schema.org", "@type": "FAQPage", "@id": "https://example.com/guides/structured-data-for-ai-answers#faq", "mainEntity": [ { "@type": "Question", "name": "Is structured data a ranking factor for AI Overviews?", "acceptedAnswer": { "@type": "Answer", "text": "No. Google's documentation for AI features says there is no special schema.org structured data you need to add …" } } ] } ``` Do not use FAQPage to carry questions that are not visibly answered on the page. That is precisely what the content guideline prohibits. ## DefinedTerm and DefinedTermSet: one entity, one definition Language models resolve entities by name, and a name defined in several places, slightly differently each time, is harder to resolve than one defined once. `DefinedTerm` is schema.org's type for "a word, name, acronym, phrase, etc. with a formal definition"; `DefinedTermSet` groups terms into a glossary. Each glossary page on this site emits one `DefinedTerm` with an `@id`, and the glossary index emits the set: ```json { "@context": "https://schema.org", "@type": "DefinedTerm", "@id": "https://example.com/glossary/speakable#term", "name": "Speakable", "alternateName": ["SpeakableSpecification"], "description": "Speakable is a schema.org property (with the SpeakableSpecification type) that identifies, by CSS selector or XPath, which parts of a page are best suited to be read aloud or quoted verbatim.", "url": "https://example.com/glossary/speakable", "inDefinedTermSet": { "@id": "https://example.com/glossary#set" } } ``` The `@id` is what makes this useful beyond the glossary. Any guide that discusses the term references the same `@id` in its `about` array, so a parser can connect a definition, the pages that use it and the pages that link to it without string matching. The `description` is the same field that renders as the visible definition; the two cannot diverge. ## Person, BreadcrumbList and WebSite: context around the page ### Person with sameAs Author markup only works if the author is unambiguous. `sameAs` takes URLs that identify the same person elsewhere — a GitHub profile, a personal site, an ORCID record — and Google's Article documentation names `sameAs` as an alternative to `author.url` for disambiguating authors. One `Person` node with an `@id`, referenced from every article, is enough. ```json { "@context": "https://schema.org", "@type": "Person", "@id": "https://example.com/authors/endrit-krasniqi#person", "name": "Endrit Krasniqi", "url": "https://example.com/authors/endrit-krasniqi", "jobTitle": "Front-end engineer", "sameAs": ["https://github.com/Endrit-seek"], "worksFor": { "@id": "https://example.com/#organization" } } ``` ### BreadcrumbList Breadcrumbs tell a crawler where a page sits within the site. Google requires `position`, `name` and `item` on each `ListItem`, with `item` optional for the final entry, and at least two items for the rich result. Generate the list from the route rather than by hand: home, section, page. ### WebSite `WebSite` markup once powered the sitelinks search box. Google's blog announced it would remove that visual element "starting on November 21, 2024", while the `WebSite` type "continues to be supported" for site names. The site-names documentation requires the markup to be on the home page — "the domain or subdomain level root URI" — with `name` and `url`, plus an optional `alternateName`. Give it an `@id` and let every article's `isPartOf` point at it. ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Citable", "inLanguage": "en", "publisher": { "@id": "https://example.com/#organization" } } ``` ## SpeakableSpecification: pointing at the answer [Speakable](/glossary/speakable) is the most literal type in this guide: it names the element on the page that contains the passage to read aloud or quote. Google documents it as a beta feature, used by the Google Assistant to answer news queries from publishers writing in English; it recommends "roughly two to three sentences" per section, and says to use either `cssSelector` or `xpath`, not both. No answer engine has confirmed that it uses the property. It is nonetheless nearly free if your template already has a short-answer block: ```json "speakable": { "@type": "SpeakableSpecification", "cssSelector": ["[data-speakable='short-answer']", "[data-speakable='headline']"] } ``` The selector targets a `data-speakable` attribute rather than a class name, so a redesign cannot silently break it. ## Generate markup from CMS fields so it never drifts The common failure with structured data is not missing markup. It is markup that says something the page no longer says: a `dateModified` nobody updates, an author who has left, an FAQ answer edited in the CMS but not in the JSON-LD. Each of those breaks Google's content guideline, and each is a false statement made to the system you are hoping will quote you. The fix is architectural. Structured data should be a projection of the same fields that render the visible page, so that nothing is typed twice. On this site the guide template builds its JSON-LD from the Storyblok story in one function, with no literals of its own: ```ts import { absoluteUrl, pathForSlug } from "@/lib/site"; import type { GuideStory } from "@/lib/storyblok/types"; export function guideJsonLd(guide: GuideStory) { const c = guide.content; const url = absoluteUrl(pathForSlug(guide.full_slug)); return { "@context": "https://schema.org", "@type": "TechArticle", "@id": `${url}#article`, headline: c.title, description: c.short_answer, datePublished: c.published_at, dateModified: c.updated_at || c.published_at, author: { "@id": absoluteUrl(`${pathForSlug(c.author.full_slug)}#person`) }, citation: c.sources.map((s) => ({ "@type": "CreativeWork", name: s.title, url: s.url, })), speakable: { "@type": "SpeakableSpecification", cssSelector: ["[data-speakable='short-answer']"], }, }; } ``` The component that renders it escapes `<`, so a string value can never close the script element early: ```tsx export function JsonLdScript({ data }: { data: object }) { const json = JSON.stringify(data).replace(/; } ``` Because the same `short_answer` field feeds the visible block, the `description` property and the speakable selector, editing it in the CMS updates all three at once. That is the property to design for: one source of truth, several projections. **Structured data review for an answer page** - [ ] Every value in the JSON-LD is derived from a CMS field, never typed separately - [ ] datePublished and dateModified are ISO 8601 with a timezone, and dateModified changes on every edit - [ ] author is a Person node with @id, url and at least one sameAs - [ ] citation lists the same sources shown on the page - [ ] FAQPage answers are identical to the visible FAQ text - [ ] Glossary terms use DefinedTerm with a stable @id, referenced from about on the pages that use them - [ ] speakable targets a data attribute, not a styling class - [ ] BreadcrumbList is generated from the route - [ ] Output checked in Google's Rich Results Test and the Schema Markup Validator after every template change > **Tip: Where to go next** > > [FAQ content for answer engines](/guides/faq-content-for-answer-engines) covers writing the question–answer pairs that FAQPage describes. [Modelling content for answer engines in a headless CMS](/guides/modeling-content-for-answer-engines-in-a-headless-cms) shows how to design the fields this markup is generated from. ## Frequently asked questions ### Is structured data a ranking factor for AI Overviews? No. Google's documentation for AI features says there is no special schema.org structured data you need to add and no additional requirements beyond those for Google Search. Structured data can make a page's meaning unambiguous — who wrote it, when, what a passage is — but it does not by itself make a page more likely to be cited. ### Should I remove FAQPage markup now that Google's FAQ rich result is gone? No. Google's 2023 announcement said there is no need to proactively remove it, and its May 2026 deprecation notice did not change that. FAQ rich results were limited to government and health sites in August 2023 and stopped appearing altogether on 7 May 2026, so the search appearance is gone for every site. The markup still describes question–answer pairs in a machine-readable form, which is useful independently of rich results, provided the answers match the visible text exactly. ### Which is better for a guide: Article or TechArticle? TechArticle is a schema.org subtype of Article intended for technical and how-to material, so it is the more precise label for documentation and guides. Google's Article documentation lists Article, NewsArticle and BlogPosting as the types it supports for its Article feature. If that search appearance matters to you, emit Article; if precision matters more, emit TechArticle. Both carry the same author, date and citation properties. ### Do ChatGPT, Perplexity or Claude read JSON-LD? Only Google documents how it treats structured data. OpenAI's, Anthropic's and Perplexity's published crawler documentation covers user agents and robots.txt, not markup. Their crawlers fetch the same HTML that contains your JSON-LD, so the data is available to them, but there is no vendor statement that it influences which pages are cited. Treat it as a low-cost clarity layer, not a guaranteed signal. ### Where should the JSON-LD go on the page? Inside a script element with type application/ld+json, in either the head or the body. Google's documentation says it can read JSON-LD in either location, including when it is injected by JavaScript, but server-rendering it is safer for crawlers with small render budgets. Escape the less-than character in the serialised JSON so a string value can never close the script tag early. ## Sources 1. [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) — Google Search Central (2025) 2. [Introduction to structured data markup in Google Search](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) — Google Search Central 3. [Article (Article, NewsArticle, BlogPosting) structured data](https://developers.google.com/search/docs/appearance/structured-data/article) — Google Search Central 4. [Changes to HowTo and FAQ rich results](https://developers.google.com/search/blog/2023/08/howto-faq-changes) — Google Search Central Blog (2023) 5. [Google Search Central documentation changelog (FAQ rich result deprecation, May 2026)](https://developers.google.com/search/updates) — Google Search Central (2026) 6. [Farewell, Sitelinks Search Box](https://developers.google.com/search/blog/2024/10/sitelinks-search-box) — Google Search Central Blog (2024) 7. [General structured data guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) — Google Search Central 8. [DefinedTerm](https://schema.org/DefinedTerm) — Schema.org ## Related guides - [FAQ content that answer engines pick up (and why FAQPage rich results went away)](https://citable.wiki/guides/faq-content-for-answer-engines) - [E-E-A-T for answer engines: authors, dates and sources that machines can verify](https://citable.wiki/guides/eeat-for-answer-engines) - [Modelling content for answer engines in a headless CMS!](https://citable.wiki/guides/modeling-content-for-answer-engines-in-a-headless-cms) - [What is Answer Engine Optimization (AEO)?](https://citable.wiki/guides/what-is-answer-engine-optimization) --- Source: https://citable.wiki/guides/structured-data-for-ai-answers Author: Endrit Krasniqi More: https://citable.wiki/llms.txt