Why is rel="canonical" pointing at a URL with parameters bad?

[Solid_Gold]

Context

Our website has a large number of crawl issues stemming from duplicate page content (source: Moz).

According to an SEO firm which recently audited our website, some amount of these crawl issues are due to URL parameter usage. They have recommended that we "make sure every page has a Rel Canonical tag that points to the non-parameter version of that URL…parameters should never appear in Canonical tags."

Here's an example URL where we have parameters in our canonical tag...

http://www.chasing-fireflies.com/costumes-dress-up/womens-costumes/

rel="canonical" href="http://www.chasing-fireflies.com/costumes-dress-up/womens-costumes/?pageSize=0&pageSizeBottom=0" />

Our website runs on IBM WebSphere v 7.

Questions

1. Why it is important that the rel canonical tag points to a non-parameter URL?
2. What is the extent of the negative impact from having rel canonicals pointing to URLs including parameters?
3. Any advice for correcting this?

Thanks for any help!

[Solid_Gold]

Thanks for the response, Eric.

My research suggested the same plan of attack: 1) fixing the canonical tags and 2) Google Search Console URL Parameters. It's helpful to get your confirmation.

My best guess is that the parameters you've cited above are not needed for every URL. I agree that this looks like something WebSphere Commerce probably controls. I'm a few organizational layers removed from whoever set this up for us. I'll try to track down where we can control that.

[Solid_Gold]

Thanks Peter!

[Eric_Rohrback]

Peter has a great answer with some good resources referenced, and i'll try to add on a little bit:

1. Why it is important that the rel canonical tag points to a non-parameter URL?

It's important to use clean URLs so search engines can understand the site structure (like Peter mentioned), which will help reduce the potential for index bloat and ranking issues. The more pages out there containing the same content (ie duplicate content), the harder it will be for search engines to determine which is the best page to show in search results. While there is no "duplicate content penalty" there could be a self inflicted wound by providing too many similar options. The canonical tag is supposed to be a level of control for you to tell Google which page is the most appropriate version. In this case it should be the clean URL since that will be where you want people to start. Users can customize from there using faceted navigation or custom options.

2. What is the extent of the negative impact from having rel canonicals pointing to URLs including parameters?

Basically duplicate content and indexing issues. Both of those things you really want to avoid when running an eComm shop since that will make your pages compete with each other for ranking. That could cost ranking, visits, and revenue if implemented wrong.

3. Any advice for correcting this?

Fix the canonical tags on the site would be your first step. Next you would want to exclude those parameters in the parameter handling section of Google Search Console. That will help by telling Google to ignore URLs with the elements you add in that section. It's another step to getting clean URLs showing up in search results.

I tried getting to http://www.chasing-fireflies.com/costumes-dress-up/mens-costumes/ and realize the parameters are showing up by default like: http://www.chasing-fireflies.com/costumes-dress-up/mens-costumes/#w=*&af=cat2:costumedressup_menscostumes%20cat1:costumedressup%20pagetype:products

Are the parameters needed for every URL? Seems like this is a websphere commerce setup kind of thing.

[Mobilio]

Clean (w/o parameters) canonical URL helps Google to understand better your url structure and avoid several mistakes:
https://googlewebmastercentral.blogspot.bg/2013/04/5-common-mistakes-with-relcanonical.html <- mistake N:1
http://www.hmtweb.com/marketing-blog/dangerous-rel-canonical-problems/  <- mistake N:4

So - your company that giving this advise is CORRECT! You should provide naked URLs everywhere when it's possible.