What is a Magento Grouped Product ?
A Magento Grouped Product is a product type that displays N simple products together on one PDP without bundling them. Each child has its own price, stock, and Add-to-Cart row — customers buy any subset with its own quantity. There is no parent-level price, stock, or SKU. Use it to surface "buy together" relations without forcing a kit purchase.
Five steps to ship a Grouped Product end to end
A grouped parent is a presentation wrapper, not a SKU you sell. Here is exactly how Magento composes the PDP and the cart from a grouped product.
-
01
Create the grouped parent (name, SKU, NO price)
In the Magento admin, open Catalog → Products → Add Product → Grouped Product. Fill in the name, SKU, category assignments, and SEO fields exactly as you would for any other product. Do not set a price field — grouped parents have no parent-level price. The parent is essentially a wrapper that controls listing presentation, URL key, meta tags, and child sort order. All commercial data (price, stock, weight, tax class) lives on the children.
-
02
Link child simple products via "Products in Group"
Scroll to the Products in Group section on the grouped product edit page and click Add Products to Group. Tick each simple (or virtual) product you want to surface on this PDP. Save. Each linked child gets a position integer that controls the row order on the storefront table — lower numbers appear first. Re-order by editing the position values; no drag-and-drop in vanilla Magento, but position is the only thing the storefront sorts by.
-
03
Set each child's default quantity
Per-child Default Quantity is the qty that pre-fills the child's input field when the PDP renders. Customers can edit it before pressing Add to Cart. Leave it at 0 if you want the customer to consciously type a quantity (good for "pick the optional accessory" scenarios); set it to 1 (or N) if you want the bundle to feel pre-curated. The default quantity is stored on the
catalog_product_linktable, not on the child product itself, so the same simple child can carry different defaults in different grouped parents. -
04
PDP shows a table of children with individual Add-to-Cart rows
On the storefront, the grouped PDP renders a single table listing every linked child — name, qty input, price, optional thumbnail. There is no single Add to Cart button for the parent; instead one big button submits all the children at once with whatever quantities the customer typed. Children with qty 0 are skipped. Out-of-stock children render disabled. This is the visual signature that tells customers "these are related but separate items, pick what you actually want."
-
05
Cart treats each child as its own simple-product line
Once submitted, the cart contains N independent line items — one per ticked child, each with its own SKU, price, qty, and stock check. The grouped parent does not appear in the cart at all. This means promotions, tax rules, shipping calculations, refunds, and reporting all see the child SKUs directly. You can refund one child without touching the others. Inventory deducts from each child's own stock pool. Reorder-from-history pulls the child SKUs, not the parent. The grouped parent is purely a PDP-rendering layer.
Four scenarios where Grouped beats Bundle and Configurable
Grouped earns its place whenever customers should see related items together but stay free to pick any subset. These four cases come up most often.
-
Cross-sell that customers configure themselves
Office chair + footrest + lumbar pillow on a single PDP. The chair is the hero; the footrest and pillow are optional add-ons. A grouped product gives the customer an at-a-glance "everything that goes together" view without forcing them into a kit purchase — they tick what they actually want. Conversion rate on the primary item typically goes up because the page reads as "we curated this for you" rather than "you also might like" (which is dismissed as a banner).
-
Series or collection sold as separate volumes
A 7-book fantasy series, a 5-album discography, a 3-part course curriculum. Customers want to see the whole series on one URL (good for SEO, good for browse intent) but buy whichever volumes they don't already own. A grouped PDP lists every volume with its own stock, price, and qty input. Bundle would force the whole set; configurable doesn't fit because volumes aren't variants. Grouped is the only product type that gets this UX right.
-
Replacement parts and compatible spares
A coffee machine model lists its descaler, filter cartridge, replacement carafe, and milk frother on one "spares for Model X" PDP. The customer arrives via a "Model X filter replacement" search query, lands on one page that surfaces every spare for that model, and ticks only the bits they need. Selling replacement spares this way reduces SKU sprawl in search results and keeps related parts discoverable without polluting the main catalogue with kit listings.
-
Beauty / personal-care mix-and-match sets
Skincare routines, hair-care regimens, scent samplers — categories where customers expect to pick their own combination. A "morning routine" grouped PDP lists the cleanser, toner, serum, and SPF as separate children; the customer chooses which sizes (or which subset) to buy. Bundle locks the recipe; grouped respects that everyone's routine is slightly different. Average order value typically beats single-PDP cross-sell carousels because the related items are above-the-fold, not buried below recommendations.
Three traps that turn a Grouped product into a support ticket
Every grouped-product problem I've been called to fix in the last 8 years comes back to one of these three confusions. Avoid them up front.
-
Confusing Grouped with Bundle
A grouped product is not a kit. Each child becomes its own cart line, with its own SKU, stock, and price — the customer can buy one, all, or any subset. A bundle product, by contrast, is a single composite SKU sold as one purchase with one cart line. If business requirements say "the gift box must always contain X, Y, and Z and ship as one unit," use Bundle. If they say "show these related items together but let the customer pick what they want," use Grouped. Picking the wrong type here means rebuilding the PDP later.
-
Setting a price on the parent
Magento's admin will accept whatever you type into the price field on a grouped parent, but the storefront ignores it. The PDP price column always shows each child's own price; the cart always uses child prices. Setting a parent price creates a mental model mismatch — admin users will assume changing it changes the displayed total, then file support tickets when it doesn't. Leave the parent price field empty. Update child prices to change what the customer pays.
-
Trying to link configurable products as children
Grouped product children must be simple or virtual product types. Configurable, bundle, and downloadable types cannot be linked — the admin product picker will not even show them. If you need "size variants of three related items on one PDP," the answer is not grouped-of-configurables; it is either three separate configurable PDPs cross-linked, or a single configurable product with extended attributes. Trying to force configurables into a grouped parent via direct DB inserts will break the PDP renderer.
Magento Grouped Product — frequently asked questions
-
Grouped vs bundle — what's the practical difference?
A bundle is a single composite SKU bought as one unit: one cart line, one price, one shipment. A grouped product is a presentation wrapper: each child becomes its own cart line with its own SKU, price, and stock — the customer can pick any subset (including just one) and the cart shows each pick separately. Bundle is the right call for gift sets, hampers, or fixed kits. Grouped is the right call for "buy together" UX where the customer should still be free to deselect any item. The clearest test: would you ever ship just one of the items independently? Yes = grouped. No = bundle. -
Why does my grouped product page show no price?
Grouped products have no parent-level price by design. The storefront renders each child's own price in the products-in-group table, not a single price at the top. If you want a "from $X" indicator at the top of the PDP, you need either a custom Block or theme override that loops the children, finds the minimum price, and renders it next to the title. Magento's default template will not do this for you. The same applies to category listings — without customization, grouped products appear with no price label in the category grid. -
Can I track stock at the parent grouped level?
No. Stock lives on each child simple/virtual product, and the grouped parent has no stock record of its own. The parent shows as "in stock" on the storefront as long as at least one child is in stock; out-of-stock children render disabled in the PDP table. If you need a parent-level stock concept (e.g. "only sell this set while all four items are in stock"), you need a custom plugin on the stock-status logic or a switch to a Bundle product (which does carry parent-level stock derived from its options). -
Can children be configurable products?
No. Grouped product children must be simple or virtual. Configurable, bundle, and downloadable are not allowed and the admin product picker will filter them out. If the requirement is "show three related configurable products on one PDP," the correct pattern is either three separate configurable PDPs with cross-sells, or a single configurable product with the variant axes you actually need. Magento intentionally restricts grouped children to simple/virtual to keep the cart-line model trivial: every line is a single concrete SKU. -
How does this affect promo rules and cart price rules?
Cart price rules apply to children, not to the grouped parent. A condition like "SKU equals GROUPED-001" will never match because GROUPED-001 never enters the cart — only the child SKUs do. Write rules against child SKUs, child attributes, or child categories instead. Catalog price rules behave the same way: they discount child products by SKU/attribute/category match, and that discount surfaces on both the grouped PDP price column and the cart line for that child. This is consistent with the underlying model where the parent is presentation, the children are commerce. -
Do grouped products work with Adobe Commerce B2B?
Yes. Grouped products work in Adobe Commerce (and Adobe Commerce B2B) on every supported version. Customer-segment pricing, shared catalogues, company-account quoting, and tiered prices all apply at the child level, which is exactly where you usually want them in B2B (different companies see different prices on each child item). The one thing to watch is requisition lists: customers add the child SKUs to lists, not the grouped parent — make sure your sales team and storefront copy reflect that the "set" is conceptual and the SKUs are still individual.
Not sure which product type fits your catalogue?
Send your store URL and a sample of the SKUs you're modelling — I'll reply with a product-type recommendation per SKU group, a migration plan if you're changing types, and a fixed-price quote. 24-business-hour turnaround.