Why does Google sometimes show M-Dot URLs in desktop results?

What does mobile-first indexing actually change?

Mobile-first indexing means that Googlebot crawls and indexes the mobile version of your site primarily, even for determining rankings in desktop results. If you're using a M-Dot architecture (separate mobile and desktop versions on different subdomains), Google discovers and indexes your m.example.com URLs first.

The problem arises when your redirects only work one way. You may have set up a desktop → mobile redirect for mobile users, but forgot the opposite. As a result, Google indexes m.example.com, and when a desktop user clicks, they end up on the mobile version because the server does not return a 302 redirect to www.example.com.

Why doesn't Google always use the desktop URL?

Let's be honest: Google displays the URL it has indexed. With mobile-first, that's often the M-Dot version. If your rel=alternate/canonical annotations are correct but your server redirects are absent or misconfigured, Google trusts what it actually crawls.

The engine isn't going to guess that a desktop version exists elsewhere if your server doesn't send the proper signals. This is particularly problematic because the URL displayed in the SERPs becomes the one users see and share, creating a domino effect of signal dilution.

What signals does Google expect to avoid this issue?

Google expects a complete consistency between HTML annotations and server behavior. On the HTML side, your desktop pages must point to mobile via rel=alternate, and your mobile pages must point to desktop via rel=canonical. But that's not enough.

On the server side, you need to implement bidirectional 302 redirects based on user-agent. Desktop on m.example.com? Redirect 302 to www.example.com. Mobile on www.example.com? Redirect 302 to m.example.com. Without this server layer, HTML annotations remain suggestions that Google may ignore.

• Bidirectional 302 redirects depending on the user-agent (not 301, as they are temporary by nature)
• Rel=alternate annotations on desktop pointing to the mobile version
• Canonical on mobile pointing to the desktop version
• Test with different user-agents to check actual server behavior
• Check in Search Console that Google is correctly indexing desktop URLs for desktop queries

Is this statement consistent with real-world observations?

Absolutely. I've seen this scenario play out on dozens of poorly configured M-Dot sites since the full rollout of mobile-first indexing. The pattern is always the same: developers thinking link rel tags are sufficient, and three months later discovering that their mobile URLs are squatting on desktop SERPs.

What’s frustrating is that Google doesn't clearly report this issue in Search Console. You don't get an alert saying, 'Warning, your M-Dot URLs are appearing in desktop.' You have to actively monitor your SERPs or analyze indexed URLs to catch the issue. And that's where it gets tricky.

What nuances should be added to this statement?

Mueller talks about redirects being 'not properly implemented,' but we need to be precise: the problem occurs when server redirects are absent or asymmetric. If you redirect desktop→mobile but not mobile→desktop, Google will index mobile and display it everywhere.

Another nuance: this problem is specific to M-Dot architectures. If you use responsive design or dynamic serving, you are not impacted — you serve the same URL to everyone. This is, in fact, a major reason why Google has been pushing for responsive design for years. [To be checked]: to what extent does Google attempt to 'fix' this problem automatically if it detects inconsistencies between annotations and server behavior? The documentation remains vague.

In what cases does this rule not apply?

If you are using a responsive design or dynamic serving, you are immune to this problem. Same URL, same base HTML (with CSS or server adaptation), so there's no risk of a mobile version squatting on desktop results.

Additionally, if you've migrated from an M-Dot architecture to responsive but Google hasn't yet recrawled your entire site, you may temporarily see M-Dot URLs persist in the index. In this case, force a recrawl via Search Console and check that your old M-Dot URLs properly return 301 permanent redirects to the unified versions.

What concrete actions should be taken to avoid this problem?

First action: test your redirects with different user agents. Use curl or a tool like Screaming Frog in custom user-agent mode. Visit m.example.com with a desktop user-agent (Chrome, Firefox) and check that the server returns a 302 to www.example.com. Then do the reverse: www.example.com with a mobile user-agent should redirect to m.example.com.

Second action: audit your HTML annotations. Each desktop page must contain a <link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/page">. Each mobile page must contain a <link rel="canonical" href="http://www.example.com/page">. No inconsistencies tolerated.

How to verify that Google is indexing the correct URLs?

Use the Search Console and filter by device type. In the coverage report, verify that the indexed URLs for desktop indeed correspond to www.example.com and not m.example.com. If you see M-Dot URLs indexed, that's an immediate alarm signal.

Complement this with a site:m.example.com search on Google in desktop mode. If results appear, it means Google is indexing and displaying your mobile URLs in a desktop context. Conversely, test site:www.example.com in mobile mode to check the reverse consistency. These manual tests are quick and immediately reveal flaws.

What strategy should be adopted if you are already in a crisis situation?

If Google is already showing your M-Dot URLs in desktop SERPs, don't panic and don't implement permanent 301s from m.example.com to www.example.com. You need temporary 302 redirects based on the user-agent, not a harsh redirect that would break the mobile experience.

Implement the bidirectional redirects, submit your desktop and mobile sitemaps in Search Console, and then request a recrawl of strategic pages. Monitor the evolution over 2-3 weeks. If Google continues to show M-Dot URLs, check your server logs to confirm that Googlebot is indeed receiving the 302 redirects. These technical optimizations can be complex to implement alone, especially if your server infrastructure involves multiple layers of cache or CDN. In this context, hiring a specialized SEO agency can help you avoid costly mistakes and accelerate the resolution of the problem with personalized support on your specific technical stack.

• Test bidirectional 302 redirects with curl or Screaming Frog (desktop and mobile user agents)
• Check for the presence and consistency of rel=alternate (desktop) and rel=canonical (mobile) tags
• Audit Search Console to identify M-Dot URLs indexed in a desktop context
• Conduct manual site: searches to detect indexing inconsistencies
• Monitor server logs to confirm that Googlebot is receiving the right redirects
• Submit desktop and mobile sitemaps separately in Search Console