A mobile redirect is an HTTP redirect that detects visitors using mobile devices, smartphones and tablets, and routes them to a mobile-optimised version of a website rather than serving them the same content delivered to desktop browsers. When a mobile visitor requests example.com a mobile redirect detects the mobile user agent and redirects to m.example.com: a separate mobile site, or to a mobile-specific URL pattern, example.com/m/: that serves content formatted and optimised for small screens and touch interfaces.

Mobile redirects were the dominant approach to mobile web development in the early smartphone era, roughly 2007 to 2015, when creating separate mobile-specific sites was the practical solution to the challenge of serving usable web content to small-screen, slow-connection mobile devices. Desktop websites with complex layouts, large images, and hover-dependent navigation were essentially unusable on early smartphones, separate mobile sites served simplified, optimised content through mobile-specific redirect routing.

The rise of responsive web design, CSS-based approaches that adapt a single page’s layout to different screen sizes, has made mobile redirects largely obsolete for new development. A responsive site serves all devices from the same URL with the same HTML, no redirect is needed because the design adapts to the device’s screen size automatically. Google’s adoption of mobile-first indexing: evaluating sites primarily through their mobile experience, has further shifted best practice away from separate mobile sites and toward responsive design at a single URL.

However mobile redirects remain present across the web, legacy implementations built during the separate-mobile-site era, specific use cases where separate mobile experiences are genuinely warranted, and mobile app redirects that route mobile visitors to native app experiences rather than web content. Understanding mobile redirects, how they work, their SEO implications, and when they remain appropriate, is important for managing legacy mobile implementations and for the specific modern use cases where mobile-specific routing remains valuable.

How mobile redirects work technically

Mobile redirects detect the visitor’s device type and conditionally route mobile visitors to different URLs, while desktop visitors access the original URL without redirection.

User agent detection: the primary detection mechanism for mobile redirects. Mobile browsers include device-identifying strings in their User-Agent request header. Smartphones include identifiers like iPhone, Android, Mobile, and BlackBerry. Tablets include iPad and Android with tablet-specific identifiers.

Server-side user agent detection in Nginx:

# Mobile user agent detection
map $http_user_agent $is_mobile {
    default 0;
    "~*Mobile" 1;
    "~*Android" 1;
    "~*iPhone" 1;
    "~*iPad" 1;
    "~*BlackBerry" 1;
    "~*Windows Phone" 1;
}

