Should you really duplicate your structured data between mobile and desktop?

Why does Google insist on duplicating structured data?

The reason relates to the mobile-first indexing architecture. When Google crawls your site, it now prioritizes the mobile version for indexing and ranking your pages. If your structured data is only present on the desktop version, the engine may completely ignore it during mobile crawling.

This situation specifically affects sites using distinct URLs for mobile and desktop (such as m.example.com or mobile.example.com). Responsive sites are not affected since they serve the same HTML regardless of the request's origin. Confusion often arises because many professionals think the rel=alternate and rel=canonical annotations are sufficient for Google to understand the relationship between the versions.

What types of structured data are affected by this requirement?

Google targets all schema.org markups that generate rich results: articles, products, recipes, events, FAQs, reviews, job offers, breadcrumbs. Anything that can trigger the display of a rich snippet or enriched card in SERPs must be present on both versions.

The classic pitfall? Implementing a full Product markup on the desktop side with price, availability, and reviews, then drastically simplifying the mobile version by removing structured data in the name of reducing code. Google crawls your mobile version, doesn't find product data, and your rich snippets disappear from search results.

Is this requirement truly applicable to all sites with separate versions?

Google's wording leaves little room for doubt: if you maintain distinct mobile and desktop versions, structured data must be duplicated. This rule applies even if your mobile traffic constitutes 95% of your visits and almost no one views the desktop version anymore.

The logic behind this constraint is that Google cannot guess which version you consider the reference. In the absence of structured data on one version, the engine assumes that the rich content simply does not exist on that variant, even if link rel annotations indicate equivalence between the URLs.

• Responsive sites are exempt from this requirement as they serve the same HTML code to both types of devices.
• Dynamic serving configurations (same URL, different HTML based on user-agent) are also affected and must duplicate schema.org.
• Desynchronization between versions is the primary risk: an updated price on desktop not reflected on mobile creates inconsistencies detectable by Google.
• Google testing tools (Rich Results Test, Search Console) should be used on each version to validate the presence and consistency of structured data.
• The maintenance cost doubles mechanically as each rich content modification must be applied in two distinct places.

Is this statement consistent with what we observe in the field?

In essence, yes. Audits regularly reveal sites with separate versions that lose their rich results after the shift to mobile-first indexing, specifically because structured data was only implemented on the desktop side. Google Search Console also reports explicit errors when schema.org is absent from the mobile version.

Where it gets tricky: Google does not specify how it handles inconsistencies between versions. If a product's price differs between mobile and desktop in the schema.org markup, which version takes precedence? Field tests suggest that the mobile version always prevails since mobile-first indexing, but Google has never officially confirmed this behavior. [To be verified]

Why doesn't Google unify the reading of structured data between linked versions?

This is the real question that this statement skims over. Technically, Google could perfectly read the rel=alternate/canonical annotations, identify that two URLs represent the same content, and consolidate the structured data found on either version. The engine already performs this type of consolidation for other signals.

The likely explanation lies in the granularity of crawling. Google does not necessarily crawl both versions of a page at the same time or with the same frequency. Requiring the presence of data on each version simplifies the indexing pipeline: the bot extracts schema.org from the version it crawls, period. No dependencies, no complex consolidation, no risk of temporal inconsistency.

What edge cases does Google not mention?

First blind spot: sites using client-side JavaScript to inject structured data. If this JS only executes on desktop, the crawled mobile version will contain no schema.org, even if the source code is identical. Google crawls the final render, and if your structured data only appears after executing JS that's desktop-only, they are invisible to the mobile bot.

Second gray area: conditional structured data. Some sites display different schema.org depending on user context (geolocation, authentication, personalization). How to manage these cases when mobile and desktop have divergent personalization logics? Google remains silent on this point. [To be verified]

What concrete steps should be taken to ensure compliance?

Start with a differentiated audit of both versions. Use Google's Rich Results Test in both mobile AND desktop mode on your strategic pages. Compare the detected schema.org: absences, differences in values, syntax errors. Search Console also provides a report dedicated to rich results with filtering by device type.

Next, implement a unified generation logic. The classic mistake is hardcoding structured data into the mobile and desktop templates separately. Result: each modification requires two interventions, and desynchronization looms. Instead, favor a single source (database, CMS, API) that dynamically generates identical schema.org for both versions.

What mistakes should be avoided when duplicating structured data?

Avoid the trap of excessive simplification on mobile. Under the pretext of reducing page weight, some developers remove optional properties of schema.org on mobile. Google interprets this difference as a signal that mobile content is less rich, which can negatively impact ranking.

Also, avoid factual data inconsistencies between versions. If your Product markup indicates a price of €49 on desktop and €45 on mobile, Google detects an anomaly. The same logic applies to event dates, review scores, and stock quantities. Any numerical divergence potentially triggers a quality flag that could remove your rich snippets.

How to verify that structured data is correctly synchronized?

Set up automated monitoring. Tools like Schema Markup Validator, OnCrawl, or Screaming Frog allow you to crawl both mobile and desktop versions simultaneously and then compare the extracted schema.org. Configure alerts in case of detected divergence on critical properties (price, availability, ratings).

Also test the actual rendering in Google Search Console. The URL Inspection feature shows you exactly what Googlebot sees and extracts as structured data, both mobile and desktop. Compare the two renders: if differences appear while your source code is supposed to be identical, it’s likely a JavaScript execution issue or a user-agent detection problem.

• Audit both versions with Rich Results Test and identify any absence or divergence of schema.org.
• Centralize the generation of structured data via a shared single source between mobile and desktop.
• Validate the consistency of factual values (prices, dates, quantities) between both versions.
• Configure automated monitoring to detect desynchronization after each deployment.
• Test the Googlebot render via Search Console to confirm that structured data is properly crawled and interpreted.
• Document the updating process to ensure that every schema.org change is systematically applied to both versions.