Schema Markup for AI Search: The 2026 JSON-LD Playbook
How to use schema markup for AI search so ChatGPT, Perplexity, and Google AI Overviews can actually parse, trust, and cite your pages.
Who this is for: developers, marketers, and business owners who already have a website and want AI answer engines (ChatGPT, Perplexity, Gemini, Google AI Overviews) to correctly extract who they are, what they sell, and what they're an authority on. Not for people who haven't shipped a page yet — ship first, then come back here.
Schema markup for AI search isn't a ranking trick anymore. It's the structured data layer that large language models and their retrieval pipelines lean on to disambiguate entities, verify facts, and decide who to cite. I've added JSON-LD to about 40 client sites in the last two years, and the ones with clean Organization, Article, and FAQPage markup show up in AI Overviews and Perplexity citations at a noticeably higher rate than visually similar competitors without it. This guide covers exactly which schema types matter in 2026, how entities and sameAs work, and JSON-LD patterns that actually get parsed instead of silently ignored.
Why schema markup matters more for AI search than for classic SEO
Classic Google SEO used schema mostly for rich results — star ratings, breadcrumbs, recipe cards. If your markup was wrong, you lost a visual enhancement but still ranked on content quality.
AI search is different because most answer engines don't re-crawl and re-render your whole page for every query. They work from a pre-built index of extracted entities and facts, refreshed on their own schedule (see google-ai-overviews-kidum for how Google's version of this pipeline behaves). Schema markup is the cheapest, highest-confidence signal you can hand that extraction layer. A FAQPage block with a clean question-answer pair is far more likely to get lifted verbatim into an AI Overview or a ChatGPT answer than the same content buried in a paragraph, because the model doesn't have to infer structure — you already gave it structure.
There's a second reason: entity disambiguation. If your business name is generic ("Apex Consulting", "Bright Solutions"), an LLM pulling facts from the open web has no reliable way to know which "Apex Consulting" a scraped sentence refers to. Organization schema with a sameAs array pointing to your verified social profiles and Wikidata/Crunchbase entry is what lets a knowledge graph pin the facts to the right node. Get this wrong and your content gets attributed to nobody, or worse, to a competitor with a similar name.
Reality check: schema markup does not guarantee a citation. It removes ambiguity and increases the odds you're eligible to be cited. The content still has to be accurate, current, and genuinely answer the query — see geo-answer-engine-optimization for the content side of this equation.
The four schema types that actually matter in 2026
Schema.org has over 800 types. You need roughly four, applied correctly, plus one or two situational ones.
1. Organization (or LocalBusiness)
This is your entity anchor. Every page on your domain should ideally reference the same Organization node (via @id), not redeclare a fresh one per page — fragmentation is one of the most common mistakes I see.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://nisai.dev/#organization",
"name": "NisAi",
"url": "https://nisai.dev",
"logo": "https://nisai.dev/logo.png",
"sameAs": [
"https://www.facebook.com/nisai.dev",
"https://wa.me/972585802298"
],
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+972-58-580-2298",
"contactType": "customer service",
"areaServed": "IL",
"availableLanguage": ["he", "en"]
}
}
If you're a physical or local-service business, use LocalBusiness (or a more specific subtype like ProfessionalService) instead — it adds address, geo, and openingHoursSpecification, which matter a lot for local AI answers. See local-seo-google-business-israel for how this interacts with Google Business Profile.
2. Article / BlogPosting
For every guide or blog post, wrap it in Article (or BlogPosting) with author, datePublished, dateModified, and a publisher that references your Organization @id. dateModified is underrated — several site owners I've worked with saw AI Overview citations shift toward their pages after they started actually updating dateModified when they refreshed content, rather than leaving it frozen at the original publish date.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Schema Markup for AI Search: The 2026 JSON-LD Playbook",
"datePublished": "2026-07-14",
"dateModified": "2026-07-14",
"author": { "@type": "Person", "name": "Noam Nissan" },
"publisher": { "@id": "https://nisai.dev/#organization" },
"mainEntityOfPage": "https://nisai.dev/guides/schema-markup-for-ai-search"
}
3. FAQPage
This is the single highest-leverage type for AI search specifically, because the question-answer format is exactly the shape LLMs are trained to extract and reuse. Google still shows FAQ rich results only for government/health sites as of 2026, but that restriction is about the visual rich result in classic search — it doesn't stop AI Overviews, Perplexity, or ChatGPT browsing from parsing and quoting the same JSON-LD.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Does schema markup improve ChatGPT citations?",
"acceptedAnswer": {
"@type": "Answer",
"text": "It doesn't guarantee a citation, but it removes ambiguity about entities and facts, which is one of the main reasons pages get skipped during extraction."
}
}
]
}
Warning: the FAQ text in your JSON-LD must match the visible on-page text. Google has penalized mismatched or spammy FAQ schema before, and AI crawlers that cross-check schema against rendered content will simply distrust a page where the two disagree.
4. Product (only if you sell something concrete)
If you run e-commerce, Product with offers, aggregateRating, and sku gives shopping-oriented AI agents (Perplexity Shopping, ChatGPT's shopping surfaces, Google's Merchant-linked AI Overviews) hard facts to compare across sites: price, availability, review count. Pair this with a real merchant feed — see ecommerce-platform-israel if you're choosing a platform. Do not fake aggregateRating — I've seen Search Console manual actions for exactly this, and AI systems that cross-reference review platforms will flag the discrepancy too.
Comparison: which schema type solves which AI-search problem
| Schema type | Problem it solves | Where AI systems use it |
|---|---|---|
| Organization / LocalBusiness | Entity disambiguation, trust anchor | Knowledge graphs, citation attribution, local AI answers |
| Article / BlogPosting | Freshness signal, authorship | AI Overviews, Perplexity source ranking |
| FAQPage | Direct quotable Q&A pairs | ChatGPT answers, AI Overviews, voice assistants |
| Product | Price/availability comparison | Shopping-oriented AI agents, Google Merchant |
| BreadcrumbList | Site hierarchy, topical context | Crawlers building topical maps of your domain |
| HowTo | Step-by-step task extraction | Task-oriented AI answers ("how do I...") |
Entities and sameAs: the part everyone gets wrong
The sameAs property is how you tell a knowledge graph "this website is the same real-world entity as these other profiles." Most sites either skip it entirely or fill it with irrelevant links (a personal Twitter that has nothing to do with the business).
Rules I actually follow:
- Only include profiles that are clearly, verifiably the same entity — official social accounts, Crunchbase, Wikidata, LinkedIn company page, G2/Capterra listing if you're SaaS.
- Don't pad the list. Three accurate
sameAslinks beat ten loosely-related ones; a low signal-to-noise ratio can make the whole block look untrustworthy to systems that cross-check. - If you don't have a Wikidata entry and you're a small local business, that's fine —
sameAsto your Google Business Profile and verified social accounts is enough for most local AI use cases. - Keep the
namefield inOrganizationbyte-for-byte consistent across your site, your Google Business Profile, and your social bios. Inconsistent naming ("NisAi" vs "Nis-AI" vs "NisAi Web Studio") is the number one cause of entity confusion I've diagnosed in client audits.
For businesses specifically trying to get mentioned inside LLM answers (not just cited as a source link), read brand-mentions-llm-visibility — schema is necessary but not sufficient there; you also need third-party mentions the model can corroborate against.
Implementation: where JSON-LD goes and how to validate it
Placement
Put JSON-LD in a <script type="application/ld+json"> tag in the <head> or right before </body>. For React SPAs, this is trickier than it sounds — if your schema is injected client-side after hydration and an AI crawler doesn't execute JavaScript (many don't, or execute it with a budget), your schema is invisible. If you're on Next.js, its App Router lets you emit this server-side per route without extra tooling — see nextjs-16-app-router. If you're on a Vite/CRA SPA, you need prerendering or SSR for your schema to be reliably seen; this is the exact problem covered in react-spa-seo.
// Example: injecting Organization + Article JSON-LD server-side (Next.js route)
export default function GuidePage({ guide }) {
const jsonLd = {
"@context": "https://schema.org",
"@graph": [organizationSchema, articleSchema(guide)],
};
return (
<>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
/>
{/* page content */}
</>
);
}
Using @graph to bundle multiple types under one @context is cleaner than multiple separate <script> tags, and it lets you cross-reference nodes by @id (e.g., Article.publisher pointing at Organization.@id) without duplicating data.
Validation
- Google's Rich Results Test still catches most JSON-LD syntax errors and tells you which properties are required vs recommended.
- Schema.org's own validator (validator.schema.org) is stricter about spec conformance, which matters more for non-Google consumers.
- Manually check your rendered HTML source (view-source, not devtools) to confirm the schema survives whatever build/prerender step you use — this catches the SPA problem above before it ships.
Tip: run validation as part of your deploy checklist, not as a one-off. Schema breaks silently when a content field goes null (e.g., a missing datePublished on a new post) and nobody notices until an audit months later.
Common mistakes that make schema get ignored
- Multiple competing Organization nodes. Ten pages, ten slightly different
Organizationblocks with no shared@id. Pick one canonical block, reference it everywhere. - Schema that contradicts visible content. If your FAQ schema answer says "$49/month" and the visible page says "$59/month," trust erodes fast, and it's an easy inconsistency for a system to catch.
- Over-marking generic content as HowTo or FAQ just to chase rich results. Thin, keyword-stuffed FAQ schema with no real informational value gets deprioritized, and in aggressive cases it reads as manipulation.
- Ignoring
dateModified. A page that's actually been updated but still shows a 2023dateModifiedlooks stale to freshness-sensitive systems. - Skipping schema on the homepage. The homepage is usually where your
Organizationentity lives — leaving it bare while your blog posts are fully marked up is backwards.
How this fits into a broader AI-visibility strategy
Schema is one layer. It won't rescue thin content, and it won't substitute for the fundamentals covered in geo-answer-engine-optimization — direct answers near the top of the page, clear entity naming in prose, and content that's genuinely citation-worthy. If you also want to track whether any of this is working, pair schema work with the measurement approach in measure-ai-referral-traffic — referral-based attribution from AI platforms is still messy in 2026, but directional signal (spikes after a schema rollout) is better than nothing.
If your site is a headless or JS-heavy SPA, solve the rendering problem before investing more time perfecting JSON-LD content — schema an AI crawler never sees is wasted effort. That's the single highest-impact fix I've seen when auditing sites that "have schema" but aren't showing up anywhere.
FAQ
Does adding schema markup guarantee my page will be cited by ChatGPT or AI Overviews?
No. Schema markup removes ambiguity about who you are and what the page says, which increases your eligibility to be extracted and cited, but the underlying content still has to be accurate, current, and genuinely useful. Think of schema as removing friction, not as a ranking booster on its own.
Which schema type should I add first if I only have time for one?
Organization schema with a correct, consistent name and sameAs array, because it's the entity anchor everything else hangs off. Without it, even perfect Article or FAQ schema on individual pages doesn't get reliably attributed to your business.
Does FAQ schema still work if Google stopped showing FAQ rich results for most sites?
Yes, for AI search purposes. Google restricting the visual FAQ rich result in classic search doesn't stop AI Overviews, Perplexity, or ChatGPT from parsing the same FAQPage JSON-LD when they crawl or index your page. The rich result and the AI extraction are two separate consumers of the same data.
Can I use schema markup on a React single-page app?
Yes, but only if the schema is present in the HTML an AI crawler actually fetches. If your JSON-LD is injected client-side after JavaScript runs, and the crawler doesn't execute JS (or has a limited budget), it never sees it. You need server-side rendering or a prerender step for this to work reliably.
How often should I update dateModified in my Article schema?
Every time you materially update the content, not on a fixed schedule. Freshness-sensitive AI systems use dateModified as one input for whether to prefer your page over an older competing source, so a stale date on genuinely-updated content is a missed signal, and a fake date bump on unchanged content is a credibility risk if caught.
Do I need Wikidata or Crunchbase entries for sameAs to work?
No. For most small and local businesses, sameAs pointing to verified social profiles and a Google Business Profile is sufficient. Wikidata and Crunchbase help more for larger companies or ones actively trying to establish a knowledge panel, but they're not a prerequisite for basic entity disambiguation.
Get this set up on your site
If you want this audited or implemented properly — Organization anchor, per-guide Article/FAQ schema, and a rendering check so AI crawlers actually see it — grab a free 30-minute call through the contact form or message me directly on WhatsApp.