Google’s mobile-first indexing shift means that page experience signals are primarily evaluated based on the mobile version of a page. For responsive sites, the canonical URL serves both mobile and desktop, and CrUX data from mobile Chrome users on that URL directly determines the page experience assessment. For sites with separate mobile URLs (m.example.com or dynamic serving), the signal path is more complex: Google must associate the mobile URL’s CrUX data with the desktop canonical, and misconfigurations in this association are a documented source of page experience signal loss. This architectural choice has measurable consequences for how reliably your performance data translates into ranking signals.
How CrUX Data Maps to Page Experience Signals Under Each Architecture
For responsive sites, the signal path is direct. CrUX collects performance data from mobile Chrome sessions on the canonical URL (www.example.com/page). This same URL is what Google indexes, ranks, and evaluates for page experience. The CrUX data and the ranking evaluation share a single URL identifier. There is no translation, mapping, or association step.
For sites with separate mobile URLs (m.example.com/page), CrUX collects performance data on the mobile URL where real Chrome users browse. Google must then associate this CrUX data with the desktop canonical URL (www.example.com/page), because under mobile-first indexing, Google internally treats the mobile version as the canonical even when the explicit canonical tag points to the desktop URL. John Mueller has confirmed that Google selects the mobile version as the canonical internally, regardless of which version the webmaster designates.
This association depends on correct bidirectional annotations: the desktop page must include <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page"> and the mobile page must include <link rel="canonical" href="https://www.example.com/page">. Both annotations must be present, consistent, and correct for Google to properly associate the mobile CrUX data with the desktop canonical for ranking evaluation.
When these annotations are missing, inconsistent, or point to incorrect URLs, Google may fail to associate the mobile CrUX data with the canonical. In such cases, Google may evaluate page experience using whatever CrUX data it can find for the canonical URL — which might be desktop Chrome data, incomplete mobile data, or no data at all. The result is a page experience assessment that does not reflect the actual mobile user experience.
The Signal Association Risk with Separate Mobile URLs
The rel="alternate" annotation on the desktop page must point to the exact correct mobile URL, and the mobile URL must canonical back to the exact correct desktop URL. This bidirectional mapping must hold for every URL pair across the entire site. On a 50,000-page site, that is 50,000 URL pairs that must be validated and maintained.
Annotation breakage occurs through several common patterns. Partial migrations that move some pages to responsive design while leaving others on separate mobile URLs create inconsistent annotation patterns. CMS updates that change URL structures on one version but not the other break the mapping. Template changes that modify the mobile URL pattern (adding or removing path segments) invalidate existing desktop annotations. Pagination where the desktop and mobile versions paginate differently creates URL pairs that cannot be mapped one-to-one.
These breakages happen silently. There is no Google Search Console alert for broken mobile-desktop URL associations. The only diagnostic signal is comparing CrUX data for the desktop canonical against expected mobile performance. If the CrUX data for the canonical URL shows desktop-like performance characteristics (larger viewports, faster connections) rather than mobile characteristics, the mobile CrUX data association has likely broken.
For sites with thousands of pages, annotation auditing at scale is a persistent operational burden. Google’s own documentation recommends responsive design specifically to avoid this complexity, stating that responsive design is the easiest configuration to implement and maintain.
Mobile-First Indexing and Which Version Google Evaluates
Since July 2024, mobile-first indexing is fully rolled out — sites whose content is not accessible on mobile devices are no longer indexable at all. Google crawls the mobile version of every site as its primary indexing source, regardless of the mobile configuration architecture.
For responsive sites, the mobile version is the same URL rendered at a mobile viewport. Google’s crawler renders the page with a mobile user agent and viewport, and the responsive CSS delivers the mobile layout. Content, internal links, structured data, and meta tags are all present in the single URL’s HTML.
For separate mobile sites, Google crawls m.example.com/page and uses that version’s content, structured data, and internal links as the primary indexing source. If the mobile site has different content than the desktop site — fewer images, shorter text, simplified navigation, missing breadcrumbs, reduced structured data — Google indexes the mobile version’s content, not the desktop version’s richer content.
This content parity requirement is critical. Internal links removed from the mobile version to save screen space (breadcrumbs, footer links, sidebar navigation) reduce PageRank flow through the mobile version that Google indexes. Structured data absent from the mobile version means Google does not process those signals. Meta descriptions or Open Graph tags present only on the desktop version are invisible to Google’s mobile-first crawler.
Page experience evaluation follows the same path. Google evaluates the mobile version’s performance as captured in CrUX. If the mobile version loads slower than the desktop version (due to different server infrastructure, different CDN configuration, or different resource optimization), the slower mobile performance is what determines the page experience assessment.
Responsive Design’s Signal Clarity Advantage and When Separate URLs Remain Justified
Responsive design eliminates the signal association problem entirely. One URL serves all devices. One CrUX dataset captures all user experiences. Google evaluates that single dataset for page experience. There is no annotation to break, no canonical mismatch to debug, and no risk of desktop CrUX data being substituted for missing mobile CrUX data.
The simplicity of the responsive signal path provides several specific advantages beyond the commonly cited content parity benefit:
- CrUX data completeness: all mobile Chrome sessions contribute to a single URL’s CrUX dataset. With separate URLs, mobile traffic splits between the mobile URL (where users browse) and potentially the desktop URL (if some users are not redirected correctly), fragmenting the data pool.
- Internal link consolidation: all backlinks, internal links, and social shares point to one URL. With separate URLs, link equity splits between desktop and mobile URLs despite canonical consolidation.
- Indexing consistency: there is no possibility of Google crawling one version and evaluating performance on a different version. The crawled URL and the CrUX-evaluated URL are identical.
- Maintenance simplicity: performance optimizations apply to all users through the single codebase. With separate URLs, performance work must be duplicated across both versions or carefully synchronized between them.
Google explicitly recommends responsive design as the preferred configuration for these reasons. The recommendation is not solely about developer convenience — it reflects the reduced risk of signal loss in Google’s own evaluation pipeline.
Some organizations maintain separate mobile URLs for legitimate architectural reasons that outweigh the signal clarity advantage of responsive design.
Legacy systems that cannot be migrated to responsive design without a complete rebuild may require maintaining separate mobile URLs during a multi-year migration timeline. The migration cost and risk may exceed the signal clarity benefit in the short term.
Fundamentally different mobile experiences — a mobile banking app with a web fallback, a simplified e-commerce checkout flow, or a mobile-specific content format — may require separate URL structures to deliver the appropriate experience for each device context.
Performance optimization at the server level: some sites serve dramatically different HTML payloads for mobile (smaller images, fewer scripts, simpler DOM) that cannot be achieved with responsive CSS alone. Dynamic serving from the same URL achieves this without separate URLs, but legacy architectures may not support it.
For these sites, the mitigation is rigorous bidirectional annotation monitoring using automated crawling tools (Screaming Frog, Sitebulb, or similar) that validate mobile-desktop URL pair consistency. CrUX data validation per URL pair confirms that Google is receiving mobile performance data for the canonical. Regular auditing of the mobile URL’s content parity — structured data, internal links, meta tags, and content completeness — ensures the mobile version provides Google with the full signal set.
Does Google evaluate desktop Core Web Vitals at all for ranking, or only the mobile version?
Google uses mobile-first indexing, which means the mobile version is the primary source for ranking signals including page experience. Desktop CWV data exists in CrUX and may influence desktop search results, but the mobile assessment is what determines page experience status for the vast majority of queries. Sites that pass mobile CWV but fail desktop CWV do not face a mobile ranking penalty from the desktop failure.
Can responsive sites have different CrUX scores for mobile and desktop even though they serve the same URL?
Yes. CrUX segments data by form factor even for the same URL. A responsive page may pass CWV on desktop where devices have faster CPUs and wider viewports, but fail on mobile where image decoding is slower, JavaScript execution takes longer, and layout shifts from dynamic content are more frequent. Both scores are reported separately in CrUX and evaluated independently for their respective search contexts.
Does using the Vary: User-Agent header on separate mobile URLs affect how CrUX associates performance data?
No. CrUX identifies the page by the URL the user visited, regardless of server-side Vary headers. If mobile users visit m.example.com and desktop users visit www.example.com, CrUX records separate entries for each URL. The Vary header affects CDN caching behavior but does not change how CrUX attributes performance data to URLs or origins.
Sources
- https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing
- https://developers.google.com/search/docs/appearance/core-web-vitals
- https://ahrefs.com/blog/mobile-first-indexing/
- https://www.lumar.io/office-hours/separate-mobile/
- https://developer.chrome.com/docs/crux/methodology/metrics
