PrestaShop Multistore: running multiple stores from one admin panel

Reviewed June 2026, the shop-group / shop / shop-URL model and the Advanced Parameters → Multistore screen apply to PrestaShop 1.7, 8 and 9.

PrestaShop Multistore is the feature merchants reach for when one shop turns into three: a German storefront, a French one, a wholesale arm. The pitch is appealing. Run them all from a single admin, share one product catalogue, log in once. And it largely delivers. But Multistore is not a multi-language switch and it is not a way to glue together unrelated businesses. It is a specific piece of PrestaShop architecture with its own context model, its own gotchas, and one decision (what you share versus what you separate) that you make once and live with for years. This guide is about that architecture and the day-to-day of operating it. What the back office actually gives you, where the shop context will bite you, and when Multistore is the wrong tool entirely.

What Multistore actually is, structurally

Under the hood, PrestaShop Multistore is three nested levels, and understanding them is the difference between confident administration and accidental cross-shop damage:

• Shop groups (the shop_group table, id_shop_group). A group is the boundary for sharing. Customers, orders, available stock and carts can be shared within a group but never across groups. If two shops must share a customer login, they must live in the same group.
• Shops (the shop table, id_shop). The individual storefront, its own theme, its own catalogue selection, its own configuration values.
• Shop URLs (the shop_url table). Each shop is reached through one or more domain/physical-URI combinations, myshop.de, myshop.fr, or shop.example.com/de. This is what maps an incoming request to the right shop.

You enable the whole system at Advanced Parameters → Multistore (in older 1.6 installs it lived under Preferences → General → Enable Multistore). Once on, almost every back-office page gains a shop context selector in the top-left, and this selector is the single most important control in a Multistore install: it determines whether the edit you are about to make lands on All shops, one shop group, or a single shop.

The shared-vs-overridden model

The sharing model is not one universal mechanism. It works differently for catalogue entities and for configuration, and that distinction matters. For catalogue data like products, categories and carriers, PrestaShop keeps one base record and adds a per-shop association table, product_shop, category_shop, carrier_shop and so on. That lets a given shop override specific fields (for a product, things like price, active status, redirect, even the name) while inheriting the rest. So you genuinely manage one product, but its price on the French shop and its visibility on the wholesale shop can each differ. Settings, by contrast, are not associated rows at all: they live in the configuration table with a shop and shop-group scope, so a value can be written globally, per group, or per shop. This layered override is the real benefit of Multistore over running separate installations: edit once, vary deliberately.

When Multistore is the right tool

Country-specific stores on different domains

The cleanest fit. myshop.de, myshop.fr and myshop.es as three shops in one group, sharing products and customers, each with its own theme, default currency, default language and tax rules. Stock is shared so you are not reconciling three inventories. This is Multistore working exactly as designed, but note the sharp line: Multistore handles the storefronts, it does not on its own get you correctly localized currencies, tax-inclusive display per country, or hreflang. Those are separate jobs covered in selling across Europe: languages, currencies and tax and hreflang tags.

Premium and budget brands, one warehouse

Same physical products, two storefronts with different names, themes and price points, drawing on one shared stock pool. The per-shop price override and per-shop product name make this a few clicks rather than a duplicated catalogue.

B2B and B2C side by side

A retail shop showing tax-inclusive prices and a wholesale shop showing net prices, minimum order quantities and invoice payment, both on the same product database. Customer groups plus a second shop in the same group give you shared stock with completely different commercial rules.

Several niche stores with partial product overlap

Garden, kitchen and bathroom stores that share a chunk of catalogue but have distinct branding. The overlap is what justifies Multistore; the shared products earn their keep every time you update one and it propagates.

When Multistore is the wrong tool

You only want more languages

This is the most common mistake. PrestaShop is multilingual in a single shop. Every translatable field (product name, description, CMS, meta) is stored per language in _lang tables, and you add languages under International → Localization → Languages. If all you need is English plus French copy at the same prices, Multistore adds context-juggling for nothing. Do it the standard way, see multi-language store setup.

The stores are genuinely unrelated

