Product Variants or Separate Products? Catalog URL Design

In an online store, the catalog decision is the one made earliest and noticed latest: will the different colours of the same product be separate products, or options of a single product? The decision takes two clicks in the admin panel, but its consequences show up separately in stock, in the checkout flow, in the URL structure and in the feed files.

Turkish-language sources usually treat this subject in two different places: stock and option management on one side, product page optimisation on the other. Little content treats the two as faces of the same decision. Yet the variant decision is not an admin preference; it is, at the same moment, a URL architecture decision.

The text below takes the decision together with its three consequences: what each setup means for stock, what it produces in the URL structure and how it is read on the machine side. How a product page becomes quotable in AI search is something we covered separately in our article on GEO for ecommerce; the subject here is not the page copy but the skeleton of the catalog.

The catalog decision is not something you fix later

The catalog is the load-bearing structure of the store. The way a product is defined determines the stock movements tied to it, the order lines, the return records and the data sent to outside channels. As those records pile up, the cost of changing the structure rises.

Fixing it is expensive for more than the workload. When a product's definition changes, its URL changes too; when the URL changes, the record that search engines and shopping channels have built up about that product has to be rebuilt. In a store with a hundred products that is a week of work; in a store with ten thousand products it is a project of its own.

So the right question during setup is not "which is easier" but "which work will this structure make harder two years from now".

The same product in another colour: a separate product or an option

There is a practical distinction: if customers search by that attribute, it is a separate product; if they choose that attribute after finding the product, it is a variant.

Size is almost always a variant; nobody searches for a product by size, they find the product and then pick the size. Colour is a grey area. On a piece of furniture, colour is often the purchase decision itself and people search for it directly; on a T-shirt it is an option.

Three further criteria sharpen the decision:

• Difference in images and content. If the story, the size chart or the usage information changes between options, there is an argument for separate products.
• Difference in price. If there is a serious price gap between options, showing a single price on a single page breaks expectations.
• Stock behaviour. If the other options keep selling when one of them runs out, that is variant behaviour.

When the criteria conflict, the default choice is a variant: merging is easier than splitting apart later.

Three consequences of the decision: stock, checkout flow, URL structure

Stock. In a variant setup, stock is held on the lowest-level option; every colour-size pair carries its own stock record. In a separate-product setup, each product is independent. The second looks simple, but it can lead to two records being kept for the same physical product and to mismatches at stock count.

Checkout flow. The variant is chosen before adding to the basket. If the choice is mandatory and unclear in the interface, the customer gives up not because they cannot add the item but because they do not understand what to choose. How missing information turns into abandonment at the checkout step is covered separately in our article on checkout abandonment.

URL structure. A separate-product setup produces a separate URL for every option. That means pages that look very alike multiply; pages answering the same question can suppress one another. A variant setup has a single URL, and the choice is usually made through a query parameter.

How to structure a stock code

A stock code (SKU) is an internal identifier the business creates itself; a barcode is the product's identity in the outside world. When the two get mixed up, the resulting problem is usually spotted late.

A healthy stock code has three properties: it is unique, it is defined at the lowest variant level and it does not change over time. Price, campaign name or supplier information is not embedded in the code; those things change, and the code should not.

A readable pattern makes the work easier: product family, model, then the distinguishing attributes. What matters is less the pattern itself than applying it consistently. When the same code appears in the warehouse, in the admin panel, in accounting and in the feed file, every later mapping job gets simpler.

On the barcode side, the product's global number supplied by the manufacturer is used; the business does not invent this number itself. For products you make yourself, having no such number is normal, and it opens a separate topic when you send data to outside channels.

One last warning about code structure: in a product with variants, a code has to be defined for both the parent product and every variant. If the code is kept only on the parent, the order line cannot tell you which option was sold; if it is kept only on the variants, reporting on the product family becomes hard. Giving both levels their own code lets every later mapping job — marketplace, accounting, warehouse — run on a single key.

The category tree: depth, multiple categories and the primary category

The category tree does two jobs at once: it gives the customer navigation, and it tells the system where the product belongs. When the two line up, the customer wins.

Depth. In trees deeper than three levels, customers get lost and the admin burden grows. For most stores a main category, a subcategory and, where needed, one further split are enough. Finer distinctions are the job of filters, not categories.

Multiple categories. A product can appear in more than one category, and that is often correct. But if every category produces its own URL, the same product opens from more than one address. In that case the product should have one canonical URL and the others should point to it.

Primary category. A product's "real home" should be singular. The breadcrumb, the category field in the feed file and reporting all depend on this choice. When the primary category is left undefined, the system picks one at random and that choice looks inconsistent everywhere.

When filters generate URLs: which combinations get indexed

Filtering is the part of catalog architecture that generates the most URLs. Five filters with a few options each can multiply into thousands of URLs. Not all of them are worth crawling, and when crawlers try, crawl budget is taken away from the pages that actually matter.

The distinction comes down to one simple question: do people actually search for this filter combination? "Kırmızı koşu ayakkabısı" (red running shoes) is something people search for and deserves its own page; "red, size 42, mid price range, in stock, sorted newest first" is not something anyone searches for.

In practice, three rules work:

1. For the small number of combinations people search for, real category pages are built; those pages get their own title and description.
2. The remaining filter URLs either point to the main category page or are closed to crawlers.
3. Parameters that change sorting, pagination or the view are never treated as separate pages.

