Should you really abandon your separate mobile site for responsive design?

Why is Google pushing for responsive instead of separate sites?

Google's position is based on a simple technical observation: managing two versions of a site multiplies the chances of errors. Separate sites (m.example.com vs www.example.com) require rigorous redirect configuration, bidirectional canonical tags, and perfectly synchronized alternate/canonical annotations.

When this setup goes awry, the consequences are immediate. Google crawls two URLs for the same content, dilutes the relevance signal, and sometimes indexes the wrong version depending on the context. The crawl budget gets fragmented between the two domains. Backlinks disperse. Maintenance becomes a nightmare as soon as a page changes: you have to replicate the change, check the canonicals, and test the redirects.

Responsive design eliminates this complexity from the root. One single URL, one HTML content that adapts via CSS and JavaScript. Google crawls once, indexes a unique version, consolidates all signals on this URL. Fewer friction points, less room for error.

Are separate sites doomed by algorithms?

No, and it’s crucial to understand this. Google does not penalize architectures in m.example.com if they are implemented correctly. The problem lies in execution: few teams truly master the complete configuration (dynamic redirects based on User-Agent, crossed canonicals, coordinated hreflang if the site is multilingual).

Google finds that 90% of the errors reported by Search Console on sites with separate versions come from faulty configurations: canonicals pointing into the void, looping redirects, mobile content poorly detected by the bot. Responsive design eliminates these structural errors, which is why Google recommends it by default.

What are the real constraints of responsive design for SEO?

Responsive design transfers complexity elsewhere: mobile performance and JavaScript. Serving the same desktop HTML on mobile means loading often oversized resources (images 2000px wide, unnecessary desktop scripts). If the site compensates with poorly implemented lazy loading or hides entire sections in CSS, Google might not see critical content.

Mobile-first indexing amplifies this risk. Google crawls and indexes the mobile version of the URL, even for desktop ranking. If your responsive design hides important elements on mobile, they disappear from the index. Accordions, tabs, content folded into drawers: all this must remain accessible to the bot, otherwise the signal evaporates.

• Responsive architecture = a single unique URL, all SEO signals consolidated (links, authority, history)
• Separate sites = crawl fragmentation, high risks of incorrect canonical/redirect configurations
• Mobile-first indexing: Google indexes the mobile version, even for desktop ranking
• Critical performance: poorly optimized responsive design penalizes Core Web Vitals (LCP, CLS, INP)
• Hidden content on mobile: accordions and tabs must remain crawlable, otherwise signal loss occurs

Is this recommendation consistent with field observations?

Absolutely, and the Search Console data confirms it. Sites migrating from an m.example.com architecture to responsive design see 70-80% of canonical and redirect configuration errors disappear. Crawling stabilizes, the budget concentrates on real pages, indexing becomes predictable.

I have audited dozens of sites with separate versions: almost all showed leaks. Desktop canonical pointing to the mobile version by mistake, 302 redirects instead of 301, User-Agent sniffing that bugs on certain bots. Responsive design eliminates this mess. But let's be clear: it doesn’t solve everything. If your responsive site loads 3MB of unnecessary JavaScript on mobile, you will struggle with Core Web Vitals, and ranking will fluctuate.

In what cases does a separate site remain relevant?

Google doesn’t say, but there are legitimate cases. Massive e-commerce platforms with radically different user journeys between mobile (quick search, visual scan) and desktop (detailed comparison, complex filters). Serving two separately optimized experiences may justify the complexity.

Sites with legacy technical constraints where redesigning into responsive would cost a fortune and take 18 months. As long as the canonicals and redirects are impeccable, Google indexes correctly. The issue is that "impeccable" requires a rare level of expertise. [To verify]: Google does not publish any metrics on the performance SEO delta between well-executed responsive design and well-executed separate sites. The argument for "simplification" remains vague without quantified benchmarks.

What critical errors are still seen on responsive sites?

The first: incomplete mobile content. Entire sections hidden in CSS with display:none, lazy-loaded images that Googlebot does not trigger, folded menus without HTML fallback. Google indexes what it sees on mobile, and if half of the content is invisible, ranking collapses.

The second: disastrous performance. Loading a hero image in 4K on an iPhone with slow 4G destroys the LCP. The CLS rises with ads that reflow. The INP deteriorates with bulky JS frameworks. Responsive design without a performance strategy is worse than a well-optimized separate site.

What should I do if I still have a site in m.example.com?

The first step: audit the current configuration. Ensure each desktop page points to its mobile version through rel="alternate" media, and vice versa with rel="canonical". Test the User-Agent redirects: a desktop bot hitting m.example.com should be redirected in 301 to www. A mobile user on www should land on m.

If you find inconsistencies (broken canonicals, chain redirects, orphan pages), you have two options. Either you fix everything with surgical precision, or you plan a responsive migration. Fixing is costly in long-term maintenance. Migrating requires a heavy project but resolves the problem definitively.

How to migrate from a separate site to responsive without breaking SEO?

The standard method: 1:1 migration with 301 redirects. Each URL m.example.com/page redirects to www.example.com/page. You remove the alternate/canonical annotations and keep the new responsive design in place. Google recrawls, reindexes, consolidates signals on the unique URL.

The pitfall: the Core Web Vitals must be on point on the new version. If your responsive design is slow, Google will detect a regression in user experience, and ranking may temporarily drop. Test in preproduction with PageSpeed Insights, Lighthouse, WebPageTest. LCP under 2.5s, CLS under 0.1, INP under 200ms. Otherwise, you will lose traffic.

What priority optimizations should be made for a high-performing responsive design?

First, images. Responsive images with srcset, next-gen formats (WebP, AVIF), native lazy loading. Hero and above-the-fold images must load first. Fonts: preload critical ones, use font-display:swap, limit variants.

Next, JavaScript. Code splitting, deferred loading of non-critical modules, avoid bulky frameworks if your site is mostly static. CSS: critical path CSS inline in the , keep it async. Test on actual mobile devices, not just in Chrome DevTools responsive mode.

• Audit canonicals and redirects on the current site (Search Console, Screaming Frog)
• Plan a 1:1 migration with permanent 301 redirects
• Optimize Core Web Vitals before the switch (LCP < 2.5s, CLS < 0.1, INP < 200ms)
• Implement responsive images (srcset, WebP/AVIF, native lazy loading)
• Ensure mobile content is fully crawlable (no critical display:none)
• Monitor indexing post-migration (Search Console, server logs)