What to check in the week after you group a catalog

Short answer: check the app embed on your live theme, then one product page, then one collection card, then a product you know has no option value. Rubik Combined Listings shows the embed status on its dashboard, which settles the most common failure without opening the theme editor. Free plan, 5.0 stars, 91 reviews.

Bulk grouping is fast. Point it at a title pattern, review what it found, accept, and four hundred products are in families before lunch.

Then everyone moves on, and nobody looks again until a shopper emails asking why the sand is missing from a shirt that definitely comes in sand.

The failures in that first week are boring, repetitive and entirely avoidable, which is the best kind of failure to write a list about. Here is the list, roughly in the order things go wrong.

In this post

1. The four checks before you close the laptop
2. The theme republish trap
3. A product missing from its row
4. Cards that do not match the product page
5. Another app fighting for the same element
6. Day seven, and the only number worth reading
7. Three things that look wrong and are not
8. Questions merchants ask

The four checks before you close the laptop

Ten minutes, in this order, on the day you build the groups. Skipping them is how a shop spends a fortnight shipping a storefront that renders nothing.

1. The embed status card on the dashboard. It reads Active, Inactive or Action needed. Active on your live theme is the only one that means anything is happening.
2. One product page, in a private window. Not the theme editor. A preview session can serve an older copy of the storefront data than a real visit does, which is why the theme editor is the worst place to check whether something shipped.
3. One collection page. Card swatches are a separate setting from product page swatches, and it is entirely possible for one to be live and the other not.
4. One product you expect to be missing. A draft product, or one you know has no option value. Confirming that the absent thing is absent for the right reason is worth more than confirming ten present things.

That last one catches people out. If you cannot explain why a product is not in its row, you do not yet know whether the grouping worked or whether you got lucky.

The theme republish trap

This is the single most common way a working setup stops working, and it has nothing to do with linking separate products as variants itself.

The app embed is per theme. Switch it on, everything renders, everyone is happy. Three weeks later a developer publishes an updated theme, or you duplicate the live one to make a change and publish the copy, and the embed on the new theme has never been switched on. The storefront reverts to an ungrouped catalog with no error anywhere, because nothing failed. A switch is off.

Your groups are untouched by any of this. They live on the products, not in the theme, so switching the embed on brings everything back exactly as it was. That is reassuring and it is also why the failure is so quiet: nothing is lost, so nothing complains.

Add it to your theme deploy checklist, next to whatever else you check after a publish. If you do not have a theme deploy checklist, this is a good first line for one.

A product missing from its row

Three causes, and they are easy to tell apart once you know what to look for.

• It is draft or archived. Those are excluded on purpose, and the product reappears in its row by itself when it goes active again. No group editing required. That is the behaviour you want at the start of a season.
• It has no option value. A product in a group with no value has nothing to render as a swatch, so it is silently skipped. This is the commonest one after a bulk import, where a few products did not match the pattern cleanly.
• It was never added. Bulk grouping shows you what it found before it creates anything, and it is easy to accept a run that found ninety of a hundred. Compare the count in the group against the count in the collection.

The second one is worth a deliberate sweep in week one. Magic Fill will read each product’s image and title and write the option value for you, including picking the hex color and a second color when the product is two toned, and it fills blanks without overwriting anything you set by hand. One pass over a freshly bulk grouped catalog usually closes the gap.

Cards that do not match the product page

Swatches on product pages but nothing on collection cards is the second most common ticket, and there are only two explanations.

Either card swatches are switched off, which is a setting, or your theme builds its product card in a way the app did not expect, and that is a mapping. The app carries selectors for 358 themes, 283 official ones, 68 third party and 7 page builders, so most shops are already mapped. For the rest, naming your theme by hand in the app embed screen usually does it, and support will map a theme properly if you send them a collection page URL.

There is a third case that looks identical and is not a fault. Cards that arrive after the page has loaded, from infinite scroll, a filter, or a quick view modal, are watched for and get their swatches injected when they appear. If yours are not appearing on a filtered collection, that is worth a ticket rather than a shrug.

You can check whether your theme is on the mapped list before any of this, on the theme list, which is searchable.

Another app fighting for the same element

If you are moving from another grouping or swatch app, this is the week it shows up.

Two apps both rewriting the variant picker, or both injecting into the product card, can collide. The symptom is usually intermittent rather than absolute: swatches appear on some loads and not others, or one app’s row appears above the other’s. It looks like a bug in whichever app you installed most recently, and it usually is not.

