Schema Markup for AI Search — Which Types Actually Matter

Schema markup does not earn you an AI citation, but it lowers the cost of quoting you — and when an engine is choosing between sources that say the same thing, the one it can parse unambiguously has an advantage. Five types do nearly all the useful work: Organization, Article/BlogPosting, FAQPage, BreadcrumbList and SoftwareApplication or Product.

Everything else is optional. This is what each one does for answer engines specifically, with markup you can adapt.

Why the purpose changed

In classic SEO, structured data bought a visual upgrade in the results page: star ratings, recipe cards, FAQ accordions. It was a trade — you describe your content precisely, Google gives you more space.

Google has since withdrawn most of those features for most sites. FAQ rich results were largely removed in 2023, and a lot of teams stripped their FAQ schema out in response. For SERP features, that was rational.

For AEO it was the wrong move, because the job changed rather than disappeared. An answer engine parsing your page has to decide where a question ends and its answer begins, who wrote the claim, and what entity the page is about. Schema states all three explicitly instead of making the model infer them. Inference is where you lose to a source that did not require any.

The five that matter

1. Organization — entity resolution

The most underrated, especially for a brand that is not yet well known.

Answer engines resolve names to entities. If "Acme" could be your company, a competitor or a cartoon brand, the engine cannot confidently attribute anything to you. Organization with a stable @id and sameAs links gives it corroboration to anchor to.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme",
  "alternateName": ["Acme Inc", "Acme.com"],
  "url": "https://example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png"
  },
  "description": "One sentence stating what the company does.",
  "foundingDate": "2024",
  "knowsAbout": ["Topic one", "Topic two"],
  "sameAs": [
    "https://www.linkedin.com/company/acme/",
    "https://x.com/acme",
    "https://en.wikipedia.org/wiki/Acme"
  ]
}

Three details do most of the work:

• @id — a stable identifier every other node on the site can reference, so author, article and product nodes all point at the same organisation rather than repeating a name string.
• sameAs — corroborating profiles. An entity claim with no external references is just an assertion. This is the single most valuable field for a new brand.
• alternateName — catches the spellings people actually use, which matters when your name is easily confused with another.

If your brand name gets autocorrected to a different company in search, this node plus consistent off-site profiles is the on-site half of the fix. The other half is off-site and slower.

2. Article / BlogPosting — attribution

Establishes who made a claim and when, which is what makes it safe to repeat.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/post#article",
  "headline": "The exact H1 of the page",
  "description": "The same text as the meta description.",
  "url": "https://example.com/blog/post",
  "datePublished": "2026-09-24",
  "dateModified": "2026-09-24",
  "author": {
    "@type": "Person",
    "name": "Real Human Name",
    "url": "https://example.com/about"
  },
  "publisher": { "@id": "https://example.com/#organization" },
  "wordCount": 1800,
  "inLanguage": "en"
}

The author must be a Person with a URL that resolves to a real page about that person. "author": "Editorial Team" carries close to nothing — it names no one and points nowhere.

Keep dateModified truthful. Bumping it on every deploy without changing the content is a freshness signal you are inventing, and it degrades the value of the field.

3. FAQPage — pre-chunked citable units

The highest-value type for extraction, precisely because it removes all ambiguity about passage boundaries.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the question, phrased as a user would ask it?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A complete answer in 40 to 90 words that makes sense with no surrounding context."
      }
    }
  ]
}

The rule that matters: the schema must match visible page content exactly. Markup describing questions a reader cannot see is spam, and it is one of the few structured-data violations that reliably gets acted on.

The robust way to guarantee this is to generate the schema from the rendered content rather than maintaining it separately. OPSYRA's article template parses the page's own FAQ section — each H3 becomes a question, the prose beneath it becomes the answer — so the two physically cannot drift apart. Hand-maintained duplicates drift within a couple of edits.

4. BreadcrumbList — structural context

Cheap, and it tells an engine where a page sits in your information architecture, which helps it judge topical relevance.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "This Post", "item": "https://example.com/blog/post" }
  ]
}

Pair it with a visible breadcrumb. Schema that mirrors something on the page is always stronger than schema that exists only in the markup.

5. SoftwareApplication or Product — the thing you sell

For commercial queries, this states what your product is, what category it belongs to and what it costs — facts an engine otherwise has to scrape from prose.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Acme",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "description": "What it does, in one sentence.",
  "featureList": ["Feature one", "Feature two"],
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "49",
    "availability": "https://schema.org/InStock"
  }
}

If you mark up a price, keep it current. Stale pricing in schema is worse than no pricing, because an engine may repeat it to a prospect.

Use one @graph, not five script tags

Scattering separate JSON-LD blocks across a page means nothing references anything else, and you end up repeating the publisher in every node. A single @graph with @id cross-references is cleaner and expresses the relationships:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Acme" },
    { "@type": "WebSite", "@id": "https://example.com/#website",
      "publisher": { "@id": "https://example.com/#organization" } },
    { "@type": "BlogPosting", "@id": "https://example.com/blog/post#article",
      "publisher": { "@id": "https://example.com/#organization" } }
  ]
}

Now "who published this article" is an explicit edge rather than a matching exercise on name strings.

Five mistakes that waste the effort

1. Schema that does not match visible content. The one that gets penalised. Generate from content where you can.
2. JSON-LD injected by client-side JavaScript. AI crawlers do not run JavaScript, so schema added at runtime does not exist for them. It must be in the served HTML.
3. Anonymous authors. "author": "Admin" satisfies a validator and signals nothing.
4. Invented dateModified. Freshness you did not earn.
5. Unescaped < in string values. A </script> inside any field terminates the block and silently invalidates everything. Escape it as <.

How to verify

• Google Rich Results Test — validates and shows what Google parses.
• Schema Markup Validator — broader, not restricted to Google's supported types.
• View source, not devtools. Devtools shows the DOM after JavaScript. curl shows what a crawler receives. If your schema only appears in the first, it is not there.

curl -s https://yoursite.com/page | grep -c 'application/ld+json'

Zero means no crawler sees your structured data, whatever the browser shows. OPSYRA runs this check across every page of a site and generates the missing JSON-LD for the ones that need it.

FAQ

Does schema markup help with AI Overviews?

It helps indirectly rather than acting as a ranking factor. Structured data gives answer engines unambiguous boundaries for questions, answers, authorship and entity identity, which makes a page cheaper and safer to quote. It does not cause a citation, but among comparable sources the one that can be parsed without inference has an advantage.

Which schema type is most important for AEO?

Organization is the most important for a brand that is not yet well established, because it anchors entity resolution through a stable @id and sameAs links. For individual content pages, FAQPage does the most work, since it hands the engine pre-separated question and answer pairs that need no chunking.

Can I add schema with JavaScript?

Not for AI search. GPTBot, PerplexityBot and ClaudeBot do not execute JavaScript, so structured data injected at runtime is invisible to them. Googlebot does render JavaScript and may pick it up on a second pass, but schema should be present in the initial HTML response to be reliable.

Does FAQ schema still work now that rich results were removed?

The SERP feature is largely gone for most sites, but the markup still serves a purpose for answer engines by explicitly delimiting question and answer pairs. Removing FAQPage schema because the rich result disappeared optimises for a surface that no longer exists while giving up an extraction advantage that does.

How much schema is too much?

Mark up what is genuinely on the page and stop there. The five types covering your organisation, articles, FAQs, breadcrumbs and product cover nearly all useful cases. Adding types that do not describe actual page content adds no benefit and risks a mismatch between markup and visible content, which is treated as spam.