PrestaShop multistore: when to use it, when not to and what is shared

Multistore is one of those PrestaShop features that looks like the answer to everything. Want one store for trade customers and another for consumers? Multistore. One for Spain and another for Portugal? Multistore. A second brand with a different design? Multistore. And it is true that it can do all of that, but every store you add multiplies the configuration, the testing and the possible failures. Before enabling it, you should know exactly what you gain and what you pay.

What multistore is

It is a core option that lets you run several stores on a single installation and a single database. They are managed from the same back office, choosing in a selector which store (or which store group, or all of them) each change applies to. Each store can have its own domain or folder, its own theme, its own visible catalogue, its own prices and its own configuration.

Stores are organised into store groups, and it is at group level that you decide what they share.

What is shared and what is not

What is common to all of them

• The installation: same files, same core version, same modules on disk. If you update PrestaShop, you update all of them at once.
• The base catalogue: a product exists once and is associated with one or more stores. Many of its fields (name, description, price, visibility) can have different values in each store.
• Employees, who can have access to all stores or only to some.

What the store group decides

• Sharing customers: whether a customer registered in one store can log in to the others in the group with the same account.
• Sharing stock: whether the stores in the group sell from the same stock or each keeps its own.
• Sharing orders: only possible if stock is shared, and it allows, for example, customers to see in their account the orders from every store in the group.

What belongs to each store

• Domain, theme and visual configuration.
• The configuration of most modules, which can differ in each store (or be the same, if you save it for all).
• Carriers, payment methods, currencies, languages and active countries.
• CMS content and its own pages.

When it does pay off

• Different brands with the same warehouse. Two stores with a different name, design and audience that sell part of the same catalogue from the same stock. Multistore avoids duplicating products and synchronising stock between two installations.
• One team managing several small stores that share a supplier, logistics and way of working, and that needs to see all their orders in one place.
• Stores per country with real differences in catalogue, prices, carriers or legal texts, going beyond translation.

When it does not pay off

• You just want another language. PrestaShop handles several languages in a single store, with a URL per language. You do not need multistore for that.
• You just want different prices for trade customers. Customer groups, specific prices and catalogue price rules handle B2B selling within the same store, with the same catalogue.
• You just want another currency. Currencies are also handled within a single store.
• The two stores have nothing in common: different catalogue, different team, different logistics. Then the only thing you share is the risk. An update or a failing module breaks both, and you cannot update one without the other.

What it complicates day to day

Modules

Not all modules are properly prepared for multistore. Some save their configuration only once for all stores, do not filter their data by store or show in one store what was configured for another. Before installing a module in a multistore, ask explicitly whether it supports it and test it with at least two stores.

The back office selector

Every change is applied in the context chosen at the top: one store, a group or all of them. It is easy to change a price or a setting thinking it affects one store and apply it to all, or the other way round. With several people working in the back office, it is worth agreeing who touches what and from which context.

Performance

Many queries have to take the store into account, and tables with per-store data grow with every store you add. In large catalogues, it shows.

Updates

A core update affects all stores at once, with all their modules and themes. The test list is multiplied by the number of stores: a failure may appear in one store's theme and not in the other's.

SEO

If two stores sell the same products with identical descriptions in the same language, they compete with each other in search engines. If you are going to have shared products, consider writing separate descriptions for each store.

Questions to help you decide

1. Do the stores sell from the same stock? If not, much of the advantage disappears.
2. Can what you want to separate be solved with languages, currencies or customer groups? If so, a single store is simpler.
3. Do all your essential modules work in multistore?
4. Can you accept that the stores will always be updated at the same time?
5. Who is going to manage the back office, and are they used to working with the context selector?

If multistore still makes sense after these questions, the next step is to set it up first on a test copy, with two real stores and the modules you are going to use, and check the complete flow before opening it to the public.

How to solve it in PrestaShop

Enabling multistore takes one click; designing the groups properly, choosing what is shared and checking that each module behaves well with several stores takes more work. With a Rekire support hours package we analyse your case and tell you whether multistore suits you or a single store with languages and customer groups, set up the configuration on a test copy, review your modules and, if you already have a multistore that is causing problems, find where data is getting mixed up between stores.