server {
    listen 443 ssl;
    server_name example.com;
    
    if ($is_mobile) {
        return 302 https://m.example.com$request_uri;
    }
    
    # Desktop content served here

# Mobile user agent detection
map $http_user_agent $is_mobile {
    default 0;
    "~*Mobile" 1;
    "~*Android" 1;
    "~*iPhone" 1;
    "~*iPad" 1;
    "~*BlackBerry" 1;
    "~*Windows Phone" 1;
}

server {
    listen 443 ssl;
    server_name example.com;
    
    if ($is_mobile) {
        return 302 https://m.example.com$request_uri;
    }
    
    # Desktop content served here

# Mobile user agent detection
map $http_user_agent $is_mobile {
    default 0;
    "~*Mobile" 1;
    "~*Android" 1;
    "~*iPhone" 1;
    "~*iPad" 1;
    "~*BlackBerry" 1;
    "~*Windows Phone" 1;
}

server {
    listen 443 ssl;
    server_name example.com;
    
    if ($is_mobile) {
        return 302 https://m.example.com$request_uri;
    }
    
    # Desktop content served here

Apache.htaccess mobile detection:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "(Mobile|Android|iPhone|iPad|BlackBerry)" [NC]
RewriteRule ^(.*)$ https://m.example.com/$1 [R=302,L]

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "(Mobile|Android|iPhone|iPad|BlackBerry)" [NC]
RewriteRule ^(.*)$ https://m.example.com/$1 [R=302,L]

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "(Mobile|Android|iPhone|iPad|BlackBerry)" [NC]
RewriteRule ^(.*)$ https://m.example.com/$1 [R=302,L]

Screen width detection, client hints: modern browsers support User-Agent Client Hints, structured request headers that provide device information more reliably than parsing user agent strings. Sec-CH-UA-Mobile: ?1 indicates a mobile device explicitly, a boolean signal that is more reliable than pattern-matching user agent strings. Using client hints for mobile detection requires the server to request them through the Accept-CH response header on initial page loads, slightly more complex than user agent parsing but more accurate.

JavaScript detection, client-side: detecting mobile devices client-side through JavaScript, reading navigator.userAgent, window.innerWidth, or touch capability detection, and executing redirects through window.location assignment. Client-side detection is less reliable for redirect purposes, the page content loads before the redirect fires, creating visible flicker. JavaScript redirects are also processed in Googlebot’s rendering phase rather than immediately, making them less reliable for search engine signal processing than server-side redirects.

The m-dot mobile site pattern

The most common historical mobile redirect pattern routes mobile visitors to a separate subdomain, typically m.example.com or mobile.example.com: serving a stripped-down mobile-optimised version of the site.

m-dot site architecture: the m-dot pattern serves fundamentally different HTML to mobile visitors, simplified navigation, optimised image sizes, touch-friendly UI elements, and reduced content density. The m-dot site may use different templates, different content, and different URL patterns than the desktop site.

example.com/products/blue-widget on desktop corresponds to m.example.com/products/blue-widget on mobile, or sometimes to m.example.com/p/blue-widget if the mobile site uses different URL structures.

Canonical tag requirements for m-dot sites: the most critical SEO requirement for m-dot implementations. Each mobile page must include a canonical tag pointing to its corresponding desktop URL, and each desktop page must include a link annotation pointing to its corresponding mobile URL:

Desktop page at example.com/page:

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

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

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

Mobile page at m.example.com/page:

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

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

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

Without canonical tags Google may index the m-dot URLs as separate pages, creating duplicate content issues and splitting SEO equity between desktop and mobile URLs.

Mobile site URL correspondence: the mobile site must have corresponding pages for all desktop pages, and vice versa. A desktop page with no corresponding mobile page creates problems, mobile visitors redirected from the desktop URL to the mobile site’s homepage rather than a relevant mobile equivalent have a poor experience. Google’s Webmaster Guidelines explicitly identify faulty mobile redirects, redirecting to irrelevant pages, as a mobile usability problem.

Mobile redirects and modern SEO

The SEO implications of mobile redirects have become increasingly significant as Google’s mobile-first indexing has made mobile experience the primary indexing signal.

Mobile-first indexing: Google now primarily uses the mobile version of a site’s content for indexing and ranking. For m-dot sites this means Google primarily indexes m.example.com content, not example.com content. If the mobile site has less content than the desktop site, a common issue with stripped-down m-dot implementations, the indexed version has less content than the full desktop version.

This mobile-first indexing reality makes the content parity between desktop and mobile sites critical. Mobile sites that omit content for simplicity, product descriptions, technical specifications, FAQs, are now indexed with less content than the desktop version. Responsive design eliminates this problem, the same content is served to all devices.

Redirect type for mobile redirects: mobile redirects should use 302 temporary redirects rather than 301 permanent redirects. Mobile device ownership is not permanent, a user may access the same site from a desktop browser at a later time. The 302 signals that the routing is conditional on the current device rather than a permanent content move. Using 301 for mobile redirects signals to search engines that the mobile URL is the permanent canonical destination, potentially causing indexation problems.

Faulty redirect detection: Google’s Search Console identifies faulty mobile redirects, situations where mobile visitors are redirected to a different page than the one they requested. example.com/specific-product redirecting mobile visitors to m.example.com homepage rather than m.example.com/specific-product is a faulty redirect. Faulty redirects generate negative mobile usability signals, Google explicitly flags them as problems in the Mobile Usability report.

When mobile redirects remain appropriate

Despite responsive design’s dominance mobile redirects remain appropriate in specific contexts, where genuinely different mobile experiences are warranted rather than simply different layouts.

Native app routing: routing mobile visitors to a native app rather than a web experience. When a native iOS or Android app provides a significantly better experience than the mobile web a mobile redirect to an app deep link or app store listing serves mobile visitors better than any web content could. Universal links, iOS, and App Links, Android, provide the appropriate mechanism, routing app-installed users to the app and non-installed users to the web.

Progressive Web App routing: routing mobile visitors to a Progressive Web App, PWA, experience that is distinct from the desktop web experience. PWAs may be hosted at a separate URL or served conditionally based on device capabilities, mobile redirects can route appropriately capable mobile browsers to the PWA experience.

Dramatically different mobile journeys: genuinely distinct conversion journeys for mobile users that cannot be achieved through responsive design alone. A complex multi-step desktop workflow that is fundamentally unsuitable for mobile may warrant a simplified mobile-specific flow at a different URL, accessed through mobile redirect routing.

Legacy site maintenance: many existing sites have m-dot implementations that cannot be immediately migrated to responsive design due to cost, complexity, or technical constraints. Maintaining and correctly managing the existing mobile redirect implementation, with proper canonical tags, complete URL correspondence, and correct redirect types, is preferable to leaving a poorly configured implementation in place during a gradual migration.

Migrating from mobile redirects to responsive design

Organisations with legacy m-dot implementations and the desire to migrate to responsive design need a careful redirect migration approach.

Responsive design implementation: build the responsive version of the site, serving appropriate layouts to all devices from the same URL, before migrating away from the m-dot site. The responsive version should pass Google’s Mobile Usability tests and Core Web Vitals assessments before the m-dot redirect is removed.

m-dot to desktop redirect: after deploying responsive design redirect all m-dot URLs to their desktop equivalents with 301 permanent redirects. m.example.com/page redirects to example.com/page: permanently, consolidating all link equity from any backlinks pointing to m-dot URLs to the canonical desktop, now responsive, URLs.

Removing mobile detection redirects: remove the server-side or edge mobile detection redirect rules that were routing mobile visitors to the m-dot site. Desktop visitors continue to access example.com as before. Mobile visitors are no longer redirected, they receive the responsive version of example.com directly.

Search Console notification: submit updated sitemaps to Google Search Console containing only the canonical desktop, responsive, URLs. No m-dot URLs should appear in sitemaps after the migration. Monitor the Search Console Coverage report to verify that Google is transitioning indexation from m-dot URLs to canonical desktop URLs.

Common mobile redirect mistakes

Redirecting mobile visitors to the homepage instead of the equivalent page: the most common and most impactful mobile redirect problem. A desktop visitor following a link to example.com/products/blue-widget who is on a mobile device should reach m.example.com/products/blue-widget: not m.example.com. Homepage redirects lose the visitor’s specific intent and generate faulty redirect signals in Google Search Console.

Using 301 permanent redirects: mobile detection is conditional on the current device, not a permanent state. Using 301 sends incorrect signals about the permanence of the routing, use 302 for all device-based redirects.

Missing canonical tags on mobile pages: allowing m-dot URLs to be indexed independently as separate pages without canonical tags pointing to desktop equivalents, creating duplicate content and splitting SEO equity.

Different content on mobile and desktop: serving substantially less content on mobile than desktop creates SEO equity problems under mobile-first indexing. The mobile version should have equivalent content to the desktop version, not stripped-down versions that omit important information.

Not updating links after migration: removing mobile redirect infrastructure without redirecting m-dot URLs to canonical desktop URLs. External backlinks pointing to m-dot URLs, accumulated during the m-dot site’s operation, continue to send traffic and equity to the m-dot domain. Permanent redirects from all m-dot URLs to desktop equivalents preserve this accumulated equity.