Schema markup for AI search: the four things that actually matter

Most structured-data guidance is written for Google's rich results: stars, recipe cards, event listings. That's a different job from being understood by an AI assistant, and it optimises for a different subset of schema.org.

For AI answers, the question an engine is trying to settle is narrower and more basic: what is this, and is it the same thing as that other mention I've seen?

Four things answer it. Everything else is downstream.

1. Organization: does the entity exist at all

Without an Organization node, an engine has to infer your company's existence from prose. That usually works for well-known brands and often fails for everyone else.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Inventory",
  "url": "https://acme.com",
  "logo": "https://acme.com/logo.png",
  "description": "Inventory software for independent hardware stores."
}

Use your legal or consistently-used name, not a tagline. "Acme Inventory", not "Acme | Inventory Software for Modern Retail".

2. sameAs: is this the same company as that one

This is the one most sites skip and the one that does the most work.

sameAs is a list of URLs pointing at your other profiles. It's what tells an engine that your website, your LinkedIn page, your GitHub org and your Crunchbase entry are one entity rather than four weakly-attested ones.

{
  "@type": "Organization",
  "name": "Acme Inventory",
  "sameAs": [
    "https://www.linkedin.com/company/acme-inventory/",
    "https://www.crunchbase.com/organization/acme-inventory",
    "https://github.com/acme-inventory",
    "https://x.com/acmeinventory"
  ]
}

Why it matters more than it looks: an engine's confidence in naming you is related to how much it knows about you. If mentions of your company are scattered across sources it can't connect, you look like several barely-known companies instead of one reasonably-known one. sameAs consolidates them.

One rule: only list profiles you actually control. A sameAs pointing at something that isn't yours is a false identity claim in machine-readable form, and it's the kind of thing that gets a site distrusted rather than merely ignored.

The strongest entries are ones where the link runs both ways, with a profile that lists your domain back. That mutual agreement is what actually consolidates an entity, rather than you asserting it one-directionally.

3. A product entity: is there something to recommend

Recommendation questions are about products and services. An organisation with nothing attached to it is difficult to return as an answer to "what's the best X."

Use Product, Service or SoftwareApplication depending on what you sell, and include an offers block:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Acme Inventory",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": {
    "@type": "Offer",
    "price": "40",
    "priceCurrency": "USD"
  }
}

Stating a price is worth doing. "How much does X cost" is one of the highest-intent questions asked of assistants, and a machine-readable answer is more likely to be repeated accurately than one buried in a pricing table image.

4. FAQPage: give it a passage to quote

Assistants quote passages, not pages. An explicit question-and-answer pair is the easiest possible passage to lift.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Does Acme work with multiple locations?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Yes. Stock levels sync across locations in real time, and each location keeps its own reorder thresholds."
    }
  }]
}

Write the answers to stand alone. If the text only makes sense with the rest of your page around it, it's not quotable, and quotable is the whole point.

The failure mode worth knowing about

Invalid JSON-LD is worse than none.

Not because engines penalise it. As far as anyone can tell, they don't. It's worse because of what it does to you. A block that fails to parse is completely invisible: the engine sees nothing, you get nothing, and meanwhile you believe your structured data is working, so the missing markup never gets fixed.

A single trailing comma does it. So does a template that renders an unescaped quote into a description field. If you check nothing else, check that your JSON-LD parses.

Where this stops

Everything above makes you legible. It tells an engine what you are, that you're one entity, that you sell a specific thing, and gives it text it can quote.

None of it makes you worth recommending. An engine that can identify you perfectly will still name a competitor if that's what its sources say. Structured data is a precondition: it removes a reason to leave you out. It doesn't supply a reason to put you in. That comes from what third-party sources say about you, which is a slower and much harder problem.

Any tool that shows you a green checklist and implies the checklist is the outcome is selling you the easy half.

You can check any page against these four with our structured data checker. It reports what's present, what's missing, and the specific markup to add, and it counts unparseable blocks separately for the reason above.