You implemented comprehensive structured data on your desktop pages — product schema, FAQ markup, breadcrumb schema, review aggregates. Rich results were appearing in search. Then they disappeared. No code changes were made. The cause: your mobile template, which Google now uses as the primary indexing source, was loading a stripped-down version of the structured data — or none at all. Under mobile-first indexing, structured data that exists only on the desktop version is invisible to Google’s primary indexer, which means rich results, enhanced SERP features, and knowledge graph eligibility depend entirely on what the mobile version delivers.
Mobile-first indexing uses the mobile page as the sole primary source for structured data
As of July 5, 2024, Google completed the full transition to mobile-first indexing across 100% of websites. John Mueller confirmed that even the final holdout sites previously crawled with desktop Googlebot switched to Googlebot Smartphone after that date. There is no desktop fallback. The mobile-rendered version of every page is the singular source for indexing signals, including structured data.
When Googlebot Smartphone fetches and renders a page, it processes the JSON-LD, Microdata, or RDFa present in the rendered DOM of that mobile version. Structured data that exists only in the desktop version’s HTML — whether because the mobile template omits it, the JavaScript that injects it runs only above a certain viewport width, or the server delivers different HTML to mobile user agents — is not indexed. Google’s Search Central blog post on mobile-first indexing and structured data states this directly: structured data should be present on both versions of the page.
The consequence for rich results is immediate. Google’s Rich Results Test evaluates structured data from the mobile-rendered version. If Product schema exists on the desktop version but is absent from the mobile version, the page loses eligibility for product rich results, price annotations in search, and merchant listing features. The desktop version’s structured data is effectively invisible to the systems that determine rich result eligibility.
JSON-LD blocks are the most common casualty because they are often injected via JavaScript. If the script responsible for JSON-LD injection uses viewport-width detection or device-capability checks to determine execution, it may run on desktop browsers but not during Googlebot Smartphone’s rendering pass. Googlebot Smartphone uses a Chromium-based renderer with a specific viewport width (approximately 412px by 823px), and scripts that check window.innerWidth or media query conditions may bypass JSON-LD injection on this viewport.
One subtle failure mode involves conditional data loading. A product page that fetches review aggregates via an API call and injects them as JSON-LD may succeed on desktop where the API call completes within the rendering window but fail on mobile where the API response is slower or the rendering budget is exhausted before the injection completes.
Common parity gaps: where mobile versions typically omit structured data
The most frequent structured data parity failures fall into predictable categories, each with a distinct technical cause.
Viewport-conditional script execution. JavaScript that checks viewport width before injecting structured data will fail when Googlebot Smartphone’s viewport does not meet the condition. A script that injects FAQ schema only when window.innerWidth > 768 will never execute for Googlebot Smartphone. The fix is to remove viewport conditions from structured data injection logic. Structured data is not a visual element — it does not need viewport-responsive behavior.
Server-side template divergence. Sites using separate mobile templates (m.example.com or dynamic serving that delivers different HTML based on User-Agent) frequently have structured data on the desktop template that was never ported to the mobile template. This is the most straightforward parity gap to identify and fix: compare the HTML source of both versions and add missing schema to the mobile template.
AMP page schema mismatches. Sites that maintain AMP versions may implement different structured data on AMP pages than on their canonical pages. If the AMP page is the one Google indexes (as determined by the canonical/amphtml link relationship), its schema is what determines rich result eligibility. AMP pages that implement Article schema but omit Product or FAQ schema present on the canonical page lose those rich result types.
CSS display:none hiding schema-containing elements. While Google generally processes content in elements hidden with display:none, the behavior for structured data is nuanced. JSON-LD blocks in the <head> or <body> are processed regardless of CSS visibility because JSON-LD is not tied to visible elements. However, Microdata or RDFa embedded in HTML elements that are hidden via CSS may not be processed reliably if the hidden elements are also stripped from the rendered DOM by the mobile template.
Lazy-loaded or deferred schema injection. Structured data injected after a user interaction (click to expand, scroll to section, load more button) is not processed by Googlebot. The renderer does not simulate user interactions. Schema must be present in the initial render — either in the HTML source or injected by JavaScript that executes without user input during the initial page load.
Rendering differences and parity evaluation beyond structured data
Structured data is the most visible parity gap because the impact — lost rich results — is immediately noticeable. But mobile-first indexing parity requirements extend to every indexable element on the page.
Body content parity is the highest-impact requirement. Google has stated that if content is not on the mobile version, it does not exist for ranking purposes. Developers frequently hide secondary content sections, sidebar text, or expanded product descriptions on mobile to improve load times or visual cleanliness. Under mobile-first indexing, this hidden content is not indexed. Accordion menus and expandable tabs are acceptable — Google reads the full text regardless of CSS display state — but content gated behind JavaScript interactions (load more buttons, infinite scroll triggers) may not be processed.
Internal link parity affects crawl discovery and PageRank flow. If the mobile navigation omits links present in the desktop version (e.g., a mega menu reduced to a hamburger menu with fewer links), those omitted links do not contribute to crawl discovery or equity distribution under mobile-first indexing. The internal link graph that Google uses for ranking is built from the mobile-rendered DOM.
Meta tag parity includes title tags, meta descriptions, and robots directives. If the mobile template generates different title tags (common with dynamic title generation that varies by viewport), the mobile title is what Google indexes. Discrepancies in robots meta tags between versions can cause pages to be indexed on one version and noindexed on another.
Image alt text parity affects image search visibility. Images on the mobile version without alt text (or with different alt text than the desktop version) will be indexed with the mobile version’s attributes. Sites that lazy-load images on mobile without proper alt text lose image search signals.
Heading hierarchy affects semantic understanding. A desktop page with a clear H1-H2-H3 hierarchy that is restructured on mobile (e.g., headings removed for visual compactness) provides Google with a different semantic signal. The mobile heading structure is what Google uses for content understanding and potential featured snippet extraction.
Parity requirements ranked by ranking impact: (1) body content, (2) internal links, (3) structured data, (4) meta tags, (5) images and alt text, (6) heading structure.
Googlebot Smartphone renders pages using a Chromium-based engine (the Web Rendering Service, or WRS) that matches a specific Chrome version. As of 2024-2025, the WRS uses a recent stable Chrome release, updated periodically. The user-agent string identifies as a Nexus-class device, and the rendering viewport is approximately 412×823 pixels.
Critical differences between Googlebot Smartphone’s rendering environment and actual mobile devices:
No touch events. Googlebot does not simulate touch interactions. Content loaded via touch event handlers (touchstart, touchend, swipe gestures) is not triggered during rendering. If structured data injection or content loading depends on touch events, it will not execute.
No scroll simulation. Googlebot renders the page and captures the DOM state after initial JavaScript execution completes (or after a timeout). It does not scroll the page. Content loaded via scroll-triggered JavaScript (IntersectionObserver callbacks, infinite scroll loaders) executes only if the observer triggers based on the initial viewport position.
Fixed rendering timeout. The WRS allocates a finite rendering budget per page. If JavaScript execution exceeds this budget, the render is captured in its current state. Heavy JavaScript applications that load content progressively over several seconds may be captured before critical content or structured data has been injected.
No service workers. Googlebot does not support service workers. Sites that use service workers to cache and serve content, including dynamically injected structured data, will not see this content processed during Googlebot’s render.
No device-specific APIs. APIs that depend on device capabilities (accelerometer, camera, geolocation, NFC) are unavailable. Content conditionally loaded based on these APIs will not render.
These rendering differences mean that testing mobile parity requires rendering the page specifically as Googlebot Smartphone sees it, not as a standard mobile browser sees it. The URL Inspection tool in Search Console provides the most authoritative view of what Googlebot renders. Chrome DevTools mobile emulation can approximate the viewport but does not replicate the WRS rendering environment.
Parity audit methodology and ongoing monitoring framework
A one-time audit is insufficient because template changes, CMS plugin updates, third-party script modifications, and A/B testing tools can reintroduce parity gaps at any time. The audit methodology must include both initial detection and ongoing monitoring.
Initial parity audit:
- Crawl the site with both user agents. Using Screaming Frog, Sitebulb, or an equivalent crawler, perform two separate crawls: one with the Googlebot Desktop user agent and one with the Googlebot Smartphone user agent. Store both datasets for comparison.
- Compare structured data between crawls. For each URL, extract the JSON-LD blocks from both versions. Identify URLs where desktop JSON-LD types (Product, FAQ, Breadcrumb, Review) are absent from the mobile version. Flag any URLs where the mobile JSON-LD contains fewer properties or different values than the desktop version.
- Compare content and link counts. For each URL, compare word count, heading count, internal link count, and image count between the desktop and mobile crawls. Pages where the mobile version has significantly fewer words (more than 10% difference), fewer internal links, or missing headings require investigation.
- Validate with URL Inspection. For flagged URLs, use the URL Inspection tool in Search Console to verify what Googlebot Smartphone actually renders. The “View Tested Page” option shows the rendered HTML and a screenshot. Compare the rendered structured data against what the audit crawler found.
- Test structured data with Rich Results Test. Run flagged URLs through Google’s Rich Results Test, which tests the mobile-rendered version. If rich result types present on desktop are missing from the Rich Results Test output, the parity gap is confirmed.
Ongoing monitoring framework:
- Automated crawl comparison on a weekly or biweekly schedule. Compare the current mobile crawl against the previous crawl to detect newly introduced parity gaps. CMS updates and theme changes are the most common triggers.
- Rich result monitoring via Search Console’s Enhancements report. A drop in rich result counts (Product, FAQ, Review) that does not coincide with content changes suggests a parity regression.
- Structured data validation in deployment pipelines. Add automated checks to staging/pre-production deployments that compare mobile and desktop structured data. Block deployment if parity tests fail.
- Third-party script auditing. Marketing tags, A/B testing scripts, and consent management platforms can modify the DOM in ways that affect structured data. Audit these scripts quarterly for mobile-specific behavior changes.
The mobile-first indexing ranking diagnosis framework provides the methodology for identifying when parity gaps have already caused ranking impact, complementing this preventive audit approach.
Does lazy-loaded content that requires user scroll interaction appear in Googlebot Smartphone’s mobile-first index?
Googlebot Smartphone does not simulate scrolling behavior. Content loaded through scroll-triggered lazy loading only appears in the index if it is present in the initial rendered DOM or loaded through intersection observer patterns that fire without actual scroll events. Content gated behind scroll depth thresholds will not be indexed. For mobile templates using lazy loading, verifying that critical content renders in the initial viewport or through non-scroll-dependent triggers is essential.
Does a responsive design automatically guarantee content parity for mobile-first indexing?
Responsive design serves the same HTML to both mobile and desktop crawlers, which eliminates most parity risks. However, CSS-based content hiding (display:none on mobile viewport sizes) can create parity gaps that responsive design does not prevent. Googlebot renders the page at a mobile viewport width, so any content hidden at mobile breakpoints is invisible to the primary indexing crawler. Responsive design is the recommended approach, but CSS visibility rules still require review for mobile-specific content suppression.
Does mobile-first indexing affect how Google evaluates internal links for PageRank flow if the mobile navigation has fewer links?
Under mobile-first indexing, the internal link graph visible to Googlebot Smartphone is the primary source for PageRank calculations. A mobile navigation that removes sidebar links, collapses menu categories, or hides footer links reduces the internal link equity flowing to those target pages. Pages that rely on desktop-only navigation links for their internal authority may see ranking declines after mobile-first indexing because the mobile crawler’s view of the link graph is the one that counts.
Sources
- Google Search Central. “Mobile-First Indexing Best Practices.” https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
- Google Search Central Blog. “Mobile-First Indexing, Structured Data, Images, and Your Site.” https://developers.google.com/search/blog/2018/12/mobile-first-indexing-structured-data
- Search Engine Land. “Mobile-First Indexing: Everything You Need to Know.” https://searchengineland.com/mobile-first-indexing-everything-you-need-to-know-450286
- Screaming Frog. “How to Perform a Parity Audit.” https://www.screamingfrog.co.uk/seo-spider/tutorials/how-to-perform-a-parity-audit/
- Kasra Dash. “Mobile-First Indexing: How Google Crawls, Renders, and Ranks Your Site.” https://kasradash.com/seo/technical-seo/mobile-first-indexing/
