I am going to be using jQuery Mobile to create a mobile version of my site.

My question is about the best practice on the location of the mobile site, specifically, the URL. I am looking into two options:

  1. Just detect whether the user is mobile and serve them a mobile template, no need for a separate URL for the mobile site. For example, mysite.com/foo/bar would have a mobile and desktop version of the page. My site uses HTTP cache and this would complicate things...

  2. Have a mobile URL (m.mysite.com). I prefer this method as I see this in a lot of places (ie m.facebook.com). My hesitation is with SEO, isn't duplicating content bad?

Any insights, thoughts, comments on my dilemma? Is there a strategy I am missing?

  • 1
    Technically speaking this question cannot be answered definitively. This topic is a whole broader discussion that is currently evolving in the web development community - also being called "responsive web design." I'll give you some points to consider, however. Jul 13, 2011 at 4:24

3 Answers 3


Most sites choose option #2. If you do it won't hurt your SEO as Google knows there are mobile versions of websites. That's why Google has two bots: Googlebot and Googlebot-Mobile. Googlebot crawls desktop-browser type of webpages and content embedded in them and Googlebot-Mobile crawls mobile content.

Google covered mobile SEO recently. If you're interested in mobile SEO it's worth reading.

A very common question we see is: Does it matter if the different types of content are served from the same URL or from different URLs? For example, some websites have www.example.com as the URL desktop browsers are meant to access and have m.example.com or wap.example.com for the different mobile devices. Other websites serve all types of content from just one URL structure like www.example.com.

For Googlebot and Googlebot-Mobile, it does not matter what the URL structure is as long as it returns exactly what a user sees too. For example, if you redirect mobile users from www.example.com to m.example.com, that will be recognized by Googlebot-Mobile and both websites will be crawled and added to the correct index. In this case, use a 301 redirect for both users and Googlebot-Mobile.

If you serve all types of content from www.example.com, i.e. serving desktop-optimized content or mobile-optimized content from the same URL depending on the User-agent, this will also lead to correct crawling by Googlebot and Googlebot-Mobile. This is not considered cloaking by Google.

It is worth repeating that regardless of URL structure, you must correctly detect the User-agent as given by your users and Googlebot-Mobile, and serve both the same content. Don’t forget to keep the default content, the desktop-optimized content, for when an unknown User-agent requests it.


You should also look into creating your website to respond based on the screen size.

Ethan Mercotte published an article describing this. This is the current trending technique for dealing with mobile of websites:


In my opinion this is the best mobile strategy and simplifying the process for SEO as well.

  • In some cases this is not the best solution. It is proven that developing a mobile-specific version has better performance. You usually have a richer interface (components, images) in the desktop version and a more simplified version in mobile. But of course, this depends on the project, as I said it only applies to certain cases, it is the responsibility of the developer / architect to know which solution to use. Feb 18, 2013 at 20:39

Kevin, the answer to your question strictly speaking is: it depends.

There are several factors to consider in selecting either of the options you have described, and neither is "wrong" per se. It just depends what your goal and circumstances are.

That being said, scope and scalability of your site/application are the primary concerns.

I've done a fair amount of research on this topic for 6 mo. - 1 year now (for my work on CURE.org, where we've already implemented one of these options for cure.org/blog), and in fact revisited this discussion again this week for my personal site, joelglovier.com.

So when I say that "scalability" is a concern, you have to remember that if your site is going to have continually updating content, then you have to accomodate that in both places if you have your scenario of m.site.com setup. If you're site is database driven and/or uses a good CMS, that isn't necessarily too difficult to setup.

Nevertheless, depending on how often you are creating fresh content, landing pages, or campaigns on your site, it could grow cumbersome to have to create that content twice every time.

And if you're referring to a simple portfolio site for yourself or a client, then again repurposing content (without any type of database or CMS infrastructure) can get cumbersome quickly.

But on the other hand, when you have a site like Facebook, for example - where scalability of your site/content is critical to what you're doing as a whole - then a subdomain is really very appropriate. Partly because at the web application level you're most certainly going to have a CMS or dynamic environment that will fairly easily support your ongoing content publishing to both the mobile site and the desktop site environment (after initial development of course).

The separate mobile site really allows you to feed users only the markup and content that you want them to have versus serving everything and hiding much of it via the @media-queries method or a jQuery method.

Personally, for my own simple portfolio site I've more or less settled on not having a separate mobile site because I'm not building anything that is really application level. So I'm going with CSS3 media queries, and jQuery fallback for IE users.

Here's some of the recent resources I've been thumbing through:







Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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