Merchant questions with a situation attached

You can run this alongside them or instead of them, but they are not the same shape, so it is not an import. Native combined listings restructure your products into a parent listing; this app leaves products as they are and adds a storefront layer. Moving across means building groups from the same families, which bulk grouping can usually do from your existing titles or tags in one session. Nothing has to be undone first.

Usually not from nothing. Most of these apps ask you to encode the grouping somewhere, in tags, in a metafield, or in a naming convention, and bulk grouping here can read all three. If your previous app wrote its grouping into product tags, point tag detection at that tag format. If it used a metafield, point metafield grouping at that key. What you cannot import is the styling, which is set up again here.

Uninstall it after this one is set up and verified, not before. Two apps both rewriting the variant picker or the product card can collide, so the overlap should be short, but a gap where neither runs is worse: shoppers see the ungrouped catalogue. Set up here, check a collection page, then remove the other.

Only if you want to rebuild from them later. Once groups exist here they are stored independently, and the tags are inert. Many merchants keep them anyway because a tag that describes the family is useful for collection rules and for the next migration.

This is the catalogue shape the app fits best. Print on demand splits by design, by garment and often by print position, and each split is another product with another URL. Group by garment and the shopper sees every design on it, or group by design and they see every garment it prints on. Bulk grouping from a title pattern usually finds these on the first attempt, because print on demand titles are generated and therefore consistent.

Use multi option swatches, which draw two rows: material above, colour below. The shopper picks along each axis instead of reading one long row where both are mixed. Alternatively, sub sections label parts of a single row, which suits a family where one dimension has only two or three values.

Only that the sold out rules will never fire, so leave them alone. Everything else is the same.

Option names and option values are shopper-facing text, so they need translating. Export them as CSV, translate the column, import it back. The grouping itself is not duplicated per language: one group serves every market.

The swatches render the price the storefront is showing that shopper, because they read the page rather than a stored copy. If your B2B pricing is served through Shopify's own mechanisms, the swatches follow it.

Magic Fill strips the prefix a whole group shares, so the swatch labels are the part that differs rather than the whole title. Where a label is still long, the swatch shows a trimmed version and the full name in a tooltip, or you can shorten the option value by hand: it is a free text field and does not have to match the product title at all.

Product page swatches are rendered from data already present in the page, so they add no request and nothing arrives late enough to shift the layout. Card swatches fetch their data once for the page rather than once per card. The honest caveat is that any app adds something to a page; the design goal here was that nothing a shopper sees waits on our servers, and that is met.

No, because nothing is duplicated. The products already existed and already had their own pages. If you were worried about duplicate content between near identical colour pages, that concern predates this app and is answered the same way it always was: distinct titles, distinct descriptions, distinct images.

That is a decision about your catalogue rather than about this app, and for most shops the answer is no. Canonicalising the siblings to one page throws away the reason they are separate products. Merchants who wanted one canonical page usually wanted Shopify's native combined listings, or one product with variants.

A small script and the swatch markup. There is no framework, no font and no image loaded by the app itself: swatch images are your own product images from Shopify's CDN, at the size the swatch needs.

It reads the page, so it sees the product it landed on plus a set of links to the siblings with their option values as text. That is more legible than a gallery of unlabelled photos, which is the alternative. The option values being real words rather than swatch images is what makes it readable, and is a reason to fill them in properly even where the swatch is an image.

Existing groups keep working. You are asked to upgrade before adding more than the new plan allows, rather than having anything switched off underneath you.

Bulk grouping reads a CSV, which is also the shape a group takes going out. If you need a full export for a migration or a backup, ask support.

Anyone with access to the app in your Shopify admin, which is your staff permissions rather than a separate account system. The data is counts by product, group, device and position; no shopper is identified anywhere in it.

Only to Shopify, which is where it came from, and to OpenAI when you press Magic Fill, which sends the product image URL and title and nothing about your shop, your customers or your orders. If you never use the AI features, nothing is sent to OpenAI at all. The privacy page lists every sub-processor.

Ask support and you will get one. The privacy page describes what is processed and by whom in the meantime.