The weighting principle is the same in both cases, Google evaluates page experience signals, Core Web Vitals in particular, on the URL as actually served and rendered to the user. The real difference isn’t in how heavily signals count, it’s in how many URLs there are to evaluate and how much configuration overhead sits between them. A responsive site has one URL carrying the experience for every device, which makes attribution simple. A separate mobile URL (an m-dot configuration) has two distinct URLs, meaning two distinct experiences to measure, correctly annotated and correctly resolved for the version Google actually indexes.
The mechanism: mobile-first indexing measures what’s actually indexed
Since Google completed its shift to mobile-first indexing, the version of a page used for indexing and ranking evaluation is, for the vast majority of sites, the mobile version, regardless of whether that mobile version lives at the same URL as desktop (responsive) or at a separate URL (m-dot). This matters because it means the page experience assessment, including Core Web Vitals field data from the Chrome UX Report, mobile-friendliness, and interstitial checks, is fundamentally a mobile-URL evaluation either way. Google isn’t applying a different weighting scheme to m-dot signals versus responsive signals; it’s evaluating “the URL Google has indexed as the canonical mobile-served experience,” whichever architecture produced that URL.
For a responsive site, there is exactly one URL per page, so the signal path is direct: whatever Core Web Vitals data accumulates for that URL, from real Chrome users on that URL regardless of their device, is the same data feeding the ranking-relevant assessment. There’s no configuration step required to tell Google which version matters, because there’s only one version.
For an m-dot setup, the desktop URL and the mobile URL are technically two separate documents that need to be correctly linked to each other: the desktop page should carry a rel="alternate" annotation pointing to its mobile counterpart, and the mobile page should carry a rel="canonical" pointing back to the desktop URL (this is Google’s documented pattern for separate mobile URLs). If that annotation pairing is missing, broken, or inconsistent, Google can misattribute signals, treat the two as unrelated pages, or fail to correctly identify which URL is the canonical target for indexing purposes, which then complicates rather than changes the weighting of page experience signals themselves.
Why m-dot isn’t inherently disadvantaged, but is more failure-prone
It would be a mistake to conclude m-dot sites are structurally penalized in page experience scoring. Google has consistently said it evaluates whichever configuration is present, provided it’s set up correctly; the ranking system doesn’t have a rule that says “subtract points for having a separate mobile domain.” What actually creates worse outcomes for many m-dot sites in practice is operational: m-dot templates are frequently older, less actively maintained, and slower to receive the same performance investment as the primary desktop template, since engineering attention has shifted toward the main site over time. When an m-dot page is genuinely under-optimized, that shows up as worse real-user Core Web Vitals data, which does affect page experience assessment, but the cause is the underlying page quality, not an m-dot penalty.
There’s also a real risk specific to the architecture: if annotations break (a common failure mode after a redesign or CMS migration), Googlebot can end up indexing the wrong version, evaluating signals for a URL that isn’t actually receiving the intended mobile traffic, or splitting authority signals across two URLs that should be treated as one entity.
A related failure mode: dynamic serving
A third architecture worth distinguishing here, though less common today, is dynamic serving, one URL that returns different HTML or CSS depending on the detected user agent, rather than a separate mobile URL or a single responsive markup. Dynamic serving sits between the other two approaches: it shares the URL-simplicity of responsive design (no separate mobile URL to annotate) but reintroduces some of m-dot’s fragility, because it depends on a Vary: User-Agent HTTP header being correctly set so caching layers (browser caches, CDNs, proxies) don’t serve the wrong version of the page to the wrong device type. If that header is missing or a caching layer ignores it, a user can end up served the desktop markup on mobile or vice versa, which creates a genuine page-experience problem, not a measurement artifact, since the actual rendered experience for that user is now wrong for their device. Google’s guidance on dynamic serving has long flagged this specific header requirement as the detail most likely to be overlooked during implementation.
Practical implication
For sites still running m-dot architecture, the priority is auditing the rel="alternate"/rel="canonical" pairing across every template and verifying it survives redesigns, since that relationship is what keeps Google correctly resolving the two URLs as a single logical page rather than fragmenting signals. It’s also worth checking Core Web Vitals data specifically on the m-dot URLs in the Chrome UX Report or Search Console, not just the desktop domain, since that’s the version mobile-first indexing is actually scoring. A useful audit trigger is any recent redesign, CMS migration, or vendor change, since annotation pairings are exactly the kind of cross-template configuration detail that quietly breaks during those projects without anyone noticing until rankings or indexing behavior shifts weeks later.
For sites on responsive design, this entire category of failure mode simply doesn’t exist, one URL, one canonical signal path, correctly evaluated by default. That operational simplicity, not a difference in how signals are weighted, is the real advantage responsive design has over maintaining separate mobile URLs at this point in Google’s indexing evolution. It’s a large part of why most publishers who migrated away from m-dot architecture over the past decade did so, not because Google penalized the old structure, but because eliminating an entire class of annotation-maintenance risk was worth the migration effort on its own.
A worked example of annotation drift causing a measurement gap
Suppose Site X runs a classic m-dot setup, with desktop pages at siteX.com/product and a parallel mobile version at m.siteX.com/product, correctly cross-annotated for years. During a CMS migration, the team rebuilds the desktop templates but the developer handling the change forgets to carry over the rel="alternate" tag pointing to the mobile URL on twelve of the site’s fifty templates. For those twelve templates, Google can no longer confidently resolve which mobile URL corresponds to which desktop page, and Search Console’s Core Web Vitals report starts showing those mobile URLs as a separate, unlinked group of pages with thin traffic and inconsistent field data, even though the actual m.siteX.com pages are rendering fine for real users. A responsive competitor covering the same twelve product categories has no such gap, because there was never a second URL and annotation pair to keep in sync in the first place. Site X’s page experience signals weren’t judged more harshly for being m-dot; the annotation break simply left Google unable to cleanly attribute the mobile experience to the right canonical page, which is the operational risk responsive design never has to manage.
