In late 2011 a report was released showing over 90% of mobile eCommerce purchases came from iPhone and iPad devices. For merchants having a moblie website that performs well and allows consumers to research, shop and complete transactions is really no longer an option, but a necessity. How should merchants go from not having a mobile platform to implementing one? Should they choose a subdomain, mobile version, or app? What are the big pitfalls to watch out for?

Many of the elements for good mobile SEO seem like usability issues. The fact is, if you design, build and implement websites pages and URL’s that work well on normal desktop computers, and don’t require elaborate workarounds or jumping through hoops – mobile SEO isn’t really that different than normal SEO. The key is not to complicate the user experience for the mobile version, and not allow your technical implementation to “get in the way” of search engines understanding your pages.

Mobile Subdomains

Implementing a mobile subdomain is clearly the easiest way to solve the problem. However, in reality, this is an easy short term solution with long term problems. When you choose a mobile subdomain like:

m.example.com/some-page.php

You encounter problems when users cross platforms and view your content on desktop devices. For example, try to share a YouTube video from Facebook you liked from your phone to someone with a desktop and you will get a URL that looks like this

http://m.youtube.com/?rdm=4p9mbicqu&reload=3#/watch?desktop_uri=%2Fwatch%3Fv%3DmxpDTzeUM8A&v=mxpDTzeUM8A&gl=US

Try to click and view that link on a desktop computer and you get redirected back through a series of multiple urls and eventually end up at a dead end with no video. While viewing a YouTube video isn’t mission critical for anyone, what if it was a product someone wanted to buy? Sure you could have smart programmers put a lot of time, effort and programming resources and make sure the urls redirect properly, but the more moving parts you have, the more spots there are for errors to creep in. If the programmers at Youtube can’t get it right, do you think you have more programming resources to solve the problem?

The second danger of using a mobile subdomain is that search engines will index them. For example search engines will index the standard and mobile versions of your website make a “best guess” which is the page they want to rank in the search engines. Most of the time they will get it right, but they aren’t perfect, and when they do get it wrong you have an angry customer with a bad user experience on their hands.

Mobile Version

Having a mobile version of your website is similar to a mobile subdomain with a simple but important difference. The URL for every page is the same, however the content will change based on if the user is coming from a mobile or desktop computer. In a perfect world you would keep the URL identical for both visitors, however using CSS and server side programming, you would serve a different style sheet and omit information not necessary for the mobile platform. You could do it with just a style sheet, and “hide” certain elements from displaying. However this would make the mobile page larger than it needs to be, slower to load and have an impact on performance. Google has indicated page speed is now a component in search engine rankings so avoid creating this potential trouble spot if possible.

It is possible to keep the URL’s the same and “activate” the mobile version with a parameter like this:

example.com/some-page.php?ver=mobile
example.com/some-page.php#mobile

These implementations share the same problems as a subdomain: if a person on a desktop computer clicks a mobile link, you still need to redirect them to the full site version or risk them viewing a tiny or “lite” version of your page.

From a link building perspective, having a mobile subdomain or URL with parameters is problematic as well. If search engines see links to different versions, it’s possible they will misattribute or divide the link equity between the standard and mobile pages. You can use the rel=canonical tags to give the search engines hints to the real URL but its an imperfect solution that doesn’t work 100% of the time.

Mobile App

Creating a mobile app is a “sexy” solution a lot of companies are choosing, but it’s not the right solution for everyone. If you are a large well known store, or have a dedicated customer base who makes multiple purchases from you per year, then developing a mobile app makes absolute sense. However if you are a smaller merchant and your customers only visit you once or once a year, asking them to download and install a mobile app creates a speed bump or abandonment point in the checkout process, and is not something you’d want to do.

From a long term maintenance standpoint, creating a mobile app means creating another maintenance point. So be sure it’s something you can support for the long run. If your IT budget is small, serving a mobile version on the one URL is the most cost effective solution.

If you do decide to go with a mobile app, it’s important to make sure the mobile app sends the information to the live website. For example if you put an item in your shopping cart in the amazon mobile app but don’t checkout, the item is still in your cart on the regular website. This is also true for your wish lists:

Takeaways from this post:

Having a mobile friendly website is essential if you want to perform mobile eCommerce

• While mobile subdomains may get you up to speed faster, they are problematic in the long run, difficult to maintain and require more programming resources
• Mobile subdomains often leads to duplicate content or incorrect context being interpreted by the search engines
• Using one URL, but changing the content based on what device the user has is usually the optimal solution
• Using parameters in URL to activate mobile versions works, but make sure you don’t serve the mobile version to desktop users
• Use mobile apps only when you have a large number of returning customers

Image credit: Shutterstock/Zhiltsov Alexandr