Pet food and electronics, no shared products, no shared customers, no shared operations. Here Multistore gives you the complexity tax with none of the sharing benefit. Two separate installations are easier to reason about, easier to back up independently, and impossible to cross-contaminate with a wrong-context edit. Multistore earns its keep through overlap; with zero overlap it is pure overhead.

One person, already stretched

Every Multistore edit carries the question "which context am I in?" A solo operator who forgets the selector once can push a price or a disabled status across every shop. If the team is small and the discipline isn't there yet, the cognitive load can cost more than separate installs would.

The shop context: where Multistore actually bites

The context selector is not a convenience. It is a live scope that changes what your save button does:

On product, category and configuration pages in single-shop context you will see a small checkbox beside many fields. That is the override toggle. Tick it and the field detaches from the shared value for this shop only. Leave it unticked and the shop inherits. The practical rule we live by: read the context selector out loud before you click Save. "All shops" mode editing when you meant one shop is the single most expensive Multistore mistake, and it produces no error. It just quietly does exactly what you told it to, everywhere.

Data sharing: the decision you make once

For each data type you choose share-or-separate when you create the shop, and changing your mind later is migration work. The honest defaults:

• Products, usually shared. One catalogue, per-shop overrides for price, name and visibility. This is the core efficiency win.
• Customers and carts. Shared within a group when the same person should log in across your markets; separate (different groups) for genuinely distinct brands where one identity makes no sense.
• Orders. Always keep their originating shop (each order carries its id_shop). If the shop group is configured to share orders, they can be visible and shared within that group; otherwise an order stays scoped to its own shop. Either way you can view and process all shops' orders from one Orders list, which is the centralized-fulfilment payoff.
• Available quantities (stock). Can be shared within a shop group when the group's "share available quantities" option is enabled, which is what makes the one-warehouse scenarios work; otherwise stock stays per shop.
• Categories and CMS, shareable but often you want them split: a shared product tree but localized legal pages and a country-specific homepage.

The module compatibility problem

This is the biggest practical risk, and it is real. Multistore-awareness in a module is not automatic. The developer has to build it. A module that ignores Multistore will:

• Ignore the shop context and apply every change to all shops, because it reads and writes configuration with Configuration::get() / Configuration::updateValue() without passing the shop id or honouring Shop::CONTEXT_SHOP.
• Store settings globally, so you cannot give two shops different values, the second shop overwrites the first.
• Create its own database tables without an id_shop column, so its data is unavoidably shared even when it should be per-shop.
• Work fine on the main shop and break, or silently leak data, in any other shop context.

A well-built module reads its settings with the shop id (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop) via the shop context), adds id_shop to its tables, and registers hooks per shop. Before you commit to Multistore, audit every module you depend on for this. Check the documentation, ask the developer directly, and, non-negotiable, test in a staging install with at least two shops before you build out the real thing. Discovering a critical module isn't Multistore-aware after you've set up three live shops is a genuinely bad afternoon.

This is squarely why we build the way we do. Our module suites are written shop-context-aware from the data layer up, so a setting you change on the French shop stays on the French shop and a module's tables carry their id_shop rather than smearing data across every store. That is the difference between a Multistore install you can trust and one where every config save is a small gamble. Relevant whether you run SEO management, invoicing or on-store content across your shops. Always verify per module, but the point of buying from a developer who tests multi-shop is that you don't inherit the compatibility problem above.

Currencies, flags and the per-shop storefront details

Multistore gives each shop its own default currency and its own enabled language set, but the customer-facing pieces, the currency switcher, the language flags, the way a returning visitor lands on the right shop. Are storefront work that sits on top of Multistore, not inside it. Getting those small details right is what stops an international visitor bouncing; we cover them in currency selector and language flags, and the full mechanics of running prices in several currencies in the multi-currency setup guide.

Practical management tips

