Responsive vs Adaptive vs M-dot URLs

Responsive design is Google's recommended configuration. One URL, one HTML source, CSS media queries for layout changes. Google prefers responsive. It simplifies crawling, indexing, and rendering. There is no duplicate content risk and no redirect overhead.

Google's mobile-first indexing documentation explicitly calls responsive design the recommended pattern. https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing

Responsive sites are easier to maintain. One codebase, one deployment pipeline, one SEO configuration. Changes apply everywhere instantly.

Adaptive sites use the same URL but serve different HTML based on the User-Agent header. Google can handle this pattern. The Vary: User-Agent HTTP header must be present so caches know the content varies by device.

The problem with adaptive is complexity. Every user-agent check must handle new devices and browsers. Googlebot Smartphone must receive the mobile variant. Testing requires multiple user-agent strings. Misconfiguration risks serving desktop HTML to mobile crawlers. https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-dynamic-serving

M-dot sites use a separate subdomain with different URLs. m.example.com/page and example.com/page are distinct pages. This requires canonical tags, rel=alternate tags, and redirect logic.

Google can handle m-dot sites, but the configuration is error-prone. Missing or incorrect rel=canonical tags cause duplicate content issues. Source link tags pointing mobile pages to desktop equivalents must be present on both sides.

Google's documentation on separate mobile URLs lists the required markup. https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing

Common m-dot failures: mobile pages missing canonical tags, incorrect hreflang on multilingual m-dot sites, and redirect loops between desktop and mobile URLs.

Responsive web design wins. It is the simplest, the most maintainable, and the least error-prone. Google recommends it. The SEO industry agrees. A 2025 HTTP Archive study showed that 87% of the top 10,000 sites use responsive design. M-dot usage is below 5% and declining.

M-dot sites survive in legacy enterprise environments. Content management systems that cannot refactor to responsive, or sites with vastly different mobile functionality, still use separate subdomains. If you maintain an m-dot site, audit the rel=canonical and rel=alternate tags monthly.

Performance advantages of m-dot are negligible in 2026. Responsive sites with proper CSS deliver equivalent load speeds. HTTP/2 multiplexing and CDN edge caching eliminate any theoretical m-dot speed advantage.

• [ ] Confirm responsive (same URL and HTML) is the delivery method
• [ ] If dynamic serving: verify Vary: User-Agent header is present
• [ ] If m-dot: verify rel=canonical and rel=alternate on all pages
• [ ] Check Google Search Console for mobile usability errors
• [ ] Test top 20 URLs in the URL Inspection Tool
• [ ] Verify no redirect chains between mobile and desktop URLs

Note the gap between your delivery method and responsive. If you still run m-dot, you carry ongoing maintenance overhead that responsive sites avoid.

Audit quarterly.