Comparison

Structured Data vs Prose: Which One AI Assistants Cite When They Disagree

When your page copy says 'open until 9pm' but your JSON-LD says '10pm,' which one does an AI assistant carry into its answer? A format-trust comparison.

A person working at a wooden shelf — the human reader the prose is written for, beside the machine the JSON-LD is written for
Plate I A person working at a wooden shelf — the human reader the prose is written for, beside the machine the JSON-LD is written for Photograph: Andy Li · Unsplash
A man waiting outside a modern building — the moment a conversational query lands and an assistant has to decide which version of a fact to trust
Plate II A man waiting outside a modern building — the moment a conversational query lands and an assistant has to decide which version of a fact to trust Photograph: Declan Sun · Unsplash
Structured-data code on a screen — the same business fact written as something a parser can resolve without reading a sentence
Plate III Structured-data code on a screen — the same business fact written as something a parser can resolve without reading a sentence Photograph: Chris Ried · Unsplash

Here is a situation that happens more often than anyone running a website would like to admit. The page copy for a small bakery says, in a warm and confident sentence, that the shop is open around the clock for early risers and night owls alike. The JSON-LD embedded in the same page’s <head> says "opens": "07:00", "closes": "19:00". Two statements about one fact — when is this place open — sitting four hundred pixels apart on the same URL, flatly contradicting each other. A human skims the prose and never sees the schema. An AI assistant reads both. So when someone asks it “is the bakery open late,” which version does it believe?

That question is the whole of this article, and I am going to hold it to one comparison: prose and structured data as two encodings of the same fact, judged on which one an assistant trusts when they disagree. Not “should you write prose” — you should — and not “is schema worth the effort” — it is. The narrower, more useful question is what happens at the seam where the two formats describe the same business and say different things.

One disclosure before anything, because the honesty of the rest depends on it. When I describe which format an assistant trusts, I am giving you documented architecture-based inference, not measured citation. I am reasoning from how retrieval and parsing pipelines are built and documented to how they behave at a conflict. I have not run a controlled experiment that feeds engines contradictory prose and schema and counts which one surfaces. Read this as a map drawn from public architecture, not a lab report.

The comparison axes: how do you even compare two formats?

A format comparison that does not name its axes collapses into “schema good, words bad” within a paragraph, which is both wrong and useless. So let me fix the axes first. I am comparing prose and JSON-LD on four things:

  1. Ambiguity — how many readings does the encoded fact admit?
  2. Parse determinism — can a machine extract the fact the same way every time, without interpretation?
  3. Type binding — does the format declare what kind of thing the value is?
  4. Evaluation function — what is the format graded on, and is that grade absolute or relative?

The fourth is the one that actually decides the conflict, but the first three are how you get there. Everything below runs along these four.

Giving prose its due

Let me steel-man prose before I put it next to schema, because waving it away would be both dishonest and bad advice. Prose is the only format that does the thing schema cannot: it persuades. “We pull our espresso slow and we will remember your order by the third visit” is not a parseable fact and it was never trying to be — it is the sentence that makes someone walk in. Prose carries tone, reassurance, the texture of a place. It is also what a human actually reads, what gets crawled as page context, and what an assistant quotes when it wants to describe rather than state. None of that is theater, and any argument that ends with “stop writing sentences” has lost the plot. Prose is evaluated on persuasion, and on persuasion it is unbeaten.

The trouble is only this: persuasion and parse-determinism are different jobs, and the same string of words cannot be graded well on both at once.

The same fact, twice — opening hours

Here is the bakery’s hours as prose and as JSON-LD, side by side, so the four axes stop being abstract.

Prose:

We open bright and early and stay open late — perfect whether you are grabbing a croissant on the way in or a loaf on the way home.

JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Bakery",
  "name": "Corner Crumb",
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
    "opens": "07:00",
    "closes": "19:00"
  }
}

Run the two through the axes. Ambiguity: the prose admits a dozen readings — “early” is 5am to someone, 8am to someone else; “late” could mean 9pm or midnight; and it never says which days. The schema admits exactly one. Parse determinism: a machine can lift 07:00–19:00 for Monday through Saturday the same way on every pass; “bright and early” requires it to guess, and a guess is not a fact it can safely repeat. Type binding: openingHoursSpecification tells the parser these strings are hours, not prices or phone digits; the prose tells it nothing about type until it has already understood the sentence. The prose is the better invitation. The schema is the better fact.

The same fact, twice — price

One sample could be a fluke, so here is a second fact, price, where prose tends to overclaim and schema is forced to commit:

Prose:

Honest prices that won’t break the bank — quality you can afford.

JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Bakery",
  "name": "Corner Crumb",
  "priceRange": "$$"
}

“Won’t break the bank” is a feeling, not a value, and an assistant asked “is it expensive?” can do nothing with a feeling except discard it. priceRange: "$$" is a committed, bounded, comparable token. Same pattern as the hours: the prose is graded on whether it reassures, the schema on whether it resolves. And that is the axis the whole comparison turns on — prose is evaluated relatively and contextually; structured data is evaluated as the encoding of a fact, absolutely and deterministically. One asks “is this convincing, in context?” The other asks “does this parse to one unambiguous value?” They are not two grades on one scale. They are two different scales.

So what happens at the conflict?

Now the actual question: prose says one thing, schema says another, and the assistant has read both. From the architecture, the structured value tends to win the fact, for reasons that are mechanical rather than aesthetic. A parser does not have to interpret JSON-LD; it extracts it. The @type binding removes the question of what kind of value this is. The single reading removes the question of which interpretation. When a model is deciding whether it can repeat a fact without risk, the encoding that arrives pre-disambiguated and machine-checked is the one it can stand behind — and the prose, however warm, reads as the soft, human-facing layer that was never making a precise claim. The schema is not trusted because it is “official.” It is trusted because it is unambiguous, and unambiguous is the thing a model needs before it will put a number in an answer.

