JSON-LD vs Microdata vs RDFa: The Best Structured Data Format for AI Search

The question of JSON-LD vs Microdata used to be a search engine question with a settled answer. It is now an AI search question with a more interesting one. Three formats exist for putting Schema.org data on a page, all three describe the same vocabulary, and Google parses all three without preference. Yet the teams asking which is the best structured data format are usually asking something narrower: which schema format for AI search gives content the strongest chance of being read, understood, and cited by ChatGPT, Claude, Perplexity, and Gemini.

The short answer is JSON-LD, for reasons of maintainability rather than machine preference. The longer answer, supported by controlled testing published in late 2025, is that format choice is not the variable that decides whether AI engines can use the data at all. This piece compares the three formats on syntax, maintenance cost, and standards status, then examines what the evidence indicates about how AI systems actually treat each one.

The Three Formats Compared at a Glance

The table settles the engineering question quickly. It does not settle the AI question, which the middle of this article addresses, because the AI question turns out not to be about the table at all.

What Each Format Actually Is

All three formats express identical Schema.org entities. They differ only in how those entities are serialized into the document, which means the choice is a question of ergonomics and pipeline fit rather than semantics.

JSON-LD

JSON-LD, or JavaScript Object Notation for Linked Data, places the structured data in a dedicated script block, typically in the page head or at the end of the body. The data is decoupled from the HTML: it is a separate JSON object rather than a set of annotations woven through the visible tags. JSON-LD 1.1 became a W3C Recommendation on 16 July 2020, following the 1.0 Recommendation in 2014.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data Formats Compared",
  "author": {
    "@type": "Person",
    "name": "A. Writer"
  },
  "datePublished": "2026-02-11"
}
</script>

Microdata

Microdata annotates the HTML elements that already display the content to the reader. It is part of the WHATWG HTML Living Standard, and Schema.org maintains a dedicated getting-started guide for it. A wrapping element carries itemscope and itemtype, and each annotated property carries an itemprop attribute. The coupling to the DOM is tight by design, which is both its principal strength and its principal weakness.

<article itemscope itemtype="https://schema.org/Article">
  <h1 itemprop="headline">Structured Data Formats Compared</h1>
  <span itemprop="author" itemscope itemtype="https://schema.org/Person">
    <span itemprop="name">A. Writer</span>
  </span>
  <time itemprop="datePublished" datetime="2026-02-11">February 11, 2026</time>
</article>

RDFa

RDFa, the Resource Description Framework in Attributes, also lives inline, but with a considerably richer attribute vocabulary. RDFa 1.1 is a set of W3C Recommendations published in 2013. It uses vocab or prefix to declare the vocabulary, typeof for the entity type, and property for each attribute, and it supports typed resources, datatypes, multiple vocabularies in a single document, and CURIE references that Microdata cannot express.

<article vocab="https://schema.org/" typeof="Article">
  <h1 property="headline">Structured Data Formats Compared</h1>
  <span property="author" typeof="Person">
    <span property="name">A. Writer</span>
  </span>
  <time property="datePublished" datetime="2026-02-11">February 11, 2026</time>
</article>

The three blocks above encode the same entity. Any engine that parses all three receives the same facts.

What Google Says About Format Choice

Google's Search Central documentation supports all three formats, and the format used does not affect how Google evaluates the content against its feature documentation. Google recommends JSON-LD, and the stated reason is worth quoting precisely, because it is a claim about maintenance rather than about machine comprehension: JSON-LD is, in Google's words, "the easiest solution for website owners to implement and maintain." That recommendation has been consistent since at least 2018.

Two constraints in the same documentation carry more weight than the recommendation itself. The first is that markup must describe content visible to the user; hidden or misleading markup is treated as a spam signal. The second is procedural: Google retired the Structured Data Testing Tool in 2023, and the current validators are the Rich Results Test and the Schema Markup Validator.

The visibility rule deserves attention, because the same principle that governs Google's spam policy turns out to govern AI retrieval as well, for entirely different reasons.

Adoption Has Already Chosen

The format debate is, in practice, largely concluded on the open web. W3Techs, which surveys live websites continuously, finds JSON-LD in use on roughly 54.5 percent of surveyed sites, making it the leading structured data format by penetration. The 2024 Web Almanac, based on the HTTP Archive crawl, found JSON-LD present on approximately 41 percent of mobile-crawled pages, up from roughly 34 percent in the 2022 edition. Microdata appeared on roughly 7 to 8 percent of pages, and RDFa on roughly 0.5 to 1 percent. Microdata declined over the same period that JSON-LD grew.

