Schema.org for AI search: which types actually get read

What schema actually does in an AI pipeline

Schema.org markup is a vocabulary for stating facts in a form a machine can read without interpreting prose. On your page it lives in a JSON-LD script tag. It is not visible, it is not a ranking factor anyone has documented as such, and it will not make a mediocre page citable.

What it does do is remove ambiguity, and ambiguity is the expensive problem in AI retrieval. Two mechanisms are worth understanding, and both are inferred from how these systems behave rather than from published specifications.

Entity confirmation

A model deciding whether to recommend you first has to decide who you are. Your name appears on your site, on a map profile, in two directories and in a press mention. Are those one business or four? Structured data with a stable @id and sameAs links states the connection outright instead of leaving it to be guessed from a matching address.

Consistency

Assistants weigh agreement across independent sources, which is the core argument in how AI assistants choose businesses. Schema gives you one place to state the facts that must match everywhere else. It only helps if the values are genuinely identical to your map profile, your listings and your visible page text. Markup that disagrees with your own site is worse than no markup, because you have manufactured the disagreement yourself.

The corollary matters. Never assert something in JSON-LD that the page does not also say in visible text. Assistants read rendered text reliably; whether a given one parses your markup is not something you can verify from outside. Schema should be a second statement of the truth, never the only one.

The types worth implementing for most businesses

Most sites need seven types and nothing else. The list below is ordered roughly by return on effort for an ordinary business.

Here is a generic starting graph. It is deliberately plain, and the values are placeholders: replace every one of them, and delete any node whose facts you cannot state truthfully.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Company",
      "url": "https://example.com",
      "logo": "https://example.com/logo.png",
      "email": "hello@example.com",
      "description": "One sentence saying exactly what you do, for whom, and where.",
      "sameAs": [
        "https://www.linkedin.com/company/example",
        "https://www.google.com/maps/place/?q=place_id:EXAMPLE"
      ]
    },
    {
      "@type": "ProfessionalService",
      "@id": "https://example.com/#local",
      "name": "Example Company",
      "parentOrganization": { "@id": "https://example.com/#org" },
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "1 Example Street",
        "addressLocality": "Dubai",
        "addressCountry": "AE"
      },
      "telephone": "+971500000000",
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Saturday"],
          "opens": "09:00",
          "closes": "17:00"
        }
      ]
    }
  ]
}

Three habits make this hold up over time. Use one JSON-LD script per page containing a single @graph, rather than five scattered scripts that can drift apart. Give the nodes stable @id values so other nodes reference them instead of repeating their contents. And keep dateModified honest: set it when the page genuinely changed, show the same date visibly under the heading, and resist the temptation to stamp today on everything. Fake freshness is easy to detect and it degrades the one signal you were trying to send.

The types that are usually wasted effort

Plenty of markup gets added because a plugin offers it. Some of it costs maintenance and returns nothing.

• Speakable. Tied to a narrow voice-assistant use case that never became broadly available. Almost nobody should spend time on it.
• Review and AggregateRating on your own pages. Self-serving ratings you control are weak evidence and Google restricts self-serving review markup for many entity types. Independent reviews on independent platforms are what actually move the assessment.
• WebPage on every page, filled out exhaustively. Largely redundant with information already available from the page itself. A thin WebPage node is harmless, an elaborate one is maintenance you will not do.
• FAQPage stuffed with marketing. Questions nobody asks, answered with a pitch, is markup as decoration. If the question is not one a customer would type, leave it out.
• Over-specific types that do not fit. Choosing an exotic subtype because it sounds more precise, when your business is not really that thing, introduces exactly the ambiguity you were trying to remove.
• Markup for content that is not on the page.Against Google's structured data policies, and it invites a contradiction between what you claim and what a crawler reads.

Does schema markup help with AI Overviews?

Probably a little, indirectly, and not enough to treat as a strategy. Here is the honest breakdown of what is known and what is not.

What is documented: Google states that structured data helps its systems understand the content of a page, and it is the required input for many rich results. AI Overviews are generated over pages that Google has already crawled, indexed and deemed relevant, so anything that improves understanding and eligibility sits upstream of the feature.

What is not documented: no vendor has published that schema markup is an input to whether a page is selected for or cited in an AI Overview. Google has been explicit that there is no special markup that gets you included. OpenAI, Anthropic and Perplexity say little about parsing structured data at all.

What we observe: pages that carry clean, consistent markup also tend to be the pages with clear headings, direct answers and honest dates. Untangling those factors from outside is not possible, and anyone claiming a measured uplift from markup alone is describing a test that is very hard to run cleanly. The reasonable position is to implement the seven types above because they are cheap and they make your facts unambiguous, then expect the content itself to do the work.

How to appear in Google AI Overviews

There is no submission form, no opt-in, and no guarantee. What exists is a set of levers that are genuinely upstream of the feature, listed here in the order we would work through them.

1. Be indexable and actually ranking.AI Overviews draw on Google's ordinary index. If a page is not indexed, or does not rank anywhere for the query, it is not a candidate. Conventional technical and content quality work still gates this channel, which is the point made in GEO vs SEO.
2. Make your content answer-shaped. Use the question as the heading, in the phrasing a person would type. Answer it in the first two sentences beneath, in plain language, before any context or caveats. Extractable passages are the unit of selection here, not whole pages.
3. Keep facts in server-rendered text. Prices in images, menus in PDFs and content assembled by JavaScript are all routes to being fetched and yielding nothing usable.
4. Use tables and lists for comparisons. Structured passages are lifted more readily than the same information buried in a paragraph.
5. Earn independent corroboration. Third-party sources that describe you the same way you describe yourself are the strongest available evidence, and you cannot substitute markup for them.
6. Add the schema. Last, not first. It confirms what the page already says.
7. Measure repeatedly. AI Overviews appear for some queries and not others, and the set changes. Sample the same frozen questions over weeks and track an appearance rate, using the approach in the fan-out queries guide.

One caution about expectations. Appearing in an AI Overview does not necessarily send the traffic the equivalent ranking used to. The value is being named as the answer, which is a brand and consideration outcome as much as a click one, and it should be measured accordingly.

For the wider frame, read what generative engine optimization is. For the technical prerequisites, the GEO checklist and the AI crawler robots.txt guide come first, because markup on a page no crawler can fetch is worth nothing. A plain-text summary of your site for assistants is a separate machine surface, covered in llms.txt. How we work is described on services.