Under mobile-first indexing, the mobile version of a page is the primary basis Google uses for indexing and ranking, and that includes structured data. If your mobile template strips out schema markup that’s present on desktop, whether intentionally (someone assumed structured data was a “desktop-only” concern) or as a side effect of a lighter mobile build, that structured data is effectively invisible to Google for the purposes of rich-result eligibility and entity understanding. The desktop-only markup existing somewhere on the same URL’s desktop rendering doesn’t help, because mobile-first indexing means the mobile-rendered version is what Google is actually evaluating.
Why this happens
Google’s mobile-first indexing documentation explicitly lists structured data as one of the parity elements it expects to see matched between mobile and desktop versions, right alongside main content, images, and metadata. This isn’t an incidental detail, it’s called out specifically because structured data gaps were a known and common failure mode as sites transitioned to mobile-first indexing. A common cause is templates that were built with the assumption that structured JSON-LD or microdata is a technical/backend concern unrelated to the visual mobile experience, so it gets deprioritized or conditionally excluded when a mobile template is built or when a responsive design serves a stripped-down component tree on smaller viewports.
The consequence is concrete and measurable: any rich result eligibility (review stars, FAQ markup, product pricing/availability, recipe cards, event listings, whatever schema type is affected) that depends on that structured data disappears if the schema isn’t present in what Google crawls and renders as the canonical mobile version. There’s no separate, exempt indexing path where desktop structured data gets credited even though the mobile version lacks it; the parity requirement described in Google’s own documentation applies uniformly.
This failure mode is often silent from a site owner’s perspective, because the page still looks fine to a human visiting the desktop site, and even the mobile page still “works” visually, it’s simply missing markup that a person browsing normally would never notice is absent. The gap only becomes visible when rich results quietly stop appearing or when someone specifically checks the mobile-rendered source.
Common template causes worth checking specifically
Most instances of this gap trace back to a handful of recurring template patterns rather than a one-off mistake, and knowing the pattern in advance makes the audit much faster than starting from a blank slate.
Conditional rendering logic tied to viewport or user-agent detection is the most common root cause. A template built with a “mobile-lite” philosophy sometimes strips components deemed non-essential for a smaller screen, and if the JSON-LD block was implemented as part of a component that only renders in a desktop code path (a sidebar widget, a review-summary component, a product-detail panel), that same component’s schema output disappears along with its visual counterpart on mobile, even though the underlying data still exists in the CMS. This is especially common with server-side rendering setups that branch logic based on user-agent sniffing rather than serving one shared markup structure with responsive CSS, since user-agent branching creates two genuinely different HTML payloads that can silently drift out of sync as either template gets updated independently over time.
A second common cause, now mostly historical but still present on sites that migrated late or incompletely, comes from AMP-versus-canonical schema duplication mismatches. In the AMP era, many implementations required structured data to be maintained separately in the AMP HTML and the canonical page, and it wasn’t unusual for a schema update applied to one to never get mirrored to the other. Sites that have since deprecated AMP but built their current mobile template on top of what was originally an AMP component library sometimes inherited this same duplication pattern without anyone noticing, since the AMP-specific quirks got carried forward into a non-AMP mobile template.
A third, subtler cause is schema that’s injected via tag manager rules scoped to specific page templates or breakpoints. If a JSON-LD snippet was added through Google Tag Manager with a trigger condition that inadvertently excludes mobile viewports (a common mistake when a trigger is copied from an unrelated desktop-only campaign tag and never re-scoped), the schema simply never fires on mobile, and this kind of gap is particularly easy to miss because the tag manager container looks correctly configured at a glance, the fault is buried in the trigger condition rather than the tag itself.
What to do about it
- Run the Rich Results Test or the structured-data validation available in Search Console against the mobile-rendered version of affected URLs specifically, not just the desktop version. Testing desktop alone can pass cleanly while the actual indexed (mobile) version has already lost the markup.
- Use URL Inspection in Search Console to view the actual crawled/rendered page and confirm structured data appears in what Google is really indexing, rather than assuming parity based on what a developer intended.
- If your site uses separate mobile and desktop templates (rather than a single responsive template), audit each template’s structured data implementation independently. Divergent templates are the highest-risk architecture for this specific gap, since schema has to be deliberately duplicated rather than inherently shared.
- Treat structured data as core content parity, not a backend afterthought, when reviewing any mobile-first indexing migration or template redesign checklist. It belongs in the same audit category as visible text, images, and metadata.
- After fixing a parity gap, re-verify rich result appearance over time rather than assuming an immediate restoration, since rich result eligibility involves Google’s own evaluation timing beyond just the presence of valid markup.
Auditing at scale instead of spot-checking one URL at a time
Checking a single URL with the Rich Results Test tells you nothing reliable about a template-driven problem, since the whole point of a template-level bug is that it affects every page built on that template, potentially hundreds or thousands of URLs at once. Spot-checking one product page or one review-bearing article and finding it clean doesn’t rule out the same gap existing on a different template used elsewhere on the same site, and spot-checking one broken page doesn’t tell you how widespread the problem actually is across your URL inventory.
The more reliable approach is a bulk crawl that renders both the mobile and desktop version of every URL (or a representative sample per template type) and extracts the structured data present in each rendered output, then diffs the two. A crawler like Screaming Frog, configured in JavaScript-rendering mode with the user-agent and viewport set to mobile for one crawl pass and desktop for a second pass, can extract structured data (via its structured data extraction feature or custom extraction rules targeting JSON-LD script tags) from the actual rendered DOM rather than the raw served HTML, which matters because JavaScript-injected schema won’t show up in a crawl that only reads initial HTML. Running this as two separate crawls, one per device type, and then comparing the extracted schema output URL-by-URL is what actually surfaces the scope of a parity gap: which templates are affected, how many URLs, and which schema types are missing, rather than relying on anecdotal single-URL checks that happen to catch or miss the issue depending on which page you picked.
This kind of paired crawl-and-diff is also the only practical way to catch a partial regression, where a template update fixes the gap for new pages going forward but leaves older cached or statically-generated pages still serving the stale, schema-stripped mobile version. A one-off spot check on a newly published page would pass, while the bulk of the historical URL inventory remains broken.
Rich result types most commonly affected
Not all schema types are equally exposed to this failure mode, since exposure depends on which components tend to get treated as “desktop extras” during mobile template simplification. Review and rating snippet markup is frequently affected because review summary widgets are a common candidate for simplification or removal on mobile-condensed product and listing pages, even when the underlying review content itself remains visible in some reduced form. Product markup (price, availability, SKU-level detail) is similarly exposed on ecommerce templates where a mobile product page shows a simplified buy box without carrying the same structured payload as the desktop version. FAQ markup is a third common casualty, particularly on sites that implemented FAQPage schema against accordion-style FAQ components, since accordion content is exactly the kind of interaction-dependent, collapsible element that’s prone to being restructured or trimmed differently between device-specific templates. Any one of these missing on mobile means the associated rich result won’t appear for that URL under mobile-first indexing, regardless of how solid the desktop implementation looks.
The underlying principle is simple: mobile-first indexing means “mobile is what counts,” and that applies to every parity element Google has explicitly named, structured data included, not just the visibly readable content a person would notice while browsing.
A worked example of a silent parity gap
Picture a mid-size recipe site, Site X, where the desktop template includes a review-summary component with Recipe and AggregateRating JSON-LD, built by a developer who treated that widget as a “sidebar extra” and conditionally excluded it from the mobile component tree to keep the mobile layout lighter. The mobile page still displays the recipe content, ingredients, and steps normally, a visiting reader would never notice anything missing, but the rendered mobile HTML that Google actually indexes under mobile-first indexing carries no rating markup at all. Star-rating rich results for that page, which had been appearing consistently for over a year, quietly stop showing up in search results within a few weeks, with no manual action, no Search Console penalty notice, and no visible change to the page itself. The gap is only caught when someone runs the Rich Results Test against the mobile-rendered URL specifically rather than the desktop version, which had continued to pass cleanly the entire time since its own component tree was never touched.
