Schema for AI Search: 7 Essential Types to Add First

Structured data has been sold as an SEO trick for a decade, which has made it hard to talk about honestly. The AI search era has not changed what it does — it has changed why it is worth doing. Schema for AI search is not a ranking lever; it is how a machine confirms that the “Dotance” on your contact page is the same entity as the one on your WordPress.org profile. Here are the seven types worth your time, the four to skip, and how to check what you are really publishing.

What schema for AI search actually does

Assistants read your HTML first, not your markup. They can extract most facts from well-written prose without any markup at all, which is why “add schema and get cited” is not true.

What structured data does is settle ambiguity:

Every row is a question a machine has to answer with or without your help. Schema for AI search means answering them explicitly rather than hoping the inference lands correctly.

Seven types of schema for AI search worth adding

1 and 2. Organization and WebSite

If you do one piece of schema for AI search, do this one. Most sites publish an Organization block with a name and a logo and stop, which leaves out the field that does the actual work.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example-studio",
    "https://profiles.wordpress.org/examplestudio/",
    "https://github.com/examplestudio"
  ]
}
</script>

That sameAs array is the part that matters for schema for AI search. It is the explicit statement that these scattered profiles are one entity, which is exactly the problem an assistant has when deciding whether the company in its index is the company on this page.

List profiles that genuinely exist and that you control. Three real ones beat twelve aspirational ones, and a link to a profile you abandoned in 2019 is worse than no link at all.

3 and 4. BlogPosting and Person

Article markup is the schema for AI search most SEO plugins already emit. Two fields are worth checking because they are frequently wrong: dateModified, which should reflect a real update rather than a plugin touching the row, and author, which should be a Person object rather than a bare string.

"author": {
  "@type": "Person",
  "name": "Aqib Raza",
  "url": "https://example.com/author/aqib/",
  "sameAs": [ "https://www.linkedin.com/in/example/" ]
}

A named person with a profile that can be checked is a different signal from a string. This is the least glamorous part of schema for AI search and one of the more useful, because “who says so” is a question assistants weigh heavily when deciding whether to repeat a claim.

5, 6 and 7. Breadcrumbs, products and local

These three are the situational ones. Breadcrumbs are cheap, nearly every SEO plugin emits them, and they still appear in results. Nothing to decide here — just confirm yours are present.

Product markup earns its place on any shop, with one condition: the availability value must be true. A product marked InStock that is not is both a policy problem and a customer-service one, which is part of the wider argument in handling out of stock products.

LocalBusiness matters if you have a physical address or a defined service area, and the requirement is consistency: the name, address and phone number in your markup must match your Google Business Profile and your contact page exactly. Three slightly different versions of your address is a genuine entity problem, and no amount of schema for AI search fixes it while they disagree.

Four types of schema for AI search to skip

The first two rows matter more than they look, because a great deal of published advice predates those changes and still tells you FAQ markup will win you a bigger search result. It will not, for the overwhelming majority of sites. Writing a genuine FAQ section because readers have those questions is good; restructuring a page to hit a markup format that no longer produces a rich result is wasted effort.

Verifying the schema for AI search you actually publish

Plugins claim a great deal of schema for AI search and emit less. Check the page itself rather than the settings screen:

# Which structured data blocks are on this page?
curl -s https://example.com/ | grep -o 'application/ld+json' | wc -l

# And what is in them?
curl -s https://example.com/ | sed -n '/application\/ld+json/,/\/script/p' | head -60

The duplicate-emitter row is common on sites that have had two SEO plugins over the years. Contradictory blocks are worse than one imperfect block, because you are now asserting two versions of the same facts — the same class of problem as duplicate content, at the data layer.

Google’s own testing tool remains the fastest way to see how a search engine parses what you publish; the full list of supported types is in the structured data search gallery, which is also where you confirm whether a type still produces a rich result before investing in it.

What to expect from it

Being honest about schema for AI search outcomes is more useful than a list of types, so here is the realistic version.

Row three is the whole case for schema for AI search, and it is a modest, real benefit rather than a dramatic one. Being correctly identified is not exciting, and it is the difference between an assistant recommending you by name and describing “a WordPress agency” it cannot quite place.

