Schema Markup for AI Search in 2026: What Helps, What's a Myth

Do you need special schema.org markup to appear in AI answers?

No. Google states that no special schema.org structured data is needed to appear in AI Overviews or AI Mode, and no other provider documents a rule saying otherwise.

A consultant pitches you an “AI schema pack”: an FAQ block on every page, JSON-LD “optimized for ChatGPT”. Google’s page on AI features says the opposite: “There’s also no special schema.org structured data that you need to add.” (AI features and your website). Since May 2026, Google’s generative AI optimization guide even files the topic under its myths:

In plain terms: structured data is not required for generative search, and there is no special markup to add. It stays useful for your SEO in general, because it makes you eligible for rich results. In the best practices listed on the AI features page, only one line is about markup: make sure your structured data matches the visible text on the page.

So markup isn’t dead. It just does something other than what you’re being sold: it describes, without ambiguity, who you are and what each page contains. The GEO guide puts this point alongside the other AI visibility myths.

What do OpenAI, Microsoft and Perplexity document about structured data?

Almost nothing that concerns citations: OpenAI documents a product feed in its own format, Microsoft recommends schema.org in a guide for merchants, and Perplexity and Anthropic publish nothing on the subject.

OpenAI. For shopping, OpenAI describes the Agentic Commerce Protocol, a standard that “enables ChatGPT to ingest structured catalog data”. The product feed has its own format, with a section for Google-compatible feeds; it is not schema.org. For the rest of the web, the documented requirement is to allow OAI-SearchBot: a site that blocks it does not appear in ChatGPT search answers. The setup is covered in the robots.txt and AI crawlers guide.

Microsoft. The guide From Discovery to Influence, published on January 6, 2026 by the Microsoft Advertising team, advises merchants: “Deploy Product, Offer, AggregateRating, Review, Brand, ItemList, and FAQ schema types” and “Maintain consistent values across feed, on-site schema, and user-facing displays” (PDF, page 12). It is an ecommerce recommendation, addressed to merchants by the advertising team. It does not explain how Copilot uses this markup and puts no number on any effect.

The research. The founding GEO paper (Aggarwal et al., 2023) tests nine methods for rewriting text: adding statistics, quotations, sources, a more fluent style… None of them involves markup. Claims like “schema increases citations by X%” come from tool vendors, not from a verifiable source.

Are FAQ and HowTo schema still worth anything?

Not for display in Google: the HowTo rich result disappeared in 2023 and the FAQ rich result has not been shown since May 7, 2026. The markup is still valid, but it no longer produces anything visible on the results page.

The timeline, based on Google’s announcements:

1. August 8, 2023. FAQ rich results are limited to “well-known, authoritative government and health websites”, and HowTo to desktop only (Search Central blog). On September 13, 2023, HowTo disappears from desktop too.
2. January 23, 2025. Breadcrumbs are no longer shown on mobile; they remain on desktop and BreadcrumbList markup is still supported (Search Central blog).
3. June 12, 2025. Google announces the retirement of several little-used types (Course info, Estimated salary, Vehicle listing…), noting: “This update won’t affect how pages are ranked.” (Search Central blog).
4. May 8, 2026. Removal notice for the FAQ rich result: “This feature will no longer appear in Google Search starting May 7, 2026.” (documentation updates).
5. June 15, 2026. Google removes the FAQ documentation, because the result “is no longer shown in Google Search results”.

Should you remove your FAQPage blocks? Not necessarily. Google already made the point in 2023: unused markup “does not cause problems for Search, but also has no visible effects in Google Search”. The type still exists in the schema.org vocabulary, and the Microsoft Advertising guide still recommends it. What matters is the basic rule: the markup describes questions and answers that are visible on the page. Assistants cite text; a real, well-written Q&A section is useful to them, with or without markup. Microsoft advises merchants to add “Q&A blocks AI can reason over and cite” (page 13 of the same guide), but no provider puts a number on how this format affects citations. Padding a page with made-up questions to fill a FAQPage block gets you nothing, and it is exactly what the guide on writing with AI without a Google penalty describes: content made for robots.

Which schema.org types are still useful in 2026?

Five types cover the essentials for a small business website: Organization (or LocalBusiness), Article, Product, BreadcrumbList, and FAQPage only where the page genuinely answers questions.

The wording in the third column comes from the Search Central pages for Organization, Local business, Article, Product and Breadcrumb. For merchants, Google writes that providing both structured data and a Merchant Center feed “maximizes your eligibility to experiences”. The AI features page also asks you to keep Merchant Center and Business Profile up to date: for a business, those listings matter as much as the JSON-LD.

To choose the type for a page, start from what the page is, not from what you hope to get:

flowchart TD
  A[Which page?] --> B{Homepage?}
  B -- Yes --> C{Physical address?}
  C -- Yes --> D[LocalBusiness]
  C -- No --> E[Organization]
  B -- No --> F{Can it be bought?}
  F -- Yes --> G[Product + Offer]
  F -- No --> H{Dated article?}
  H -- Yes --> I[Article or BlogPosting]
  H -- No --> J[BreadcrumbList only]
  I --> K{Visible questions?}
  K -- Yes --> L[Add FAQPage]
  K -- No --> M[Nothing more]

