<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Pros and Cons of Mobile SEO</title>
	<atom:link href="http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/</link>
	<description>The Leading Mobile Web Platform</description>
	<lastBuildDate>Thu, 02 Feb 2012 16:53:42 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Limo in baltimore</title>
		<link>http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/comment-page-1/#comment-2469</link>
		<dc:creator>Limo in baltimore</dc:creator>
		<pubDate>Mon, 09 Aug 2010 16:57:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mobify.me/2009/07/14/pros-and-cons-of-mobile-seo/#comment-2469</guid>
		<description>ideally mobify is doing great and work is ging on .</description>
		<content:encoded><![CDATA[<p>ideally mobify is doing great and work is ging on .</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aery</title>
		<link>http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/comment-page-1/#comment-2455</link>
		<dc:creator>Aery</dc:creator>
		<pubDate>Fri, 04 Jun 2010 10:27:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mobify.me/2009/07/14/pros-and-cons-of-mobile-seo/#comment-2455</guid>
		<description>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.&lt;br&gt;&lt;br&gt;Ideally, Mobify forum should have a sticky post about it.</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>Ideally, Mobify forum should have a sticky post about it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Pearce</title>
		<link>http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/comment-page-1/#comment-307</link>
		<dc:creator>James Pearce</dc:creator>
		<pubDate>Fri, 17 Jul 2009 12:12:19 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mobify.me/2009/07/14/pros-and-cons-of-mobile-seo/#comment-307</guid>
		<description>&gt; in the bright future there won’t be a need for subdomains for mobile

I don&#039;t actually believe that.

Whatever the actual syntax of URL is used, I still think there&#039;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&#039;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&#039;re a) being brave to naively overule the user if they&#039;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&#039;m a proud citizen!), but otherwise, the logic is quite strong.</description>
		<content:encoded><![CDATA[<p>&gt; in the bright future there won’t be a need for subdomains for mobile</p>
<p>I don&#8217;t actually believe that.</p>
<p>Whatever the actual syntax of URL is used, I still think there&#8217;s a place for letting users indicate preferred context in the URL.</p>
<p>Domains strongly indicate a preferred context &#8211; whether it be language, country-of-residence, or, yes, mobility.</p>
<p>For example, I don&#8217;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).</p>
<p>Similarly, whilst recognition can help with mobility, you&#8217;re a) being brave to naively overule the user if they&#8217;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.</p>
<p>We can have an argument about whether mobility is like a country (I&#8217;m a proud citizen!), but otherwise, the logic is quite strong.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Igor Faletski</title>
		<link>http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/comment-page-1/#comment-305</link>
		<dc:creator>Igor Faletski</dc:creator>
		<pubDate>Wed, 15 Jul 2009 17:41:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mobify.me/2009/07/14/pros-and-cons-of-mobile-seo/#comment-305</guid>
		<description>Thanks for your comments, James &amp; Steven!

Like I mentioned in the blog post, there are more questions than answers at this point regarding mobile visibility. For us, it&#039;s great to be in position to discover and measure many consequences of going mobile.

I agree, in the bright future there won&#039;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!</description>
		<content:encoded><![CDATA[<p>Thanks for your comments, James &#038; Steven!</p>
<p>Like I mentioned in the blog post, there are more questions than answers at this point regarding mobile visibility. For us, it&#8217;s great to be in position to discover and measure many consequences of going mobile.</p>
<p>I agree, in the bright future there won&#8217;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!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven Anderson</title>
		<link>http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/comment-page-1/#comment-301</link>
		<dc:creator>Steven Anderson</dc:creator>
		<pubDate>Tue, 14 Jul 2009 08:18:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mobify.me/2009/07/14/pros-and-cons-of-mobile-seo/#comment-301</guid>
		<description>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 &quot;www.&quot; and a non-&quot;www.&quot; 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&#039;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&#039;d love to hear your opinions on this...

Thanks.</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>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.</p>
<p>I compare this to having a &#8220;www.&#8221; and a non-&#8221;www.&#8221; 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&#8217;ll accomplish the same thing for mobile.</p>
<p>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.</p>
<p>I&#8217;d love to hear your opinions on this&#8230;</p>
<p>Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Pearce</title>
		<link>http://blog.mobify.com/2009/07/14/pros-and-cons-of-mobile-seo/comment-page-1/#comment-299</link>
		<dc:creator>James Pearce</dc:creator>
		<pubDate>Tue, 14 Jul 2009 08:10:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mobify.me/2009/07/14/pros-and-cons-of-mobile-seo/#comment-299</guid>
		<description>Good topic ;-)

You don&#039;t discuss how the results do (or, rather, should) change with the UA of the device performing the search, or whether it&#039;s the &#039;mobile version&#039; of the search engine&#039;s UI.

The contemporary act of searching means &quot;get me the best resource for my context&quot;, not &quot;get me a list of all the relevant pages anywhere on the web&quot;. When your context is mobile, that&#039;s more important than ever: it&#039;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&#039;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&#039;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 &#039;opt-in&#039; adaptation like Mobify &amp; Instant Mobilizer.

A good desktop/mobile switching algorithm needs to be sensitive to search engine crawler behaviour - especially where cookies &amp; links &amp; multiple domains are considered.

Just for completeness, there&#039;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&#039;ll never really know - but regardless, it&#039;s worth remembering that the mobile web has far less &#039;linkedness&#039;, particularly inter-site (mostly for screen real-estate reasons, but also because you&#039;re always less sure about the &#039;mobileness&#039; of the destination).

This all messes with the basic premises of &#039;authority&#039;, and is why the world of mobile discovery still has to suffer operator&#039;s preferential gardens and, um, app stores.</description>
		<content:encoded><![CDATA[<p>Good topic <img src='http://blog.mobify.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>You don&#8217;t discuss how the results do (or, rather, should) change with the UA of the device performing the search, or whether it&#8217;s the &#8216;mobile version&#8217; of the search engine&#8217;s UI.</p>
<p>The contemporary act of searching means &#8220;get me the best resource for my context&#8221;, not &#8220;get me a list of all the relevant pages anywhere on the web&#8221;. When your context is mobile, that&#8217;s more important than ever: it&#8217;s not just about a small screen, but about humans on the move.</p>
<p>This is a subtlety lost on many major search engines &#8211; 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&#8217;s going on.</p>
<p>(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.)</p>
<p>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&#8217;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 &#8211; and I think it is good we are seeing a swing towards owner-led &#8216;opt-in&#8217; adaptation like Mobify &amp; Instant Mobilizer.</p>
<p>A good desktop/mobile switching algorithm needs to be sensitive to search engine crawler behaviour &#8211; especially where cookies &amp; links &amp; multiple domains are considered.</p>
<p>Just for completeness, there&#8217;s also the matter of having a mobile top-level domain, like .mobi (instead, or probably as well as a subdomain) &#8211; if only for the reason that it will appear in the TLD zone files and get picked up quicker than a subdomain does.</p>
<p>Finally&#8230; who knows how much page-rank is used in modern ranking algorithms? We&#8217;ll never really know &#8211; but regardless, it&#8217;s worth remembering that the mobile web has far less &#8216;linkedness&#8217;, particularly inter-site (mostly for screen real-estate reasons, but also because you&#8217;re always less sure about the &#8216;mobileness&#8217; of the destination).</p>
<p>This all messes with the basic premises of &#8216;authority&#8217;, and is why the world of mobile discovery still has to suffer operator&#8217;s preferential gardens and, um, app stores.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

