I'm currently putting together a mobile version of an existing site (Django-based) and there seems to be two ways of doing this. I can do one of two things:

  1. Detect a mobile useragent and redirect the user from http://www.example.com/page/awesome/ to http://m.example.com/page/awesome/, which serves up mobile-specific markup, CSS etc.

  2. Just detect the useragent and serve up different content on the www subdomain depending on whether the useragent is mobile or not.

To me, (2) feels cleaner, because the site's adapting content served based on the client, but without changing the URL. However, (1) seems to be a lot more prevalent on various popular internet sites, and there must be some good reasoning behind it.

Obviously, (1)'s easier to test, but redirection just feels messy, as well as doubling the number of URLs.

What's the "right" way to do this, and what other pros/cons should I be looking at?

  • 1
    I think that rather than using the User Agent, which both (1) and (2) use, we will see a movement towards feature detection (ie - resolution) to determine what gets served up. That's the idea beyond responsive design, but I think programmers are more comfortable planning/working with a dichotomy, vs. something more dynamic. – Dallas Mar 10 '12 at 20:50

With the current trend towards responsive design I think you'd be correct in your assumption that (2) is the best approach.

The dividing line would be how you intend to manage the content. If you were placing different or modified content/resources on the mobile site then it may be easier and more efficient in terms of page weight to manage the site on a sub-domain.

If you have identical content and resources on both the main site and the mobile site then there is no value in the sub-domain approach.

| improve this answer | |

With Google dragging their heels and sending mixed messages on this topic, Bing has come out in favour of the 1 URL to Rule Them All approach:


| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.