Tooling reinforces the trend. WordPress, Shopify, Webflow, Wix, and the major SEO plugins default to emitting JSON-LD, which means template-driven stacks arrive at the format without a decision being made. For most organizations, the realistic question is not which format to adopt but whether there is any reason to override what the platform already produces.

Both figures come with a caveat that matters for anyone citing them: W3Techs refreshes continuously and the Web Almanac is annual, so these are snapshots rather than fixed quantities.

What AI Engines Actually Read

This is where the comparison stops being a rehearsal of settled SEO advice. A controlled experiment published in late 2025 tested eight scenarios across five AI systems, ChatGPT, Claude, Gemini, Perplexity, and Google AI Mode, using a page that carried the same product information in different placements: visible HTML only, JavaScript-rendered content, JSON-LD with no visible counterpart, Microdata on visible content, RDFa on visible content, plus conflict and dynamic-injection variants. Each scenario was queried ten times per system.

The findings complicate the standard advice about JSON-LD for AI.

When ChatGPT, Claude, and Perplexity fetched a page directly, they parsed only the rendered visible HTML. They did not read the JSON-LD script block, did not parse itemprop annotations, and did not parse RDFa attributes. Structured data with no visible counterpart on the page was, for those systems on a direct fetch, effectively absent.

Two exceptions ran the other way. PerplexityBot supports some JavaScript rendering during its crawl phase, and Gemini is built on Google's index, where Googlebot executes JavaScript and parses structured data into the knowledge graph. Information Google can parse therefore does reach Gemini's surfaces, but by an indirect route that depends on the upstream pipeline rather than on the AI system reading the markup itself.

Two further results sharpen the picture. Where the visible HTML and the JSON-LD disagreed, on a price or a name, the AI engines trusted the visible HTML. And schema injected after page load through a client-side script was missed by every AI engine tested. A separate November 2025 analysis of 23 major AI crawlers found that approximately 69 percent do not execute JavaScript, which means that the common pattern of injecting JSON-LD through a tag manager places the data beyond the reach of a substantial share of the crawlers it was written for.

One caveat belongs with these findings. The central AI-readability result rests on a single controlled study from one publisher, and it is the most rigorous public source available rather than an established consensus. OpenAI, Anthropic, and Perplexity publish little about whether their fetchers parse structured data blocks, and no public benchmark from any major engine ranks the formats by influence on AI answers. Crawler behavior also moves quickly, so any statement about engine behavior should be read with its date attached.

The practical conclusion is nonetheless robust across all three formats, which is precisely why it is useful. The question of a schema format for AI search has a smaller effect on citation outcomes than the question of whether the underlying facts are present in the rendered text that the crawler receives. Markup that duplicates visible content is a durable strategy. Markup that substitutes for visible content is not.

JSON-LD: Strengths and Limitations

The case for JSON-LD is a case about operating cost at volume.

Strengths. The markup is a single isolated block, so editing the JSON carries no risk of breaking visible markup, and a template refactor carries no risk of breaking the JSON. It is straightforward to generate server-side from a database, a headless CMS, or a static-site data layer. It diffs cleanly in version control, which makes review tractable. It works well with single-page applications and headless setups because the data can be emitted alongside the HTML payload. And it is what developers, CMS platforms, and SEO tooling already default to, which lowers the cost of every future hire and integration.

Limitations. The data sits inside a script tag, so any pipeline that does not execute JavaScript will not see it, and the 2025 crawler analysis indicates that this describes most AI crawlers. Its isolation also permits drift: a product whose price changes in the CMS while its JSON-LD remains cached or hand-edited will silently contradict the page a reader sees, which is a Google spam-policy violation and, on the evidence above, a liability with AI systems that resolve conflicts in favor of the visible text. JSON-LD also offers no mechanism for in-document typed-resource chains across multiple vocabularies.

Common failure modes. Malformed JSON causes the entire block to fail silently, and a trailing comma is enough to do it. A wrong @context value produces the same outcome. Property names that do not exist on the declared @type surface as warnings in the Rich Results Test. ISO 8601 dates without normalized timezones introduce ambiguity, multiple @context declarations on one page cause merge errors, and markup describing content the user cannot see is treated as a spam signal by Google and ignored by AI engines.

Microdata: Strengths and Limitations

Microdata is frequently dismissed too quickly. Its central property is one that the AI findings above make newly relevant.

Strengths. The annotation travels with the visible text. When the markup sits on the element the reader actually reads, the data and the page cannot diverge, which structurally prevents the drift that JSON-LD permits. It requires no JavaScript execution to be visible to crawlers that read raw HTML. And its attribute ergonomics are familiar to anyone who has written HTML.

