DavidG-MV
January 7th, 2009, 01:42 PM
We just published a new white paper titled: Address Duplicate Content and Canonicalization to Alleviate SEO Roadblock.
Topics Include:
Fixing www vs. non-www page-serving.
Resolving duplicate content issues through redirects and robots access restrictions.
Creating rewrite rules.
Understanding parts of a URL an handling URL problems like case sensitivity, query strings and URL path issues
Avoiding canonicalization problems for future websites.
PM or email me (dgreen@morevisibility.com) for a copy....or click here. (http://www.morevisibility.com/dbform.php?id=384)
Here is an excerpt:
As another example, let’s say you have a store on your site that is accessed from http://www.example.com/store. If another site links directly to http://www.example.com/store/default.aspx, but others link to your store from within your site go to http://www.example.com/store, the search engines could index both URLs and count them as duplicate content. (This is an example of what is sometimes called a “file name canonicalization issue”.)
Stated simply, the issue of un-canonicals arises when the search engine in question indexes more than one copy of the same page from multiple URLs on your site. Remember that Google and other engines consider the content in all of your subdomains as part of your site. Methods used to fix the issue and attempt to remove the duplicate URLs from the index include two general concepts:
1. Making the search engine believe that the duplicate URLs have disappeared from the website, which will cause the engine to remove the URL from its index.
2. Telling the search engine to replace the duplicate URLs with the canonical URL in the engine’s database.
Generally, some methods and tools that use the first concept above, including using a robots.txt file or physically deleting the page, may work in many situations, but have their limits. Also, depending on your site’s architecture, they may introduce several inefficiencies as well. Methods and tools that use the second concept can often be applied and changed en masse and are usually very flexible and forgiving, making that option ideal for large sites and for long-term use. However, the second method can be trickier as it requires you have full access to your site (including to your host, which is often an issue if you are on a shared server).
Topics Include:
Fixing www vs. non-www page-serving.
Resolving duplicate content issues through redirects and robots access restrictions.
Creating rewrite rules.
Understanding parts of a URL an handling URL problems like case sensitivity, query strings and URL path issues
Avoiding canonicalization problems for future websites.
PM or email me (dgreen@morevisibility.com) for a copy....or click here. (http://www.morevisibility.com/dbform.php?id=384)
Here is an excerpt:
As another example, let’s say you have a store on your site that is accessed from http://www.example.com/store. If another site links directly to http://www.example.com/store/default.aspx, but others link to your store from within your site go to http://www.example.com/store, the search engines could index both URLs and count them as duplicate content. (This is an example of what is sometimes called a “file name canonicalization issue”.)
Stated simply, the issue of un-canonicals arises when the search engine in question indexes more than one copy of the same page from multiple URLs on your site. Remember that Google and other engines consider the content in all of your subdomains as part of your site. Methods used to fix the issue and attempt to remove the duplicate URLs from the index include two general concepts:
1. Making the search engine believe that the duplicate URLs have disappeared from the website, which will cause the engine to remove the URL from its index.
2. Telling the search engine to replace the duplicate URLs with the canonical URL in the engine’s database.
Generally, some methods and tools that use the first concept above, including using a robots.txt file or physically deleting the page, may work in many situations, but have their limits. Also, depending on your site’s architecture, they may introduce several inefficiencies as well. Methods and tools that use the second concept can often be applied and changed en masse and are usually very flexible and forgiving, making that option ideal for large sites and for long-term use. However, the second method can be trickier as it requires you have full access to your site (including to your host, which is often an issue if you are on a shared server).