It matters that the decision is written down: which filters generate URLs is a setting in the admin panel, and the person who changes that setting usually does not see the consequence. When a new filter is added, this decision has to be reviewed again; otherwise the number of URLs grows quietly.

Site search belongs to the same family. Search result pages are usually not worth crawling and are closed off; on the other hand, the site search queries that return no results are a very valuable record. That list shows products your catalog does not carry, or products customers name differently from you, and it feeds directly into fixing your attribute fields.

Describing the variant group to machines

What a page tells people and what it tells machines should be the same. For a product with variants, that means the options on the page also appear in the structured data.

In product markup, a variant group is expressed as separate product records linked to a shared parent record; each variant has its own stock code, its own price and its own stock status. In a separate-product setup, each page is declared as an independent product and the relationship between them is established only through on-page links.

The single rule here is that the markup must not declare anything the page does not show. Declaring a price range in the markup while the page shows a single price, or showing an out-of-stock variant as in stock, is an inconsistency that needs fixing. The general framework of markup and its relationship with trust signals is covered in our article on schema markup and E-E-A-T.

Sold-out and seasonal products: does the page stay or go

The default behaviour is to leave the page where it is. When the URL of a product that has run out of stock is removed, the links pointing to it and the record built up around it are wasted; when the product comes back, everything starts from zero.

If the product will come back: the page stays, the stock status is honestly declared as "sold out", and where possible a notify-me option and links to alternative products are added.

If the product will never come back: the page stays up for a while longer, then redirects to its closest equivalent — the new model of the same product, or the category it belongs to. Redirecting straight to the home page is wrong; the visitor lands somewhere unrelated to what they were looking for.

For seasonal products the page stays all year. URLs recreated every season mean a record that starts from zero every season.

Attribute fields: one source for filters and feeds

Information such as a product's colour, material, dimensions or warranty period sits either in structured fields or inside the description text. The second is easy in the short run and makes everything harder in the long run: information inside the text cannot be carried to the filter, the feed file or the structured data.

The right setup is a single source: each attribute is defined in its own field, and from there it feeds the on-site filter, the table on the product page and the file going to outside channels. When the same information is written separately in three places, it is only a matter of time before the three drift apart.

When building the field list, look at two things: the information customers will want to filter by, and the fields outside channels treat as mandatory. Gaps in the second list are one of the most common reasons products get rejected on shopping channels; we go through the families of rejection one by one in our article on Merchant Center disapprovals and feed files.

Where to start fixing the catalog

In an existing store, the catalog cannot be fixed overnight. The order can be set up like this:

1. Inventory. How many products, how many variants, how many categories, how many filter URLs — get the numbers out first.
2. Duplicate records. Are there multiple records for the same physical product; if so, which one becomes the original.
3. Stock code. Is the code pattern consistent, is it defined at the lowest level, are any left blank.
4. Primary category. Is it defined on every product, is the breadcrumb consistent.
5. Attributes. Are the mandatory fields filled, is any information stuck inside the description.
6. Filter URLs. Which are open to crawling, which are closed; is the decision written down.
7. Redirects. Has a destination been defined for every URL that changes during the fix.

This order is designed so that each step produces the input for the next; starting in the middle usually means repeating the work.

How catalog and variant structure is set up during the build is described on our ecommerce website setup service page. If you would like a scan of your current catalog, you can write to us through the contact form.

Frequently Asked Questions

Should every variant have its own page?

The general answer is no. When the options of the same product are gathered on one page, the customer makes the comparison in one place and the links and accumulated record for that product collect at one URL. A separate page can only be defended when the options genuinely behave like different products: when the story, the dimensions, the price and the query people search with are different. A practical test when deciding: if the page copy you would write for the two options is largely the same, it should be one page, not two.

Can a product sit in more than one category?

It can, and in most stores it needs to; customers look for the same product along different paths. What needs care is that multiple categories do not produce multiple URLs. The product should have a single canonical URL, and the categories should work as different navigation paths leading to it. In addition, every product should have a primary category defined: the breadcrumb, reporting and the category information sent to outside channels depend on that choice, and they look inconsistent when it is left undefined.

For filter pages, which is right: blocking them from crawling or pointing them to the main page?

The two solve different problems. If a filter combination is genuinely searched for, it is built as a page with its own title and description. For combinations that exist technically but are not searched for, the preferred option is for those URLs to point to the main category page; closing them off from crawling entirely is appropriate mainly for sorting and view parameters. The common mistake is using both on the same URL and sending two signals that contradict each other.

Should we delete the page of a product that has sold out?

Not if the product will come back. The page stays in place, the stock status is declared honestly and the customer is offered an alternative or a notify-me option. When the URL is deleted, the external links pointing to it and the record built up around it are wasted, and the process starts from zero when the product returns. If the product will never be sold again, the page is left up for a while longer and then redirected to its closest equivalent; a blanket redirect to the home page is not a suitable solution, because it drops the visitor far from what they were looking for.

How do we fix thousands of products in bulk?

Not by hand, but through export and import. The catalog is exported to a spreadsheet, the fixes are made in that spreadsheet and it is loaded back; that way a record of the changes remains and you can roll back if something goes wrong. Two warnings: try it first on a small sample and check the result, and for every fix that changes a URL, define the destination for the old URL at the same time. The most expensive form of bulk fixing is changing the URLs and leaving the redirects for later.