You inherited a site running Microdata from a legacy CMS integration, added JSON-LD for new schema types, and discovered RDFa fragments from a third-party plugin. Three structured data formats on the same page, each describing overlapping entity properties with slightly different values. Google’s Rich Results Test showed valid markup, but the rich results displayed unexpected property values. The actual processing behavior is more nuanced than a simple format preference hierarchy. Understanding how Google parses, merges, and resolves conflicts across mixed formats determines whether your implementation produces correct or corrupted rich results.
Google’s Multi-Format Parsing Pipeline and Format Detection Order
Google parses all three structured data formats from the rendered DOM, not the raw HTML source. This means JavaScript-injected JSON-LD, dynamically generated Microdata attributes, and RDFa annotations all enter the parsing pipeline after the page is fully rendered by Googlebot’s WRS (Web Rendering Service).
The parser operates independently for each format. JSON-LD blocks are extracted from <script type="application/ld+json"> elements. Microdata is extracted by traversing DOM elements with itemscope, itemtype, and itemprop attributes. RDFa is extracted from elements carrying vocab, typeof, and property attributes. Each format produces a set of semantic triples (subject-predicate-object relationships) that describe entities and their properties.
These extracted triples are not automatically merged into a unified entity graph. Google treats each format’s output as a separate structured data item unless explicit identifiers (like @id in JSON-LD or itemid in Microdata) link them to the same entity. Without matching identifiers, a Product described in JSON-LD and a Product described in Microdata on the same page appear to Google as two separate Product entities.
The parsing order itself is not publicly documented as a priority sequence. Google’s official documentation states that JSON-LD, Microdata, and RDFa are all supported formats. However, John Mueller has noted that Google recommends JSON-LD partly because sites produce fewer implementation errors with it compared to inline formats. The recommendation reflects practical reliability rather than a parsing priority.
Position confidence: Confirmed. Google’s documentation explicitly states support for all three formats and recommends JSON-LD. The independent parsing behavior is confirmed through Rich Results Test output showing separate items per format.
Conflict Resolution Rules When Property Values Disagree Across Formats
When JSON-LD declares a product price of $49.99 and Microdata on the same page declares $44.99, Google does not perform a deterministic merge with a documented priority order. Instead, the behavior depends on whether Google interprets these as the same entity or different entities.
If both formats describe the same entity type without linking identifiers, Google may display either value in rich results. The selection appears non-deterministic from an external observation perspective, meaning the displayed price might alternate between the two values across different crawls or SERP renders. This inconsistency is the most dangerous outcome because it produces intermittently incorrect rich results that are difficult to diagnose.
If both formats use explicit entity identifiers pointing to the same entity (for example, @id in JSON-LD matching the canonical URL, and itemid in Microdata matching the same URL), Google’s parser has a stronger signal that these describe one entity. In observed cases, when identifiers match, JSON-LD property values tend to take precedence. This behavior aligns with Google’s stated preference for JSON-LD but is not documented as a guaranteed resolution rule.
Property type also influences resolution. For properties that must be unique per entity (like price or name), conflicting values force Google to choose one. For properties that can hold multiple values (like image or review), both values may be retained, effectively combining the two formats’ declarations.
The safest assumption is that Google does not guarantee any specific conflict resolution behavior. Any mixed-format implementation producing conflicting values for the same property is operating in undefined territory, and the resulting rich results should be treated as unreliable.
Why JSON-LD Is Preferred but Not Always Authoritative
Google’s documentation recommends JSON-LD, and multiple Google representatives have reinforced this preference publicly. The technical reasoning is straightforward: JSON-LD sits in a separate script block, decoupled from the visible HTML, making it easier to implement correctly and less prone to the nesting errors that plague Microdata implementations. Data shows that sites using JSON-LD experience approximately 23% fewer structured data errors in Search Console compared to Microdata implementations.
However, this decoupling creates a specific vulnerability. Because JSON-LD is separate from the visible page content, there is no inherent constraint preventing JSON-LD from declaring property values that differ from what users actually see on the page. A JSON-LD block could declare a product price of $29.99 while the visible page shows $39.99.
Google’s structured data guidelines explicitly require that markup reflect the content visible to users. When Microdata is embedded inline within the HTML elements displaying the actual content, it is inherently more verifiable. The itemprop="price" attribute on the same <span> element displaying “$39.99” cannot diverge from the visible value without also changing what users see.
In cases where Google detects a discrepancy between JSON-LD declarations and visible page content, the structured data may be flagged as misleading. The manual actions documentation includes structured data spam as a violation category. This does not mean Microdata overrides JSON-LD programmatically. It means that the verifiability advantage of inline formats creates situations where Google’s quality systems may distrust JSON-LD values that cannot be corroborated against visible page content.
Position confidence: Observed. The preference for JSON-LD is confirmed. The verifiability dynamic is observed through cases where inline Microdata values appeared in rich results despite conflicting JSON-LD declarations.
Practical Risks of Mixed-Format Implementations on Rich Result Accuracy
Mixed-format implementations create three distinct failure modes that compound at scale.
Duplicate entity declaration occurs when JSON-LD and Microdata both describe the same entity type without shared identifiers. Google’s Rich Results Test may show two separate Product items, two separate Article items, or two separate LocalBusiness items extracted from the same page. This duplication can cause Google to display rich results sourced from the less accurate of the two declarations, or to suppress rich results entirely due to ambiguity.
Property value conflicts produce incorrect rich results when the two formats declare different values for the same property. Price discrepancies are the highest-risk example because incorrect pricing in rich results can trigger structured data spam manual actions. Review rating discrepancies are the second highest risk because they affect user trust directly in the SERP.
Validation complexity increases exponentially with mixed formats. Debugging a rich results error on a page with both JSON-LD and Microdata requires checking both formats independently, verifying they describe the same entities, confirming property values match across formats, and testing whether the error originates from the format Google selected for display. Standard validation tools like the Rich Results Test show results per structured data item but do not highlight cross-format conflicts. This means a page can pass validation for each format individually while still producing incorrect rich results from the conflict between them.
The diagnostic approach requires extracting the structured data from each format separately (using tools like Google’s Rich Results Test or Schema Markup Validator), comparing property values side by side, and identifying any entities that exist in both formats without shared identifiers.
Migration Strategy for Consolidating to a Single Structured Data Format
Format consolidation, typically to JSON-LD, eliminates conflict risk permanently. The migration must handle three concerns: preventing rich result loss during the transition, capturing all properties from the legacy format, and verifying post-migration output completeness.
Phase 1: Audit and map. Extract all structured data from the current mixed implementation. Document every entity type, every property, and every value source for each format present. Identify properties that exist only in Microdata or RDFa and have no JSON-LD equivalent. These are the properties most likely to be lost during migration.
Phase 2: Build JSON-LD equivalents. Create JSON-LD templates that replicate every property currently declared across all formats. Validate each template against Google’s Rich Results Test before deployment. Ensure that JSON-LD property values match the visible page content exactly.
Phase 3: Deploy JSON-LD alongside legacy formats. Run both formats simultaneously for two to four weeks. Monitor Search Console for structured data errors and rich result changes. Confirm that Google detects and processes the JSON-LD declarations. This parallel period ensures that the JSON-LD implementation is correct before removing the safety net of the legacy format.
Phase 4: Remove legacy formats. Remove Microdata attributes and RDFa annotations from the HTML templates. Deploy the clean version and monitor for any rich result changes over the following two weeks. If rich results drop, the JSON-LD templates are missing a property or value that Google was previously sourcing from the legacy format.
The entire migration should be tracked through Search Console’s enhancement reports, which show rich result eligibility counts per schema type. A drop in eligible items after legacy format removal indicates an incomplete JSON-LD translation.
What specific data conflict patterns in multi-format markup trigger quality review flags?
Format mixing alone does not trigger manual actions or quality flags. The risk emerges when mixed JSON-LD and Microdata implementations produce conflicting property values for the same entity, such as different prices, ratings, or availability statuses for the same product. These accuracy discrepancies signal potential deception during quality review. Pages with consistent values across all format declarations avoid flags entirely. The practical safeguard is a validation pipeline that compares extracted property values across all markup formats before deployment.
Does Google merge properties from JSON-LD and Microdata when both describe the same entity type without shared identifiers?
Without shared @id or itemid identifiers linking them, Google treats JSON-LD and Microdata declarations as separate entities even when they describe the same real-world item. This produces duplicate entity declarations in Google’s parsing output. The duplicates may cause Google to display rich results sourced from either declaration unpredictably, or to suppress rich results entirely due to the ambiguity.
How long should the parallel deployment phase last when migrating from Microdata to JSON-LD?
Two to four weeks of parallel deployment provides sufficient time to confirm Google detects and processes the new JSON-LD while the legacy Microdata serves as a safety net. Monitor Search Console enhancement reports daily during this phase for any drop in rich result eligible items. If eligible item counts remain stable after two weeks, proceed with legacy format removal. If counts drop, the JSON-LD templates are missing properties that need correction before removing Microdata.
