How to structure a Shopify store with thousands of products

Putting 20,000 products into Shopify is not particularly difficult. Structuring those 20,000 products so customers can find them, Google can understand them and your team can maintain them without developing a deep personal dislike of the website is a different problem entirely.

We have worked with Shopify catalogues running into tens of thousands of SKUs, and the lesson is fairly consistent. Build the catalogue first, then build the website around it.

That sounds obvious, but ecommerce projects still have a habit of starting with homepage concepts, navigation layouts and product cards before anybody has properly looked at the data. Six weeks later somebody opens the supplier files and discovers three different naming conventions, missing SKUs and seventeen versions of the same manufacturer. At that point the design meeting tends to become less important.

Start with the products, not the menu

A menu is not a catalogue structure. It is simply one way of navigating the catalogue.

That distinction matters once you have thousands of products. An industrial spares business might sell actuators, flame detectors, valves, pressure switches and controls. Those make perfectly sensible menu items, but customers may also need to find all Siemens SKP actuators operating at 230V. That requires information about brand, product family, series and voltage.

Those attributes describe the product regardless of where it appears in the navigation. That is catalogue structure. The menu is just the interface sitting above it.

Treat product data as infrastructure

For a large ecommerce business, product data should be treated as infrastructure rather than content.

The way products are modelled determines what customers can search, how filters work, how automated collections are built, what appears on product pages, how feeds are generated, how Google understands the catalogue and how Shopify exchanges information with other systems.

This is why catalogue work needs to happen before most of the visual work. The shape of the data affects almost everything that follows. Button radiuses can survive the delay.

Establish a reliable product identifier

Every product needs a reliable identity. In most businesses that means a SKU, although large catalogues often reveal that the word "SKU" means slightly different things to different systems.

You may have internal SKUs, supplier references, manufacturer part numbers, legacy SKUs and occasionally several products sharing something that was supposed to be unique. If Shopify, an ERP and a supplier feed are all going to communicate, you need to know exactly which identifier is authoritative and how the others map to it.

A common structure might retain an internal SKU as the canonical identifier, a manufacturer part number for customer search and a supplier reference for incoming data. The important point is that these values are deliberately defined rather than treated as interchangeable because they happen to look similar.

Decide what a product actually is

This sounds trivial until you meet a technically complicated product.

Take a wheel available in several diameters, widths, offsets and finishes. Is that one product with variants, several products or a configurable product with combinations that should not exist until selected?

Shopify currently supports up to 2,048 variants per product and up to three product options, which gives merchants far more flexibility than older limits did. That does not mean the objective should be to fill every available slot.

The right structure depends on how customers understand the product, how stock is managed and whether each combination has its own commercial identity. In some cases 40 variants make perfect sense. In others, four variants should really have been four separate products.

Changing that decision after tens of thousands of records have been imported is possible. It is also an excellent way to discover how patient everyone involved actually is.

Build a proper product taxonomy

Taxonomy is simply the controlled structure used to classify products.

An automotive product might contain information such as product type, vehicle make, model, generation, drivetrain, engine application, material and finish. An industrial component might carry manufacturer, series, voltage, control type and application.

The point is to stop important information living only inside product titles or descriptions.

A title such as "BILLET BLACK LS SWAP ENGINE MOUNT KIT PORSCHE 997 05-08 MANUAL C2 C2S" contains plenty of information, but it is doing far too much work. Once those attributes are structured properly they can be used for filtering, search, automated collections, compatibility, specification tables and programmatic updates.

Structured data gives the catalogue something to work with.

Separate categories from attributes

Categories and attributes are often confused, which is how stores end up with navigation structures that go seven levels deep.

A category describes what the product is. An attribute describes a characteristic of that product.

For example, the category might be "Actuator". The attributes might be manufacturer, series, voltage and control type.

You generally do not need a category tree containing Actuators, then Siemens Actuators, then Siemens 230V Actuators, then Siemens 230V SKP Actuators. At some point you have stopped building navigation and started nesting folders for sport.

Use categories for meaningful product groups. Use structured attributes to let customers narrow those groups.

Decide what belongs in metafields

Shopify metafields are extremely useful for large catalogues because they allow structured information to be attached to products, variants and other resources.

They are a good place for data such as manufacturer references, technical specifications, material, voltage, dimensions, application information, lead times or technical documents.

The mistake is creating them reactively. If every new requirement results in another metafield being added without any wider plan, the store slowly accumulates fields that overlap, conflict or simply stop being used.

Eventually somebody finds “custom.product_type_new_final_2” and nobody is willing to delete it because nobody knows what will break.

Define the data model first. Then create metafields to support it.

Normalise the values

Consistency matters because databases do not automatically understand that several slightly different strings mean the same thing.

"Siemens", "SIEMENS", "Siemens AG" and "siemens" may all be obvious to a human, but without normalisation they can become separate filter values. The same problem happens with voltage, dimensions, materials, colours and virtually every other technical attribute.

This is why incoming product data often needs to be cleaned before it reaches Shopify. Normalisation is not glamorous work, but it is the difference between a catalogue that behaves predictably and one that slowly turns into a collection of edge cases.

Large stores are full of small inconsistencies. The trick is not letting them become customer-facing features.

Use collections deliberately

Shopify collections are useful for navigation, SEO, merchandising, manufacturer pages and campaign landing pages. Automated collections can also include products based on defined conditions, which is considerably more scalable than relying on staff to remember where every new product belongs.

