One of the features of MOBIFY is mapping the source site to the mobile view (www.yoursite.com/category/article & m.yoursite.com/category/article). After installing a device detection plugin, search links work on mobile without loading the heavy desktop version. This presents several interesting challenges.

1. My mobile view appears in desktop search results. We most often illustrate this using the Digg example:

200907132248.jpg

Some desktop sites are not very SEO-friendly, causing the mobile view to rank higher than the source. Google loves well-designed, well-structured sites with minimal noise. Mobile versions often match that description. Would you want to be ranked higher at the expense of your desktop version being #1? A quick fix for this situation is achieved by blocking search engine crawlers from seeing the mobile view.

2. Mobile vs Desktop Sitemaps.

Google has a whole section dedicated to mobile sitemaps in its Webmaster Central. It also has a section for desktop sitemaps. While the overall effectiveness of these can be disputed, should a mobile view have a sitemap of its own? Should there be two, in parallel? This is not clear when the URL structure and domain are the same for both properties.

3. Should mobile crawlers be driven to specific areas of a website?

Major search engines deploy mobile crawlers – masked behind User Agent strings of outdated phones like the Nokia 8300. Their task is to discover mobile-friendly pages. In the WebKit world mobile friendliness means a lot more to the publisher (from the revenue standpoint) than to the mobile user. We recommend only messing with this in case the point of entry to the mobile view is different than the index of the source site.

These are interesting decisions that come us as websites face several types of search and use context. Let us know if you have any stories to tell!

  • http://tripleodeon.com James Pearce

    Good topic ;-)

    You don’t discuss how the results do (or, rather, should) change with the UA of the device performing the search, or whether it’s the ‘mobile version’ of the search engine’s UI.

    The contemporary act of searching means “get me the best resource for my context”, not “get me a list of all the relevant pages anywhere on the web”. When your context is mobile, that’s more important than ever: it’s not just about a small screen, but about humans on the move.

    This is a subtlety lost on many major search engines – especially those who then provide their own inline transcoding and further confuse the ranking with these tinkered versions and funny little icons to try and warn users what’s going on.

    (Such unapproved adjustment might fix the syntax for mobile, but does it make the semantics of subject matter more relevant to a mobile user? Or honourably capture the intent and aesthetics of the site? Probably not.)

    Mowser, pre-dotMobi, was a mobile transcoder without site-owner opt-in. Because the search engine was rating the resulting wellformedness highly (as above), site owners *who didn’t even know about mobile* were finding their own sites pushed off the desktop rankings by the transcoded version. The platform had to deny crawler access subsequently – and I think it is good we are seeing a swing towards owner-led ‘opt-in’ adaptation like Mobify & Instant Mobilizer.

    A good desktop/mobile switching algorithm needs to be sensitive to search engine crawler behaviour – especially where cookies & links & multiple domains are considered.

    Just for completeness, there’s also the matter of having a mobile top-level domain, like .mobi (instead, or probably as well as a subdomain) – if only for the reason that it will appear in the TLD zone files and get picked up quicker than a subdomain does.

    Finally… who knows how much page-rank is used in modern ranking algorithms? We’ll never really know – but regardless, it’s worth remembering that the mobile web has far less ‘linkedness’, particularly inter-site (mostly for screen real-estate reasons, but also because you’re always less sure about the ‘mobileness’ of the destination).

    This all messes with the basic premises of ‘authority’, and is why the world of mobile discovery still has to suffer operator’s preferential gardens and, um, app stores.

  • http://whilefalse.net Steven Anderson

    The problem of SEO for mobile sites is an interesting one. I feel, however, that too often people assume their mobile site needs to sit on a separate domain, e.g. m.example.com, or example.com/mobile, or example.mobi, or any of the other numerous possibilities out there.

    By being smart with device detection and dynamic rendering of sites, you need never use a second domain at all. This allows you to utilise all the hard work you have put into your desktop SEO on your mobile site. Being able to promote a single domain accross your entire marketing/branding effort also makes it a hell of a lot easier for a user to reach your mobile site, and provides them with a briliant experience from the moment they hit your site.

    I compare this to having a “www.” and a non-”www.” website, and trying to find a solution to gain high SEO for both. The solution, of course, is not to need both domains, and to have one issue a 301 to the other. This concentrates all of your SEO effort in one place. By dynamically rendering the correct version of your site, you’ll accomplish the same thing for mobile.

    Some other advantages of using the same domain for both versions of your site are the ease of distributing links across devices, and maintaining the semantic nature of your url structure.

    I’d love to hear your opinions on this…

    Thanks.

  • http://www.mobify.me Igor Faletski

    Thanks for your comments, James & Steven!

    Like I mentioned in the blog post, there are more questions than answers at this point regarding mobile visibility. For us, it’s great to be in position to discover and measure many consequences of going mobile.

    I agree, in the bright future there won’t be a need for subdomains for mobile, iphone and desktop versions. Just like WordPress with a mobile plugin, most CMSes will be able to present an optimal layout dynamically. However, with hundreds of millions of websites designed for the desktop screen resolution it seems for the next 10-20 years there is lots of work to be done!

  • http://tripleodeon.com James Pearce

    > in the bright future there won’t be a need for subdomains for mobile

    I don’t actually believe that.

    Whatever the actual syntax of URL is used, I still think there’s a place for letting users indicate preferred context in the URL.

    Domains strongly indicate a preferred context – whether it be language, country-of-residence, or, yes, mobility.

    For example, I don’t think Amazon advertises amazon.fr or amazon.com to Germans (although they wisely suggest or correct a better choice based on IP address if one were to use them).

    Similarly, whilst recognition can help with mobility, you’re a) being brave to naively overule the user if they’ve expressed a choice, and b) missing the opportunity to promote the fact that you have a service specifically targeting that medium in the first place.

    We can have an argument about whether mobility is like a country (I’m a proud citizen!), but otherwise, the logic is quite strong.

  • http://m.gtricks.com Aery

    Really this is a very annoying problem. No webmaster wants to have duplicate content. Thanks to Google for providing much-sort help docs, but if mobify could do same in their dashboard or forum , it would be really helpful.

    Ideally, Mobify forum should have a sticky post about it.

  • http://www.limobaltimore.net Limo in baltimore

    ideally mobify is doing great and work is ging on .