If you want the parts that actually drive citations, they are content-side and covered in getting cited by AI search. Markup supports that work; it does not substitute for it — the same conclusion we reached about llms.txt, for the same reason.

One graph beats five blocks

How you structure it matters almost as much as which types you use, and this is where hand-rolled schema for AI search usually falls down.

Five separate JSON-LD blocks on a page are five unrelated assertions. A single @graph with @id references is one connected description, where the article knows which organisation published it and which person wrote it.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Studio",
      "sameAs": [ "https://www.linkedin.com/company/example-studio" ]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/post/#article",
      "headline": "A specific, honest title",
      "datePublished": "2026-09-30",
      "dateModified": "2026-09-30",
      "publisher": { "@id": "https://example.com/#org" },
      "author": { "@id": "https://example.com/author/aqib/#person" }
    }
  ]
}

Those @id references are the difference between a pile of facts and a structure. Good SEO plugins already produce this shape; if yours emits several disconnected blocks instead, that is worth knowing before you add anything by hand on top of it.

It also explains why adding a second schema plugin makes things worse rather than better. Two graphs cannot reference each other, so you end up asserting two unconnected organisations with the same name on the same page — which is precisely the ambiguity schema for AI search is supposed to remove.

The entity problem, in plain terms

All of this schema for AI search advice makes more sense once you know what an assistant is actually trying to do, because it makes the priorities above obvious rather than arbitrary.

When somebody asks an assistant to recommend a WordPress agency, it is not searching for a phrase. It is working with entities — things it believes exist, with properties and relationships. Your site is evidence about one of those entities. Every consistent signal strengthens the link between the entity and you; every inconsistent one weakens it.

That table is the actual work of schema for AI search, and only two of its five rows are markup. The rest is consistency across places you already control, which is unglamorous and costs nothing but attention.

It is also why the sameAs advice keeps returning. A profile on a platform relevant to your field — a developer directory, a professional body, a repository — that links back to you and is linked from you is a far stronger identity signal than any amount of markup describing yourself to yourself. The strategic version of this argument is in GEO versus SEO.

Where this goes wrong

The last row is quietly important. An optimisation plugin that minifies or defers aggressively can strip JSON-LD from the output entirely, and nothing in your admin will mention it. The only way to know is to look at the page a crawler receives — which is the same discipline the rest of our technical SEO checklist asks for.

The order to do it in

Schema for AI search is a two-hour job done in the right sequence and a week done in the wrong one.

Steps one and two are most of the schema for AI search value and take under an hour together. If you stop there you will have done more for your entity recognition than the average site does in a year of schema for AI search advice, because almost everybody publishes an Organization block and almost nobody fills in the field that links it to anything.

Frequently asked questions

Does schema for AI search improve my rankings?

No. Schema for AI search is not a ranking factor and never has been. It affects how results are displayed and how confidently a machine can identify what your page describes, which are different things that are worth having anyway.

How long does schema for AI search take to set up?

An hour or two on a normal site, because most of it already exists and you are correcting rather than creating. A shop with product markup to verify against real stock takes longer, and that part is worth the extra time.

Do I need a plugin for this?

Your SEO plugin almost certainly emits most of it already. The work is checking and correcting what it emits, not adding another plugin — and a second schema plugin is likely to create the duplicate-emitter problem above.

Is JSON-LD better than microdata?

Yes, for practical purposes. It sits in one block rather than being woven through your markup, which means a theme change does not silently destroy it. Every major consumer supports it.

How many sameAs entries should I have?

As many as you genuinely control, which for most businesses is three to six. LinkedIn, a relevant professional profile, and whichever platform you actually publish on. Quantity adds nothing.

Should I mark up my testimonials?

Not as AggregateRating you issue yourself. Reviews collected and displayed by a third-party platform can be marked up according to that platform’s guidance; quotes you typed into your own page cannot.

Will assistants definitely read it?

Nobody publishes a guarantee that they read schema for AI search. The difference from a proposal like llms.txt is that JSON-LD is a long-established standard already consumed by search engines, so you are adding to infrastructure that demonstrably works rather than betting on a convention that might.

How do I know whether it made a difference?

Through entity signals rather than a direct metric — no dashboard reports it — branded impressions, whether an assistant names you correctly when asked about your niche, and assistant referral sessions over a quarter. The measurement setup is in tracking AI search traffic.