Redirect Types & Concepts
What is a device redirect?
A device redirect is a redirect rule that sends visitors to a different URL based on the type of device they are using to browse. A visitor on a smartphone might be redirected from example.com to m.example.com. A visitor on a tablet might go to tablet.example.com. A visitor on a desktop stays on example.com. The redirect detects the device type from signals in the incoming request and routes visitors to a version of the site built or optimised for that device.
Device redirects were widely used in the early days of mobile web development, roughly 2009 to 2015, when building a separate mobile site was the standard approach to serving mobile users. Smartphones had small screens, slow connections, and limited browser capabilities that made desktop sites difficult to use. Creating a separate lighter mobile site at an m. subdomain and redirecting mobile visitors there was the practical solution before responsive web design became the standard approach.
Today device redirects have been largely superseded by responsive design, a single website that adapts its layout to any screen size without requiring different URLs for different devices. Most new sites should not use device redirects at all. But device redirects still exist on legacy sites built before responsive design became standard, and understanding how they work, and why they cause problems, remains relevant for anyone managing or migrating older web properties.
How a device redirect works
A device redirect detects the visitor’s device type from the User-Agent header included in every HTTP request. The User-Agent is a string sent by the browser identifying itself and the device it is running on. A smartphone browser sends a User-Agent containing identifiers like Mobile or Android or iPhone. A desktop browser sends a User-Agent containing Windows or Macintosh without mobile identifiers.
The server or CDN reads the User-Agent string, identifies whether it matches a mobile device pattern, and applies redirect logic based on that detection. If the User-Agent matches a mobile pattern, the server returns a redirect response, typically a 302, pointing to the mobile version of the site. If it does not match, the server serves the desktop version normally.
A basic device detection and redirect in a server configuration looks for User-Agent strings containing mobile identifiers:
This rule matches any request where the User-Agent contains mobile-related strings and redirects to the mobile subdomain. More sophisticated implementations use dedicated device detection libraries with larger databases of known User-Agent strings for more accurate detection across a wider range of devices.
Types of device redirects
Device redirects vary in scope and sophistication depending on how many device categories are distinguished and how the detection is implemented.
Binary mobile/desktop redirect: the simplest and most common form. All mobile devices go to the mobile site. All others stay on the desktop site. Two destinations, one detection rule. This was the standard pattern for m. subdomain mobile sites.
Three-way device redirect: distinguishing between smartphones, tablets, and desktops and redirecting each to a different destination. Smartphones to a mobile-optimised site, tablets to a tablet-optimised site, desktops to the full site. This was used by sites that invested in building three distinct versions of their experience.
Capability-based redirect: redirecting based on specific device capabilities rather than device category, screen resolution, touch support, connection speed, to route visitors to the most appropriate version. More precise than User-Agent matching but significantly more complex to implement.
App store redirect: redirecting mobile visitors to an app store listing rather than a mobile website. A visitor on an iOS device is redirected to the App Store. A visitor on Android is redirected to Google Play. Used when the primary mobile experience is a native app rather than a web experience.
Device redirects and the m. subdomain pattern
The most recognisable implementation of device redirects is the m. subdomain: a separate mobile site at m.example.com that desktop visitors never see. This pattern dominated mobile web development from approximately 2010 to 2016 and is still found on many older sites.
The m. subdomain approach involves maintaining two entirely separate sites: the desktop site at example.com and the mobile site at m.example.com. Each has its own URL structure, its own templates, and often its own content; mobile sites were typically stripped-down versions of the desktop site with less content and fewer features.
From an SEO perspective the m. subdomain approach has significant challenges.
Separate URL structures — the desktop and mobile versions of a page exist at different URLs. Links pointing to the desktop version do not automatically benefit the mobile version and vice versa. SEO equity is split between two URL systems rather than consolidated in one.
Duplicate content: similar or identical content at two different URLs, example.com/page and m.example.com/page, creates duplicate content issues. Canonical annotations are required to tell search engines which version is preferred.
Separate crawl budget consumption: Googlebot crawls both the desktop and mobile sites separately, consuming crawl budget for two parallel URL structures.
Maintenance overhead: every piece of content must be maintained in two places. Changes to the desktop site may not automatically propagate to the mobile site. The two sites can drift out of sync over time.
Google switched to mobile-first indexing in 2019, primarily indexing and ranking the mobile version of sites. For sites still using the m. subdomain pattern this significantly increased the importance of the mobile version, and the costs of maintaining two separate sites.
Device redirects and SEO
Device redirects introduce several SEO considerations that do not apply to standard redirects.
Use 302 not 301: device redirects should use temporary redirects. A 301 permanent redirect from example.com/page to m.example.com/page would cause search engines and browsers to treat the mobile URL as the permanent destination for all users, including desktop users who should never go there. The 302 correctly signals that the redirect is conditional and temporary: this URL redirects to a different location for some visitors but remains the canonical address.
Canonical annotations: a desktop page that device-redirects mobile visitors to a mobile equivalent should include a <link rel="canonical"> pointing to itself, example.com/page, to signal to search engines that the desktop URL is the canonical version. The mobile page at m.example.com/page should include both a canonical pointing to the desktop version and a <link rel="alternate" media="only screen and (max-width: 640px)"> pointing to itself to indicate it is the mobile variant. Google provides specific annotation guidance for m. subdomain sites.
Googlebot and smartphone Googlebot: Google runs two crawlers: a desktop Googlebot and a smartphone Googlebot. The smartphone Googlebot sends a mobile User-Agent and will be redirected to the mobile site. The desktop Googlebot sends a desktop User-Agent and will see the desktop site. Both versions are crawled and indexed. For mobile-first indexing the smartphone Googlebot’s view, the mobile version, is what primarily determines rankings.
Avoid faulty redirects: a faulty redirect occurs when a mobile visitor requests a specific page on the desktop site, perhaps following a link, and is redirected to the mobile homepage rather than the equivalent mobile page. Google explicitly identifies faulty redirects as a mobile usability issue. If a visitor requests example.com/specific-page they should be redirected to m.example.com/specific-page, not to m.example.com. Path-preserving device redirects avoid faulty redirects.
Device redirects vs responsive design
Responsive design has largely replaced device redirects for new site development and is the approach Google recommends. Understanding why helps explain both why device redirects persist on legacy sites and why migrating away from them is worthwhile.
Responsive design: a single URL serves all device types. CSS media queries adapt the layout, typography, and visual presentation to any screen size. The same HTML is served to all visitors; only the presentation changes. Search engines see one URL with one set of content. There is no duplicate content, no split SEO equity, no separate crawl budget consumption. Links to the site work regardless of device. Maintenance is unified.
Device redirects: multiple URLs serve different device types. Different HTML, and often different content, is served to different visitors. SEO equity is split. Duplicate content management requires explicit annotations. Maintenance is multiplied. User experience is inconsistent across devices.
Google has stated its preference for responsive design over separate mobile URLs because it is simpler to implement correctly and avoids the common errors, faulty redirects, duplicate content, split equity, that separate mobile sites introduce.
The practical guidance is clear. For new sites, use responsive design. For legacy sites using device redirects and m. subdomains, the migration path to responsive design involves consolidating content under the desktop URLs, updating canonical annotations, removing device redirect rules, and ensuring the responsive design covers the full range of device sizes previously served by the mobile site.
Migrating from device redirects to responsive design
Moving from a device redirect architecture to responsive design is a significant project but a worthwhile one. The general approach follows a structured migration.
Audit the current state: document all device redirect rules in place, the URL structure of both the desktop and mobile sites, and any canonical annotations currently configured. Understand the full scope of what needs to change.
Build the responsive version: develop or update the desktop site to be fully responsive, adapting correctly to all screen sizes from the narrowest smartphone to the widest desktop display. This may involve significant design and development work depending on how different the mobile site was from the desktop version.
Content reconciliation: if the mobile site contained content different from the desktop site, stripped-down versions, mobile-specific pages, features only on one version, decide which content belongs in the unified responsive site and migrate it.
Redirect m. subdomain URLs: once the responsive desktop site is live, configure 301 redirects from all m. subdomain URLs to their desktop equivalents. m.example.com/page permanently redirects to example.com/page. This consolidates all equity from mobile-specific backlinks to the canonical desktop URLs.
Remove device redirect rules: once the responsive site is live and m. subdomain redirects are in place, remove the device redirect rules that previously sent mobile visitors to m.example.com. Mobile visitors now receive the responsive desktop site directly.
Update canonical annotations: remove the mobile-specific canonical and alternate annotations from the desktop site. The unified responsive site needs no special canonical handling: one URL, one canonical, all devices.
Monitor after migration: track Google Search Console for any coverage issues, monitor mobile usability reports for problems with the responsive implementation, and verify that rankings for mobile searches are maintained through the transition.
Common device redirect mistakes
301 instead of 302: a permanent redirect for a device-conditional rule causes browsers to cache the redirect and send all future visitors from that device to the mobile site regardless of server configuration changes. Always use 302 for device redirects.
Faulty redirects to the mobile homepage: redirecting all mobile visitors to the mobile homepage regardless of which page they requested. Any mobile visitor following a link to a specific page lands on the homepage rather than the equivalent mobile page. Always preserve the path through device redirects.
User-Agent detection errors: User-Agent strings are complex and change frequently as new devices and browser versions are released. A detection pattern that was accurate when written may miss new devices or incorrectly classify some browsers. Use a maintained device detection library rather than a simple string match.
No desktop link from mobile site: mobile sites that provide no way for users to switch to the desktop version trap visitors in the mobile experience even when they prefer the full desktop site. Always provide a visible link to the desktop version from the mobile site.
Inconsistent content between versions: if the mobile site contains different or missing content compared to the desktop site, mobile-first indexing means the missing content may not be indexed at all. Ensure content parity between versions or migrate to responsive design.