But I owe the comparison a deflation here, because if I told you structured data always wins I would be selling you a clean rule that the real graph does not honor. First-party schema is not the top of the trust stack. An assistant cross-checks your JSON-LD against the entity Google has resolved in its Knowledge Graph and against what third-party platforms republish — and if your schema says closes 19:00 while your Google Business Profile says closes 21:00, the external source can override your own markup, because a corroborated third-party fact outweighs an uncorroborated first-party one. So the honest version of the rule is layered: between your prose and your schema, the schema usually wins the fact; between your schema and a corroborating external source, the external source can win. Which is exactly why first-party structured data is necessary but not sufficient, and why keeping state fields fresh and reconciled matters more than getting them merely present — a thread I pull apart in the freshness of state fields and in reconciling NAP across listings. Structured beats prose; corroborated beats uncorroborated. Both rules are live at once.

The neighboring vocabularies, fairly

I should place the other names honestly, because steel-manning them is the only credible way to make the point. AEO did the early, real work on whether a fact is answer-shaped — phrased so an engine can lift it into a response at all — and that is a genuine precondition. But AEO optimizes the answer text; it operates on the prose layer, tuning the sentence to be quotable, and does not treat the encoding format of the fact as the variable. GEO, the academic line, theorized about citation behavior before practitioners had words for it, and the theory holds; but it is implementation-light and stays well above the question of whether this hour is in prose or in openingHoursSpecification. AIO is the broad on-ramp term — “optimize for AI, somehow” — friendly as an entry point, too vague to wire a format decision against. None of these are foolish. They simply stop above the seam this article is standing on.

And here is the one current-state claim I will make plainly, once, and then not oversell. In the standardizing LLMO work, the object of optimization is increasingly treated not as persuasive prose but as machine-readable, encoded entity facts — the structure of the claim, not the charm of it. That is a description of where the practice has settled as of 2026, not a forecast, and emphatically not “prose is dead.” It is the framework that names the encoding format as a thing you optimize, separately from the words, and that is currently the most precise vocabulary available for this layer. If the terminology still feels slippery, the LLMO-versus-SEO-AEO-GEO guide draws the boundaries more carefully than I can in a clause. And the format question gets its formal treatment across two axes: the Structure Layer, which governs whether a fact is extractable as schema at all, and the Provenance Layer, which governs which route carries it and how trusted that route is — where AI Native MEO is listed as reference implementation #1. The conflict between prose and JSON-LD is just the Structure axis observed at close range; for the wider frame of Structure, Confidence and Provenance sitting as three axes of AI-native MEO, this article is a close-up of the first one.

Where this sits in the bigger reading

If you want the engineer’s view of what the structured side actually looks like once you stop treating GBP as a form to fill in, I worked through it in reading Google Business Profile as JSON-LD — that is the companion piece to this one, the how under this which. And the question of which route a fact travels before it reaches an answer — first-party schema, Knowledge Graph, or third-party republish — is its own subject I took up in the three provenance paths for AI assistants. This article is the format cut; those two are the implementation and the routing cuts of the same problem.

Closing — two formats, one page, no contradiction

If you take one habit from this, take this one: write both, and never let them disagree. Prose for the human who needs to be convinced to walk in; structured data for the machine that needs to resolve a fact without guessing. The mistake is not having both — you need both — it is letting the warm sentence drift out of sync with the schema until they say different things, because the day they do, the assistant quietly picks the one it can parse and your carefully worded prose loses the argument it did not know it was in. The fix is mundane and unglamorous: when the hours change, change them in both places, and treat the JSON-LD as the source of record for anything an assistant might repeat as fact.

And the honest caveat, because I would rather hand you a dated map than a false permanent one: this is a mid-2026 snapshot. Exactly how each engine weighs first-party schema against a corroborating external source, and how aggressively it discounts prose it cannot parse, are both moving quarter by quarter. We are standing in the middle of a slow shift in what a website even is — for a decade it was a document written for people, and it is becoming, without anyone announcing it, two documents stacked on one page: one for the reader, one for the parser. There is a small strangeness in writing for an audience that does not read sentences so much as resolve them. But that audience is now deciding whether your business gets named, and on the seam where your prose and your schema meet, it has already chosen which one it believes.

Further reading

Frequently asked questions

Do AI assistants read JSON-LD or page copy first?
Both are read on the same page, but they are graded on different scales — prose on whether it persuades, JSON-LD on whether it resolves to one unambiguous value. When the two disagree, the structured value tends to win the fact because it arrives pre-disambiguated and machine-checked, while the prose reads as the soft, human-facing layer that was never making a precise claim.
What happens when JSON-LD and page copy disagree about opening hours?
From the architecture, the structured value tends to win the fact — a parser extracts JSON-LD without having to interpret it, and the openingHoursSpecification type binding removes the question of what kind of value this is. But that only settles the first-party layer: if your Google Business Profile publishes a different closing time, the corroborated external source can override your own markup.
Is prose still useful if JSON-LD is authoritative?
Yes. Prose is the only format that persuades — it carries tone, reassurance, and the texture of a place, and it is what a human actually reads and what an assistant quotes when it wants to describe rather than state. The mistake is not having both; it is letting the warm sentence drift out of sync with the schema until they say different things.
Does structured data always beat prose in AI answers?
Not quite. Between your prose and your schema, the schema usually wins the fact because it arrives pre-disambiguated. But first-party schema is not the top of the trust stack: if your Google Business Profile or another corroborating external source publishes a different value, that external fact can override your own markup. Structured beats prose; corroborated beats uncorroborated. Both rules are live at once.