Should I use rel=canonical on similar product pages.

[PremioOscar]

Hello there,

I manage an e-commerce site and because we have similar products and issues with duplicate content we have implemented product groups pages with a drop-down menu' listing the different options for a particular product and then we have used the rel="canonical" with the different product pages. In this way we have solved this issue and it works very well.

If you do implement it, make sure every passage is done correctly otherwise, as Matt Cutts says, you will have an headache trying to sort it out.

Hope it helps

[PremioOscar]

Also I forgot to mention that in this way you also don't have to worry about creating tons of different product descriptions because you will put one description for, let's say, 6 different products.

the way we built it, allow us to have just product group pages are reachable; the products pages are indexed and crawled and they have to be there otherwise the whole system wouldn't work, but no optimization is done on them and customers can't see it.

[Dr-Pete]

This can get tricky when you dive into the details, but I general agree with Takeshi and EGOL - consolidate or canonicalize. If the products are different brands/versions of a similar item, it's a bit trickier, but these variations do have a way of spinning out of control. In 2013, I think the down side of your index running wild is a lot higher than the up side of ranking for a couple more long-tail terms. It does depend a lot on your traffic, business model, etc., though. I'm not sure any of us can adequately advise you in the scope of a Q&A.

[mark_baird]

It seems to me that for most ecommerce sites (myself included) that canonical is not the answer. If you have to many near identical products on your site it may be better to re evaluate what you have stocking and if you must stock them then the way forward is to make one page that properly explains them and allows purchase rather than many.

The only uses I can see for canonical is to consolidate old blogs and articles on similar topics. Using it to tidy an ecommerce site seems to be a misuse of the tool.

[Dr-Pete]

So, here's the problem - if you follow the official uses of our options, then there is no answer. You can't have thin content or Google will slap you with Panda (or, at the very least, devalue your rankings, you can't use rel=canonical on pages that aren't 100% duplicates, and you're not supposed to (according to Google) just NOINDEX content. The official advice is: "Let us sort it out, but if we don't sort it out, we'll smack you down."

I don't mean that to be critical of your comment, but I'm very frustrated with the official party line from Google. Practically speaking, I've found index control to be extremely effective even before Panda, and critical for big sites post-Panda. Sometimes, that means embracing imperfect solutions. The right tool for any situation can be complex (and it may be a combination of tools), but rel=canonical is powerful and often effective, in my experience.

[Mark-Tillison]

Hey Pete

Can you explain, "you can't use rel=canonical on pages that aren't 100% duplicates" a little further please?

Do you mean that only duplicate pages should be canonicalised? Identical pages in two different sub-directories is fine, but two similar pages is not?

[Dr-Pete]

To clarify, that's the official stance - rel=canonical should only be used on true duplicates (basically, URL variants of the same page). In practice, rel=canonical works perfectly well on near-duplicates, and sometimes even on wildly different pages, but the more different you get, the more caution you should exercise. If the pages are wildly different, it's likely there are more appropriate solutions.

[Mark-Tillison]

Thanks Pete

So, for a more specific example, if an eCommerce store has an "email this product" page for each product (Magento seems to love doing this and creates a duplicate of the same email page for every product), would you recommend a canonical link for each of those pages to the main Contact page or canonically linking each page to each related product page?

From setup, I'd consider NoIndex on all of those pages anyway, but it's a bit late for that once a site has been live for years.

The email pages are obviously related to the product page, but the content there isn't anywhere near identical.

Or maybe there's a "more appropriate solution" that you alluded to?

[Dr-Pete]

I would Meta Noindex an "email this page" template. It has no value for SERPs, it's generally at the end of a path, and no one is going to link to it. Just keep it out of the index altogether.

[Mark-Tillison]

Good. Same page

I was looking in to rel=contents and those variations before, but I can't quite decide whether this is worth the effort or not.

e.g. There's a huge list of resources on a single page, segmented in to categories. The page is HUGE and takes ages to load, so I've been creating new pages for each segment and optimising those pages independently, but there is some common content with the primary page.

V1: Horror Novels page has a section for each author, each section lists all novels by that author.

V2: Each Author has a page which lists novels by that author, but links back to the Horror Novels page which is essentially an index of the Author pages. Would you also

Would you use rel=contents, rel=prev/next or a different approach in this case? From what I've read so far, there doesn't seem any "SEO value" in linking that way.

I guess we're trying to improve the UX through faster load times and segmenting the information in smaller chunks, but also presenting a number of pages to Google as a body of content rather than a single page without causing issues with duplicate or similar content - we just need to make sure that we're optimising it in the right way, of course.

[Dr-Pete]

I haven't heard any SEO recommendations or benefits regarding rel="contents". Rel=prev/next has mixed results, but I'd generally only use it for its specific use case of paginated content.

I guess you could treat V2 as "pages" within V1. If you did that, what you'd need to do is treat the main page as a "View All" page and link to it from each author page. I'm not sure if that's the best approach, but it's more or less Google-approved.

If the site has decent authority and we're only talking 100s of pages, I might let them all live in the index and see what happens. Let Google sort it out, and then decide if you're ok with the outcome. If the site is low authority and/or we're talking 1000s of pages, I might be more cautious.

It's hard to speak in generalities - it depends a lot on the quality of the site and nature of the pages, including how much that content is available/duplicated across the web. One problem here is that author pages with lists of books probably exist on many sites, so you have to differentiate yourself.

[Mark-Tillison]

Thank you Sir. I think we reached the same conclusion.

By the way, the it was a just a simple example of the page hierarchy - we're not doing Horror Books

[BlairKuhnen]

Dr. Pete,

I have a internal debate going and I was hoping you might be a tie breaker on rel=canonical vs noindex given these paginated pages and might be a good use case for others:

https://www.newhomesource.com/communityresults/market-269/citynamefilter-cedar-park

https://www.newhomesource.com/communityresults/market-269/citynamefilter-cedar-park/page-2

The individual list items are unique, but clearly want to rank for essentially the exact same terms.  Page titles, metas, copy about cit is the same.  Just the list elements are different, but not a 12 pack of pens, 24 pack etc.  Is this tricky or clear?

[Dr-Pete]

There's no perfect solution, but Google's advice is to use rel=prev/next. This looks like pretty classic pagination. Rel-canonical is a stronger signal, but it's generally going to keep pages 2+ from ranking.