Google’s own documentation supports all three structured data formats, JSON-LD, Microdata, and RDFa, and will parse each of them if present on a page. But Google explicitly recommends JSON-LD as its preferred format, and when multiple formats describe the same entity on the same page with conflicting property values, Google’s documented behavior is that resolution becomes inconsistent and unpredictable rather than following a clear, disclosed precedence rule. The direct answer to “what happens when they conflict” is: don’t rely on there being a sensible resolution, because Google hasn’t published one, and mixing formats for the same entity is discouraged precisely for this reason.
The mechanism: format support versus format recommendation
Google’s Search Central “Introduction to structured data” documentation is explicit on two separate points that are worth keeping distinct. First, technical support: Google’s parsers are built to read JSON-LD, Microdata, and RDFa, so a page using any of these (or, technically, more than one) will have its structured data extracted rather than ignored outright. Second, recommendation: despite supporting all three, Google’s documentation states a clear preference for JSON-LD specifically, citing its practical advantages (it can be embedded as a single script block without needing to be interleaved with visible HTML, which makes it easier to implement and maintain, especially via tag managers or templated systems, without risk of the markup breaking the visible page structure).
The conflict scenario the question raises, the same entity described twice on one page, once via JSON-LD and once via Microdata, with different property values (a different price, a different name, a different rating), is not something Google’s documentation describes a specific precedence order for. There’s no published rule stating “JSON-LD wins” or “the format listed first in source order wins” or any comparable deterministic tie-breaker. The honest, accurate answer is that Google hasn’t disclosed how its parser resolves this conflict, and practitioner reports of the actual behavior in this scenario are inconsistent, which is itself informative: an undocumented, non-deterministic outcome is a real finding, not merely an absence of information.
Why this matters practically, beyond the theoretical conflict case
The practical risk isn’t limited to the edge case of deliberately conflicting data. It’s more commonly a maintenance problem: sites that accumulate multiple structured data implementations over time, an older Microdata implementation from a previous developer or plugin never fully removed, plus a newer JSON-LD implementation added later for the same entity, without anyone auditing for overlap. In this common scenario, the “conflict” isn’t intentional at all, it’s often a stale value in the old implementation drifting out of sync with the current value in the new one (a price update reflected in JSON-LD but never removed from lingering Microdata attributes in the template, for instance). The resulting risk is the same regardless of whether the conflict was intentional or accidental: unpredictable resolution of which value Google actually uses for rich result eligibility and display.
What to actually do about it
Pick one format per entity and standardize on it. Google’s stated preference for JSON-LD is a reasonable default to standardize around site-wide, both because it’s Google’s own documented recommendation and because it’s operationally easier to maintain (a single script block per entity, not markup interleaved through the visible HTML that has to survive every template and CMS change without breaking).
Audit for legacy structured data before adding new implementations. Before adding a JSON-LD implementation to a template or page type, check whether an older Microdata or RDFa implementation for the same entity already exists in the template history, in a plugin, or in a previous developer’s work. This is a common, avoidable source of the exact conflict this question describes, and it’s found by actually viewing page source and checking for itemscope/itemprop attributes (Microdata) or RDFa attributes alongside any <script type="application/ld+json"> blocks, not by assuming a single clean implementation exists just because the current developer only added one.
Remove the redundant format entirely rather than trying to keep both in sync. Once a JSON-LD implementation for an entity is in place and verified, the practical fix for a legacy Microdata or RDFa implementation of the same entity isn’t to painstakingly keep both synchronized, it’s to remove the older one. Maintaining two parallel structured data implementations for the same entity indefinitely is strictly higher-maintenance-burden than having one, for no benefit, since Google already tells you it prefers the single JSON-LD format and doesn’t promise any benefit from redundant coverage across formats.
Validate with the Rich Results Test after any format consolidation to confirm the page now presents a single, unambiguous, correctly formatted description of each entity, rather than assuming removal of the redundant markup was clean without checking.
