Here is a recap of what happened in the search forums today, through the eyes of the Search Engine Roundtable and other search forums on the web.
Here is a recap of what happened in the search forums today, through the eyes of the Search Engine Roundtable and other search forums on the web.
The canonical tag was jointly introduced by Google, Yahoo and Microsoft earlier this year. Google hinted they would soon support cross domain canonical tag and they officially announced it last night. What is a canonical tag? It basically allows you to communicate to Google that a page has moved to a new location, without you using a server side 301 redirect.
Why is this important? A few reasons:
(1) Some hosts don't allow webmasters to deploy 301 redirects
(2) Some site owners aren't technical enough to implement a 301 redirect
(3) In some cases, webmasters do not want to redirect users but rather only search engines (i.e. pagination, weird filtering, tracking parameters added to URLs, etc).
Initially this was launched to work within a domain only. So you could only say that domainA.com/pageA has moved to domainA.com/pageB. Now you are able to do this across domains, so you can say, domainA.com/pageA has moved to domainB.com/pageA or even domainA.com moved to domainB.com.
Google made this cute graphic to explain it:
There is a lot of technical detail on how to implement this tag over here but in short, you just add this tag to the head section of your HTML of the page you want to redirect. Make sure the URL you specify is the URL you want GoogleBot to be redirected to:
<link rel="canonical" href="http://www.example.com/true-url.html" />
JohnMu, who wrote the Google blog post also put some FAQs, and note the "hint" he keeps referring to. I assume the "hint" will become less of a hint and more of an "instruction" as time goes on.
Q: Do the pages have to be identical? A: No, but they should be similar. Slight differences are fine.
Q: For technical reasons I can't include a 1:1 mapping for the URLs on my sites. Can I just point the rel="canonical" at the homepage of my preferred site?
A: No; this could result in problems. A mapping from old URL to new URL for each URL on the old site is the best way to use rel="canonical".Q: I'm offering my content / product descriptions for syndication. Do my publishers need to use rel="canonical"?
A: We leave this up to you and your publishers. If the content is similar enough, it might make sense to use rel="canonical", if both parties agree.Q: My server can't do a 301 (permanent) redirect. Can I use rel="canonical" to move my site?
A: If it's at all possible, you should work with your webhost or web server to do a 301 redirect. Keep in mind that we treat rel="canonical" as a hint, and other search engines may handle it differently. But if a 301 redirect is impossible for some reason, then a rel="canonical" may work for you. For more information, see our guidelines on moving your site.Q: Should I use a noindex robots meta tag on pages with a rel="canonical" link element?
A: No, since those pages would not be equivalent with regards to indexing - one would be allowed while the other would be blocked. Additionally, it's important that these pages are not disallowed from crawling through a robots.txt file, otherwise search engine crawlers will not be able to discover the rel="canonical" link element.
Forum discussion at Google Webmaster Help.
Here is one more oddity to add to Microsoft Bing's web crawler, MSNBot. Why on earth are people reporting that MSNBot is crawling the same page twice, once for the compressed version and then once again for the uncompressed version? Technically, it should probably only crawl once and it should opt for the compressed, gzip version - don't you think?
We have two threads complaining about this, one oldish one at WebmasterWorld and another at Bing Forums. Let me quote the Bing thread:
I've notice that bing is crawling each page of my website twice, first making an HTTP 1.1 request and getting a compressed response then immediately issuing an HTTP 1.0 request to receive the same page without gzip compression
The following lines from my log show the issue (there are thousands more similar occurrences):
65.55.207.74 - - [13/Dec/2009:14:58:42 +0000] "GET /specimen/235698/ HTTP/1.1" 200 1742 "-" "msnbot/2.0b (+http://search.msn.com/msnbot.htm)"
65.55.207.74 - - [13/Dec/2009:14:59:06 +0000] "GET /specimen/235698/ HTTP/1.0" 200 4259 "-" "msnbot/2.0b (+http://search.msn.com/msnbot.htm)"
65.55.106.209 - - [13/Dec/2009:15:03:08 +0000] "GET /specimen/250262/ HTTP/1.1" 200 1733 "-" "msnbot/2.0b (+http://search.msn.com/msnbot.htm)"
65.55.106.209 - - [13/Dec/2009:15:03:14 +0000] "GET /specimen/250262/ HTTP/1.0" 200 4164 "-" "msnbot/2.0b (+http://search.msn.com/msnbot.htm)"
This seems a waste of bandwidth and completely defeats the point of supporting http compression.
Indeed a waste of bandwidth and yes, it defeats the point of supporting HTTP compression.
A Bing representative, Brett Yount said:
could you please mail this information to bwmc@microsoft.com and I will get our crawling team to check it out?
But we have no confirmation from Bing on why this issue is occurring or when it will be fixed. Like I said, just one more oddity to add to MSNBot's crawl behavior.
Forum discussion at WebmasterWorld and Bing Forums.
Over a month ago, there were reports in two Google Maps Help threads that the local pack for searches in the flavor of [web design], [web development] and so on, were not triggering local pack results. We covered this about three weeks ago with our story named Google Bug Removes Web Designers in Local Pack and it is still not fixed.
Back then, a Googler said the reason for the bug had to do with a one box local result bug being fixed to show a local 7 pack. That bug was fixed, but it triggered a new bug with queries such as [web design], [web development] and so on. Even if you add a local qualifier to such queries, i.e. [web design new york] or [web design 10010] the local pack is not triggered at all.
Google never offered an ETA for when this would be fixed, but it has been a month since a Googler responded to the issue and we have yet to get an update, while the bug lingers on. Google, when will this bug be resolved?
Forum discussion at Google Maps Help.
A WebmasterWorld thread reports that Yahoo Search Marketing is down for some. When some advertisers are trying to use Yahoo's pay per click ad system, they get an error.
The error reads:
We are currently experiencing a technical issue that is causing the ads of some advertisers to not be displayed properly to users. This may cause your account to receive a lower volume of clicks than normal. We are aware of this issue, and are working diligently to resolve it as soon as possible. We apologize for any inconvenience this may cause you.
So far, we have two confirmed reports of this bug in the WebmasterWorld thread.
I am not sure how widespread the issue is or if it is resolved yet.
Forum discussion at WebmasterWorld.
Yahoo updated the thread, saying:
I can confirm that this issue was resolved at approximately 10:30 a.m. Pacific Time on December 15, and ads should be displaying normally since then. Sorry for any inconvenience this may have caused.