Mobile Redirect

The m-dot pattern solved a real problem. In 2010 a desktop layout on a phone was unusable, CSS media queries were young, and phones were slow enough that serving a stripped-down document was the only way to make a site work. Splitting the site in two was the pragmatic answer.

Three things removed the reason for it. Responsive CSS matured, so one document can serve every viewport. Phones got fast enough that the performance argument for a separate lightweight site mostly evaporated. And in 2018 Google began moving sites to mobile-first indexing, completed for all sites by 2024 — meaning the mobile version is the one indexed and ranked, not a secondary copy of a desktop original.

That last change inverted the pattern's logic. A separate mobile site used to be a lighter alternative to the real one. Now it is the real one as far as search is concerned, while usually carrying less content, fewer internal links and thinner metadata than the desktop version it was derived from.

Faulty redirects. The correct behaviour is that every mobile URL maps to the equivalent desktop page — m.example.com/blue-widget to example.com/blue-widget. What is implemented in practice, often as a single catch-all rule, is that everything redirects to the mobile homepage. Google names this specifically as a mobile usability problem, and it is worse than it sounds: every deep link from search lands on the homepage, so the visitor arrives having asked a specific question and is handed the front door.

Split signals. Two URLs for one piece of content accumulate links, shares and engagement separately unless they are explicitly paired. The pairing is a rel="canonical" on the mobile page pointing at the desktop URL, plus a rel="alternate" on the desktop page pointing back. Get either direction wrong and the two versions compete rather than combine.

Say example.com/pricing has a mobile counterpart. The desktop page declares the alternate:

<link rel="alternate" media="only screen and (max-width: 640px)"
      href="https://m.example.com/pricing">

And the mobile page declares the canonical back:

<link rel="canonical" href="https://example.com/pricing">

Both are required. The canonical alone tells Google which version to index but leaves it to discover the pairing; the alternate alone announces a mobile version without consolidating the signals.

Then check the redirect actually maps path to path:

curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
  https://example.com/pricing | grep -i location

location: https://m.example.com/pricing     # correct
location: https://m.example.com/            # the failure mode

The end state is one responsive URL. The migration is a standard site move and the order matters.

Build the responsive version at the desktop URLs first and verify it on real devices, because you cannot retire the mobile site until the single URL genuinely serves phones well. Then remove the user-agent redirect, so both URL sets serve the same responsive page. Then 301 each mobile URL to its desktop equivalent — path to path, never to the homepage — and remove the canonical and alternate pairing, which now has nothing to pair. Keep the redirects permanently: links to m-dot URLs will exist for years.

Expect a settling period. Google has to recrawl both URL sets and consolidate them, which takes weeks rather than days on a large site.