Most Shopify duplicate content is not something you created. Your store generates it on its own, out of tags, storefront filters, and pagination, and each of those URLs is a real page that Google can crawl and index.
The popular fixes get one big thing wrong, and I will show you the live evidence for that. Not every duplicate is worth killing, and one of them is worth promoting.
Wichtigste Erkenntnisse
- Shopify creates duplicate collection URLs automatically from product tags, storefront filters, and pagination, on top of the well-known
/collections/x/products/yproduct duplicates. - Shopify’s default robots.txt blocks
sort_by, tag combinations (the+patterns), and two filters used together. It does not block a single tag URL, a single filter, or?page=2. - A single tag URL like
/collections/all/merchreturns HTTP 200, renders a full product grid, and carries a self-referencing canonical, so it is a separate indexable page. - Paginated pages also canonical to themselves, and Google’s own documentation says not to canonical page 2 back to page 1.
- Some tag URLs have real search demand and deserve promotion into proper collections, rather than a blanket noindex.
- Every store’s robots.txt is different, because it can be edited, so check yours at
yourstore.com/robots.txtbefore you trust any list, including mine.
Where Shopify’s duplicate collection URLs actually come from
Shopify creates duplicate collection URLs automatically, from three sources: every product tag on a collection gets its own URL, every storefront filter adds another, and each of those paginates. The result is one collection that quietly becomes dozens of near-identical pages sharing the same heading and intro copy.
Take a “Shoes” collection with 12 tags and a color filter. The tag URLs alone give you /collections/shoes/blue, /collections/shoes/running, and ten more, none of which you sat down and created.
Add the filter and you get /collections/shoes?filter.v.option.color=blue. Then each of those lists paginates into ?page=2, ?page=3, and so on.
Nobody in your team made those pages, so nobody in your team is watching them. That is exactly why the crawl bloat creeps up on stores that are otherwise well run.
How one collection turns into dozens of URLs
- You create one collection: /collections/shoes
- Every product tag adds a URL: /collections/shoes/blue
- Every storefront filter adds a URL: ?filter.v.option.color=blue
- Each of those paginates: ?page=2, ?page=3
- Each one is a crawlable page with the same heading and intro
Here is a small irony that makes this harder to look up than it should be. Search the phrase and Google’s AI Overview answers a completely different question, telling you how to duplicate a collection inside the Shopify admin, which is not the problem you have.
What Shopify’s default robots.txt blocks, and what it leaves crawlable
Shopify’s default robots.txt blocks the combinations, not the singles. It disallows sort_by, tag combinations (the + and its encoded %2B forms), and two filters used together. A single tag URL, a single filter parameter, and pagination are not matched by any default rule, so they stay crawlable.
I pulled a real store’s file to check rather than trusting the blog posts on this. Here are the rules that matter, straight out of it.
| URL pattern | Beispiel | Blocked by the default robots.txt? |
|---|---|---|
| Sort parameter | /collections/shoes?sort_by=price-ascending | Yes, Disallow: /collections/*sort_by* |
| Two tags combined | /collections/shoes/blue+sale | Yes, Disallow: /collections/*+* und dessen %2B forms |
| Two filters together | ?filter.v.option.color=blue&filter.v.price=50 | Yes, Disallow: */collections/*filter*&*filter* |
| One tag | /collections/shoes/blue | No. Crawlable. |
| One filter | ?filter.v.option.color=blue | No. Crawlable. |
| Paginierung | /collections/shoes?page=2 | No. Not in the file at all. |
Read those patterns closely, because the whole problem hides in the wildcards. /collections/*+* only matches a URL that contains a +, and a single tag URL has no + in it.
The filter rule is stricter still: */collections/*filter*&*filter* needs the word filter to appear twice, with an & between them. One filter param sails straight through it.
There is one caveat I want you to take more seriously than the table. Every store’s robots.txt can be different, because robots.txt.liquid is editable. I pulled a second large Shopify store in the same session and its file was customized: it had an extra rule, and it was missing the multi-filter rule the first store had.
So go and open yourstore.com/robots.txt right now and read your own. That takes ten seconds, and it beats trusting any blog’s list of the defaults, mine included.
Why a single tag URL is a separate indexable page
A single tag URL is a full, standalone, indexable page. It returns HTTP 200, renders a complete product grid, carries no noindex, and its canonical points at itself rather than back at the parent collection.
I checked this live on a real store rather than repeating it from memory. Loading deathwishcoffee.com/collections/all/merch gives a normal collection page, and the canonical in the head reads:
<link rel="canonical" href="https://www.deathwishcoffee.com/collections/all/merch">
That is the page pointing at itself. So Google is not being told “this is a variant of the parent collection”, it is being told “this is the page, index it.”
The title does change a little on most themes (you get a “tagged” suffix), but the body, the heading, and the intro copy are the same as the parent. That is a thin, near-duplicate page from Google’s point of view, and you have one for every tag on every collection.
Here is a useful diagnostic that follows from the way Shopify works. If a tag in the URL is not used on any product, Shopify redirects to the collection URL with the tag removed. Shopify’s own theme documentation states it plainly: if a tag in the URL is not used on any of the store’s products, the store redirects to the collection URL without it.
So when you are auditing, a tag URL that redirects is not part of your bloat, and one that renders is. That one test sorts your list fast.
Should you canonical page 2 back to page 1?
No, and this is where I part company with a chunk of the advice on this topic. Google’s documentation says it directly: “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL.” Shopify’s default behavior already does exactly that.
I confirmed the default on the same live store. Loading /collections/all?page=2 gives a canonical pointing at ?page=2, not at the base collection. Shopify is already doing the right thing here, and the popular “fix” undoes it.
Several Shopify SEO guides recommend canonicalling every paginated page back to page 1, and it is easy to see why it appeals. It looks tidy, and it makes the duplicate-looking URLs disappear from your reports.
The cost is that it hides your deeper products. If pages 2 and 3 all point at page 1 as the “real” page, you are telling Google that the products only visible on those pages belong to a URL they do not appear on, and you have made them harder to discover, not easier.
To be fair to the other side, Google’s guidance also suggests linking back to page 1 from every page in the sequence, because page 1 is usually the page you want people to land on. That is a linking hint, though, not a canonical instruction, and the two are not interchangeable.
There is one pagination duplicate genuinely worth cleaning up: ?page=1. That URL is a true duplicate of the base collection URL, so if your theme links to it anywhere, fix the links so they point at the clean URL. Read Google’s ecommerce pagination guidance if you want the full reasoning.
While you are in there, one more thing worth knowing: the old rel="next" und rel="prev" markup is retired. Google’s documentation says it no longer uses those tags, so if a guide is still telling you to add them, that guide is out of date.
The collection-path product URLs everybody already writes about
This is the one cause the existing guides cover well, so I will keep it short and give them their due. When a theme links to products through the collection, Shopify serves the same product at /collections/shoes/products/blue-runner as well as at /products/blue-runner.
The fix lives in your theme’s product-grid snippet. Use {{ product.url }} anstelle von {{ product.url | within: collection }}, so your internal links all point at the clean product URL.
One warning that Amsive gets right and that is worth repeating: do not add a noindex to those collection-path product URLs. They are already canonicalized to the clean product URL, and a noindex on a canonicalized duplicate is a conflicting signal that can end up suppressing the page you actually wanted indexed. Keep them out of your sitemap and let the canonical do its job.
Which tag pages to promote, block, or noindex
Sort every tag URL into one of three buckets: promote it into a real collection if it has search demand, noindex it if it is a genuine near-duplicate nobody searches for, and leave it alone if it is already blocked or redirecting. The blanket “noindex all tag pages” advice throws away the first bucket, and that bucket is where the money is.
Think about what a tag URL usually represents. /collections/shoes/waterproof is a page about waterproof shoes, and “waterproof shoes” is a phrase people genuinely search. That is not bloat, that is a collection you have not built yet.
The difference between the two is demand, and demand is checkable. If you are not sure how to size it, my guide on validating an ecommerce niche walks through the same demand check at a product level.
| What you found | Was ist zu tun? | Why |
|---|---|---|
| The tag matches a phrase people search (“waterproof shoes”) | Promote it. Build a real collection with its own copy, title, and internal links | It has demand, and a proper collection page will outperform an auto-generated tag list |
| The tag is an internal label (“ss24-batch2”, “clearance-old”) | Noindex it via a theme condition on the tag template | Nobody searches it, and it is a thin copy of the parent collection |
| The tag URL redirects when you load it | Leave it. Nothing to fix | Shopify already removes unused tags from the URL |
| The URL has sorting, combined tags, or stacked filters | Leave it. Already disallowed | The default robots.txt covers these patterns |
| You want to block a pattern robots.txt misses | bearbeiten robots.txt.liquid, carefully | Shopify supports it but does not support you: see the warning below |
If you do decide to edit your robots file, read Shopify’s own warning first. Their help documentation is blunt about it: “This is an unsupported customization. Shopify Support can’t help with edits to the robots.txt.liquid file… Incorrect use of the feature can result in loss of all traffic.”
When you do edit it, add and remove directives with Liquid rather than pasting a plain-text file over the template. Shopify recommends the Liquid method precisely because it preserves their ability to keep the file updated for you, and warns that a hardcoded replacement means rules may become out of date.
And remember what robots.txt actually does. It stops crawling, not indexing, so it is the wrong tool for a page that is already indexed and that you now want removed. For that job you want a noindex, and I have walked through the mechanics in how to deindex a page.
How to check your own store in Search Console
Open the Pages report in Search Console and read the reasons, not the totals. The two rows that tell you this problem is live on your store are “Duplicate without user-selected canonical” und “Indexed, though blocked by robots.txt”, and each one means something different.
Click into each reason and look at the URLs themselves. If you see /collections/ paths with a tag on the end, or a filter. parameter, you have found the pages this article is about.
The “Indexed, though blocked by robots.txt” row surprises people, so it is worth saying plainly: it is not a bug. Shopify’s own documentation calls it normal behavior and usually not a cause for concern, because search engines can index a page they discovered elsewhere without ever crawling it.
You may also find a pile of collection URLs sitting in “Crawled, currently not indexed”, which is Google telling you it looked and decided the page was not worth a slot. That state has its own causes and its own fixes, and I have covered them in crawled, currently not indexed.
One honest note about scope. This article is about the URLs your storefront generates, which is a crawling and indexing problem. If your product data is also going into Google Shopping, that is a separate surface with its own rules, and I keep those in the Merchant Center requirements guide.
So how much does Shopify duplicate content from collections really matter?
Honestly, for a store with 20 products and three tags, not much. Google is good at picking a canonical on its own, and you have better things to do than prune a handful of tag URLs that nobody would ever land on.
It starts to matter when the multiplication does. A store adding collections quickly, with a dozen tags each and a filter set turned on, is generating hundreds of crawlable near-duplicates without a single person deciding to.
If this were my store, I would not start with a noindex sweep. I would export the collection URLs Google has actually crawled, sort them into the three buckets in the table above, and I would expect to find at least one tag URL with real demand that deserves to become a proper collection.
That reframes the whole job. The tidy-up is worth doing, but the win is the collection page you did not know you needed, and no amount of canonical housekeeping will hand you that.
Not sure which of your collection URLs to keep?
Send me the list and I will look. You can kontaktieren Sie uns oder E-Mail directly, and I am happy to tell you which ones are bloat and which one is a collection worth building.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