Limitations. The same coupling that prevents drift creates fragility. Microdata is tied to DOM structure, so a redesign that changes a wrapping element or splits a paragraph can strip an annotation without any visible symptom. It is verbose in templates, nested entities become painful quickly, and most modern CMS tooling no longer emits it by default, which means the implementation is maintained by hand. Adoption has declined year over year since at least 2022, which slowly erodes the tooling and documentation around it.

Common failure modes. Omitting itemscope on the wrapping element causes every inner itemprop to go unrecognized. Typos in itemtype URLs fail silently. Empty annotated elements yield nothing. A property split across multiple elements is read literally, whitespace included. And hiding annotated content with CSS violates Google's guidelines.

The theoretical advantage in the RDFa vs JSON-LD and Microdata comparison, that inline formats guarantee parity between markup and visible content, is real. It is generally not sufficient to overcome the maintenance economics, and parity can be achieved with JSON-LD through generation discipline rather than through syntax.

RDFa: Strengths and Limitations

RDFa occupies a narrow position that it occupies well.

Strengths. It is the most expressive of the three, supporting typed resources, datatypes, multiple vocabularies in a single document, and CURIE references. That expressiveness is the point in publishing pipelines that mix Schema.org with vocabularies such as FOAF or Dublin Core, and RDFa has a long history in library systems, scholarly metadata, government open data, and cultural heritage publishing.

Limitations. It has the steepest learning curve of the three, the highest maintenance cost when templates change, and the lowest adoption on the open web, which means the smallest body of tooling and community knowledge. For typical use cases it confers no advantage over JSON-LD. The most common implementation error is omitting vocab or typeof and assuming the vocabulary is inferred; mixing property with rel or rev in conflicting ways and using CURIEs that do not resolve are close behind. The visibility rule applies identically.

For ordinary SEO and AI-readiness work, RDFa vs JSON-LD is not a close contest. Where multiple vocabularies or typed resources are genuine requirements, it is not a contest either, in the opposite direction.

Validation and Tooling

Format choice determines which validator is appropriate. The Rich Results Test is Google's official validator, accepts a URL or a code snippet, and reports rich result eligibility, errors, and warnings against Google's feature documentation. The Schema Markup Validator is format-agnostic and checks Microdata, RDFa, and JSON-LD against the Schema.org vocabulary without evaluating Google-specific eligibility. Search Console's Enhancements reports cover structured data Google has detected across a live site, which is the only view that reflects production at scale. Third-party linters in SEO plugins and CI pipelines catch syntax errors before deployment, which is where malformed JSON is cheapest to fix.

None of these tools evaluate whether the marked-up facts appear in the visible text, which is the check the AI findings suggest matters most and the one that remains manual.

Which Format Should You Choose

The recommendation is situational, and in most situations it is short.

A new site or a new template. Default to JSON-LD. It is what the CMS emits, what Google recommends, and what the surrounding tooling assumes. Overriding that default requires a specific reason.

A working Microdata implementation. Do not migrate for its own sake. As long as it validates and the visible content matches, the implementation is fine. Migration becomes justified when the maintenance cost begins to bite, typically at a redesign.

A linked-data publishing context. Libraries, scholarly metadata, government open data, and cultural heritage publishing should stay on RDFa. The expressiveness is the requirement, not an indulgence.

Optimization specifically for AI answer engines. JSON-LD for AI remains the right format, but the binding constraint is content parity rather than format choice. Every fact in the structured data should also appear in the rendered HTML, and that HTML should be rendered server-side wherever possible so that the majority of AI crawlers, which do not execute JavaScript, still receive it.

Client-side or tag-manager schema injection. Audit whether the same content appears in the initial HTML response. If it does not, the data is invisible to a large share of AI crawlers regardless of how well-formed it is. Moving schema generation server-side or into a prerender step resolves it.

Across every one of these situations, the determining factor for AI visibility is the same, and it is not the syntax. It is whether the facts are in the text.

From Format Decision to Citation Outcome

Choosing JSON-LD is a decision that takes an afternoon. Keeping structured data, visible content, and publishing cadence aligned across a growing library is the part that consumes quarters, and it is where the parity requirement above tends to fail: not at implementation, but at the fiftieth article, when the schema is generated by one system and the prose by another.

That alignment is easier when schema markup, heading structure, internal linking, and metadata are produced as part of writing rather than added afterward, which is how DeepSmith's writing pipeline is built. Because the platform also tracks mention and citation rates across ChatGPT, Gemini, Perplexity, Claude, and Google AI Mode, the effect of a structural change is observable rather than assumed. It does not control whether an engine cites a page, and no tool does. It does make the relationship between what is published and what gets cited legible.

Teams that want to see both halves on their own content can start a free trial and work from real data rather than inference.