Which schema types actually matter for AI search?

Fewer than most checklists suggest. One Organization node with a stable identifier, a WebSite node, Article or WebPage per document, BreadcrumbList, and FAQPage where you genuinely have questions and answers on the page. Adding exotic types does less than connecting the basic ones properly.

Our markup validates but nothing changed. why?

Validation only proves the syntax parses. The two things that matter beyond that are connection and agreement: whether your nodes reference one another through identifiers instead of floating separately, and whether the markup says the same thing the visible page says. Disconnected or contradictory markup validates perfectly and still gets discounted.

Should sameAs point at profiles we are about to create?

No. Point it at profiles that exist today and add the rest as they go live. An empty sameAs is honest and harmless; one pointing at 404s is a broken claim about your own identity, which is the opposite of what the property is for.

Schema and JSON-LD for AI search

Structured data for AI search is not a list of types to add to a page. It is one graph describing one company, and almost all of its value comes from the connections between nodes rather than from their number. 94% of the sites in our dataset had no JSON-LD at all, so most of the opportunity is still in the basics.

three rules that cover most of it

one organisation, referenced everywhere

Describe your company once, give that node a stable identifier, and have every other node point at it rather than re-describing the company. The most common failure we find is not missing markup but disconnected markup: an Organization on the homepage and a separate publisher block on the blog, unlinked, describing the same company in slightly different words. To a parser that is two weak entities instead of one strong one.

external references that exist

sameAs is where you point at the profiles that confirm you are real. It only works if the URLs resolve. Empty is fine while you are building them; pointing at pages that do not exist is a broken claim about your own identity.

agreement with the visible page

Whatever the markup says, the page must say too. Ratings without reviews on the page, FAQ answers that differ from the visible text, prices that contradict the pricing section — each of these is a reason for structured data to be ignored wholesale. We have found contradictions like these on sites whose SEO reports were clean, because validators check syntax rather than truth.

what to build, in order

a minimal graph that does real work
node	what it carries	why it matters
Organization	Name, alternate names, URL, email, founding year, description, sameAs, founder	The entity everything else attaches to
WebSite	URL, name, publisher pointing at the organisation	Ties the pages into one site-level entity
Article / WebPage	Headline, description, dates, image, author, mainEntityOfPage	Makes a document quotable and attributable
FAQPage	Questions and answers matching the visible text exactly	The format models lift most readily
BreadcrumbList	Position of the page in the site	Cheap structural context

the type trap

Choosing a type that implies something untrue costs you. A service business with no physical location marked up as a local business implies an address that does not exist; the honest choice is a plain Organization. We changed our own markup for exactly this reason. Pick the type that describes what you are, not the one with the most properties.

how to check it properly

Validate the syntax — necessary, not sufficient.
Print every node and confirm each one references the organisation identifier rather than repeating it.
Diff the markup text against the visible text, especially FAQ answers.
Open every sameAs URL and confirm it returns 200.
Ask an engine to describe your company and check every fact it states against your own markup.

The wider technical layer is on technical GEO, and the terms used here are defined in the glossary.

schema and JSON-LD for AI search