Structured Data vs Clear Prose for AI Search

They are not competing for the same job. Structured data is a claim about what a thing is. Prose is the thing a model can actually quote back to a user.

The short version: prose decides whether a passage can be quoted, structured data decides whether the machine knows who is doing the talking. Skip either one and you lose a different thing.

Start with the part nobody has to argue about, because the platform wrote it down.

Google's own intro to structured data says it plainly: "Google uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general." That second clause is the interesting one. Markup does not only feed the result snippet, it feeds the knowledge layer, which is exactly the layer an assistant leans on when it needs to know which "Apollo" or which "Sparky" you meant.

On the AI side, the clearest platform confirmation comes from Microsoft. At SMX Munich in March 2025, Bing principal product manager Fabrice Canel confirmed that schema markup helps Microsoft's LLMs understand your content. That is one vendor speaking for its own stack, not a law of nature, but it is a named person from a named platform, which is more than most GEO advice can offer.

Three jobs where markup earns its keep:

Entity disambiguation. A stable @id plus sameAs links tells a machine that the "SparkCliks" on the pricing page, the blog and the contact page are one organization, and which external profiles are that same entity. Prose cannot do this reliably, because prose repeats a name without ever asserting identity.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.sparkcliks.com/#organization",
  "name": "SparkCliks",
  "url": "https://www.sparkcliks.com/",
  "sameAs": ["the URL of a profile you actually control"]
}

Explicit relationships. "Written by", "published on", "costs", "is part of", "is a step in". A human infers these from layout. A parser reading author, datePublished and offers does not have to infer anything, and it will not mistake a byline for a quoted source.

Facts that survive extraction. A price in a styled span is a string. A price inside a PriceSpecification is a number, a currency and a validity window. When a system builds a fact table from your page, the typed version arrives intact and the styled version arrives as a guess.

Now the honest limit. Google Search Central's guide to optimizing for generative AI features, added in May 2026, states that "structured data isn't required for generative AI search, and there's no special schema.org markup you need to add." The companion page on AI features and your website says the same about machine-readable files: "You don't need to create new machine readable files, AI text files, or markup to appear in these features." Anyone selling schema as the entry ticket to AI Overviews is contradicting the vendor.

The strongest published evidence for the prose camp is a controlled experiment, and it is worth reading rather than quoting from a summary.

In GEO: Generative Engine Optimization (Aggarwal, Murahari, Rajpurohit, Kalyan, Narasimhan and Deshpande, KDD 2024), the authors built GEO-bench, a set of roughly ten thousand queries drawn from nine sources, then rewrote source documents nine different ways and measured how visible each version became in the generated answer. The abstract's headline: "GEO can boost visibility by up to 40% in generative engine responses."

What moved the needle is the part that gets skipped. The nine methods were Authoritative, Statistics Addition, Keyword Stuffing, Cite Sources, Quotation Addition, Easy-to-Understand, Fluency Optimization, Unique Words and Technical Terms. Adding quotations, statistics and source citations performed best. Keyword stuffing performed worst, showing little to no improvement and landing below baseline on several metrics. And none of the nine was structured data. The study did not test it, which is a good reason to treat "the GEO study proves schema works" as a misreading rather than a finding.

Google's guidance points the same direction in plainer language: "Write content for your human audience and make sure the content is well written and easy to follow. People generally appreciate it when web pages are organized by paragraphs and sections, along with headings."

So what does prose actually buy you?

• A passage that stands alone. If the sentence answering the question needs the two paragraphs above it to make sense, a retrieved chunk carries the question and not the answer.
• The definition in the first sentence under its heading. Not the third. The opening sentence of a section is disproportionately likely to survive truncation, summarization and quoting.
• Question-shaped headings. A heading that matches how someone phrases the query gives the retriever a cheap match, and gives the writer a forcing function to answer it directly underneath.
• Named entities repeated in full. "It" and "the platform" are fine in a paragraph a human reads top to bottom. In a chunk lifted out of context, they refer to nothing.
• Content controls that actually apply. The snippet controls Google documents (nosnippet, data-nosnippet, max-snippet) act on page text. There is no documented switch that hides one JSON-LD property from an AI feature, which tells you something about which representation the answer surfaces are reading from.

Here is the mechanical reason the two camps keep talking past each other.

An answer engine does not hand a whole page to the model. It extracts text, splits it into passages, embeds them, retrieves a handful that match the query, and generates from those. Text extraction almost always drops script tags, and your JSON-LD lives in a script tag. So at the exact moment a sentence of yours is selected for quoting, the schema that describes it is usually not in the room. We walked through that split in detail in AI answer engine retrieval: chunks, not pages.

That does not make markup useless. It relocates where markup works. Structured data does its job earlier, at crawl and index time, when the system is deciding what your page is about, who published it and which entity it belongs to. Prose does its job later, at retrieval and generation time, when a specific passage is being chosen and paraphrased.

