Schema markup for AI search: the types that actually get read

Most advice about structured data is a list of types with the instruction to add as many as apply. That advice produces pages carrying nine declarations, one of which is malformed, and none of which changes what an assistant says about the company.

A better starting question: what does an answer engine have to work out about this page, and which of those things is it currently guessing?

Markup removes inference, not competition

An assistant composing an answer has to establish a handful of facts before it can use a page. Who published it. Whether this Acme is the same Acme it saw on a different site. When the claim was made, and whether it is still true. What the thing is called and what it costs.

In prose, all of that is inferred from context, and inference is where two companies with similar names become one. Markup states it instead. That is the entire mechanism, and it is worth being precise about what it implies: structured data does not make a page worth quoting. A page with perfect markup and nothing to say stays unquoted. What it does is stop a page that is worth quoting from being misattributed, misdated or confused with somebody else.

Which is why “more schema” is the wrong goal, and why the schema checker never scores a page on how many types it declares.

The types that earn their place

Organization — the one that matters most

This is the declaration that binds a name on your site to an entity. Without it, every mention of your company on every page is a string that a machine has to match against other strings.

The field that does the work is sameAs: your LinkedIn, your Crunchbase, your GitHub, your Wikipedia entry if you have one. Each is a thread tying a mention somewhere else back to you. An assistant that can follow those threads is an assistant that knows the Acme in a review and the Acme on your pricing page are the same company.

Put it on your homepage at minimum, and reference it as the publisher of everything else. Where you have a physical presence, LocalBusiness is the more specific version and carries the address.

Article and BlogPosting

Where author and datePublished stop being styling and become facts. An assistant deciding whether to rely on a claim wants to know how old it is; a dateline rendered in a <span> is a string in the middle of a page, and datePublished is an assertion.

Add dateModified and keep it honest. An article that says it was revised last week and was not is a claim that will eventually be checked against the page.

Product and Offer

Name, price, currency, availability. Ask ChatGPT what something costs and it has to find a number on a page and decide whether it is the price, the discount, the annual figure or the per-seat figure. Offer answers that without the guess. If you have a pricing page and no Offer markup, you have left the most frequently asked question about your product to be inferred from a table.

FAQPage

Its role in Google’s rich results has narrowed considerably, and a lot of advice has not caught up. As a way of stating a question and its answer as one linked pair, though, it is still the cleanest shape an answer engine can lift directly — which is a different reason to add it, and one that does not depend on a results feature staying switched on.

Use the questions people actually ask, in their words. A FAQ written to contain keywords is a FAQ nobody asked.

BreadcrumbList

Cheap, and more useful than it looks. Every page in an AI answer is read out of context — pulled out of your navigation and considered alone. Breadcrumbs are how the page’s position in a structure survives that.

WebSite

On the homepage, ties the domain to a name, and carries an internal search action where you have one. One block, once.

Types that are mostly decoration

• HowTo. Retired from Google’s rich results. Not harmful, rarely the best use of an afternoon.
• Review and AggregateRating on your own pages. Heavily policed, and self-serving review markup is the specific abuse the policing was built for. If the reviews are real and visible on the page, mark them up; if they are neither, do not.
• Speakable. Narrow in scope and narrow in support.
• Anything describing a page that does not exist. Markup that does not match the visible content is the one category of mistake with a real downside, because it is the one an engine treats as deliberate.

The mistake that costs the most, and shows the least

Malformed JSON-LD. It is in your source, absent from every consumer, and completely invisible in a browser — the page renders perfectly, because nothing on the page depends on the block being valid.

A trailing comma. A smart quote pasted out of a document. An unescaped quotation mark inside a description. Any one of those and the entire declaration is skipped in silence. This is why broken markup survives on pages for years: there is no symptom, and the only way to find it is to parse the block and look at the error.

Its close cousin is a block with no @context. That is valid JSON and not JSON-LD; without "@context": "https://schema.org" the types in it mean nothing to a consumer, and the block is skipped exactly as if it were broken.

The order to do it in

1. Parse what you already have and fix anything that does not. Broken markup is not neutral; it is work you already paid for and are not receiving.
2. Add Organization with sameAs, on the homepage, and reference it as the publisher everywhere else.
3. Add Article to anything dated, and Product/Offer to anything sold.
4. Add BreadcrumbList site-wide — usually a template change rather than a content one.
5. Add FAQPage where you have real questions and real answers on the page.

Steps one and two are most of the value. The schema checker covers both: it reads the JSON-LD on any page, keeps the blocks that fail to parse instead of discarding them, and only suggests a type when something on the page gives a reason to want it.