Sorry no one has posted on this issue you're facing. I also posted a similar thread and have received no responses.
I posted just several of the issues that occur b/c of the Collections duplication URL. But it seems like all I've read from Shopify is that the Collections canonicals are supposed to be the solution to the issue. It's absolutely not and I have some hard data to back up just how extensive of an issue this is.
The bad thing is that once, or if, you decide to remove/rename the longer Colleection product URLs that are duplicate, you then have to redirect all of that particular product URLs that occur under Collections/*. This could be 2, 3, 5+ URLs that have to be redirected to the shorter products/* URL.
Anyway, this is a real nightmare. I hope you've found a solution that works for you.
... View more
I'll have to say that I'm kind of shocked at the lack of responses to this thread. I've outlined a critical SEO issue and can back it up with hard data from backlinks, Analytics, etc. to show the Collections/* product URLs are not the way to go with Shopify, even with the canonicals.
I assume we'll need to find our own solution here since there seems to be a lack of support or concern.
... View more
We're facing some issue with Shopify's Collection URLs and maybe others have faced the same or can enlighten us on possible solutions.
For us, Shopify creates at least 3 versions of the product URL -- one being the product URL itself and the other 2 (or 3, 4+) are the Collections URLs the product has been tagged/assigned to. Example:
I could have plenty more URLs depending on the total amount of Collection types the product is assigned or belongs to.
Note: I realize that canonicals are in place for Collections/[some-cat/blue-widget] created URLs and that they point to the shortened product URL. But I don't feel the canonical method is all that great or foolproof. Let me explain...
Back in March 2017, Gary Illyes from Google said:
"rel-canonical is a hint, not a directive"
"[rel-canonical is] a very strong hint but may still be outweighed by other signals"
Over the past several days I've noticed a growing number of 404s occuring in our Google Search Console, many of which were some derivative of Collections/[some-cat/blue-widget]. The cause? We recently performed a Shopify site migration to another theme, where we also renamed some Collections pages, added other new ones, removed others, or we removed products altogether. The main issues I've noticed so far include:
Redirections issue: The Collections URLs create numerous variations of the same product in various long-form Collections/[some-cat/some-product] URLs that cannot all get efficiently redirected or removed, if needed.
External backlinks issue: Backlinks from external websites pointing to long-form Collections/[some-cat/blue-widget] URLs create confusion, especially when removing or renaming a product or Collection. In the bolded URLs examples above I could feasably have backlinks to all of those 3 Collections URL variations and to my product URL. When I remove or rename my Shopify product, those external backlinks get broken, subverted, or do not pass value unless I capture and redirect all Collections/[some-cat/blue-widget] URL variations to another location. Even if done, it's not optimal.
Internal linking issues: Let's say, over time, we link from anywhere within the website to any of the multiple Collections/[some-cat/blue-widget] URLs variations, we then have to update them all manually which creates an internal link-correcting headache -- as any of the multiple linked Collections/[some-cat/blue-widget] URLs now needs to be found, updated, or removed.
Rel-canonical isn't foolproof: The reason above from Google and I've logged some instances where canonical URLs cause indexation issues.
These are just the few issues off the top of my head. I'm sure there are others.
Are Collections pages that include the product "tag" really needed for "front-facing" URLs that can easily get indexed?
Why not simply use a faceted search method where Collections tagged/assigned product URLs do not get indexed at all, either with META Noindex or similar.
Is it as simple as simply changing the internally created Collections/[some-cat/blue-widget] URL to point directly to the actual product URL and fore go all of the multitudes of Collections/[some-cat/blue-widget] URls that get created.
Am I missing something, maybe an app, that can fix this issue? I'm fine with modifying theme code.
Thanks in advance!
... View more
I've read other related threads but nothing specific to the issue we are having within our theme. We have the Turbo theme installed and when you visit any /collections/ URI we have the standard sort by Featured, Best Selling, Price: Low to High, etc. The canonicals on these URLs are all correct, pointing back to the main /collections/ URL. Ex:
For the above URL the canonical is:
However, from the theme we have another dropdown/sorting option beside the standard one above that lists all of the tags the collection has within it, such as:
For all of these sorting URIs the canonical is that actual URL, so for one example above, a canonical would be:
<link rel="canonical" href="sitename.com/collections/blue-widgets/nylon" />
This causes issues primarily because:
These URIs hardly change any of the content on the page when selecting from the dropdown
There is a unique snippet of copy at the top of the main /collections/ URI which gets duplicated across all sorting URLs.
Overall, this causes a saturation of URIs from sorting that do not need to be there or indexed, which can cause Google to confuse the main URI with other sorting URIs.
My question is initially how would we go about adding a META noindex,nofollow on these tag sorting URIs? That would be a first step since we do want want them indexed at all.
Thanks in advance for any advise!
... View more
We are importing all of our reviews from Yotpo to Shopify Reviews and having a similar issue with the product_handle field (there may be more but the import fails at that point when trying to import a sample of 9-10 reviews into Shopify Reviews. The exact error is:
9 reviews failed to import.
Make sure your CSV file matches the format of this sample CSV template.
Line 1 - Error: Could not find product "".
Line 2 - Error: Could not find product "".
Line 3 - Error: Could not find product "".
Line 4 - Error: Could not find product "".
Line 5 - Error: Could not find product "".
Line 6 - Error: Could not find product "".
Line 7 - Error: Could not find product "".
Line 8 - Error: Could not find product "".
Line 9 - Error: Could not find product "".
The product_handle is formatted exactly as needed and I've checked multiple times that it is just the product name with dashes, such as "product-widget-blue-123" with no other characters within the product_handle field. And the product_handle column matches exactly to the Search Engine Listing Preview for the product which also matches the live product URL.
To note, I've alsoready formatted the entire spreadsheet to match exactly what Shopify illustrates on the example csv file linked from this URL: https://help.shopify.com/manual/apps/apps-by-shopify/product-reviews/import-export-reviews
Any advise on how to solve this?
Thanks in advance.
... View more
I added the exclusion in Analytics today for checkout.shopify.com so will see if it gets excluded. However, I wonder what the impact of doing this is considering this recent post from Shopify?
Can someone please explain any impact on the referral source URL exclusion or if it's even a nessesary step now?
FYI, our issue was that we saw a drop in transactions recently in August. So, while examining Analytics I noticed the biggest and almost only noticeable drop in transactions was for the checkout.shopify.com referrer. It was quite a large drop in transactions and the drop started on July 31st, when the Shopify announcement from the URL above was posted.
However, I still see plently of checkout.shopify.com referrals still being logged in Analytics under the referral traffic/transactions segments. It really causes quite a lot of confusion for reporting.
Thanks in advance for any reply,
... View more