The right sequence when migrating is to set this one up and verify it, then remove the old app. Not the other way round. A short overlap is uncomfortable; a gap where neither runs means shoppers see the ungrouped catalog, which is worse. And if the two do collide, say which app it is when you contact support. Most of these end in a setting on one side rather than a choice between the two.

Day seven, and the only number worth reading

A week in, resist the urge to look at conversion rate. Seven days of one shop’s traffic will not separate a swatch row from the weather, and you will talk yourself into a conclusion either way.

Read the click counts instead. They answer a smaller question honestly: is anybody using this.

• Total clicks, split between product pages and cards. Zero on one side and plenty on the other is a rendering problem, not a shopper problem. Go back to the checks above.
• The busiest groups. Usually your best sellers, and the fact that it is unsurprising is what makes it a good sanity check. A group you have never heard of at the top is worth opening.
• Mobile against desktop. Compare the split to your overall traffic split. If phones are 70 per cent of sessions and 20 per cent of swatch clicks, your mobile row is too small or sits somewhere nobody scrolls to.

The sold out demand report will be almost empty at day seven, and that is correct. It needs a color to run out and stay out for a while before it has anything to say. Come back to it in a month, when it becomes the most useful thing in the app.

If you want a sense of whether the pages themselves are pulling their weight alongside all this, Craftshift has a free Product Page Grader that scores a URL in a few seconds.

Three things that look wrong and are not

Week one also generates false alarms, and chasing them wastes the attention the real issues deserve.

1. The collection page still shows every color as its own card. Yes. Twelve products are twelve products, and the swatch row under each card is what links them. Collapsing a family to one card is a different operation and a different kind of app.
2. A filtered collection shows swatches for colors the filter excluded. Shopify’s filters work on the products in the collection; the swatches still link to the whole family. Some merchants want that, because it is a route back to the rest of the range. If you do not, the visibility rules are per context.
3. Your product URLs are unchanged. That is the design, not an incomplete setup. No handle, redirect, canonical or sitemap entry is created or changed, That is the design, and the whole reason the change is safe to make in November.

Run the checks on five groups first

Five product groups are free with no time limit and no card. Enough to walk this entire list on a real storefront before you commit a catalog to it. Everything here behaves the same at five groups as at five hundred, so nothing you learn on the free plan has to be relearned later. The pricing page has the plan detail.

Demo store | Docs | Help centre

Questions merchants ask

How do I fix swatches that stopped showing after a theme update?

Switch the app embed on for the new theme. The embed is per theme, so publishing a duplicate or an updated theme leaves it off there, and the storefront quietly reverts to an ungrouped catalog with no error. Rubik Combined Listings shows the embed status on its dashboard, including the awkward case where the embed is on but on a draft theme rather than the live one. Your groups are untouched throughout, because they live on the products.

Why is one product missing from its group?

It is draft or archived, which excludes it on purpose and reverses itself when the product goes active, or it has no option value, which leaves nothing to render as a swatch. After a bulk grouping run the second is far more likely, and a Magic Fill pass over the group usually closes it.

I made a change and the storefront still shows the old one.

Give it a minute and reload with the theme editor closed. A preview session can serve an older copy of the storefront data than a real visit does, which is why a private window is the only honest way to check whether something is live.

How long should I wait before judging whether grouping worked?

A month for anything about behaviour, and longer for anything about buying. At a week you can tell whether it renders and whether anyone clicks. You cannot tell whether it sells, and a seven day conversion comparison will give you a confident answer that happens to be noise.

Do I need to redo anything when I add a new color?

Add the product to the existing group and give it an option value. Everything else, including the swatch image and the price, is read from the product itself and stays current as you edit it.

Can I check all this without opening the theme editor?

Mostly. The embed status card covers the theme side, the group list covers the product side, and a private browser window covers the storefront. The theme editor is only needed to switch the embed on in the first place.

Related reading

• The help centre, which covers install, bulk grouping and troubleshooting in order
• Merchant questions, for migrations and theme specific cases
• What grouping does to your product URLs, the answer to the check nobody thinks to run
• The theme list, to see whether yours is mapped
• Sibling products not showing on Rubikify, for the longer diagnostic path

Put the embed check on the deploy list

Of everything above, that is the one that will actually bite you, and it will bite in month four rather than week one, on a day when a developer publishes a theme and nobody connects the two events.

One line on a checklist. Cheaper than the afternoon you would otherwise spend working out why a catalog that has been fine since spring suddenly is not.