Structured Data for AI Search: A Practical Implementation Guide
Why JSON-LD specifically
Schema.org structured data can be implemented as JSON-LD, Microdata, or RDFa — but JSON-LD is the format Google explicitly recommends and the one most AI crawlers and parsers are built to expect, since it sits in a single script block separate from the visible HTML rather than being interleaved with page markup. Mixing JSON-LD with Microdata or RDFa on the same page is redundant at best and genuinely confusing to a parser at worst — pick one format, and JSON-LD is the correct choice for a modern implementation.
The schema types that actually matter for AI search
- Organization and Person — the foundational entity nodes everything else should reference.
- WebPage and its more specific subtypes (ProfilePage, CollectionPage) — describing what kind of page each URL actually is.
- Article / BlogPosting — for genuine editorial content, with author and publisher pointing back to the Person and Organization nodes.
- FAQPage and HowTo — for genuinely Q&A- or instructional-formatted content, covered in more depth in the companion post on FAQ schema.
- BreadcrumbList — helping both traditional crawlers and AI systems understand a page's position in the site's hierarchy.
- Service and Product — for commercial offerings, giving AI shopping and recommendation contexts structured facts to draw from.
The single-@graph pattern
Rather than emitting several disconnected JSON-LD blocks per page, a single linked @graph — where each node has a stable @id and references other nodes by that @id — lets a crawler resolve the full set of relationships in one parse: this WebPage's mainEntity is this Person, who worksFor this Organization, who offers this Service. Disconnected blocks force a crawler to infer relationships that a linked graph states explicitly, which is a meaningfully weaker signal.
Common implementation mistakes worth checking for
- Markup that doesn't match the visible page content — a direct violation of structured data guidelines and a trust-damaging inconsistency once detected.
- Missing or inconsistent @id values, breaking the entity-resolution chain a linked graph depends on.
- Using a generic type (Article, WebPage) where a more specific one exists and is more accurate (ProfilePage, Service, HowTo).
- Structured data present but the described content missing from the actual server-rendered HTML — a mismatch that undermines the markup's credibility entirely.
Validating the implementation
Google's Rich Results Test and the general Schema.org validator both check for syntactic correctness, but neither confirms that the markup accurately reflects the page — that check has to be done manually, comparing each schema property against what's genuinely true and genuinely visible on the page. A page that validates syntactically but misrepresents its content has passed the wrong test.
How this compounds with everything else in this cluster
Structured data is the machine-readable backbone that the rest of this AEO/GEO cluster builds on — FAQPage schema needs a coherent Organization and Person graph behind it to carry full weight, and a knowledge graph (see the companion post on building a knowledge graph for entity SEO) is, in practice, largely built out of correctly linked JSON-LD across every page on the site. Get this layer right first — most of the other AEO tactics depend on it working correctly underneath them.
Frequently asked questions
Should I use JSON-LD, Microdata, or RDFa?
JSON-LD. It is the format Google explicitly recommends and the one most AI crawlers and parsers are built to expect, because it sits in a single script block separate from the visible HTML rather than being interleaved with page markup. Mixing JSON-LD with Microdata or RDFa on the same page is redundant at best and genuinely confusing to a parser at worst, so pick one format.
Which schema types actually matter for AI search?
Organization and Person as the foundational entity nodes everything else references. WebPage and its more specific subtypes to describe what each URL actually is. Article or BlogPosting for genuine editorial content, with author and publisher pointing back to those entity nodes. FAQPage and HowTo where content really is question-and-answer or instructional. BreadcrumbList for hierarchy, and Service or Product for commercial offerings.
Is it better to have one schema block or several?
One linked graph. Rather than emitting several disconnected blocks per page, a single graph where each node has a stable identifier and references other nodes by it lets a crawler resolve the full set of relationships in one parse: this page's main entity is this person, who works for this organization, which offers this service. Disconnected blocks force inference where a linked graph states relationships explicitly.
My schema passes the Rich Results Test — does that mean it's correct?
No. Google's Rich Results Test and the Schema.org validator both check syntactic correctness, but neither confirms that the markup accurately reflects the page. That check has to be done manually, comparing each schema property against what is genuinely true and genuinely visible on the page itself. Markup that validates cleanly while misrepresenting the content around it has simply passed the wrong test, and a clean validator result should not be read as confirmation.
What are the structured data mistakes worth auditing for first?
Markup that does not match the visible page content, which violates structured data guidelines and damages trust once detected. Missing or inconsistent identifiers, which break the entity-resolution chain a linked graph depends on. Generic types used where a more accurate specific one exists. And structured data describing content that is missing from the actual server-rendered HTML, which undermines the markup's credibility entirely.
Where should structured data sit in my order of work?
First. It is the machine-readable backbone the rest of this discipline builds on. FAQPage markup needs a coherent Organization and Person graph behind it to carry full weight, and a site-level knowledge graph is in practice largely built out of correctly linked JSON-LD across every page. Most other tactics depend on this layer working correctly underneath them, so get it right before layering anything on top.
Book a free 10-minute consultation
Sapun Lamichhane is a business growth analyst and founder of Arcetis, based in Pokhara, Nepal. If you want a second opinion on your account, your funnel, or whether a channel is worth your budget at all, book a free 10-minute call — no pitch, and a straight answer even when the answer is that you do not need help.
Direct: +977 9846162626 · lamichhanesapun2@gmail.com
This post supports the frameworks documented in full on the Authority page.