Monday, October 31, 2011<\/p>\n
\n A piece of content can often be reached via several URLs, not all of which may be on the same \n Webmasters can greatly influence our algorithms’ selections using one of the currently supported \n To be transparent about cross-domain URL selection decisions, we’re launching new Webmaster Tools There are many scenarios that can lead our algorithms to select URLs across domains.<\/p>\n \n In most cases, our algorithms select a URL based on signals that the webmaster implemented to \n However, we regularly see webmasters ask questions when our algorithms select a URL they did not \n In rare situations, our algorithms may select a URL from an external site that is hosting your \n And as always, if you need help in identifying the cause of an incorrect decision or how to fix
\n domain. A common example we’ve talked about over the years is having the same content available
\n on more than one URL, an issue known as
\n duplicate content<\/a>.
\n When we discover a group of pages with duplicate content, Google uses algorithms to select one
\n representative URL for that content. A group of pages may contain URLs from the same site or
\n from different sites. When the representative URL is selected from a group with different sites
\n the selection is called a cross-domain URL selection. To take a simple example, if the group of
\n URLs contains one URL from a.com and one URL from b.com and our algorithms select the URL from
\n b.com, the a.com URL may no longer be shown in our search results and may see a drop in
\n search-referred traffic.\n<\/p>\n
\n mechanisms to indicate the preferred URL, for example using
\n rel=\"canonical\"<\/code> elements<\/a>
\n oder
\n 301<\/code> redirects<\/a>.
\n In most cases, the decisions our algorithms make in this regard correctly reflect the webmaster’s
\n intent. However, in some rare cases we’ve also found many webmasters are confused as to why it
\n has happened and what they can do if they believe the selection is incorrect.\n<\/p>\n
\n messages that will attempt to notify webmasters when our algorithms select an external URL instead
\n of one from their website. The details about how these messages work are in our
\n Help Center article about the topic<\/a>,
\n and in this blog post we’ll discuss the different scenarios in which you may see a cross-domain
\n URL selection and what you can do to fix any selections you believe are incorrect.\n<\/p>\nCommon causes of cross-domain URL selection<\/h2>\n
\n influence the decision. For example, a webmaster following
\n our guidelines<\/a>
\n and
\n best practices<\/a>
\n for moving websites is effectively signalling that the URLs on their new website are the ones
\n they prefer for Google to select. If you’re moving your website and see these new messages in
\n Webmaster Tools, you can take that as confirmation that our algorithms have noticed.\n<\/p>\n
\n want selected. When your website is involved in a cross-domain selection, and you believe the
\n selection is incorrect (that is, not your intention), there are several strategies to improve the
\n situation. Here are some of the common causes of unexpected cross-domain URL selections that we’ve
\n seen, and how to fix them:\n<\/p>\n\n
\n webmasters use substantially the same content in the same language on multiple domains,
\n sometimes inadvertently and sometimes to geotarget the content. For example, it’s common to see
\n a webmaster set up the same English language website on both example.com and example.net, or a
\n German language website hosted on a.de, a.at, and a.ch.Depending on your website and your users,
\n you can use one of the currently-supported canonicalization techniques to signal to our
\n algorithms which URLs you wish selected. Please see the following articles about this topic:\n <\/li>\n\n
\n specifically
\n rel=\"canonical\"<\/code> elements<\/a>
\n and
\n 301<\/code> redirects<\/a>\n <\/li>\n
\n and more about
\n working with multi-regional websites<\/a>\n <\/li>\nrel=\"alternate\" hreflang=\"x\"<\/code><\/a>\n <\/li>\n<\/ul>\n
\n algorithms to make an incorrect decision. Examples of misconfiguration scenarios include:\n <\/li>\n\n
\n canonicalization techniques<\/a>
\n pointing to URLs on an external website can lead our algorithms to select the external URLs to
\n show in our search results. We’ve seen this happen with misconfigured content management
\n systems (CMS) or CMS plugins installed by the webmaster. To fix this kind of situation, find
\n how your website is incorrectly indicating the canonical URL preference (for example, through
\n incorrect usage of a rel=\"canonical\"<\/code> element or a 301<\/code> redirect) and
\n fix that.\n <\/li>\n
\n content from site a.com is returned for URLs on b.com. A similar case occurs when two
\n unrelated web servers return identical
\n soft 404<\/code> pages<\/a>
\n that we may fail to detect as error pages. In both situations we may assume the same content
\n is being returned from two different sites and our algorithms may incorrectly select the
\n a.com URL as the canonical of the b.com URL.You will need to investigate which part of your
\n website’s serving infrastructure is misconfigured. For example, your server may be returning
\n HTTP 200 (success)<\/code> status codes for error pages, or your server might be
\n confusing requests across different domains hosted on it. Once you find the root cause of
\n the issue, work with your server admins to correct the configuration.\n <\/li>\n<\/ol>\n
\n cause undesired canonicalization. For example, the malicious code might cause the website to
\n return an
\n HTTP 301<\/code> redirect<\/a>
\n or insert a cross-domain
\n rel=\"canonical\"<\/code> link<\/code> element<\/a>
\n into the HTML <head><\/code> or HTTP header, usually pointing to an external URL
\n hosting malicious content. In these cases our algorithms may select the malicious or spammy URL
\n instead of the URL on the compromised website.In this situation, please follow our
\n guidance on cleaning your site<\/a>
\n and submit a reconsideration request when done. To identify
\n cloaked<\/a>
\n attacks, you can use the
\n Fetch as Googlebot<\/a>
\n function in Webmaster Tools to see your page’s content as Googlebot sees it.\n <\/li>\n<\/ol>\n
\n content without your permission. If you believe that another site is duplicating your content in
\n violation of copyright law, you may contact the site’s host to request removal. In addition, you
\n can request that Google remove the infringing page from our search results by
\n filing a request under the Digital Millennium Copyright Act<\/a>.\n<\/p>\n
\n it, you can see our
\n Help Center article<\/a>
\n about this topic and ask in our
\n Webmaster Help Forum<\/a>.\n<\/p>\n