Check store collections: Which products actually belong?

A store collection is correctly assembled when the expected products are included and intentionally excluded products are absent. Start by expressing the selection rule in plain language, build a small expected-results list, and then inspect the actual storefront. A suitable heading alone does not prove that the product selection is correct.

Cover image: AI-generated illustration of product cards and selection areas. It represents a planning concept, not a real store interface or a Shirtee.Cloud feature.

Turn a theme into a testable rule

Imagine a collection called “Coastal designs on shirts”. The idea combines two properties: the design belongs to the coastal series, and the item is a shirt. A matching tote bag should deliberately be absent. A shirt with a woodland design should also be excluded.

This is a different decision from creatively planning a small collection. That process establishes a shared visual language and product roles. Here, you check whether the store's selection mechanism actually represents that decision.

Write the rule in full: “Show products from the coastal series that are classified as shirts.” Avoid ambiguous shorthand such as “coast/shirts”. The slash does not explain whether both properties are required or whether either one is sufficient.

Check which collection model your store uses

The current Shopify collections documentation describes a new model replacing the previous manual and smart collections. Until it becomes available in a particular admin, the previous models remain relevant. Check your own interface before following a sequence of clicks.

The creation guide distinguishes rule-based and manual inclusion, among other options. The new model also supports variants as a source. This is a Shopify feature; it does not establish any particular data transfer or native Shirtee.Cloud function.

You do not initially need sophisticated automation for the following review. You need a clearly described selection and suitable test products. Whether you implement it manually or with conditions depends on its scope, how often it changes and the functions actually available.

Four test products expose the difference between AND and OR

For our fictional example, use two deliberately maintained attributes: the tag coastal-design and the product type Shirt. These are original working values, not predefined platform categories or real Shirtee products.

With AND, only P01 is wanted. With OR, P02 and P03 would also satisfy the selection. Shopify explains matching all conditions versus any condition in its original documentation. The four products above form our own truth table; this is not a test report from an existing store.

Check each test product separately. If P02 appears, first examine the selection rule and the attributes actually stored for it. Do not change its title, tag and product type at the same time. Otherwise, you will not know which change produced the result.

Give manual exceptions a visible reason

An additional manual inclusion can be intentional. Perhaps one complementary product should appear despite failing the normal rule. Record its identifier, the reason for the exception and the review date. The decision should not exist only in someone's memory.

Shopify's creation guide notes that manually added products or variants remain included until manually removed. A new condition therefore does not reliably replace a review of those entries. When a product appears unexpectedly, inspect how it entered the collection.

Our example needs no exception. P02 remains excluded even though its design fits the theme. If you later want a broader “Coastal designs” collection, that would be a different rule with its own expected-results list.

Review membership, visibility and variants separately

A product in an internal membership list does not prove how it appears publicly. Inspect the intended storefront page and the route to it: Is the menu link correct? Does the page title fit? Does the product tile open the expected item? Do the image and selected variant match?

For a collection intended to show particular colours only, our product-level rule is insufficient. First define whether you mean entire products or individual variants, and check what your available collection model supports. Do not promise an exclusive colour selection if clicking through presents additional colours as equivalent choices.

For a small assortment, you can compare the entire expected list with the visible list. For a larger assortment, targeted boundary cases help, but they do not establish how much of the catalogue was actually inspected. State the scope of your review explicitly.

A small acceptance record keeps selection traceable

Save the rule, the expected product identifiers and the result for each test case. Add the interface actually used and the time of the visual check. After a relevant change to tags, product types or sources, repeat those same cases.

Then align the customer-facing message with the checked selection. If the collection is called “Coastal designs on shirts”, its title, image and products should convey the same scope. A grid of product cards becomes an understandable selection whose boundaries you can explain and test again after a change.