User Agent Detection and Redirection

Mobile SEO: User Agent Detection and Redirection

If you haven’t noticed, there is a lot of room for improvement in the mobile search algorithms. The main way that the current algorithms fall short, is in knowing when to rank a mobile page verses ranking a corresponding mobile page. In many cases, (especially if you are searching from a SmartPhone,) the search engines will rank a traditional page on a website, even if there is a corresponding mobile page available.

The smart phone algorithm gives only a minimal advantage to mobile pages (if any at all), and essentially, they must compete against their traditional counterparts. This makes mobile SEO difficult, because traditional pages generally have more links, history and successful site traffic than the corresponding mobile pages, so they have the algorithmic advantage. Consequently, mobile SEO involves a lot of contingency planning which can makes it quite complicated. The complication is mostly related to the large variety of mobile screen sizes and resolutions, as shown below:



If you have a traditional site, and corresponding mobile pages on an ‘m.’ or ‘/m’ the best way to combat this shortcoming in the smart phone search algorithm is to set up server-side user agent detection and redirection between the traditional pages and their mobile counterparts. With this in place, you can take advantage of the traditional pages that rank in mobile search, but still provide a mobile-friendly experience when the site is accessed on a mobile phone.

The image below is precisely what Google says about this, indicating that it is not considered cloaking or a negative indicator. As long as you are serving the same content to mobile users as would to a mobile bot, it is considered a user-experience enhancement, and totally kosher.  The original article can be found here: (http://


The important thing to remember with user-agent detection and redirection is that it is for the benefit of the user. You want to make their experience as seamless as possible weather they are on a computer, tablet, smart phone or feature phone. How you do this will depend on the intricacy of your website; websites with lots to functionality may need more attention than websites that are mostly static.

Mobile-Traditional Hybrid Pages

The simplest option is to use your existing content and create different external style sheets that are pulled based on the screen size of the device that is accessing the content. In this option, you rely on one set of pages to do all the work. It is great for SEO because there is no risk of duplicate content, and no additional effort beyond creating all the style sheets. Unfortunately, it may just not be a viable solution if there is functionality on your traditional website like Flash that will not work on mobile phones, or if there is a lot of other content on the traditional site that you will not want to display on the mobile rendering.

It is fine to use ‘display-none’ to block some content from your traditional site from showing on the mobile rendering, but remember that it will still have to download, even if it does not display, so it can still have a negative impact on download speed. The best alternative is to use CSS image replacement to send something else instead of using ‘display-none.’

Separate Mobile Pages

For the next degree of complexity, you can create a separate group of mobile pages which are hosted on a mobile subdomain or subdirectory. These pages are meant to work on both smart phones and feature phones, so in general, you should build them to meet the lowest common standards, which will be the feature phones. This will limit the amount of HTML5, JavaScript, AJAX and video that you will be able to successfully use on the mobile pages. On the less dynamic sites, this is generally fine. You can use the complex codes to some degree, but you will always need a contingency plan, in case the user is accessing the site from a less sophisticated phone.

In terms of server settings, the user-agent detection and redirection will simply recognize all mobile devices and send them to these mobile-friendly pages. If tablets access the site they are sent to the traditional website, because the mobile experience might be too limiting, and the tablets will be able to handle almost all of the functionality on the traditional pages.

Touch-Screen Pages and Feature Phone Pages

An even more complex option is to create two mobile pages for each traditional page – One version that will be served when touch-screen phones access the site and another that will be served when feature phones access the site. This option is a lot of work, so be sure you make the most of it. Keep the static, less dynamic design for the feature phones, but do a really good job updating the functionality of the touch-screen site.

When designing a mobile rendering for touch-screen phones, try to think more like an app developer than a web developer. Go to the various application marketplaces, and review apps that are in your category so that you can mimic the functionality, look and organization of the apps on your site. Using animation, JavaScript and mobile AJAX with XHTML and HTML5 can really make a site that behaves almost like an application. Include buttons so that visitors can easily bookmark the page or add it to their home screen. If you are really sophisticated, you can integrate geo-location and SMS interaction on this version of the site.

In terms of user-agent detection and redirection you should plan on redirecting most devices that have a screen resolution of 240 x 320 or higher. This can be done on the server or with a CSS media query, but it should also be combined with a query that will check if the device is touch capable. It looks like this:

if(window.Touch) { /* JavaScript for your touch interface */ }

This is a great article by Tim Wright that gives a lot more insight:

Tablets & iPads

The last level of complexity is the new entry of tablets and iPads, which are touch screen, and slightly mobile, but much bigger than phones. In most cases, I recommend simply serving your traditional website to devices like this. Unless there is a compelling justification for the additional expenditure, it might not be worth it to add this additional complexity to the site. In general, if it is justified, it is because the traditional site relies heavily on Flash, which will not work on the iPad, or if the brand feels strongly that the content of the traditional website should be made touch-friendly for this new group of devices.

The other concern for tablets and iPads is load time. Remember that sometimes tablets will be accessing the web over a WiFi connection, but other times they may be accessing the content over a slower mobile network, at 3 and 4G speeds. Load time becomes a concern for tablets when they are accessing traditional websites over a mobile connection, especially if the traditional site is already slow to load or has a high number of DNS requests and dependent files. If load time is the only concern, then the best option might be simply to speed up the load time of the traditional site, but if there are other concerns, you may need to create tablet-specific pages.

When you have table-specific pages, you will use the same methods to identify touch screen devices. The lowest screen resolution for a tablet is 480×800, which is the same as some smart phones. 600×1024 is a more likely resolution for a tablet, and the iPad resolution is 1024×768. The problem is that some smart phones have a resolution as high as 1024×480. While we expect a couple of standard tablet screen resolutions to emerge, not all tables are touch screen, so it gets even more complicated. You can set up basic rules, but you may have to specify down to the exact user-agent of each device to get the optimum result from your user-agent detection.