Structured data for AI surfaces — what still matters in 2026
JSON-LD isn't dead. It is more important for AI citation than it ever was for classic rich results. Here's what we ship and what we skip.
Every few years, someone declares structured data dead. They are always wrong, and they are especially wrong now.
JSON-LD is the single most reliable way to tell an AI model what a page is, who wrote it, what it's about, and how its claims relate to others. Models read it. Search engines still read it. And the cost of writing it is trivial compared to the cost of being misread.
Here is what we ship on every AEO engagement, and what we quietly skip.
What we always ship
Organization on every page
One canonical Organization graph, referenced by @id, sourced from a single file. Includes name, legalName, url, logo, sameAs, contactPoint, address, and knowsAbout. The last one is under-used — it's how you name your category in machine-readable terms.
knowsAbout does not need to list everything. Three to eight terms that accurately describe what you do is better than twenty that dilute.
WebSite with search action
Simple, but it signals to models that you have an internal taxonomy worth querying. If your blog has real search, point at it. If not, skip it.
BreadcrumbList
Cheap to generate, high signal. Makes hierarchy explicit for the model. We add it on every deep page.
The type that matches the page
This is where most teams underinvest. An explainer is an Article or a DefinedTerm. A comparison is ItemList with nested Things. A how-to is HowTo. A FAQ is FAQPage. A pricing page can be Product with multiple Offers.
Matching the type to the content is not a stylistic choice. It changes whether the model thinks the page is a primary source for the thing it describes.
Article for blog posts
Always with datePublished, dateModified, author (as Person), and publisher (referencing your Organization). headline must match the page's <title>. mainEntityOfPage must be the canonical URL.
What we usually skip
Ornamental schema on thin pages
Do not add FAQPage to a page with three generic questions that don't appear as visible content. Do not add Review without actual review content.
Models penalize structure-that-lies more than structure-that's-missing. If in doubt, leave it out.
BreadcrumbList where there is no breadcrumb
If your site has no hierarchy, don't fake one. Build the hierarchy first, then mark it up.
Multiple Organization nodes
One @id, referenced from wherever you need it. Never inline the Organization on a product page if you already have a site-wide graph.
The biggest failure mode we see
The prose says one thing. The schema says another.
A page reads: "We've been helping teams since 2018." The Organization schema says foundingDate: 2021. A product page says "Starting at $49." The Offer says price: 99.
Models see both. Models notice. Models will often resolve the ambiguity by trusting neither.
Before you ship a page, grep the JSON-LD for every claim that appears in the prose. Make sure they agree. This one habit has moved more citations for our clients than any other single change.
Tooling we like
- Schema.org validator for basic syntax.
- Google's Rich Results Test for Google-specific verification.
- Your own
/api/public/*routes for site-wide consistency. Ship your schema from one source of truth; generate it programmatically.
What we'd love to see in 2026
A spec that tells models where to look for a site's canonical knowledge graph. Something between sitemap.xml, llms.txt, and a SPARQL endpoint. Not here yet. When it arrives, we'll write about it.
Until then — write the schema, keep it honest, and stop believing anyone who tells you it doesn't matter.
We audit and rebuild schema graphs as the first deliverable of every diagnostic. See services or book a call.