Structured data that AI systems actually use
Which schema types are worth implementing for AI search visibility, how to keep markup compliant with search guidelines and which types are commonly oversold.
Structured data is machine-readable annotation describing what a page is about. For AI visibility it does something slightly different from what it does for rich results: it reduces ambiguity about your entity so a system has firmer ground for asserting something specific about you.
This lesson covers what is worth implementing and what is oversold.
Prerequisite: What GEO actually involves.
The one rule that governs everything
Structured data must describe content that is visible on the page.
Marking up claims, prices, ratings or FAQs that a visitor cannot see is a spam-policy violation in Google’s documentation and it is the fastest way to lose rich result eligibility entirely. It is also pointless for AI visibility, a system that retrieves your page and finds the markup contradicts the text has learned you are unreliable, not authoritative.
Use JSON-LD in a <script type="application/ld+json"> block. It is the format
Google recommends and the easiest to maintain, because it does not entangle
markup with layout.
Worth implementing, in priority order
1. Organization
The highest-value type for AI visibility, because it is where your entity is
defined. Include name, alternateName for genuine spelling variants, url,
logo, description, areaServed, contactPoint and sameAs.
sameAs should list profiles you actually control, your LinkedIn company page,
your verified social accounts, relevant directory listings. It is how a system
connects the scattered mentions of you into one entity. Listing profiles you do
not own is worse than listing none.
Keep the description identical to how you describe yourself elsewhere.
Consistency is the point.
2. WebSite
Small but useful. Links your pages to the organisation via @id, which is the
structure that signals a coherent site rather than a collection of pages.
3. BreadcrumbList
Communicates where a page sits in your hierarchy. Cheap to implement, helps systems understand site structure and produces breadcrumb display in results. Make it mirror your visible breadcrumb exactly.
4. Article / BlogPosting
For editorial content. headline, datePublished, dateModified, author and
publisher. Dates matter more than people realise, recency is a plausible
input to retrieval and undated content is harder to trust.
Only use author with a real, identifiable person or a named editorial entity.
Inventing an author persona is a credibility risk, not a ranking tactic.
5. Service
Where you genuinely offer a defined service. Include name, description,
provider linked by @id to your Organization, serviceType and areaServed.
Do not use Offer with a price unless the price is genuinely published and
current on that page.
Use with care
FAQPage
Still valid markup but Google substantially restricted FAQ rich results, they now show for a narrow set of authoritative sites rather than broadly.
Implement it where the page genuinely is a set of questions and answers, because the structure is still a clear signal of what the content contains. Do not implement it expecting rich results and do not restructure a page into an FAQ purely to deploy it.
VideoObject
Worth it when you have a real video but it needs name, description,
thumbnailUrl, uploadDate and ideally duration and contentUrl. Incomplete
VideoObject markup does nothing. If you cannot supply a genuine thumbnail and
upload date, leave it out.
Person
Only where a real author profile exists with a genuine bio. This is a strong credibility signal when true and a liability when fabricated.
Commonly oversold
Review and AggregateRating on your own site. Self-serving review markup is tightly restricted in Google’s guidelines and inventing ratings is deceptive advertising independent of any search consequence. Do not.
Marking up everything. There is no bonus for schema volume. Five accurate, maintained types beat twenty generated ones that drift out of sync with the page.
llms.txt. Not structured data and not an adopted standard. No major
platform has committed to reading it. Publish if you want; do not count it as
implementation.
Validating your work
Two tools, both free:
- Google’s Rich Results Test, tells you whether Google can parse the markup and what rich results it is eligible for.
- Schema.org validator, stricter about schema correctness generally and catches type errors the Google tool ignores.
Validate after every template change. Structured data breaks silently, nothing on the page looks wrong when the markup stops parsing.
A realistic expectation
Structured data does not make you rank and it does not make a model cite you. It removes ambiguity about who you are, which makes it easier for a system to say something specific and correct about you.
That is a real benefit and a modest one. Treat it as hygiene, not as leverage.