Originally published on the Merlonix blog.
There are two different questions about your site and an AI answer engine, and people collapse them into one. The first is can the engine reach your page — a crawling question, answered by robots.txt and your edge. The second is once it has the HTML, can it tell what your page is — a parsing question, answered by structured data. You can pass the first and fail the second completely: the crawler fetches a page it can read but not understand, so it has to infer from rendered prose whether this is a product, an article, a company, or an FAQ. An engine that has to guess cites less confidently, and often cites the competitor whose page told it plainly.
Structured data — specifically schema.org JSON-LD — is how you tell it plainly. This is the same structured data that's driven Google rich results for a decade; what's new is that it now does double duty as the machine-readable meaning layer AI answer engines lean on to form a confident, citable entity. Here's what it is, the failure that isn't "missing schema," the types and fields that actually matter, and how to check yours.
JSON-LD is a <script>
block you drop in your page's HTML that describes the page as structured data, using the schema.org vocabulary:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Structured Data for AI Answer Engines",
"author": { "@type": "Organization", "name": "Merlonix" },
"datePublished": "2026-08-24"
}
</script>
That's it — a self-contained block of JSON that states, in a vocabulary machines already know, this page is an Article, here's its headline, its author, and when it was published. No engine has to infer any of that from your <h1>
and a byline it may or may not parse correctly.
Schema.org supports three syntaxes — JSON-LD, Microdata, and RDFa — but JSON-LD is the one to use. It's the format Google explicitly recommends, and it's the one AI engines parse most reliably, because it's a clean, isolated JSON object rather than attributes (itemscope
, itemprop
) scattered through your markup that a parser has to reassemble. Microdata still "counts," but it's strictly worse: a parser has to walk your DOM to reconstruct the entity, and any of it can break when your template changes. If you have a choice — and building fresh, you do — emit JSON-LD.
Everyone's first instinct is "do I have structured data, yes or no." That's the easy half, and it's not where sites lose. The real failure is a schema block that's present but thin — technically valid, so every "do you have JSON-LD?" checker gives it a green tick, but missing the fields that make the entity actually citable.
An Article
with no author
and no datePublished
. A Product
with a name
but no description
. A FAQPage
declared but with no mainEntity
— the questions and answers themselves. To an AI engine, these are half-formed entities: it knows what kind of thing the page is but not enough about it to quote it with confidence. Presence is the floor; completeness is what separates "the engine noticed you exist" from "the engine cited you."
And there's a silent-failure mode worse than thin: malformed JSON-LD is skipped entirely. A trailing comma, an unescaped quote, a template that interpolated a value wrong — and the block is invalid JSON, so the engine's parser discards the whole thing and treats your page as having no structured data at all. It looks present in your HTML. It counts for nothing. Nothing surfaces an error, because a broken JSON-LD block isn't a page error — it's just quietly ignored.
You don't need to schema-annotate everything; you need the right type per page with its citation-critical fields filled in. The ones that carry the most weight for AI answers, and the fields an engine leans on for each:
@type |
Fields that make it citable |
|---|---|
Organization |
name , url (who you are, and the canonical home) |
WebSite |
name , url
|
WebPage |
name |
Article / BlogPosting / NewsArticle / TechArticle
|
headline , author , datePublished
|
Product |
name , description
|
FAQPage |
mainEntity (the actual Q&A pairs) |
BreadcrumbList |
itemListElement |
LocalBusiness |
name , address
|
SoftwareApplication |
name , applicationCategory
|
Service |
name , provider
|
Person |
name |
A few that punch above their weight for AI answers specifically:
Article
(and its cousins) want author
and datePublished
.FAQPage
is the highest-leverage type for AI answersmainEntity
— the Question
/acceptedAnswer
pairs. An answer engine looking for a direct answer to a direct question is handed exactly that, pre-formatted. Declaring FAQPage
without populating mainEntity
is declaring an empty box.Organization
on your homepagename
url
(plus logo
and sameAs
links if you have them) is what lets an engine resolve "Merlonix" to a specific, canonical thing rather than a string.Match the type to the page — Product
on product pages, Article
on posts, FAQPage
where you have real Q&A, Organization
WebSite
on the homepage — and fill the citation-critical fields. That's 90% of the value.
Structured data is one of three layers that decide whether an AI agent can use your site, and they go in order:
llms.txt
They're independent, and the first one gates the rest: a perfect JSON-LD block on a page a WAF is 403-ing the crawler off changes nothing, because the engine never gets the HTML to parse. Comprehension only pays once access is real. But of the three, structured data is the one with the longest independent track record — it's earned rich results for a decade — so it's rarely wasted effort even setting AI aside.
"Has JSON-LD" is the wrong test. Test for present, valid, and complete:
curl
the page) and find application/ld+json
. Copy the JSON into any JSON validator — if it doesn't parse, an engine is silently discarding it, and that's your highest-priority fix.@type
matches the page.Article
/BlogPosting
, not WebPage
. The homepage should carry Organization
(and usually WebSite
).Article
with an author
and a datePublished
, a FAQPage
with a real mainEntity
, a Product
with a description
. Present-but-empty is the common miss.If you'd rather not walk all four by hand, the free AI Agent-Readiness checker does it from outside your stack: it fetches your homepage, finds your JSON-LD, reports which schema.org @type
s it found, flags blocks that are malformed (and therefore being skipped) separately from ones that are valid-but-missing recommended fields, and folds that into a 0–100 score next to the two layers that come first — whether your robots.txt
actually lets the answer-engine crawlers in, and whether you publish an llms.txt
. It tells you whether your weak layer is access, legibility, or comprehension, which is the only thing worth acting on. No signup, one domain at a time.
The one-line version: crawlable gets you fetched; parseable gets you cited — and the gap between them is a JSON-LD block that's present, valid, and complete, not just present. Pick the right @type
per page, fill the fields an engine needs to form a confident entity (author
and datePublished
on articles, mainEntity
on FAQs, description
on products), and make sure a template change never quietly breaks the JSON.
Merlonix watches all three layers the way it watches SSL, DNS, and domain expiry: continuously, and from outside your infrastructure, so a redeploy that strips your JSON-LD, a template refactor that malforms a block, or a new WAF rule that 403s the answer engines doesn't quietly erode your AI-answer visibility weeks before anyone notices the referral traffic fall off. Run the free agent-readiness scan to see where a domain stands today, check its live SSL and DNS while you're there, and browse the rest of the free tools. Being cited by an answer engine starts with being understood by it — and being understood is a markup problem you can fix this afternoon.