Should we still use separate mobile URLs (m-dot) for our site?

Why does Google now advise against m-dot URLs?

Separate mobile URLs (such as m.example.com) were a common solution between 2010 and 2015, at a time when responsive design had yet to become mainstream. This architecture required managing two distinct versions of the website: one for desktop (www.example.com) and one for mobile (m.example.com).

The problem is that this setup multiplies technical friction points. Google has to crawl twice as many URLs, understand the canonical relationship between versions, and manage the rel="alternate" and rel="canonical" annotations that link the two. When these annotations are poorly implemented — which is frequent — it creates situations where Google indexes the wrong version or dilutes signals between the two URLs.

What architecture does Google favor today?

The recommendation focuses on a single URL serving both desktop and mobile. Two technical approaches can achieve this: responsive design (where HTML adapts via CSS) or dynamic serving (where the server sends different HTML based on the user-agent but on the same URL).

Responsive design remains the simplest solution to maintain. A single codebase, a single HTML, no complex technical annotations. Dynamic serving works too, but requires reliable user-agent detection on the server side and the use of the HTTP header Vary: User-Agent to signal to Google that the content varies.

Does this recommendation apply to all sites?

Google speaks here of simplification, not a strict technical requirement. Existing m-dot sites continue to function — they are not penalized outright. However, they impose a significantly heavier maintenance and technical oversight burden.

For a new project, starting with separate URLs makes no sense in 2025. For an existing m-dot site, the question is whether the technical resources required to maintain this architecture are justified, or if migrating to responsive would bring operational efficiency gains.

• A single URL eliminates annotation errors rel="alternate" and rel="canonical" between versions
• The crawl budget is better utilized as Google only crawls one version of each page
• Ranking signals (backlinks, engagement, authority) are no longer diluted between two URLs
• Responsive design remains the simplest approach for the majority of sites
• Existing m-dot sites can continue to operate, but require constant technical oversight

Is this recommendation consistent with observed practices in the field?

Absolutely. Since Google transitioned to mobile-first indexing, maintaining separate URLs has become a headache. The most frequent errors I observe are: missing or reversed rel="alternate" annotations, 302 redirects instead of 301, and impoverished mobile content that drops in ranking once mobile indexing is activated.

Sites that still function properly in m-dot are generally large players with dedicated technical teams. For 90% of sites, this architecture creates more problems than it solves. The cost/benefit ratio has not held up for at least five years.

In what cases might the m-dot architecture still be justified?

Let's be honest: legitimate cases can be counted on one hand. You could argue for sites with radically different user experiences between desktop and mobile — but even then, dynamic serving on a single URL is still preferable.

Some legacy sites with millions of pages and inherited technical constraints may find themselves stuck. Migrating a site of that size to responsive represents a substantial project. But beware: staying in m-dot out of inertia is not a strategy, it’s a technical debt that accumulates. Every passing year makes migration more complex and costly.

What are the concrete risks of maintaining separate URLs today?

The main risk is the gradual desynchronization between the two versions. I've seen sites where the mobile version hadn't been updated for months, with outdated content ending up indexed by Google. Result: traffic drop, orphaned pages, confusion in the SERPs.

The other issue concerns backlinks. When a site receives links sometimes to the www version and sometimes to the m version, authority signals become dispersed. Even with perfect canonicals, it remains suboptimal. And here's the catch: how many sites consistently have perfect annotations? Very few.

What should you do if your site still uses m-dot URLs?

First step: assess the scale of the project. How many pages? What technical complexity on the server side? What dependencies with other systems (CRM, analytics tools, advertising campaigns)? Migrating to responsive is not trivial, especially on a site with thousands of pages.

Second step: if migration isn’t feasible in the short term, strengthen technical oversight. Automate annotation checks, set up alerts for 404 errors between versions, regularly audit content parity between desktop and mobile. Never allow the two versions to diverge.

How to properly migrate from an m-dot architecture to responsive?

The standard method: implement a complete 301 redirect plan for all m.example.com URLs to www.example.com. Before switching, extensively test responsive on a staging environment. Ensure that all critical features work on mobile: forms, e-commerce checkout, interactive content.

Once the redirects are in place, monitor Search Console like a hawk for 4 to 6 weeks. Watch the indexation evolution, crawl errors, and any positional drops. Notify Google via the address change tool in Search Console if you're also changing the main domain (rare, but possible).

What mistakes should you absolutely avoid during migration?

The classic error: reducing mobile content on the pretext of being responsive. Google now prioritizes indexing the mobile version — if you remove entire sections from mobile, you risk losing ranking on that content. Keep all the information, just adapt the formatting.

Another pitfall: neglecting loading times after migration. A poorly optimized responsive site can be heavier than a well-designed m-dot. Prioritize lazy loading of images, compress assets, use a CDN. Core Web Vitals matter as much as the URL architecture.

• Audit the complete content parity between desktop and mobile versions before migration
• Implement permanent 301 redirects for all m-dot URLs to their responsive equivalents
• Thoroughly test responsiveness across all device types and screen sizes
• Configure Search Console to monitor mobile-first indexing post-migration
• Optimize performance (Core Web Vitals) to avoid any speed regression
• Keep rel="canonical" annotations during the transition phase (minimum 4-6 weeks)