Which explains the pattern behind why AI answers cite pages that don't rank in the top ten. Citation selection is passage-level. A page with immaculate markup and mushy paragraphs loses the quote to a plainer page carrying one crisp, self-contained answer. The reverse also happens: a sharply written page from an entity the system cannot place gets read and then attributed to somebody it recognizes. Both failure modes are real, and each one is fixed by the other representation.

The strongest version of each camp's argument converges on one rule, and Google's structured data general guidelines state it directly: "Don't mark up content that is not visible to readers of the page", and "Your structured data must be a true representation of the page content." Break it and a structured data manual action can cost the page its rich result eligibility outright.

That rule kills the whole idea of schema as a side channel. Markup is not a place to smuggle in facts you did not write. It is a second encoding of facts you did write. Which gives you a practical test.

The two encodings test. For every fact you want an engine to attribute to you, ask two questions. Is it stated in a self-contained sentence, in the visible body, under a heading that matches how someone would ask for it? Is that same fact expressed as a typed property in JSON-LD? Two yes answers mean the fact is retrievable and unambiguous. One yes is a known failure mode.

That third column is also why brand consistency keeps showing up in citation studies. When several sources describe the same entity the same way, the system has an easier time resolving it, which is the mechanism underneath the correlations in brand mentions vs backlinks for AI citations.

Most posts on this topic assert. Here is the same set of claims with a grade attached, so you can see which ones would survive a technical reader asking "who says?"

Two of those deserve a flag. "Plausible, not proven" is not a polite way of saying yes. And the GEO result, real as it is, came from a research harness built to imitate a generative engine, not from a production assistant, so treat the 40% as a demonstration that content edits can move visibility, never as a number to expect on your own site.

Ninety minutes, no tooling beyond what you already have. Every figure below is an illustrative example, not SparkCliks data.

Step 1: pull the pages worth auditing. In Google Search Console, open Performance, then Search results. Set the date range to the last 28 days, switch to the Pages tab, then add a position filter of higher than 5 and lower than 15. These are pages a search engine already trusts enough to show but that are not winning the click. Export the top 20 by impressions.

Step 2: score each page on two axes. Open each URL twice. Once as a reader: find the single sentence that answers the query the page targets, and record whether it is self-contained, whether it sits in the first two sentences under its own heading, and whether it uses the entity's full name rather than a pronoun. Once as a parser: view source, find the JSON-LD block, and record whether that same fact appears as a typed property. Run the markup through the Rich Results Test and the Schema Markup Validator while you are in there, so a syntax error does not get scored as a strategy problem.

Step 3: put the results in a grid. Every page lands in one of four cells, and each cell has a different fix.

In a typical audit of 20 mid-position pages, the bottom right cell is the crowded one, and it tends to be crowded with pages whose owners believe they "did schema" last year.

Step 4: change one variable. Take the 10 worst pages from the bottom row and rewrite only the opening sentence of the target section. Leave the JSON-LD exactly as it is. Then pick 10 more pages from the same cell, matched roughly on impressions, and change nothing at all. That second set is your control, and it is the part almost everybody skips.

Step 5: read it after a full cycle. Two 28-day windows, baseline and post-change, compared in the Performance report with the same position and country filters applied. Read the treated set against the control set, never against its own history, because a whole category can drift on its own. If both sets moved the same way, you measured the season and not the edit. On a 20-page sample, a swing of a fraction of a position is noise. You are looking for a divergence between the two groups that holds across the full 28 days.

For AI referral visibility, add a GA4 exploration segmented on the session source values the assistants send, and expect small numbers. Those counts are sparse enough that a month over month change on 20 pages will rarely clear the noise floor by itself.

Run this against your own site. It is ordered by return, not by effort.

1. Every page: one Organization block with a stable @id, sitewide, and the same organization name written the same way in the visible text. This is the cheapest entity signal available.
2. Every page: the answer to the page's main query in the first two sentences under a heading that matches the question. If you do exactly one thing on this list, do this one.
3. Money pages: Product or LocalBusiness with real, typed, currently true values. Wrong prices in markup are worse than no markup.
4. Editorial pages: BlogPosting with the organization as author and publisher, plus a datePublished that matches the visible date.
5. Anything with steps or questions: keep HowTo and FAQPage only where the steps and questions are visible on the page, and treat both as machine readability rather than a rich result play.
6. Never: markup describing content that is not on the page. That is the one item here that can cost you eligibility rather than just wasting an afternoon.
7. Only after items 1 to 5: the more exotic types. Dataset, SoftwareApplication and friends are worth it when they describe you accurately, and worth nothing when added speculatively.

No engine publishes the weight it puts on any of this, and anyone quoting you a ratio is guessing. The correlation work circulating on AI citations cannot separate structured data from brand size, publishing cadence or link profile, because the sites with the best markup tend to be the sites with the most of everything else. Nothing here should be read as a promise of rankings, citations or traffic, and any vendor offering that promise is selling something no search engine has agreed to.

What you can control is whether a machine reading your page can tell who you are, and can find one sentence worth quoting. Both are checkable today, on your own site, without waiting for a platform to confirm anything. For how the assistants differ in what they retrieve and cite, see how AI assistants pick sources.