Schema markup for AI search: what earns its keep in 2026
Siddhant AryanLead Designer · AI AutomationListen to this article
The short answer
Structured data does not make you rank or get cited. It makes you unambiguous — which matters because generative systems are conservative about stating facts they cannot corroborate. Six types earn their keep for most businesses: Organization (with `sameAs`), LocalBusiness for anyone with a physical or service area, Service, Article with a real `author`, FAQPage, and BreadcrumbList. Implement them as JSON-LD, nest them into one connected graph with `@id` references rather than shipping five disconnected blocks, and make sure every claim in the markup is also visible on the page. The errors that actually cost you are contradictions between your markup and your profiles, not missing properties.
On this page
The most common structured-data conversation I have starts with a client showing me a validator screenshot full of green ticks and asking why nothing happened. Valid markup that says nothing useful is the norm. It passes every test and still leaves a machine unable to answer 'who are these people, where do they operate, and can I repeat what they claim?' — which is the only question schema exists to settle. This is what I implement, why, and the mistakes I keep removing.
What schema is for (and isn't)
Structured data is a machine-readable restatement of what your page already says. It does not add authority, it does not improve rankings directly, and no amount of it rescues a page with nothing to say. What it does is let a system resolve you to a specific entity with specific attributes, confidently enough to repeat those attributes in an answer.
That is why the highest-value markup is usually the least exciting: your name, your address, your phone number, your profiles, who wrote this article and what their credentials are. Not clever nesting — facts, stated once, consistently.
The test that matters
Could a system read only your JSON-LD and correctly answer: who is this, where do they operate, what do they sell, who wrote this, and where else can that be verified? If not, add facts before adding types.
The six types that earn their keep
You can markup almost anything. Most businesses need six things done properly, and adding a seventh rarely changes anything.
| Type | Where | What it settles |
|---|---|---|
| Organization | Sitewide | Who you are, your logo, and — via sameAs — where you are verifiable |
| LocalBusiness | Home + location pages | Address, phone, hours, service area, geo |
| Service | Each service page | What you offer, to whom, in which area |
| Article / BlogPosting | Every post | Author, dates, language, word count, what it is about |
| FAQPage | Pages with real Q&As | Question-and-answer pairs a system can extract directly |
| BreadcrumbList | Every nested page | Where this page sits in your site's structure |
sameAs is the underrated one
Linking your Organization to your verified LinkedIn, Google Business Profile and other real profiles is the single cheapest entity-clarity win. It turns a name into something checkable.
Nest it into one graph, not five islands
The pattern I see most often is five separate `<script type="application/ld+json">` blocks that never reference each other: an Organization here, an Article there, a BreadcrumbList that mentions nobody. Technically valid, and it forces a consumer to guess that the Article's publisher is the Organization on the same page.
Use `@graph` with `@id` references so the relationships are explicit: the Article's `publisher` points at the Organization's `@id`, the `author` points at a Person node, the LocalBusiness is `parentOrganization` of nothing or something specific. It is the same information with the joins stated, which is exactly what a machine needs.
How to structure it
- 1One JSON-LD block per page, using `@graph` to hold multiple nodes.
- 2Stable `@id` values — a canonical URL plus a fragment, e.g. `https://site.com/#organization`.
- 3Reference, don't repeat. The Article's publisher is `{"@id": "…/#organization"}`, not a second copy of the Organization.
- 4Name a real author as a Person node with a URL to their profile page, and use `sameAs` for their external profiles.
- 5Keep `dateModified` honest — a date that updates on every deploy while the content sits unchanged is noise, and eventually discounted.
The mistakes that actually cost you
In order of how often I find them: markup that contradicts the page (an FAQPage listing questions that appear nowhere on it), a phone number or address in schema that differs from the Google Business Profile, `dateModified` auto-bumping on deploys, review markup a business generated about itself, and LocalBusiness on every page of a site that has one location and no local relevance on most of those pages.
All five share a shape: the markup is making a claim the rest of the web does not support. That is worse than no markup, because an inconsistency is a reason for a cautious system to prefer a competitor it can verify.
Fix these before adding anything new
- Markup that isn't on the page. Every FAQ, price and rating in JSON-LD must be visible to a human reader.
- NAP drift. Name, address and phone must match your Google Business Profile character for character.
- Fake freshness. `dateModified` should change when the content changes, not when the site rebuilds.
- Self-serving review markup. Ratings you created about yourself are a policy problem, not a rich-result shortcut.
- Type spam. Five types where two would do makes the page harder to interpret, not more authoritative.
Does FAQPage markup still do anything?
For rich results in Google, FAQ snippets were heavily curtailed — so if your only reason for the markup was a bigger listing, that reason has largely gone. For AI answers, the picture is different: a clean question-and-answer pair is the most extractable unit of content there is, and a system looking for a passage that answers a specific question finds one pre-labelled.
So keep it, but keep it honest: real questions people ask, answered completely in the text, marked up because they exist — not questions invented to justify the markup.
Q&A pairs
The most extractable content unit for AI answers — which is why FAQ blocks still matter even where FAQ rich results were reduced.
How to verify without fooling yourself
Validators tell you your syntax is legal, not that your markup is useful. Run one, fix the errors, then do the harder check by hand: read your JSON-LD as a stranger would and ask whether it answers who, where, what, who-wrote-it and where-to-verify. Then open your Google Business Profile and your LinkedIn page side by side and confirm the facts match exactly.
Do that once per quarter and you will be ahead of nearly every competitor, most of whom implemented schema once at launch and have not looked at it since the phone number changed.
A quarterly 30-minute audit
- 1Validate the home page, one service page and one article. Fix errors, ignore cosmetic warnings.
- 2Read the graph as prose. Can you state the business's identity from it alone?
- 3Cross-check NAP against Google Business Profile and your main directory listings.
- 4Spot-check dates on three articles — do they reflect real edits?
- 5Confirm sameAs links still resolve and still belong to you.
Key takeaways
- Schema removes ambiguity rather than adding authority — its job is to let a system state facts about you confidently enough to repeat them.
- Six types cover most businesses: Organization with sameAs, LocalBusiness, Service, Article with a real author, FAQPage and BreadcrumbList — nested in one @graph with @id references.
- The expensive errors are contradictions: markup that isn't on the page, NAP that differs from your Google Business Profile, and dateModified that fakes freshness.
Frequently asked questions
Does schema markup help with AI search and AI Overviews?
Indirectly, by removing ambiguity. Structured data lets a system identify you as a specific entity with specific attributes — name, location, services, author, verifiable profiles — which makes it safer for that system to repeat those facts in an answer. It is hygiene rather than a lever: it will not rescue a page that has no clear answer in it.
Which schema types should a small business implement first?
Organization sitewide with sameAs links to your verified profiles, LocalBusiness on your home and location pages with address, phone, hours and service area, and Service on each service page. Add Article with a named author on blog content, FAQPage where you have genuine Q&As, and BreadcrumbList on nested pages.
Is FAQPage schema still worth adding in 2026?
Yes, but for a different reason than before. Google heavily reduced FAQ rich results, so it is no longer a way to get a bigger search listing. It remains valuable because a labelled question-and-answer pair is the most extractable content unit for AI answers — as long as the questions are real and answered fully in the visible page text.
Should I use JSON-LD or microdata?
JSON-LD. It is Google's stated preference, it keeps structured data out of your markup so designers and developers do not break it accidentally, and it lets you express relationships cleanly with @graph and @id references. Microdata still parses, but there is no reason to choose it for new work.
Can incorrect schema hurt my site?
Contradictory schema can. Markup claiming things the page does not show, an address or phone number that differs from your Google Business Profile, self-created review ratings, or dateModified that bumps on every deploy all give a cautious system a reason to trust a competitor it can verify instead. Missing properties are a lost opportunity; contradictions are an active liability.
Tools & next steps
Put this into practice, go deeper, or see how we'd do it for you.
Written by
Mr. Siddhant Aryan
Lead Designer & AI Automation, Global Info Edge
Lead designer and AI-automation specialist at Global Info Edge with 5 years building fast, conversion-focused websites and the workflows that run behind them.
View full profile