• Read the context selector before every save. It is the one habit that prevents the costliest Multistore error. Treat "All shops" as a loaded setting.
• Name shop-specific assets by shop. banner-myshop-de.jpg, not banner.jpg. When you are uploading per-shop logos and theme images, the filename is your only reminder of which shop you are in.
• Test in each shop's context. A theme tweak that looks right on Shop A can break on Shop B with a different theme or module configuration. View the live front office of each shop after a change, not just the main one.
• Back up before structural changes. A wrong-context edit can cascade across every shop at once; a recent database dump is your undo button.
• Document the shop map. Which shops are in which group, what's shared versus overridden, which modules are shop-specific. When something breaks or someone new joins, this is the document that saves the day.
• Watch the shop_url mapping. SSL settings, the main-URL flag and the physical/virtual URI per shop are easy to misconfigure and produce redirect loops or the wrong shop loading. Check them under Advanced Parameters → Multistore → each shop's URL.

Performance considerations

Every Multistore query carries a shop filter, PrestaShop joins against the _shop association tables and filters by id_shop on most catalogue and configuration reads. For two or three shops with normal catalogues this overhead is negligible. For ten-plus shops with large catalogues it becomes measurable, and the fix is ordinary database hygiene: make sure indexes exist on the id_shop columns of the heavy association tables, keep your category and product counts in check, and lean on full-page caching so the front office isn't re-running shop-filtered queries on every hit. Measure on your own install, enable Multistore, then watch query times in the Debug profiler before you assume there's a problem.

Frequently asked questions

Is Multistore the right way to add more languages?

No. This is the most common mistake. PrestaShop is multilingual inside a single shop: every translatable field is stored per language in _lang tables, and you add languages under International → Localization → Languages. If all you need is the same catalogue at the same prices in English and French, Multistore adds context-juggling for nothing. Use the built-in multilingual fields, see multi-language store setup. Reach for Multistore only when markets need genuinely different catalogues, pricing structures or branding.

What's the single most expensive Multistore mistake?

Saving in "All shops" context when you meant one shop. The context selector (top-left) is a live scope: in "All shops" mode a save writes the value to every shop at once, and it produces no error. It quietly does exactly what you told it to, everywhere. The habit that prevents it is simple: read the context selector out loud before you click Save, and treat "All shops" as a loaded setting.

Can my shops share customers and stock?

Within a shop group, yes. A shop group is the boundary for sharing. Customers, carts and available stock can be shared within a group but never across groups. So if two shops must share a customer login, they have to live in the same group, and shared stock (when the group's "share available quantities" option is enabled) is what makes the one-warehouse scenarios work. Orders always keep their originating shop's id_shop, but you can process every shop's orders from one Orders list.

How do I know a module is safe to use across multiple shops?

You have to verify it. Multistore-awareness isn't automatic, the developer has to build it. A module that ignores the shop context will apply every change to all shops, store settings globally so two shops can't differ, or create tables without an id_shop column so its data is unavoidably shared. A well-built module reads settings with the shop id (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop)), adds id_shop to its tables, and registers hooks per shop. Test every dependency in a staging install with at least two shops before you build out the real thing. Our module suites are written shop-context-aware from the data layer up. Relevant whether you run SEO management, invoicing or on-store content across your shops.

Does Multistore handle currencies, tax and hreflang per country for me?

No, Multistore handles the storefronts. Each shop gets its own default currency and enabled language set, but correctly localized currency display, tax-inclusive pricing per country, and hreflang across separate domains are separate jobs that sit on top. See selling across Europe for currency and tax, and hreflang tags for the cross-domain SEO signalling that core won't assemble across stores.

Related reading

• Multi-Language Store Setup. The right tool when you only need more languages, not more stores.
• Selling Across Europe, the currency, tax and OSS layer that Multistore doesn't solve on its own.
• Hreflang Tags. Cross-domain reciprocity is the hard case once each market has its own store.

The bottom line

Multistore is the right answer when your stores genuinely overlap, shared products, shared customers, shared stock, and you want to vary the storefront, the pricing and the branding deliberately on top of that shared core. It is the wrong answer for "I just need more languages" (use the built-in multilingual fields) and for genuinely separate businesses (use separate installations). Get the share-versus-separate decision right up front, respect the context selector religiously, verify your modules are shop-aware before you build, and Multistore turns three installations' worth of admin into one. The setup discipline is the price; the daily operational simplicity is what you buy.

For a step-by-step walkthrough of creating your first shop group and shop, see our How to Set Up PrestaShop Multistore knowledge base guide.