How to add JSON-LD schema for AI enginesSix schema types cover 80% of practical cases.
JSON-LD is the recommended way to describe a page's entities for both Google and AI engines. This page covers the six core schema.org types, the @graph pattern, validation tools, and the production-pattern that ships JSON-LD reliably from a Next.js App Router build.
By Martin Yarnold · UpdatedThe six core schema types
Site-level (use once)
WebSite — the site itself, with searchAction if you have site search.
Page-level (per page type)
Frequently asked questions
Which schema.org types matter most for AI engines?
For most sites: Organization (site-level), Article (content pages), Product (commerce), FAQPage (Q&A sections), Person (author bylines), BreadcrumbList (navigation). Specialised types add value where applicable: HowTo for instructional content, Dataset for data publications, DefinedTerm for definitions, Event for time-bound content. The schema.org vocabulary is large; covering the six core types above handles 80% of practical cases. Specialised types add diminishing returns once the foundation is in place.
What is the @graph pattern and should I use it?
Yes for any page that has more than one entity to describe. The @graph pattern wraps multiple schema types in a single JSON-LD block, with shared @id references between nodes. The Promagen Sentinel authority pages use this pattern: BreadcrumbList + Article + Person + Organization + FAQPage in one @graph. Engines parse it as efficiently as separate blocks, and the shared @id references let you link the article to its author and publisher cleanly.
How do I validate JSON-LD?
Three tools, in order of strictness. (1) validator.schema.org — schema.org's official validator. Strictest checks against vocabulary. (2) Google's Rich Results Test — checks Google-specific eligibility for AI Overviews and SERP enhancements. (3) Run the JSON through a schema linter in CI before deploy — catches malformed JSON before it ships. Use all three for any production site; validator.schema.org alone for prototype pages.
Should I use <script type="application/ld+json"> or HTML microdata?
JSON-LD in a script tag. Google recommends it, AI engines parse it more reliably, and it keeps structured data separate from rendered HTML so content edits do not break schema. Microdata is older, harder to maintain, and offers no AI-visibility advantage. There is no scenario in 2026 where new structured data should be authored as microdata rather than JSON-LD.
Where in the HTML should the JSON-LD script go?
In the <head> for site-wide schema (Organization, WebSite). In the body or head for page-specific schema (Article, Product, FAQPage) — engines parse both locations. Next.js App Router pattern: use Next's metadata API for site-wide schemas, and inject page-specific JSON-LD as a <script> with dangerouslySetInnerHTML in the page component. The Promagen Sentinel authority pages follow this pattern.
How do I catch schema drift over time?
Two mechanisms. (1) CI check: run the schema linter on every PR; fail the build if validation breaks. (2) Continuous monitoring: a tool like Promagen Sentinel re-validates every Monday and flags pages where schema disappeared or broke. Both matter — CI catches developer-introduced drift; monitoring catches content-management drift (e.g. a CMS editor saved a page in a way that stripped the schema).