# Structured Data for AI Answer Engines: Why JSON-LD Decides Whether You Get Cited > Source: > Published: 2026-08-24 20:22:21+00:00 *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 ` ``` 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 `

` 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 answers`mainEntity` — 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 homepage`name` + `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](https://merlonix.com/tools/agent-readiness/) 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](https://merlonix.com/tools/agent-readiness/) to see where a domain stands today, [check its live SSL and DNS](https://merlonix.com/tools/domain-health/) while you're there, and browse the rest of the [free tools](https://merlonix.com/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.