301 to canonical

[ThomasHarvey]

I'm doing some work on a website, they have a very popular product search where you enter a specific part code (6 digits) and it takes you to the product. So for example

Search: 123456

Page redirected to domain.com/product/123456

With a canonical of domain.com/product/this-is-the-product-title

Would it be beneficial to redirect from /product/123456 to /product/this-is-the-product-title

Google seems to be indexing both versions. For some of these products a reasonable amount of links are built.

[ATP]

No prob, let me know how things turn out (professional curiosity)

Like yourself my main project is dated in areas and a workaround is more cost effective than a rebuild, always interesting to see how people get around issues.

GL!

[ThomasHarvey]

The 123456 url is only used in once place (or on banners in various places) any time this is in a category it is using the canonical url, once stock is loaded it only takes an hour for this to pull through. So the mass of links to this is the canonical url (however it usually has some form of tracking attached to it)

It's a very large and dated website, so we've got to try and get workarounds until development get round to sorting this kind of thing.

The mass of urls are showing as the canonicals, we've just got a few (hundreds) that aren't playing ball.

Really appreciate your help.

[ATP]

Sorry just want to check i understand this,

The product is originally created as domain.com/123456.html and is utilised at this url for a period of time.

You get the canonical url of domain.com/product-title.html later the day the product goes live.

You then create the canonical url and insert the canonical tags at a later time?

If all these are correct then it could explain why your having issues.

Google will crawl and index 123456.html pretty quickly, if this is the base url the product is created at you will most likely find that the links off your category pages use this url and any initial links use this url, this is bad for what you are trying to achieve.

When you then change to the canonical you create a situation where you have 2 copies of the page. 1 with loads of links pointing to it, especially internally, and another with no links. But your trying to tell google that the one with no links is the main version. I would bet this is why it is indexing both.

Even if  you change all of the links and add the correct canonical tag it can take time for google to change, even then it can choose to ignore it (it can be frustrating).

Ideally you want to create the canonical URL first or at the same time as the 123456.html url and instantly add all the canonical tags, this way that all default links that a created internally point to it, and the first time it gets crawled it is already pointing to the canonical url.

In your current timetable, I would say redirects would be more suitable than canonical for both the order you release them and the general use.

About your plan,

If your timings are correct, then sure, that doesn't sound like too much of a time commitment and i think the benefit would be worth it. What I would expect to see within the month is the de-indexing of all the 123456.html versions

**Just remember, check all your canonicals actually need a 301 before doing them on bulk. You may have places on your site that you have canonicals because both versions of a page are needed, don't redirect these in your haste

[ThomasHarvey]

Thank you for your response ATP.

I've done numerous checks and we're following all of the best practices, the only thing I can think of is that this url is the first that's seen (we only release stock on a time due to the nature of the business, we then only get the canonical on that day) so any scheduled work uses the part code, which we then at a later date manually change to the canonical url.

We are always trying to get these links changed to the correct version, however as we have a large site (570k+ pages) crawling for these is always an issue.

We can quite comfortably get a list of the canonicals thanks to screaming frog and being able to export our product codes (which are these six digit numbers). So you think it would be a viable solution to bulk upload our whole product catalog and on the /product/123456 urls redirecting to the /product/product-title and we should see a benefit from this? (Would take about an hours work initially then just adding current urls being 5 minutes a day)

[ATP]

Hi Thomas,

Firstly, the canonical does the same job as the 301 (for all intensive purposes) without the physical redirect. So in theory only the canonical should be being indexed and all the link juice should be being passed.

The fact that both are indexed suggests that the canonical isn't behaving as intended

• I would check for common cannonical errors to begin with
• If this isn't the case, i would suggest that the 123456 version has too many links maybe internally and externally and that google is ignoring the canonical because it has too much authority.

An issue with using canonical like this is that people who use the search are not sent to the main canonical url. This gives people the opportunity to copy and link to the wrong version of the url, which isn't a practice you want.

A possible solution would be to find all backlinks and get them changed to the main canonical version internally and externally, this could be a lot of work.

The 301 redirect is better in my opinion because it achieves the following

• Customer always see a useful URL and the main canonical URL
• Because of this, links will only likely be built the the url you want
• Google will de-index the 123456 version because it becomes inaccessible

However, unless you can automate this procedure, it can take too much time to create all those 301's for every product.

Personally i use the following guidlines as i find it keeps things clean and tidy
301 any url that isn't domain.com/main-product-url.html
keep the canonical on domain.com/main-product-url.html  so that any version created from filtering or unexpected cms pages dont create duplicate content.