How to handle desktop and mobile users

This post has been updated at the bottom.

This seems to be a recurring topic that somehow just doesn’t want to settle, and since I recently did a presentation on this topic I thought it would be nice to highlight this particular step.

Just before I headed up to ExpOn in São Paulo last month. I spent some time trying to put together a simple flowchart that would illustrate nicely how you as a webmaster should handle desktop content and mobile content, and with the help of John Mueller we managed to put together something we thought would be clear and simple enough. One thing to keep in mind before I start is that you should always show to Googlebot the same content you show to a user on a desktop browser, because Googlebot will not be crawling or indexing all mobile versions.

There are mainly 2 types of mobile devices:

• Smartphones – that have full featured browsers (most common are Android, iPhone, Windows Phone, etc);
• Feature Phones – that have limited capabilities, processing power, etc. (and usually can only handle WAP, WML, xHTML, etc) these often need a transcoder too to render normal HTML pages.

There is only one scenario where Google wants to crawl a mobile version of a site and that’s when there is a Feature-phone version. That’s because, due to the limited capabilities of these devices, Google stores these sites in a different index, specially tailored to serve this kind of content. So if you have to think about content delivery according to users and Google, you should think something along these lines: This has changed, see updated at the bottom.

So now let’s say you want to decide how to handle mobile users VS desktop users but you have been undecided in how you should set it up. You saw people that have set a mobile version using the same URLs and others who have set a mobile version using different URLs and everybody tells you their way is the best, and aaaaah… You can’t decide!

Well, to start you need to decide if you want or even need to have a mobile version of your site for Feature-phones or if it’s enough to have just a Smartphone optimized layout. It will depend of how mainstream your business is, is it a global business that reaches to everyone or is it a niche business that reaches only to a small amount of people? You need to assess your audience… What do they use most?

After you have decided what your audience uses most and what type (or types) of mobile site you want to have, than you can start planning how it will be structured. To help you with that here are the most popular options (Green arrows = YES; Red arrows = NO):

Using the same URLs

Using different URLs

If a visitor goes directly to your mobile version, the best thing is not to do any kind of redirections, but sometimes you might want to distinguish between a Smartphone user and a Feature Phone user, so if a user navigates to your mobile version directly and you want to present the best version for the type of mobile device, here is how you should think about it:

Hope this contributes to clarify things a bit and clear some of those pesky doubts about how and what’s the best option for your site.

 
UPDATE: Since I frist wrote this posts, Google changed how they handle smartphone optimized websites. How Google treats content for SmartPhones is the only thing that changes.

BEFORE:

• You wouldn’t serve your SmartPhone optimized site directly to Googlebot/Googlebot-mobile.
• Googlebot-mobile would only index content specifically tailored to FeaturePhones.
• You wouldn’t allow it to be indexed or it would be canonicalized to the desktop version of your site.

NOW:

• You can serve your SmartPhone optimized site to Googlebot-mobile.
• Googlebot-mobile will index both FeaturePhone and SmartPhone content.
• You can serve based on the UA, see post I wrote about “how to handle mobile users” but have new stuff in consideration:

REMEMBER:

• Mobile sites are/should be accessible, light and simple by nature.
• You should start to worry about how your mobile version shows up in search results.

How to Handle Mobile Web Performance

No related posts.