Schema markup won't make AI cite you. Wrong schema can make it doubt you.

Every GEO checklist has a line that says "add schema." It's usually the most concrete item on the list, which is why it gets done first and trusted most. Somebody installs a plugin, a validator turns green, and the box is ticked.

Months later the brand still isn't in the answers, and nobody can say whether the markup did anything. That's the normal outcome when schema is treated as a ranking lever. It isn't one. It's closer to a notarised copy of what your page says: useful when it matches, worthless when nobody reads it, and harmful when it disagrees with the original.

What schema markup is, in one paragraph

Schema markup is structured data written in the schema.org vocabulary, a shared dictionary of types (Organization, Service, Article, FAQPage) and the properties each type can carry. On most sites it lives in a <script type="application/ld+json"> block in the page head, in a format called JSON-LD. Visitors never see it. Machines read it to learn, without guessing, what a page is about and what the thing it describes actually is.

The words "without guessing" matter most in that definition. Prose has to be interpreted. Markup mostly doesn't. Everything schema does for AI visibility follows from that, and so do all of its limits.

The myth: markup in, citation out

The pitch goes like this: AI engines love structured data, so add more of it and you'll get cited more. Three facts undercut it.

• The search platforms don't describe it as a switch. Google's guidance for its AI features says you don't need any special markup to appear in them, and that structured data should match what's visible on the page. Microsoft's Bing team has said publicly that schema helps its models understand content. Understanding is a real benefit, but it isn't a promise of being chosen.
• Rich results and AI citations are different things. Much of the "schema works" evidence comes from rich results: stars, FAQ dropdowns, how-to steps in classic search. Google cut FAQ rich results back to a narrow set of authoritative government and health sites in 2023 and retired how-to rich results the same year. Plenty of sites kept the markup and lost the display, and neither change says anything about whether an AI answer quotes you.
• Not every pipeline reads it. When an assistant fetches a page live to answer a question, many retrieval setups reduce the page to its visible text first, and script blocks don't survive that. The search indexes behind many engines do parse structured data. The model writing the answer may never see your JSON-LD at all. It sees whatever your page says in words.

The three jobs schema actually does

Drop the myth and there's still a strong case for structured data. It does three jobs well, and all three are about removing doubt:

Notice what's not on that list: persuasion. Schema can't make you sound more authoritative or more relevant than you are. Its job is to make sure what you actually are gets read correctly.

Three ways schema goes wrong, and why validators miss them

Here's the part checklists skip. Bad markup doesn't just fail to help. It can work against you, because the one job structured data has is to be trustworthy, and wrong markup is untrustworthy in a form built to be taken at face value.

1. It contradicts the page. The markup says one price and the pricing table says another. The address block is from before the move. The Organization description is from two rebrands ago. A plugin set it once and nobody has looked since. An engine now has two versions of the same fact from the same source, which is worse than having one.
2. It's valid JSON with the wrong vocabulary. Every schema.org property belongs to specific types. Put a property on a type that doesn't define it (opening hours on a plain Organization instead of a local-business type, say) and the block still parses and still looks fine. Consumers that follow the vocabulary just ignore it. The fact you meant to state never gets stated.
3. It claims what you can't back. Profile links to accounts you don't own, ratings the page doesn't show, services you no longer offer. Search platforms have long treated markup that isn't reflected in visible content as a quality problem, and self-serving review markup is the classic example. For identity, the damage is worse: link your entity to the wrong profile and you've told engines that someone else's record is yours.

Most of the free tools people rely on stop at syntax, which is why this sticks around. Here's the gap:

Which markup is worth having

The instinct after reading the schema.org type list is to add everything that applies. Resist it. More types means more surface to fall out of date, and none of them is worth anything if it's wrong. Useful markup comes in three layers:

• One identity block, in one home. A single, complete description of your organisation: the name you actually use, what you are, and the profiles that are verifiably yours. It should be defined once and referenced everywhere else. Don't restate it slightly differently on every page, because five near-identical organisations are exactly the ambiguity you were trying to remove.
• The thing you sell. Your services or products, and the facts buyers ask assistants about: what it is, who it's for, where it's offered, what it costs if you publish that. These are the facts engines paraphrase, so these are the ones most worth stating twice.
• The page itself. What kind of page this is, what it's about, when it last changed, and, when the page genuinely has them, the questions it answers. Page-level markup is where most drift happens, so it's where "matches the visible content" matters most.

We don't publish the exact property set we build, or how we decide which profiles count as verifiably yours. That's the part a look-alike generator would copy and fill with guesses, and a confident guess in markup is how brands end up linked to the wrong company. The principle holds without it: state less, but only what you can prove. Every property should be something you'd defend if a buyer read it aloud.

How to tell if it's working

This is the uncomfortable truth about structured data: you can't watch it work directly. No engine reports "we used your JSON-LD." What you can observe is the outcome it's meant to produce, which is engines identifying you correctly and stating your facts accurately. That's what to measure.

So the real test isn't whether your markup validates. It's four questions, and the last one has to be asked of more than one engine:

1. Does it describe what's on the page? Every fact in the markup should appear in the visible content, with the same value.
2. Is the vocabulary right? Every property should sit on a type that defines it, or it's decoration.
3. Is the identity unambiguous? One organisation, described once, linked only to profiles you can prove are yours.
4. Do engines get the facts right? Ask them. If an assistant still quotes last year's price, the markup isn't winning, whatever the validator says.

The first three are checks on your site. The fourth is a check on the world, and it's the only one that tells you anything changed. Keep unknown separate from clean, too: an engine that didn't answer hasn't confirmed your facts. It hasn't told you anything.

Markup is a promise about your page. Engines reward the promise only when the page keeps it.

That loop is what AI Access runs. It scans your pages the way an AI crawler does, flags markup that's missing, mistyped, or out of step with the page, and builds a corrected identity block from facts you've verified rather than facts a model guessed. Hallucination Watch then asks the engines whether they're getting you right, which is the check a validator can't do.