The types that earn their place, the identifier that holds them together, and the jobs schema will never do for you.
Schema markup for AI search is structured data that tells a machine what a page is and who published it. It resolves your identity. It does not make your content quotable.
Schema markup is the part of AEO that is genuinely technical, genuinely cheap and almost universally misread. It is not a ranking lever, it will not get a sentence quoted, and no amount of it compensates for a page with nothing worth lifting. What it does is narrower and more valuable than the claims made for it: it removes the guesswork from the question of who published this, so that an assistant willing to name a source has a source it can identify.
Schema markup is a block of JSON-LD sitting inside a <script type="application/ld+json"> tag in your HTML, using the shared vocabulary published at schema.org. A machine reads it directly. It does not have to infer from your prose that the company behind the page is called Acme, that Acme is a software company, or that the person in the byline is a real person with a public professional record. You have said so, in a form with no ambiguity in it.
That matters because an assistant naming a source is making an attribution decision, and attribution needs a subject. Prose gives a model a probabilistic guess at who you are. Structured data gives it a statement. When the two agree, the model has corroboration from the publisher itself. When they disagree, you have manufactured a reason for it to hedge.
There is a second job, less discussed. Schema disambiguates the page as well as the publisher. A page can plausibly be read as an article, a product listing, a help document or a landing page, and those readings imply different things about how reliable its claims are. Declaring the type settles it, which is worth doing even where no search feature depends on the declaration.
There are hundreds of types in the vocabulary. For a B2B company, seven do almost all of the useful work, and adding more beyond these is usually busywork rather than progress.
| Type | What it establishes | Where it belongs |
|---|---|---|
Organization | Who you are, what you do, where else you exist | Every page, as one shared node |
Person | That your author or founder is a real, locatable individual | About and author pages, referenced from articles |
Article | That a page is editorial, by a named author, published on a date | Guides, blog posts, anything with a byline |
Product | What you sell, and on what terms | Product and pricing pages |
FAQPage | That a block of the page is a question-and-answer structure | Pages with real, visible Q&A on them |
BreadcrumbList | Where a page sits in the structure of the site | Every page below the top level |
HowTo | That a page describes a procedure with ordered steps | Genuine step-by-step instructions only |
The ordering is deliberate. Organization is the one that changes outcomes, because identity is the thing assistants are most cautious about. Person is next, because a named human with a resolvable public record is the strongest corroboration available on your own domain. BreadcrumbList is trivial to add and quietly useful, because it tells a machine the shape of the site rather than the shape of one page. The rest are situational: mark them up when the page genuinely is that thing, and leave them out when it is not.
Short, specific, and identical everywhere it appears. The description is the sentence you would want an assistant to repeat about you, because it is very often the sentence that gets repeated.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Acme Analytics",
"url": "https://example.com/",
"description": "Acme Analytics is a product analytics platform for B2B SaaS teams.",
"disambiguatingDescription": "Not related to Acme Corp, the logistics company.",
"logo": "https://example.com/logo.png",
"sameAs": [
"https://www.linkedin.com/company/acme-analytics",
"https://github.com/acme-analytics",
"https://www.crunchbase.com/organization/acme-analytics"
],
"founder": { "@id": "https://example.com/#founder" }
}Notice what is absent. No marketing adjectives, because an adjective is not a fact and a model has nothing to do with it. No awards it cannot verify. No claim that is not also visible on the page. The founder field references a Person node by identifier rather than restating it, which is the pattern the whole graph is built on.
The @id is the name of the thing, as distinct from the page it happens to be described on. It is what allows a block on your pricing page and a block on your blog post to be understood as descriptions of the same organisation rather than two organisations that resemble one another.
Content management systems break this constantly. A plugin generates an @id from the current page URL, so every page emits an organisation whose identifier is unique to that page. Forty pages produce forty organisations. Each one has the right name and the right logo, and not one of them is corroborated by any other, because nothing in the data says they are the same entity.
The fix is to choose one URI you control and never change it. A fragment on your own domain is the conventional choice — https://example.com/#organization — because it is readable, permanent and obviously yours. What it must not be is a value generated at build time, derived from the page, or regenerated when the CMS is upgraded.
Never mark up what is not on the page. Schema describing FAQs that no visitor can see, review ratings you have not collected, prices you do not charge or an author who did not write the piece is not an optimisation; it is a false statement in machine-readable form, and it is the single fastest way to make every other claim on your site less trustworthy. If it is not visible and true on the page, it does not belong in the JSON-LD.
Because consistency is the mechanism. A model deciding whether to assert that Acme Analytics is a product analytics platform is weighing how often that statement appears, how consistently it is phrased, and whether the sources agree. Forty pages saying the same thing about the same identifier is evidence. Forty pages saying slightly different things about forty identifiers is noise, and noise is resolved by hedging or by naming someone else.
In practice, one identity across the site means three habits. Emit the full Organization node once and reference it by @id elsewhere rather than re-describing it. Make every Article author a reference to a real Person node, not a bare string. And keep the description string byte-identical between your schema, your footer, your llms.txt and your third-party profiles — a point covered in full in the guide to entity SEO.
This is the section most schema advice omits, and it is the one that prevents wasted quarters.
It does not make your content quotable. A page can carry immaculate structured data and still contain nothing an assistant would repeat, because every sentence on it is hedged, comparative or dependent on the paragraph above. Extraction is a writing problem, and it is solved in the prose, not the markup. What makes a sentence liftable →
It does not grant access. If a retrieval agent is refused at your CDN, your schema is never read at all, because nothing ever fetched the page. Access is gate one and schema is gate three. Which crawlers matter, and how to test them →
It does not guarantee a Google rich result, and the ground moves. Google’s own documentation records that the FAQ rich result stopped appearing in Google Search on 7 May 2026, and the documentation page for FAQPage was removed the following month. Marking up genuine visible Q&A is still reasonable — it describes a structure that other consumers can read — but it is no longer a route to a Google search feature, and anyone selling it as one is working from an outdated brief.
It does not guarantee a citation. Assistant output is non-deterministic. Ask the same question twice and the sources named can differ. Schema improves the odds that when a model does decide to attribute something, it attributes it to you correctly. It cannot make that decision happen.
Two tools answer two different questions, and confusing them is why people believe their markup is fine when it is not.
validator.schema.org. This checks your JSON-LD against the schema.org vocabulary itself: are the types real, are the properties valid on those types, is the syntax well formed. It is the correctness test.sameAs URL by hand. A link to a deleted profile, a placeholder account with no posts or a redirect chain is worse than no link, because it is a corroboration claim that fails when checked.@id across three different pages. Homepage, a product page, a blog post. If the three values differ, you have found your largest problem.Ranked by how often they turn out to be the live problem rather than a cosmetic one:
@id regenerated per page. Silent, invisible in every validator, and it costs you the entire benefit of having schema at all."author": "Jane Smith" asserts a name and nothing else. A Person node with a stable @id and working sameAs links asserts a person.In this order, because each step is small and each one makes the next worth doing:
Organization block your site currently emits. Delete all but one.@id and reference it from every page.Person node for your founder with sameAs links that resolve today.That is a day of work and it closes the identity gate. The remaining gates — access, extractable answers, corroboration and measurement — are covered in order in the practical AEO guide, and the individual checks are listed in the 24-point checklist. If you would rather have someone else find the conflicting blocks, the free AI visibility check reports what your markup actually says and where it contradicts itself.
Schema markup does not work like a ranking factor. It resolves who published a page, which affects whether an assistant is confident enough to attribute a claim to you by name. That is an attribution effect rather than a position effect, and it cannot be measured as a rank.
Organization, with a stable @id and a description you would be happy to hear quoted. It is the only type that addresses identity, and identity is what assistants hesitate over. Person for your founder is the sensible second step.
Only where the page genuinely contains visible questions and answers. Google’s documentation records that the FAQ rich result stopped appearing in Google Search on 7 May 2026, so it is no longer a route to a Google search feature. As a description of a real Q&A structure it remains honest markup.
A plugin will usually produce valid markup and frequently produces the wrong identity — most commonly an @id derived from the page URL, so every page describes a different organisation. Generate it however you like, then check the @id is identical across three pages.
JSON-LD is the practical choice. It sits in its own script tag, it is separate from your presentational HTML, and it survives template changes that break inline microdata. Microdata and RDFa are valid but harder to keep correct over time.
Not on its own, and nobody can promise a citation — assistant output is non-deterministic and the same question can return different sources on different runs. Schema makes you identifiable; a self-contained, specific sentence on an accessible page is what actually gets lifted.