The schema markup glossary entry covers the basics if the topic is new to you.

Why does Organization markup help identify your brand?

Because it states in one place, in a machine-readable format, who you are, which site is your official one and which profiles belong to you. Google writes that it helps it “disambiguate your organization in search results”.

The problem is common: three companies share your name, or your brand is also a dictionary word. The Organization block on your homepage answers the question “which company is this?”. The key property is sameAs, which schema.org defines as the “URL of a reference Web page that unambiguously indicates the item’s identity” (schema.org/sameAs): your LinkedIn page, your Wikidata entry if one exists, your official profiles.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Atelier Lumen",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "description": "Wooden light fixtures made in Lyon, sold online to consumers and architects.",
  "foundingDate": "2019",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Lyon",
    "addressCountry": "FR"
  },
  "sameAs": [
    "https://www.linkedin.com/company/atelier-lumen",
    "https://www.instagram.com/atelierlumen"
  ]
}

What to look at in this example:

• @id gives the organization a stable identifier. The site’s other blocks (articles, products) point to it instead of repeating the name.
• description reuses the sentence from your homepage, not a keyword-stuffed version. If the visible text says something else, the markup is lying.
• sameAs lists only profiles that belong to you and link back to your site. A link to a namesake’s profile does the opposite of what you want.
• Google states that no property is required for Organization and recommends adding every one that applies.
• Google also recommends the most specific subtype: for an online store like this one, OnlineStore rather than Organization, and a subtype of LocalBusiness for a brick-and-mortar business.

The block does not build brand awareness: if no third-party site talks about you, an assistant has little to cite. The guide why ChatGPT recommends your competitor shows how to diagnose that case.

How do you mark up an article without errors?

With an Article or BlogPosting block that exactly matches the title, author and dates shown on the page, linked to your Organization through its @id, plus a BreadcrumbList that follows the visible breadcrumb.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "headline": "How to choose a pendant light for a low ceiling",
      "image": "https://www.example.com/blog/suspension-plafond-bas.jpg",
      "datePublished": "2026-09-14",
      "dateModified": "2026-10-02",
      "author": {
        "@type": "Person",
        "name": "Claire Martin",
        "url": "https://www.example.com/equipe/claire-martin/"
      },
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog/" },
        { "@type": "ListItem", "position": 2, "name": "Pendant light for a low ceiling" }
      ]
    }
  ]
}

The points that matter:

1. @graph groups several entities in a single <script type="application/ld+json"> tag. A page can also carry several separate tags.
2. dateModified changes only when the content actually changes. A refreshed date with no edit displays false information.
3. author points to a real author page. That fits what Google expects from trustworthy content (see E-E-A-T).
4. The last breadcrumb item can omit item: it is the current page.

Google recommends JSON-LD “if your site’s setup allows it”, because it is the easiest format to implement and maintain (introduction to structured data). On WordPress, Wix or Shopify, the same page advises going through the CMS settings or a plugin. In that case, check what the plugin already outputs before adding a block by hand: two conflicting Organization blocks on the same page muddy the message.

To draft the block from your own page, this prompt avoids the main pitfall, invention:

Here is the visible text of my homepage and the URLs of my official profiles. Write a schema.org JSON-LD block of type Organization (or LocalBusiness if a physical retail address appears in the text). Rules: use only information present in the text provided; do not invent any date, address or review; reuse the description exactly as written; add an @id in the form https://yourdomain/#organization; list in sameAs only the URLs I give you. End with the list of properties you could not fill in for lack of information.

Page text:
[paste the text]

Official profiles:
[paste the URLs]

What is the rule that matters most?

Markup must describe what the visitor sees on the page, nothing more and nothing less. Google repeats it both in its general guidelines and on its AI features page.

In other words: no Q&A that exists only in the JSON-LD, no reviews that appear nowhere, no price different from the one displayed. The general guidelines spell out the penalty: a manual action makes the page lose its eligibility for rich results, with no effect on its ranking in web search. They also point out that correct markup does not guarantee a rich result will be shown.

Microsoft says the same thing on the commerce side: identical values across the feed, the markup and what the shopper sees. An assistant that compares your markup, your page and your merchant listing and finds three different prices has no reason to trust any of them.

How do you check your markup?

By checking three things: the right types are present on key pages, they are technically valid, and they match the visible text.

Google’s Rich Results Test tells you whether a type is valid for a rich result that is still shown. It says nothing about your visibility in assistants, which depends first on crawler access, indexing and content. If you work with Claude or Cursor, the MCP and SEO guide shows how to run these checks from your assistant.

Two limits to know: the audit reads JSON-LD, not Microdata or RDFa, and only in the HTML returned by the server, without running JavaScript. Valid markup in those formats, or markup injected by a script, will not show up; one more reason to follow Google’s recommendation and switch to JSON-LD.