Structured Data for AI Answers: Which Schema Types Actually Matter

Structured data has a credibility problem in GEO discussions. One camp presents it as the secret unlock for AI citations. The other points out, correctly, that large language models read prose perfectly well and do not need JSON-LD to understand a sentence.

Both are wrong in the same way. Markup is not a ranking trick and it is not redundant. It is disambiguation. It answers questions the prose leaves open: which organisation is this, is this the same company as the one on that other domain, when was this written, who is responsible for it, and is this claim the page's own or something it is quoting.

The types worth your time

Organization, once, done properly

This is the highest-value markup on most sites and the most commonly botched. One Organization node, given a stable @id, with name, legalName, url, logo, a postal address, and sameAs pointing at every profile that unambiguously belongs to you: LinkedIn, Crunchbase, GitHub, the company register entry.

The sameAs array is doing the real work. It is how an engine resolves "Acme" the brand on your site to "Acme Ltd" the entity it has seen described elsewhere. An empty sameAs is a missed opportunity, and it is the field teams most often leave as a placeholder.

Article, with the boring fields filled in

headline, datePublished, dateModified, author as a real Person or Organization node, and publisher pointing at your Organization @id. Retrieval systems are cautious about undated material. Giving a machine an unambiguous date and a named author is the cheapest trust signal available.

FAQPage, for genuinely asked questions

Google retired FAQ rich results for most sites in 2023, and a lot of teams ripped the markup out in response. That was a reasonable reaction to the wrong question. The snippet is gone; the machine-readable question-and-answer pairing is not, and it is precisely the shape a generative engine wants: a question, and a self-contained answer that does not depend on the paragraph before it.

The value moved from the SERP to the answer. The markup did not change.

Two rules. The questions must be ones people actually ask, not keyword strings wearing a question mark. And the answer text in the markup must match the answer visible on the page.

HowTo, for real procedures

Ordered steps with names and text. Useful whenever the honest answer to a query is a sequence, and worth skipping when it is not. Do not wrap a feature list in HowTo because it is a step-shaped format.

Product and Offer, if you sell something

name, description, offers with a real price and priceCurrency, and aggregate ratings only if they come from genuine reviews you can evidence. Fabricated review markup is the fastest route to a manual penalty and, increasingly, to being distrusted as a source.

BreadcrumbList

Cheap, and it communicates site structure in a form that survives being read out of context.

Use one graph, not a pile of scripts

The single biggest quality improvement most sites can make is moving from several disconnected JSON-LD blocks to one @graph with stable @id values that reference each other:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example" },
    { "@type": "WebSite", "@id": "https://example.com/#website",
      "publisher": { "@id": "https://example.com/#organization" } },
    { "@type": "Article", "@id": "https://example.com/post#article",
      "publisher": { "@id": "https://example.com/#organization" },
      "isPartOf": { "@id": "https://example.com/#website" } }
  ]
}

Disconnected nodes describe three unrelated things that happen to share a page. A graph describes one entity with parts, which is what you actually have.

Four ways to waste the effort

• Markup that contradicts the page. An Offer saying 19 EUR on a page showing 29 EUR does not just fail to help. It marks you as an unreliable source.
• Injecting JSON-LD with client-side JavaScript. Googlebot will usually see it. The AI crawlers often will not. Put it in the served HTML.
• Marking up everything. Fifteen types on a contact page is noise. Mark up what the page actually is.
• Writing it once and never revisiting it. Prices change, authors leave, addresses move. Stale markup is worse than none because it is confidently wrong.

How to check it

Validate with Google's Rich Results Test and the Schema.org validator, then do the check neither performs: fetch the page as a non-JavaScript client and confirm the markup is present in the raw HTML. If it is not in the bytes, it does not exist for most of the crawlers you care about.

Markup will not make an engine recommend you. It removes every excuse for an engine to be unsure who you are, which is the part you control.