JSON-LD vs Microdata for AI Search: The 2026 Decision Framework

JSON-LD is the correct format for structured data in 2026. Google’s documentation explicitly recommends it over Microdata and RDFa, AI retrieval pipelines parse it more reliably, and it survives theme changes that routinely destroy inline Microdata. This post owns the format decision. For which schema types to implement, see our companion post on schema markup for AI search. Here we cover why JSON-LD won, when Microdata still appears, the migration path, validation tooling, and the five JSON-LD mistakes that silently suppress AI citations.

Why JSON-LD won the structured data format race

Google has supported three structured data formats since 2011: Microdata, RDFa, and JSON-LD. JSON-LD shipped last (2014) but became the recommended format by 2017. Google’s General Structured Data Guidelines state explicitly that pages should “mark up your site’s pages using one of three supported formats: JSON-LD (recommended); Microdata; RDFa.” The introduction to structured data goes further, stating that “in general, we recommend using a format that’s easiest for you to implement and maintain (in most cases, that’s JSON-LD).”

The architectural reason: JSON-LD lives in a single script tag, fully decoupled from the visible HTML. Microdata requires itemprop attributes distributed across nested HTML elements. Any template refactor, theme update, or CMS migration touches the HTML structure. JSON-LD survives intact. Microdata is silently broken.

AI search amplified the advantage. Retrieval pipelines parse JSON-LD as a clean structured object. Microdata requires the parser to walk the DOM and assemble fragments from scattered itemprop attributes. When the HTML structure shifts, the Microdata parser produces incomplete or incorrect objects without error. JSON-LD either parses correctly or fails with a clear validation error. The failure mode is auditable. The Microdata failure mode is invisible until you notice your content stops appearing as structured chunks in AI answers.

When Microdata still appears

Microdata has not disappeared. You will encounter it on legacy e-commerce platforms, older WooCommerce themes, and Magento installations that injected Product and Review markup inline before JSON-LD was available. Some accessibility tooling also uses Microdata-like attribute patterns for element-level semantic annotation. These are the remaining legitimate use cases:

• E-commerce themes (Shopify, WooCommerce, Magento) built before 2018 often have hardcoded itemtype and itemprop attributes in product templates. Replacing them requires theme-level changes, not just plugin swaps.
• Legacy WordPress themes with built-in schema injection. Theme updates typically break this schema output silently.
• Accessibility tooling that uses microdata attributes for element-level semantic metadata.

The pattern we see most: a site migrated from an old theme to a new one and the Microdata from the old theme was partially carried forward, partially dropped. The result is incomplete schema that produces incorrect objects and may suppress review and product rich results. The first step in any GEO audit is crawling for both Microdata and JSON-LD to establish what is actually on the page.

The format decision framework

For any new schema implementation, the decision is straightforward:

Migration path: Microdata to JSON-LD

Migration is safer than expected because the two formats coexist temporarily. Run them in parallel for 30 to 60 days, validate both, then strip Microdata once JSON-LD is confirmed indexed. Removing Microdata before JSON-LD is recrawled creates a gap where neither format is active and rich result eligibility drops.

1. Crawl the site with Screaming Frog and export all current schema types, counts, and source (Microdata vs JSON-LD). The combination report shows overlap and gaps.
2. Map each Microdata schema type to its JSON-LD equivalent. For Product, FAQPage, Article, and HowTo, the property names are identical. The only difference is the encoding format.
3. Add JSON-LD blocks to staging and validate with the Google Rich Results Test plus the Schema Markup Validator. Fix all critical errors before pushing to production.
4. Push to production and submit the updated sitemap to GSC. Watch the Enhancements report in GSC for the next 14 to 30 days to confirm recrawl and indexing.
5. Remove Microdata attributes from templates only after JSON-LD is confirmed indexed in GSC. Do not remove both formats simultaneously.

FAQPage and HowTo schemas in Microdata migrate cleanly because the property names are identical in JSON-LD. The FAQPage mainEntity array and HowTo step array translate directly with no property mapping needed.

Validation tooling that actually works

Use a layered validation stack. No single tool catches everything:

• Google Rich Results Test (search.google.com/test/rich-results): checks eligibility for specific Google rich result types. Use this to confirm your structured data is eligible for the features you are targeting. It does not catch all schema errors, only those that affect rich result eligibility.
• Schema Markup Validator (validator.schema.org): validates schema correctness against the full Schema.org specification, independent of Google’s rich result rules. Catches property type mismatches and missing required properties that Google’s tool may not flag.
• Screaming Frog schema export: for bulk validation across all URLs, not just spot-checks. The schema report shows which pages have which types and flags missing or duplicate schema.
• GSC Enhancements reports: the post-deployment ground truth. After pushing new JSON-LD, monitor for coverage increases in the relevant enhancement type (Article, Product, FAQ, etc.). Coverage drops after a deploy indicate a breakage in the new markup.

Run the full stack after initial implementation and after every theme or plugin update. Schema validation drift is one of the most common silent bugs on content sites: updates that appear unrelated to structured data routinely break the injection layer. Our GEO/AEO Tracker gives a second signal: if GSC coverage is flat but AI citations drop, the issue is in content quality or entity disambiguation, not schema format.

Five JSON-LD mistakes that suppress AI citations

Teams that have switched to JSON-LD often carry bugs that silently prevent AI engines from parsing correctly. These five appear most often in audits:

1. String dates instead of ISO 8601. “January 2026” in a datePublished property will not parse correctly. Use “2026-01-15”. AI engines use datePublished and dateModified for recency scoring. Malformed dates mean the page is treated as undated.
2. Missing @context. Every JSON-LD block must begin with “@context”: “https://schema.org”. Without it, the schema.org vocabulary is undefined and the entire block is unparseable.
3. Author as a string instead of a Person object. A full Person entity with sameAs links to LinkedIn and an authoritative profile page significantly improves E-E-A-T author entity recognition. This is the highest-leverage fix for editorial content.
4. Relative URLs in image properties. Schema.org requires absolute URLs. “/blog/image.jpg” fails validation. Use the full URL. This affects Article, Product, and HowTo schemas.
5. Duplicate @type declarations on the same page. Multiple script tags each declaring a different primary type (one Article, one FAQPage, one Product) for the same page URL creates a type conflict. Consolidate into a single JSON-LD block or use a single type as primary and nest others appropriately.

Audit your top 20 templates for these five mistakes. Most sites fix all five in under 4 hours of dev time. Our March 2026 study of 42,971 citations showed pages with clean schema were cited across more query types than comparable pages with schema errors.

For the type decision (FAQPage vs HowTo vs Article), see our post on FAQPage vs HowTo schema for AI citations. For entity-level optimization, sameAs disambiguation and SpeakableSpecification are the natural next steps after format and type are clean. Our HTML5 semantic tags guide covers how the visible markup layer interacts with JSON-LD for AI parsers that process both.