Shopify's New Collections: Multi-Source, Variant-Level and Nested, and What to Rebuild

For most of Shopify's life a collection was one of two things: a manual list of products, or a smart collection built from conditions that every product either met or did not. Stores worked around it. A sale collection was a tag applied by hand to two hundred products; a gift guide was a manual list that went stale the week after it was built; a red collection for Valentine's Day was impossible, because a collection held products and the red one was a variant.

On 16 July 2026 Shopify's changelog announced that collections now support multiple sources and variants, and the Help Center now describes "a new collections model" that "is replacing the legacy manual and smart collections model." This is what changed, in Shopify's words read on 20 September 2026, what it means for how a store is structured, and the three collections worth rebuilding first.

Multiple sources in one collection. Shopify's wording: "Combine automated conditions, hand-picked products, exclusions, other collections, and sources from apps in a single collection." The Help Center's example is an organic coffee collection holding products tagged organic and priced under $50 together with products whose materials metafield is ceramic and priced over $30, two conditions that the old smart collection could not hold at once.

Variants as members. A collection can be built around specific variants, size or colour, and those variants appear in the collection page, in filters, and in the sales channels including the Online Store and POS. The Help Center's own example is "only red products for Valentine's Day."

Collections as sources. A collection can be used inside another and stays in sync when the source changes: the Help Center's example is a Teaware collection built from the existing Teapots, Steepers and Infusers collections. And four ways to decide membership, in the Help Center's list: include automatically by condition, add by hand, exclude automatically by condition, and exclude by hand.

Reuse elsewhere. The same collection, including a variant level one, applies to the workflows that take collections, which the changelog names as discounts and taxes. A sale that used to need a tag now needs a collection, and the collection that drives the sale can be the one that drives the page.

Existing collections moved to the new model automatically, and the changelog says there are no breaking changes: nothing had to be deleted or recreated, and a manual or smart collection is simply a collection with one source now. The admin gained a visual grid with drag to reorder, a list view, and control of the sort order, and Sidekick can build and update collections from the admin and the mobile app.

Apps are the caveat. The changelog states that developers need API version 2026-07 for compatibility, so an app that reads or writes collections on an older version may not see a multi-source or variant level collection correctly until its developer updates. The Help Center adds a second, smaller one: a collection created in the mobile app before the new model reached the admin cannot be edited there and shows "You can't edit this collection." The plan requirement is stated too: collections need the Basic plan or higher, or the Agentic plan when building an online store.

The old model pushed structure into tags, because tags were the only thing a smart collection could combine freely, and a store of any age carries hundreds of them with nobody sure which are load bearing. The new model lets the structure live in the collections themselves: a collection built from a metafield, a price band and an exclusion, with the tags retired one by one as each collection stops needing them. That is a cleanup worth doing slowly and worth doing, because tags leak into filters, into search and into every app that reads them.

It also changes which page owns a search term. Why collection pages do not rank is mostly a story about duplication: three collections answering one term, filter URLs indexed beside the pages they filter. Nesting makes it easier to have one collection per term with sub collections feeding it, and variant level collections make it possible to answer a colour or size query with a page that only holds that colour or size, rather than a filtered URL that should not be indexed at all. The store structure that ranks is the same one it was; the new model removes the excuse for not building it.

One thing it does not change: a collection page still needs its own copy, its own title and its structured data, and a collection that exists only to drive a discount should not be published to the Online Store at all. More collections is not the goal any more than more pages is.

The sale collection. It is almost certainly a tag applied by hand, it is the collection most often wrong, and it is the one the discount now wants as its source. Rebuild it as conditions and exclusions, point the discount at it, and retire the tag.

The gift or seasonal guide. It is a manual list that went stale, and it is the case for nesting: a guide built from the collections that already exist, so a product added to Teapots appears in the Teaware guide without anybody remembering to add it. Where the guide is a colour or a size, it is the case for a variant collection, which is the page that could not be built before.

The collection that answers your biggest search term. Read it against its rivals inside the store, merge what duplicates it into sources under one page, exclude by condition what does not belong, and give the one page the copy and the title the term deserves. This is where the model pays for the store, because a category page that ranks is the most valuable page on most Shopify stores, and the answer engines read the same page.

Four things. That every app touching collections is on the 2026-07 API or later, and that the ones that are not are known. That the filters on collection pages behave with variant members, because a variant level collection can put one colour of a product on a page whose filter still lists every colour the product has. That the canonical and robots handling on filtered and sorted URLs is unchanged, since the pages that should not be indexed are still the same pages. And that the rebuilt pages are no slower: a collection with many sources is computed by Shopify, not by the theme, but the theme is where speed is usually lost, and a rebuilt page is a page worth measuring again.

On the Shopify stores we run, the new model is a structure project rather than a feature: the tag map is read, the collections that carry search terms are rebuilt as one page each with sources under them, the sale and seasonal collections are moved to conditions, and the apps are checked against the API version before any of it is published. It is done in that order because the search pages are where the money is, and it is the kind of work our Shopify management exists to do once, properly, rather than every season by hand.