Skip to content

Duplicate Content · Filter URLs

The /collections/*+* Filter URL Pattern, Explained

Shopify's default /robots.txt blocks /collections/*+* — the URL signature generated when a customer filters a collection by two tags at once (e.g. /collections/dresses/red+xl)1. The pattern matches any URL where a + appears after the collection path, which is how Shopify's tag filtering joins tags4. Both of Shopify's current default files also block sorted views and URLs that combine two or more ?filter. parameters6. The blocks exist to suppress combinatorial duplicate-content explosion. Almost no Shopify store should unblock them.

Published Verified 2026-09-16

The /collections/*+* URL pattern

When a customer filters a Shopify collection by two or more tags, the URL joins the tag handles with a + character. A 'red' plus 'xl' selection becomes /collections/dresses/red+xl. The * in /collections/*+* is a robots.txt wildcard matching any collection handle followed by any tag combination containing a + literal. Shopify's newer storefront filters work differently: they add ?filter. query parameters to the collection URL, which the next sections cover.

Why combinatorial URLs are a problem: a single collection with 8 colors and 6 sizes has 8×6 = 48 single-facet pages, 8×7/2×6×5 = some-large-number two-facet combinations, and so on. Three-way combinations multiply further. Every URL is technically crawlable, all serve mostly-overlapping product subsets, and most have zero search demand. Google's faceted navigation guidance3 identifies this combinatorial explosion as a primary cause of wasted crawl budget on ecommerce sites.

Why Shopify blocks the pattern by default

The default block exists for three reasons. (1) Combinatorial explosion: a 10-filter collection generates thousands of URL combinations, most with no search demand. (2) Thin content: filter combination pages typically show subsets of the parent collection with no unique editorial content. (3) Crawl-budget waste: search engines spend crawls on filter combinations instead of canonical primary URLs. Shopify's default robots.txt block stops this at the platform level.

Shopify's Editing-robots-txt help page1 lists /collections/*+* among the key default entries. It's in both of the default files Shopify serves today: the managed robots.txt for stores without a robots.txt.liquid, and the older set the Liquid loop prints for stores with one6. Each block exists for a reason; the /collections/*+* block is the one most operators forget exists.

One detail worth knowing: the block is robots.txt-level, which means Google still knows these URLs exist (it sees them in internal links) but won't crawl them. URLs blocked by robots.txt can still appear in search results as URL-only listings if heavily linked. In practice this rarely happens on a Shopify store because filter URLs aren't linked externally — they're only generated by customer interaction on the collection page itself.

Facets vs filters — what's blocked, what isn't

Shopify's storefront filters (e.g. /collections/dresses?filter.v.option.color=red) use query parameters rather than path segments, so /collections/*+* doesn't touch them. A second default rule does: both of Shopify's current default robots.txt files block /collections/*filter*&*filter*, which matches any collection URL that combines two or more filter parameters. A single filter stays crawlable. Sorted views (?sort_by=) are blocked by a third default rule.

The clean mental model: tag combinations (red+xl) and filter combinations (?filter.v.option.color=red&filter.v.option.size=xl) are blocked by default; a single filter (?filter.v.option.color=red) is not56. Single-filter pages are handled at the canonical layer instead: on Shopify's Dawn demo store, /collections/all?filter.v.availability=1 carries a canonical pointing back to /collections/all.

Search & Discovery app and filter URLs

The Shopify Search & Discovery app (Shopify's first-party filter/facet app) generates query-string filter URLs on collection pages. The /collections/*+* block doesn't catch them, but the default /collections/*filter*&*filter* rule catches any URL that combines two or more filters. Single-filter URLs stay crawlable, so their canonical handling depends on the theme: Dawn emits a canonical pointing back to the bare collection URL, which consolidates ranking signals without needing additional robots.txt edits.

Verify the behaviour on your store with one curl. If the canonical on a filtered URL points back to the bare collection, the platform is handling it correctly. If the canonical is self-referencing on the filtered URL, you have an extra audit step — the theme or app is treating each filter combination as a unique page, which can recreate the duplicate content surface the default block was supposed to eliminate.

bash Audit filtered URL canonical behaviour 
# Expected: canonical points to bare /collections/dresses
curl -sL "https://yourstore.com/collections/dresses?filter.v.option.color=red" \
  | grep -i 'canonical'

# Expected output:
# <link rel="canonical" href="https://yourstore.com/collections/dresses">

When to unblock (almost never)

Unblocking /collections/*+* is the wrong move for ~99% of Shopify stores. The only legitimate use case: a niche store with high-intent multi-facet queries that need their own ranking targets (e.g. 'red wedding dresses size 8' is a real search query the store wants to rank for). In this case, you don't unblock the default — you create a hand-built static collection page at /collections/red-wedding-dresses-size-8 with curated content, structured navigation, and full editorial treatment. That's a named collection, not a filter URL.

The principle: every URL Google should rank for needs to be a real, curated, content-rich page — not an auto-generated filter combination. The default robots.txt block keeps the filter URLs out of the index, and the merchant builds named collections for the high-intent queries that justify dedicated pages. This is the standard ecommerce faceted-navigation strategy Google recommends in its faceted-navigation doc3.

For the broader robots.txt.liquid mechanics — the editable Liquid template that controls this block — see the robots.txt.liquid hub and the leaf on default rules.

Keep reading