Fixing Shopify's Duplicate Content Problem

Shopify duplicate content is one of the most written-about SEO topics in the ecosystem and one of the most consistently overstated. A large share of the advice describes a problem the platform solved years ago, and sells a fix for it.

The genuine problems are different, less discussed, and more expensive. They are also diagnosable in about ten minutes.

What Shopify already handles

Start here, because it eliminates the most commonly sold fix.

A product on Shopify can be reached at /products/product-handle and also at /collections/collection-handle/products/product-handle. Same product, different URL.

Shopify sets a canonical tag on the collection-scoped version pointing at the bare product URL. That tells Google which version to index, and it works.

Any article or app offering to "fix Shopify's duplicate product URLs by adding canonical tags" is offering you something you have. This claim is common, and it works because merchants do not think to view the page source and check for themselves. It takes about thirty seconds to confirm.

Where the real cost is

Four problems the platform does not solve for you.

Filtered and sorted collection URLs. ?sort_by=, filter parameters, tag-filtered paths. On a large catalogue these multiply extremely fast, and each is a near-identical page containing a subset of the same products. This is by far the largest contributor on most stores.

Pagination. Page four of a collection is rarely a useful landing page and is frequently crawled and indexed as though it might be.

Internal links that contradict the canonical. If your theme and apps link to collection-scoped product URLs while canonicals point elsewhere, every internal link points at a page you have told Google to ignore. The equity still resolves, but you have made reconciliation work happen on every crawl.

Thin auto-generated collections. Tag-based collections multiply quietly, and each near-empty one is a crawlable page competing for attention it cannot hold.

Diagnose it before fixing anything

Ten minutes in Search Console tells you whether any of this applies to your store, and at what scale.

Open the page indexing report and read two buckets:

"Duplicate, Google chose a different canonical." Google found these, decided they were duplicates, and picked something else. On Shopify stores these are usually filtered collection variants.

"Crawled — currently not indexed." Google fetched these and decided not to index them. Some of this is normal. Large volumes of collection variants here means significant crawl budget is going nowhere.

The numbers matter more than their presence. A few dozen is background noise. Several thousand on a store with four hundred products means most of your crawl is being spent on pages that will never rank, and the pages you care about are being visited less often as a result.

Fixing the filtered URLs

The general aim is that these URLs remain crawlable but not indexed, so products reachable only through a filter stay discoverable while the near-duplicate pages do not compete.

Blocking them in robots.txt entirely is the instinct and usually the wrong move — it prevents crawling, which can make filtered-only products undiscoverable, and it does not reliably remove already-indexed URLs.

How to achieve crawlable-not-indexed depends on your theme and filter implementation, which is why generic instructions here would be unreliable. What is reliable is the sequence: confirm the scale in Search Console, identify which parameters are generating the volume, implement the fix your theme supports, and re-check the report in several weeks.

Internal links are the quiet one

The least discussed and among the easiest to fix.

If your navigation, collection grids and content link to /collections/x/products/y while canonicals point at /products/y, every internal link is aimed at a page you have declared non-canonical.

This is not catastrophic. Google resolves it. But you are asking it to do reconciliation work on every crawl, and consistency costs nothing once someone decides to enforce it.

Crawl your own site, look at where internal links point, and make them consistent with your canonicals. On most stores this is a theme change in one or two places, and it is the sort of fix that stays fixed — unlike content work, nothing erodes it over time except an app that starts generating its own links.

Consolidate thin collections while you are here

Related, and usually the highest-return action available.

Auto-generated collections built on tags proliferate silently. A tagging scheme that made sense for merchandising produces a collection per tag, most containing a handful of products, all crawlable.

Export the full list, sort by product count, and act:

Two or three products — merge, noindex or delete and redirect.

Created for a campaign that has ended — delete it and redirect to the most relevant live collection.

Nobody can explain why it exists — investigate before removing it, since something elsewhere may still reference it.

Check traffic before deleting anything, and check whether a collection is referenced by navigation, an app or a product feed. Removing one that a feed depends on causes problems well outside search, and shopping campaigns are the usual casualty because nobody connects the two events.

Why crawl budget matters at all

Merchants reasonably ask whether this is a real problem or an SEO abstraction, since Google has substantial capacity and a store with four hundred products is not large.

It is real, and the mechanism is worth understanding rather than taking on faith.

Search engines allocate a finite amount of crawling to each site, informed by how important and how fresh they judge it to be. If a large share of that allocation goes to filtered collection variants, two things follow:

Your important pages are visited less often. A new product, a price change, or an updated collection description takes longer to be noticed. On a store with frequently changing inventory, that lag has direct commercial consequences — products showing as available when they are not, or new lines taking weeks to appear.

Your site looks lower-quality in aggregate. A crawler encountering thousands of near-identical thin pages is forming an impression of the site as a whole, not just of those pages.

The second effect is harder to demonstrate and is the reason experienced practitioners treat crawl waste as worth fixing even on smaller sites. You are not only losing efficiency; you are describing your site badly.

There is a practical threshold worth applying. If your indexed page count is broadly in line with your actual products, collections and content, this is not your problem and effort is better spent elsewhere. If it is several times larger, something is generating pages you did not intend, and finding out what is the highest-value hour available.

What not to worry about

Two things that consume attention disproportionately.

Manufacturer product descriptions shared with other retailers. This makes ranking harder because nothing distinguishes your page, but it is not a duplicate content problem in the technical sense and no canonical tag fixes it. The answer is original detail on the products that matter commercially.

Your own products appearing on marketplaces. Normal, expected, and not something Google penalises you for. If a marketplace listing outranks your own product page, that is a signal about relative authority rather than a duplication problem, and the response is to strengthen your page rather than to remove the listing.

Tag and vendor archive pages, unless they exist in real volume. A handful is harmless. Several hundred, most containing one product, is the same thin-page problem as auto-generated collections and should be treated the same way.

HTTP versus HTTPS, and www versus non-www. Shopify handles these, and articles that raise them are usually recycled from advice written for self-hosted platforms.

For the collection-level structural work this connects to, see SEO and AI search. Product page specifics are covered in the same archive.