The five schema types that actually move AI citations

Structured data has an image problem. A decade of rich-snippet chasing turned it into a checkbox exercise: add the markup, hope for stars in the results page, move on. That framing is why so many teams have schema on every page and no benefit from any of it.

For answer engines, structured data does something more specific. It removes ambiguity. A model reading your page has to infer what kind of thing you are, what you sell, what it costs and whether you are the same organisation mentioned on three other sites. JSON-LD answers those questions directly instead of making the model guess, and guessing is where you lose citations to competitors who were clearer.

Structured data is not a ranking lever. It is a disambiguation tool. Five types carry almost all the weight.

1. Organization — the one nobody does properly

This is the foundation, and it is the type most often either missing or filled in badly. Organization markup tells a model your legal name, your canonical URL, what you do in one sentence, and — critically — the sameAs links that connect your site to your other profiles across the web.

The sameAs array is the part that matters most and gets left empty most often. It is how a model confirms that the company on your homepage, the company in a directory listing, and the company mentioned in a trade publication are one entity rather than three similarly named ones. Without it, every mention of you elsewhere on the web contributes less than it should.

{
  "@type": "Organization",
  "name": "Your legal trading name",
  "url": "https://yoursite.com",
  "description": "One sentence, no marketing",
  "sameAs": [ "LinkedIn", "Crunchbase", "Companies House", ... ]
}

One rule: the description field should read like a directory entry, not a tagline. "Screaming Engine measures how AI search engines see and cite brands" is useful. "Visibility, reimagined" is not.

2. FAQPage — the highest ratio of effort to return

FAQ markup pairs a question with a self-contained answer, which is almost exactly the unit an answer engine wants to retrieve. Of everything on this list it is the cheapest to add and the most likely to produce a visible change.

The caveat is that the markup must match visible content on the page. Marking up questions that don't appear on screen is both a policy violation and, more practically, a reason for a model to trust the rest of your markup less. Write the FAQ for humans, then mark up what you wrote.

Use the questions buyers actually ask. A FAQ full of "What is X?" definitions is a missed opportunity; a FAQ that answers "how long does this take", "what happens if we go over the limit" and "does this replace what we already use" is a set of pre-written passages waiting to be quoted.

3. Product or Service, with real offers

If you sell something with a price, that price belongs in structured data. Models are frequently asked comparative, budget-shaped questions, and a product whose pricing is machine-readable is far easier to include in an answer than one whose pricing sits behind a "contact us".

Include currency, billing period and what the price covers. If you have tiers, mark up each one. If pricing genuinely is custom, say so explicitly in the description rather than leaving the field out — an absent price reads as missing data, a stated "custom, based on volume" reads as a fact.

4. Article, with a real author

For anything editorial, Article markup carries the signals that separate a considered piece from generated filler: who wrote it, when it was published, when it was last updated, and which organisation stands behind it.

The author field should point at a real person with a real profile page, and that profile page should itself be marked up as a Person with sameAs links. This is the least glamorous work on the list and one of the more reliable ways to look like a source rather than a content farm.

Keep dateModified honest. Bumping it without changing anything is a well-worn trick, it is detectable, and the downside if it is noticed outweighs the upside if it isn't.

5. BreadcrumbList — small, cheap, structural

Breadcrumbs tell a model where a page sits in your site's hierarchy, which helps it understand what the page is about and how it relates to everything around it. This matters most on large sites where a URL alone gives no clue.

It takes an hour to implement across a templated site and it is the closest thing to free on this list.

What to stop doing

Three habits are worth dropping. First, marking up everything: WebPage, WebSite, SiteNavigationElement and the rest add volume without adding information a model didn't already have. Second, self-serving Review and AggregateRating markup on your own site — it is heavily discounted and occasionally penalised. Third, HowTo markup on things that are not procedures, which has become a reflex on pages that are really just explanations.

More markup is not better markup. Five accurate types beat fifteen approximate ones, and an invalid block is worse than no block at all — malformed JSON-LD is frequently discarded wholesale, taking the correct parts with it.

The order to ship them in

Organization first, sitewide, with a properly populated sameAs. Then FAQPage on your highest-intent pages — pricing, product, the pages sales sends people to. Then Product or Service with real offer data. Then Article across the blog. Breadcrumbs whenever the templating work is convenient.

Validate everything before it goes live, then leave it for a month. Schema changes need a re-crawl before they can affect anything, and a fortnight of watching the number is a fortnight wasted.