If a Siemens actuator is correctly structured, a collection can include it automatically based on manufacturer and product type. Nobody needs to remember to tick an additional box during product creation.

Any system that depends on somebody remembering a repetitive administrative step several hundred times a month will eventually fail. Usually quietly.

Design filters around how customers buy

Filters should exist because customers need them, not because the data happens to be available.

For an industrial pressure switch, useful filters might include manufacturer, pressure range, connection and approval. For fashion, colour and size may matter more. For automotive, the most important filter may not describe the product at all. It may be the vehicle the customer owns.

Shopify's filtering tools can use standard product information and structured custom data, but deciding which filters matter is a commercial and UX decision.

The correct filter set usually comes from understanding how customers identify the thing they need.

Do not make customers browse everything

Large catalogues need to reduce choice progressively.

A customer should be able to move from something broad, such as Porsche, into a model, generation, category and then a smaller group of relevant products. Filters can narrow that further by manufacturer, axle, model year or another relevant attribute.

Navigation, filtering and search should work together. Navigation helps customers understand the catalogue, filters reduce a result set and search lets experienced buyers bypass both when they already know what they want.

If the only route to a product is clicking through hundreds of collection pages, the problem is not catalogue size. The problem is navigation.

Treat search as part of the data model

Technical ecommerce search often needs to recognise more than a product title.

Customers may search by product name, manufacturer part number, internal SKU, application or an informal description. If those values are important, they should be stored in ways that allow the search layer to use them effectively.

Someone entering a precise part number expects the correct product. Someone searching "997 rear control arm" expects sensible interpretation rather than a random selection of anything containing the word "rear".

A large catalogue with poor search can still technically contain all the correct products. That is not much consolation to the customer who cannot find them.

Compatibility needs its own structure

Compatibility data deserves special treatment in automotive, machinery and replacement-parts catalogues.

One product may fit many vehicles or machines, and one vehicle may have thousands of compatible products. That is a many-to-many relationship, which is fundamentally different from ordinary category navigation.

For smaller catalogues, structured metafields or metaobjects may be enough. Larger fitment datasets may require dedicated data structures, external databases or applications that resolve customer application against compatible products.

Trying to represent complex fitment with thousands of tags can work for a while. So can balancing a chair on two legs.

Establish a source of truth

Once several systems are involved, you need to decide which one owns each type of information.

Shopify may handle the storefront and order capture. An ERP may own stock and pricing. A PIM may own technical product information. Supplier feeds may provide availability or cost data.

The exact architecture varies between businesses, but ownership has to be explicit. If Shopify says there are six in stock and the ERP says four, somebody or something has to know which answer wins.

"Whichever updated last" is not really a systems architecture.

Plan for change

A large catalogue is never finished. Products are added, discontinued, superseded, repriced, reclassified and restocked constantly.

The important question is not only how to get 30,000 products into Shopify. It is how to keep those 30,000 products correct once the store is live.

For some businesses, scheduled CSV imports may be perfectly adequate. Others need APIs, middleware, supplier feeds, PIM systems or ERP synchronisation. The correct answer depends on how often data changes and how many systems are involved.

Automation matters because manual processes become increasingly fragile as catalogue size increases.

Validate incoming data

Automation needs controls.

Computers are extremely efficient at doing the wrong thing at scale. If a supplier accidentally changes a price from £72.00 to £0.72, a perfectly functioning automated process may be delighted to publish it everywhere.

Incoming data should therefore be validated for missing SKUs, duplicates, unexpected price movements, unknown manufacturers, invalid categories, missing images and other anomalies.

Automation without validation is simply a faster way of creating catalogue problems.

Think about SEO during the structure work

SEO for large ecommerce stores starts long before anybody writes a meta description.

Catalogue architecture affects internal linking, collection pages, crawl paths, URLs, duplicate content, manufacturer pages and indexable category structures. A store selling thousands of Porsche parts may need meaningful landing pages around model generations, categories and product families, but it probably does not need Google indexing every possible combination of filter values.

Filtering architecture and SEO architecture are related, but they are not the same thing. Both should be planned rather than allowed to emerge accidentally.

What does a good large catalogue look like?

From the customer's point of view, not especially exciting.

They select what they need, the right products appear, search works, filters make sense, stock is accurate and the product page contains enough information to make a decision.

Internally, staff can add products without calling a developer, supplier updates do not destroy the catalogue and the various systems involved broadly agree with one another.

Nobody notices the architecture underneath because they do not need to.

That is usually the sign that it is working.

How we approach it

When we work on a large Shopify catalogue, we normally map four things first: the products, the data, customer behaviour and the systems behind the store.

We need to understand what is being sold, where the information originates, how buyers identify the product they need and which platforms need to exchange stock, price, product and order information.

From there we can define the taxonomy, identifiers, relationships, metafields, collections, filters, search and integrations. Once that structure exists, the storefront becomes much easier to design properly.

The order matters.

Thousands of products should not mean thousands of problems

Shopify is capable of supporting very large catalogues, but it cannot decide what your data means.

That is the important part.

A well-structured catalogue containing 50,000 products can be easier to operate than a badly structured one containing 5,000. The difference is whether the store has been engineered around the products and systems behind it.

At WYBB, that is exactly the sort of work we do. If you are planning a large Shopify build, replatforming an existing catalogue or looking at several supplier spreadsheets and wondering how any of it is supposed to become a coherent website, our Ecommerce Engineering service is built around that problem.

You can also send us the catalogue.

We have seen worse.

Probably.