I'm attempting to find out information on the SEO implications of testing ipv6 out. A couple of concerns that come to mind are: 1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only. 2) Not running ipv6 natively, or using 6to4. This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times. 3) ??? Any others that I haven't thought of ??? So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process. Thoughts? -wil
On Mon, 28 Mar 2011 15:18:30 -0700 Wil Schultz <wschultz@bsdboy.com> wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
A couple of concerns that come to mind are:
1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only.
2) Not running ipv6 natively, or using 6to4. This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times.
3) ??? Any others that I haven't thought of ???
If you are so concerned about SEO, just dual-stack your site. It works well for me. William
On Mar 28, 2011, at 3:18 PM, Wil Schultz wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
A couple of concerns that come to mind are:
1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only.
2) Not running ipv6 natively, or using 6to4. This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times.
3) ??? Any others that I haven't thought of ???
So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process.
Thoughts?
-wil
If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo. It's been working just fine for www.he.net for years. Owen
On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote:
If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo.
Why is native IPv6 needed? I'd have thought a tunnel would be fine, too. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
On Mar 28, 2011, at 7:10 PM, Karl Auer wrote:
On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote:
If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo.
Why is native IPv6 needed? I'd have thought a tunnel would be fine, too.
So why does www A 127.0.0.1 www AAAA ::1 Preclude a tunnel? I can't get native here to my IPv6 is tunneled thru he (Thanks he) but that doesn't change dual DNS entires. (Note used loopback as an example) Tom
On Mar 28, 2011, at 4:20 PM, TR Shaw wrote:
On Mar 28, 2011, at 7:10 PM, Karl Auer wrote:
On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote:
If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo.
Why is native IPv6 needed? I'd have thought a tunnel would be fine, too.
So why does
www A 127.0.0.1 www AAAA ::1
Preclude a tunnel? I can't get native here to my IPv6 is tunneled thru he (Thanks he) but that doesn't change dual DNS entires.
(Note used loopback as an example)
Tom
Well, hard to tunnel to a loopback address, but, using a better example: www IN A 192.0.2.50 IN AAAA 2001:db8::2:50 Would not preclude a tunnel at all. The issue is that he seemed concerned with additional latency from a tunnel resulting in SEO penalties, so, I suggested native as a resolution to that concern. Owen
On Mar 28, 2011, at 4:10 PM, Karl Auer wrote:
On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote:
If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo.
Why is native IPv6 needed? I'd have thought a tunnel would be fine, too.
He was worried about the latency of tunnels creating penalties for SEO purposes, but, otherwise, yes, that works too. Since he stated a desire to avoid tunnels as an initial area of concern, I went with his original statement. Owen
On Mar 28, 2011, at 3:55 PM, Owen DeLong wrote:
On Mar 28, 2011, at 3:18 PM, Wil Schultz wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
A couple of concerns that come to mind are:
1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only.
2) Not running ipv6 natively, or using 6to4. This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times.
3) ??? Any others that I haven't thought of ???
So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process.
Thoughts?
-wil
If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo.
It's been working just fine for www.he.net for years.
Owen
So far the consensus is to run dual stack natively. While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version. I'd also like to not damage SEO in the process though. ;-) -wil
I would be getting ipv6 connectivity, adding an unknown AAAA record such as ipv6 or www6; but not www, and do as many comparative ipv4 vs ipv6 tracerouts from as many route servers as possible. Then you will have the data you need to actually make an informed decision rather than just guessing how it will behave. Remove the temp record and add a real quad for www only if you liked what you saw. I assume the name servers are also available over ipv6 including glue? \n On 29/03/2011, at 9:25, Wil Schultz <wschultz@bsdboy.com> wrote:
On Mar 28, 2011, at 3:55 PM, Owen DeLong wrote:
On Mar 28, 2011, at 3:18 PM, Wil Schultz wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
A couple of concerns that come to mind are:
1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only.
2) Not running ipv6 natively, or using 6to4. This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times.
3) ??? Any others that I haven't thought of ???
So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process.
Thoughts?
-wil
If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo.
It's been working just fine for www.he.net for years.
Owen
So far the consensus is to run dual stack natively.
While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version.
I'd also like to not damage SEO in the process though. ;-)
-wil
I would be getting ipv6 connectivity, adding an unknown AAAA record such as ipv6 or www6; but not www, and do as many comparative ipv4 vs ipv6 tracerouts from as many route servers as possible. Then you will have the data you need to actually make an informed decision rather than just guessing how it will behave. Remove the temp record and add a real quad for www only if you liked what you saw.
I assume the name servers are also available over ipv6 including glue?
Why do you even need a AAAA record to do that? Just do a traceroute to the v6 address. The temporary AAAA record seems to do nothing useful in your proposed procedure. Easiest hack to test site usability: Modify your hosts file. Don't even publish the record in DNS until you're ready. Then there's no SEO implications. :)
So far the consensus is to run dual stack natively.
While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version.
I'd also like to not damage SEO in the process though. ;-)
If you're going to expose the site via a separate hostname (v6.bobdole.com), create a v6.robots.txt file that tells Google not to index v6.bobdole.com. Use an .htaccess rule to rewrite requests for robots.txt based on the host header, so v4 requests get the v4.robots.txt, and v6 requests get the v6.robots.txt, which tells Google not to index things. Nathan
Why do you even need a AAAA record to do that? Just do a traceroute to the v6 address. The temporary AAAA record seems to do nothing useful in your proposed procedure.
Easiest hack to test site usability: Modify your hosts file. Don't even publish the record in DNS until you're ready. Then there's no SEO implications. :)
You could go direct to the v6 addy, but using your hosts file for a dns record isn't going to work for the remote route servers I suggest testing from. Using a temp AAAA doesn't hurt, or lose you anything, and is technically a more accurate test, ultimatly I leave it to your discretion. \n
On Mar 29, 2011, at 1:21 AM, Wil Schultz wrote:
So far the consensus is to run dual stack natively.
While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version.
I'd also like to not damage SEO in the process though. ;-)
There has been a discussion of this in v6ops, around http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implication... "IPv6 AAAA DNS Whitelisting Implications", Jason Livingood, 22-Feb-11 and http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", Dan Wing, Andrew Yourtchenko, 14-Mar-11 In that context, you might review http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf Where you find a name ipv6.example.com, such as ipv6.google.com and www.v6.facebook.com, it is generally a place where the service is testing the IPv6 configuration prior to listing both the A and the AAAA record under the same name. The up side of giving them the same name is that the same content is viewable using IPv4 and IPv6; being IP-agnostic is a good thing. Unfortunately, at least right now, there is a side-effect. The side-effect is that a temporary network problem (routing loop etc) on one technology can be fixed by using the other, and the browsers don't necessarily fall back as one would wish. This works negatively against IPv6 deployment and customer satisfaction; it is not unusual for tech support people to respond to such questions with "turn off IPv6 and you won't have that problem". Hence, content providers often separate the names to ensure that people only get the IPv6 experience if they expect it. And Google among others whitelists people for IPv6 DNS service based on their measurements of the client's path to google - if a bad experience is likely, they try to prevent it by not offering IPv6 names. In general, I don't see a lot of difference between A and AAAA accesses, but I have had glitches when there was a network glitch. On one occasion, there was an IPv6 routing loop en route to www.ietf.org, but not one on the IPv4 path. The net result was a huge delay - it took nearly two minutes to download a page. The amusing part of that was that the same routing loop got in the way of reporting the issue to HE; I wound up sending an email rather than filing a case. Once it was fixed, matters returned to normal.
In a message written on Mon, Mar 28, 2011 at 03:18:30PM -0700, Wil Schultz wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
I don't run a web site where SEO is a top priority, so I don't track such things. Quite simply, who's crawling on IPv6? That is, will any of the search engines even notice? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Mar 28, 2011, at 9:50 PM, Leo Bicknell wrote:
In a message written on Mon, Mar 28, 2011 at 03:18:30PM -0700, Wil Schultz wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
I don't run a web site where SEO is a top priority, so I don't track such things.
Quite simply, who's crawling on IPv6? That is, will any of the search engines even notice?
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
The only crawling I have seen over IPv6 has come from Google - but I have only seen that on IPv6-only sites, not dual-stack sites: 2001:4860:4801:1302:0:6006:1300:b075 - - [28/Mar/2011:21:54:12 -0400] "GET /p/OWJjZD HTTP/1.1" 200 3790 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
On Mon, Mar 28, 2011 at 5:18 PM, Wil Schultz <wschultz@bsdboy.com> wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out. A couple of concerns that come to mind are: 1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only.
The real name for SEO is Search-Engine manipulation. And the moment you indicate "typical SEO standards", the search engine developers have likely already become aware of the existence of the problem/tactic and fiddled with knobs plenty of times since then.... Sometimes search engines penalize what they see to be duplicate content in the indexes. Spammers sometimes try to include the same content in many domains or steal content from other sites to enhance page rank. Big search engines offer some method of canonicalization or selection of a preferred domain through sitemaps. Use the tools provided by your search engine to tell them ipv6.domain.com is just domain.com. If IPv4 and IPv6 are combined in one index, there is a risk that the IPv4 pages could get penalized and only the IPv6 pages show at the top (or vice-versa). You could use robots.txt to block access to one of the sites for just the robots that penalized or a rel=nofollow. If even necessary... I for one am completely unconvinced that major search engines are penalizing in this scenario currently, solely because a site was duplicated to a "ipv6" subdomain. Keep in mind there is a search engine using this practice for their own domain. Who knows... in the future they may be penalizing sites that _don't_ have an IPv6 subdomain or v6 dual-stacking (assuming they are not penalizing that / rewarding IPv6 connected sites already). In this case attempting to put old SEO tactics first may hurt visitor experience more than help. ipv6.domain.com available over IPv6 and domain.com available over IPv4 are not really "different" domains; I expect search engines may keep IPv4 and IPv6 indexes separate. At least for a time... since there are IPv4-only nodes who would not be able to access IPv6 hyperlinks in a search results page. -- -JH
On 3/29/11 10:18 , "Wil Schultz" <wschultz@bsdboy.com> wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
3) ??? Any others that I haven't thought of ???
So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process.
Thoughts?
Do we know which spiders run on IPv6? After all an IPv6 only site may not be indexed at all...
On Mar 29, 2011, at 3:51 AM, Franck Martin wrote:
On 3/29/11 10:18 , "Wil Schultz" <wschultz@bsdboy.com> wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
3) ??? Any others that I haven't thought of ???
So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process.
Thoughts?
Do we know which spiders run on IPv6?
After all an IPv6 only site may not be indexed at all...
I haven't published any hostnames, so I don't have the entire picture... with that being said, here's what I have seen. The only big search engine I've seen at this point is google, here are the user agents I've seen to date: Googlebot-Image/1.0 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) ----------- Just FYI, Google bots all have an ipv6 suffix of 6006:1300:b075 (Google Bots, how 1337 of them!) Here are the addresses seen from google: 2001:4860:4801:1302:0:6006:1300:b075 2001:4860:4801:1303:0:6006:1300:b075 2001:4860:4801:1401:0:6006:1300:b075 2001:4860:4801:1402:0:6006:1300:b075 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 ----------- And here's a breakdown of which user agents are seen on which ip, as you can see the user-agent doesn't exactly match IP range. Googlebot-Image/1.0 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); 2001:4860:4801:1302:0:6006:1300:b075 2001:4860:4801:1303:0:6006:1300:b075 2001:4860:4801:1401:0:6006:1300:b075 2001:4860:4801:1402:0:6006:1300:b075 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 2001:4860:4801:1302:0:6006:1300:b075 2001:4860:4801:1401:0:6006:1300:b075 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 ----------- Again, I don't have the entire picture because I've not published my hostnames. The above information is just what I've seen on my selective testing. -wil
On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote:
On Mar 29, 2011, at 3:51 AM, Franck Martin wrote:
And here's a breakdown of which user agents are seen on which ip, as you can see the user-agent doesn't exactly match IP range.
Googlebot-Image/1.0
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html);
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
Interesting that there are Googlebot mobile devices! Perhaps user-experience testing of some kind? Googlers? Or IPv6 testing of the devices themselves? Although those user strings are indicative of not very recent, non-Android phones. Would be interesting to see the percentages of traffic by each user agent. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
On Mar 30, 2011, at 4:39 PM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote:
On Mar 29, 2011, at 3:51 AM, Franck Martin wrote:
And here's a breakdown of which user agents are seen on which ip, as you can see the user-agent doesn't exactly match IP range.
Googlebot-Image/1.0
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html);
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
Interesting that there are Googlebot mobile devices! Perhaps user-experience testing of some kind? Googlers? Or IPv6 testing of the devices themselves? Although those user strings are indicative of not very recent, non-Android phones.
Would be interesting to see the percentages of traffic by each user agent. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
I've got the logs still but I've torn down the VIP. I'll send hit count percentages tomorrow. -wil
On 3/31/11 11:55 , "Wil Schultz" <wschultz@bsdboy.com> wrote:
On Mar 30, 2011, at 4:39 PM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote:
On Mar 29, 2011, at 3:51 AM, Franck Martin wrote:
And here's a breakdown of which user agents are seen on which ip, as you can see the user-agent doesn't exactly match IP range.
Googlebot-Image/1.0
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html);
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
Interesting that there are Googlebot mobile devices! Perhaps user-experience testing of some kind? Googlers? Or IPv6 testing of the devices themselves? Although those user strings are indicative of not very recent, non-Android phones.
Would be interesting to see the percentages of traffic by each user agent. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
I've got the logs still but I've torn down the VIP. I'll send hit count percentages tomorrow.
Interesting: http://www.google.com/search?q=site%3Aipv6.cnn.com http://www.bing.com/search?q=site%3Aipv6.cnn.com
On Mar 30, 2011, at 4:55 PM, Wil Schultz wrote:
On Mar 30, 2011, at 4:39 PM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote:
On Mar 29, 2011, at 3:51 AM, Franck Martin wrote:
And here's a breakdown of which user agents are seen on which ip, as you can see the user-agent doesn't exactly match IP range.
Googlebot-Image/1.0
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html);
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
Interesting that there are Googlebot mobile devices! Perhaps user-experience testing of some kind? Googlers? Or IPv6 testing of the devices themselves? Although those user strings are indicative of not very recent, non-Android phones.
Would be interesting to see the percentages of traffic by each user agent. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them
I've got the logs still but I've torn down the VIP. I'll send hit count percentages tomorrow.
-wil
As promised, here are some percentages. By IP, seems there are three main IP addresses: 2001:4860:4801:1302:0:6006:1300:b075 --> 0.33% 2001:4860:4801:1303:0:6006:1300:b075 --> 0.17% 2001:4860:4801:1401:0:6006:1300:b075 --> 0.31% 2001:4860:4801:1402:0:6006:1300:b075 --> 0.17% 2001:4860:4801:1404:0:6006:1300:b075 --> 1.34% 2001:4860:4801:1405:0:6006:1300:b075 --> 48.1% 2001:4860:4801:1407:0:6006:1300:b075 --> 24.82% 2001:4860:4801:1408:0:6006:1300:b075 --> 24.70% By user-agent: Googlebot-Image/1.0 --> 0.003% Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); --> 7.26% DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 0.005% SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 92.73% And finally, percentages of IP to user-agent: Googlebot-Image/1.0 --> 0.003% of total 2001:4860:4801:1404:0:6006:1300:b075 30% 2001:4860:4801:1408:0:6006:1300:b075 30% 2001:4860:4801:1405:0:6006:1300:b075 40% Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); --> 7.26% of total 2001:4860:4801:1401:0:6006:1300:b075 1.21% 2001:4860:4801:1302:0:6006:1300:b075 1.42% 2001:4860:4801:1404:0:6006:1300:b075 2.11% 2001:4860:4801:1303:0:6006:1300:b075 2.28% 2001:4860:4801:1402:0:6006:1300:b075 2.39% 2001:4860:4801:1407:0:6006:1300:b075 9.02% 2001:4860:4801:1408:0:6006:1300:b075 37.15% 2001:4860:4801:1405:0:6006:1300:b075 44.40% DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 0.005% of total 2001:4860:4801:1407:0:6006:1300:b075 5.88% 2001:4860:4801:1405:0:6006:1300:b075 17.64% 2001:4860:4801:1408:0:6006:1300:b075 35.29% 2001:4860:4801:1404:0:6006:1300:b075 41.18% SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 92.73% of total 2001:4860:4801:1401:0:6006:1300:b075 0.24% 2001:4860:4801:1302:0:6006:1300:b075 0.25% 2001:4860:4801:1404:0:6006:1300:b075 1.27% 2001:4860:4801:1408:0:6006:1300:b075 23.79% 2001:4860:4801:1407:0:6006:1300:b075 26.06% 2001:4860:4801:1405:0:6006:1300:b075 48.39% -wil
On 29 Mar 2011, at 00:18, Wil Schultz wrote:
I'm attempting to find out information on the SEO implications of testing ipv6 out.
A couple of concerns that come to mind are:
1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only.
2) Not running ipv6 natively, or using 6to4. This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times.
3) ??? Any others that I haven't thought of ???
So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process.
Thoughts?
-wil
Twitter said: http://twitter.com/#!/look4ipv6/status/24639157611528193 Al least you would have a better page-rank in www.example.com than in ipv6.example.com with the same content. .as
participants (14)
-
Alexander Harrowell -
Arturo Servin -
Franck Martin -
Fred Baker -
Jimmy Hess -
Karl Auer -
Leo Bicknell -
Nathan Eisenberg -
Nicholas Meredith -
Owen DeLong -
Ryan Rawdon -
TR Shaw -
Wil Schultz -
William Pitcock