Responsive Web Design vs Separate Mobile Site
One codebase that reflows for every screen, or a dedicated m-dot site built just for phones. The decisive verdict on which approach to ship.
The short answer
Responsive Web Design over Separate Mobile Site for most cases. One URL, one codebase, one source of truth.
- Pick Responsive Web Design if building or maintaining basically any site today — content, commerce, SaaS, marketing. This is the default and you need a real reason to deviate
- Pick Separate Mobile Site if have a genuinely divergent mobile use case (a stripped kiosk flow, a legacy desktop app you cannot touch) AND the org headcount to maintain two sites forever. Rare
- Also consider: Whether you actually have two distinct products or just one product you are too lazy to make reflow. Almost always the latter.
— Nice Pick, opinionated tool recommendations
The verdict
Responsive web design. Not close. A responsive site is one HTML codebase that uses fluid grids and media queries to adapt to any viewport — phone, tablet, desktop, the fridge. A separate mobile site (the infamous m.example.com) is a second, parallel website built only for phones, with its own URLs, its own templates, and its own slow death by neglect. The m-dot pattern made sense in 2010 when phones were weak and CSS was weaker. It does not make sense now. Every modern device runs a capable browser, CSS handles layout adaptation natively, and Google has told you in plain English it prefers responsive. Choosing a separate mobile site today is choosing to maintain two of everything so you can ship one worse experience. If you are reaching for m-dot, you are usually solving an org problem with an architecture mistake.
Maintenance and cost
This is where the separate mobile site quietly bankrupts you. Two codebases means every feature ships twice, every bug gets fixed twice (or, realistically, once — and the m-dot rots), and every content change requires someone to remember the second site exists. They never do. The classic failure: marketing updates the desktop pricing page, forgets m.example.com, and mobile users see last quarter's prices for three weeks. Responsive collapses this into one template that you change once. Yes, responsive CSS gets gnarly at edge breakpoints, and a sloppy responsive build can ship a bloated desktop payload to phones. But that is a performance-budget problem you fix with conditional loading — not a reason to clone your entire site. One codebase has bugs. Two codebases have the same bugs plus drift. Drift is the expensive one.
SEO and URLs
The m-dot pattern splits your domain authority across two URL sets, then forces you to glue them back together with rel=canonical and rel=alternate annotations that someone will misconfigure. Get it wrong and Google indexes the mobile URLs, ranks them, and serves desktop users a phone-shaped page — or duplicates your content and dilutes both. Responsive design sidesteps the entire mess: one URL per page, one canonical, all link equity pooled in one place. Google's own guidance explicitly names responsive as the recommended configuration precisely because there is nothing to annotate and nothing to break. With mobile-first indexing, Google primarily crawls the mobile rendering anyway — so on m-dot, your thin mobile templates become the version that ranks. That is exactly backwards. If you care about organic traffic at all, responsive is the only answer that doesn't make you babysit two indexes.
When separate actually wins
I said I'd be decisive, not dishonest. There is a narrow band where a separate mobile experience is defensible — and notice I said experience, not necessarily an m-dot site. If your mobile use case is genuinely a different product (a field-tech checklist app versus a desktop analytics suite), the user goals diverge enough that one responsive layout would compromise both. Then build a separate front end — but make it a real app or a distinct route, not a parallel mirror of your marketing site. The other case: a frozen legacy desktop platform you cannot refactor, where bolting on an m-dot is cheaper than a rewrite. That is a tactical hack with a deadline, not an architecture. If you cannot articulate a divergent user goal, you don't have a mobile-site case — you have a responsive site you haven't built yet.
Quick Comparison
| Factor | Responsive Web Design | Separate Mobile Site |
|---|---|---|
| Codebases to maintain | One — single HTML/CSS, adapts via media queries | Two — parallel desktop and m-dot sites that drift apart |
| SEO / URL structure | One URL per page, all link equity pooled, Google-recommended | Split URLs needing rel=alternate/canonical glue that breaks |
| Mobile-first indexing fit | Same page ranks for all devices, nothing to misconfigure | Thin mobile templates become the indexed version — backwards |
| Divergent mobile use case | One layout can compromise two very different user goals | Can purpose-build a truly distinct mobile flow |
| Performance control on phones | Risk of shipping bloated desktop payload without a budget | Lean mobile-only payload by construction |
The Verdict
Use Responsive Web Design if: You are building or maintaining basically any site today — content, commerce, SaaS, marketing. This is the default and you need a real reason to deviate.
Use Separate Mobile Site if: You have a genuinely divergent mobile use case (a stripped kiosk flow, a legacy desktop app you cannot touch) AND the org headcount to maintain two sites forever. Rare.
Consider: Whether you actually have two distinct products or just one product you are too lazy to make reflow. Almost always the latter.
One URL, one codebase, one source of truth. The separate m-dot site is a 2011 relic that doubles your maintenance, splits your SEO equity, and breaks every time someone forgets to update it. Google itself recommends responsive. Pick the thing that doesn't rot.
Related Comparisons
Disagree? nice@nicepick.dev