Structured data for AI answers: the schema.org types that matter

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.

Article and TechArticle: provenance a machine can check

The guide 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.

{
  "@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.

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.

{
  "@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:

{
  "@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.

{
  "@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.

{
  "@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 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:

"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:

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:

export function JsonLdScript({ data }: { data: object }) {
  const json = JSON.stringify(data).replace(/</g, "\\u003c");
  return <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: json }} />;
}

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.