PrestaShop multistore is one of the most misunderstood features in open-source e-commerce. It promises a way to run several storefronts from a single administration panel, sharing catalog, customers and orders where it makes sense while keeping each brand or region distinct. For retail groups juggling multiple fascias, cross-border expansion or a wholesale arm alongside a consumer shop, that promise is genuinely valuable. It is also, done wrong, a fast route to a fragile platform that nobody wants to maintain.
This guide explains what PrestaShop multistore actually does, when it is the right architecture, and where retail teams routinely trip up. It is written for operators and technical decision makers who need to weigh multistore against alternatives such as separate installs or a full replatform. If you are still deciding on your core stack, start with our broader guide on how to choose the right e-commerce platform for your store and then come back here once PrestaShop is on your shortlist.
In short
- Multistore lets one PrestaShop install run many storefronts that can share or separate catalog, customers, carriers, prices and content, all managed from a single back office.
- It fits retail groups with shared operations: multiple brands, country-specific shops, or a B2B and B2C split that draw on the same warehouse, team and product data.
- It is not free scale: a single database, shared modules and one theme codebase mean one store’s problem can become every store’s problem.
- The biggest mistakes are structural, not technical: mixing shops that have nothing in common, or splitting shops that should have stayed one, then paying for the mismatch for years.
- Plan the group and shop hierarchy first, decide what is shared at each level, and pressure-test performance and tax handling before you migrate a single real order.
Why this topic matters in 2026
Retail groups rarely run one brand anymore. A mid-market operator might have a heritage fascia, a younger direct-to-consumer line, a clearance outlet and a trade shop, each with its own audience but the same buyers, warehouse and finance team behind the scenes. Running four disconnected websites for that reality is expensive and slow. Every price change, every new module, every security patch has to be repeated four times.
PrestaShop multistore exists to collapse that overhead. It has been a native part of the platform for years, and by 2026 it is mature enough that plenty of European and cross-border retailers rely on it in production. The renewed interest is partly cost driven. Teams are consolidating tooling, cutting the number of separate hosting bills and admin logins, and looking hard at whether they really need five installs when one could serve.
At the same time, cross-border selling has become table stakes. A retailer that sells only domestically is leaving demand on the table, and running a localized shop per country, with the right language, currency, tax rules and carriers, is far easier inside a multistore setup than as a set of parallel installs. That combination, cost pressure plus internationalization, is why the topic keeps resurfacing in platform decisions. For a wider read on where the platform sits today, see our take on PrestaShop in 2026 and whether it is still a real option in Europe.
Who is actually asking about it
Three profiles dominate. First, established retail groups with several brands who are tired of duplicated work. Second, growing single-brand shops that want to launch country-specific storefronts without cloning their whole setup. Third, businesses adding a wholesale or B2B channel that needs different pricing and access rules but the same products.
Each of these has a genuine case for multistore. The failures tend to come from a fourth group: teams that reach for multistore because it sounds efficient, without a shared operational backbone to justify it. That is the pattern this guide is built to help you avoid.
Key terms and definitions
Multistore introduces vocabulary that trips up newcomers, so it is worth getting the concepts straight before any configuration. The whole system is built on a hierarchy, and understanding the levels is most of the battle.
A shop group is the top-level container. Shops inside the same group can share customers, carriers and orders. Shops in different groups are effectively walled off from each other, which is what you want when two brands should never mingle their customer data.
A shop is a single storefront: one brand, one country, or one channel. It has its own domain or subdirectory, its own theme selection, and its own set of enabled products and categories drawn from the shared catalog.
The catalog is shared at the database level but exposed per shop. A product exists once, and you choose which shops display it, at what price, with what stock behavior. This is the feature that makes multistore worthwhile: you maintain one product record, not four.
Shared versus per-shop settings
Almost every setting in PrestaShop can be set at one of three scopes: all shops, a shop group, or a single shop. This is the mental model that matters most. When you edit a setting, you first pick the context you are editing, then change the value.
Get this wrong and you will change a price or a tax rule globally when you meant to change it for one country. The context selector at the top of the back office is small and easy to ignore, and that single UI detail is behind a large share of multistore accidents.
URL structure options
Each shop needs its own address. PrestaShop supports two models: a separate domain per shop (brand-a.com, brand-b.com), or a subdirectory of one domain (yourgroup.com/brand-a). Domains suit distinct brands that need their own identity and SEO footprint. Subdirectories suit closely related shops, such as language variants, where consolidating authority under one domain helps.
This choice is harder to reverse than it looks, so treat it as an architecture decision rather than a preference. Switching a live shop from a subdirectory to its own domain later means a full redirect map and a temporary dip in search visibility. Decide based on how independent each shop’s brand and search presence really need to be, not on what is quickest to set up on day one.
Stock and inventory scope
Stock is one of the most consequential settings, because it determines whether your shops compete for the same units or hold separate pools. PrestaShop can share a single stock figure across shops or keep quantities independent per shop, and the right answer depends entirely on your fulfillment model.
If every shop ships from one warehouse, shared stock prevents overselling and keeps availability honest across brands. If shops map to different warehouses or regions, per-shop stock reflects reality more accurately. Getting this wrong causes either phantom stockouts or oversells that end in cancelled orders, so decide it deliberately alongside the catalog scope.
How it works in practice
Enabling multistore is a single switch in the back office under advanced parameters. What happens after that switch is where the real work lives. Turning it on reveals the context selector and the shop management screens, but it does not design your architecture for you.
The first real decision is your group and shop layout. Sketch it before touching the admin panel. Draw the shops you need, then decide which belong in the same group because they should share customers and orders, and which must be isolated in their own group. This diagram is the single most important artifact in a multistore project.
Once shops exist, you assign the catalog. For each product you decide which shops sell it and at what price. PrestaShop handles this through per-shop associations, so a winter coat can appear in your Nordic shop at one price and your Southern European shop at another, or be hidden entirely where it does not sell. Categories work the same way, letting each storefront present a different structure over the same underlying products.
Carriers, taxes and payment
Shipping and tax are where multistore earns its keep for cross-border sellers. Carriers can be assigned per shop, so your German storefront offers German couriers and your French one offers French ones. Tax rules follow the shop’s country, which is essential for compliance across the European Union where VAT rates and rules differ by member state.
Payment modules are also configurable per shop, letting you offer locally trusted methods in each market. A shopper in one country may expect a wallet or bank-transfer option that means nothing in another. Multistore lets you match local expectations without maintaining separate installs.
Themes and content
Each shop selects its own theme, and content such as CMS pages, banners and category descriptions can be set per shop. In practice most retail groups run a shared base theme with per-shop styling and logos rather than wholly separate designs, because maintaining several distinct themes reintroduces the duplication multistore was meant to remove.
This is a recurring tension. The more you customize each shop, the less you benefit from the shared foundation. The teams that succeed treat divergence as a cost to be justified, not a default. If your brands genuinely demand radically different experiences, that is a signal multistore may be the wrong tool, a point we return to below.
Common mistakes and how to avoid them
Multistore rewards planning and punishes improvisation. The failures are predictable, which means they are avoidable. Here are the ones that cost retail teams the most.
Forcing unrelated brands into one install. If two brands share no operations, no warehouse, no team and no customers, they do not belong in the same multistore. You gain nothing and inherit a shared database, shared modules and shared downtime. The rule of thumb: multistore is for shops that share a backbone, not shops that merely belong to the same owner.
Ignoring the context selector. The most common day-to-day error is editing a setting in the wrong scope. Someone updates a price meaning to change one shop and changes it everywhere, or the reverse. Train everyone with back-office access to check the context indicator before every change, and lock down who can edit at the all-shops scope.
Underestimating the shared database
All shops in a multistore live in one database and run on one codebase. That is the source of the efficiency and the source of the risk. A slow query, a heavy module or a spike in traffic on one shop can degrade every shop. A bad module update breaks all of them at once.
Plan capacity for the sum of your shops, not the average. Test performance under combined load before launch, and be disciplined about modules: every module you add runs across the whole install. When you are choosing add-ons, weigh them as carefully as you would on a single high-traffic store, and lean on vetted options such as those in our roundup of the best PrestaShop modules for a serious store.
Treating migration as a copy-paste
Moving existing separate shops into a multistore is not a data dump. Customer records may overlap, product references may collide, and URL structures change, which threatens SEO. Map every redirect, deduplicate customers deliberately, and run the migration on a staging copy with real data before you go near production. Rushing this step is how teams end up with broken links and lost search rankings on day one.
Examples from US retail and e-commerce
PrestaShop’s center of gravity is Europe, but the multistore pattern maps cleanly onto how US retail groups are structured, and the lessons travel. Consider a US apparel group that owns a premium label and a value label sold through separate sites. Both draw from the same distribution center and the same merchandising team. That is a textbook shared backbone, and a single multistore serving two shops removes an enormous amount of duplicated catalog and inventory work.
Now take a US brand expanding into Canada and Mexico. Rather than standing up three unrelated sites, one multistore with a shop per country handles the different currencies, tax treatments and carriers while the core catalog stays unified. Product launches propagate everywhere at once, and reporting rolls up cleanly because the orders share one system.
A third pattern is the B2B and B2C split that many US wholesalers face. The consumer shop shows retail prices and standard checkout, while the trade shop, in a separate group, gates access to approved buyers, shows contract pricing and offers purchase-order style payment. Same products, same warehouse, two very different front doors, one install to maintain.
The common thread across all three examples is that the operations were already shared before multistore entered the picture. The warehouse, the buying team and the product data existed as one function serving several outward faces. Multistore simply made the software match the org chart. When teams try to run it the other way around, using multistore to force integration onto operations that are genuinely separate, the friction never goes away.
A cautionary example
Consider a group that acquired a second brand and rushed both into one multistore to look efficient on paper. The brands used different suppliers, different fulfillment partners and different customer service teams. Within months, every module decision became a negotiation between two teams that shared nothing operationally, and a performance issue on the larger brand repeatedly took the smaller one offline. They eventually split the install, paying twice: once to merge and once to unmerge. The lesson is blunt. Shared software should follow shared operations, never the reverse.
When US teams choose something else
Plenty of US retailers on PrestaShop’s scale end up on hosted platforms instead, and that is a legitimate outcome. If your priority is minimal operational overhead and you are comfortable with a closed ecosystem, a SaaS platform’s native multi-storefront features may serve with less maintenance. The trade-off is control and cost at scale. For a concrete head-to-head that many operators weigh, our comparison of PrestaShop versus WooCommerce for European SMB stores lays out the same open-source trade-offs that apply just as much to US teams.
Tools, partners and vendors worth knowing
A multistore project rarely succeeds on core PrestaShop alone. The ecosystem around it fills the gaps, and knowing what to reach for saves months of custom work. The categories below are where retail groups spend their integration budget.
Hosting and infrastructure. Because every shop shares one server footprint, hosting is not a place to economize. Managed PrestaShop hosting that understands the platform’s caching and database load will pay for itself. We cover what to actually look for in our guide to PrestaShop hosting requirements without the vendor pitch.
Product information and feeds. Once you sell the same catalog across shops and marketplaces, a product information management layer keeps data consistent, and feed tools push each shop’s assortment to channels like comparison engines and marketplaces. If any of your shops feed into large marketplaces, the same discipline applies as anywhere else in commerce, and our overview of tools and vendors for Amazon in 2026 is a useful reference for that channel work.
Modules and integrators
The official PrestaShop marketplace covers most multistore needs, from advanced pricing to multi-warehouse stock. Vet modules for explicit multistore support, since not every add-on respects the per-shop context, and one that ignores it can quietly corrupt data across shops. Prefer modules that state multistore compatibility and have recent updates.
For anything beyond configuration, a PrestaShop-certified agency is worth the cost on a group project. Multistore migrations, custom pricing logic and performance tuning are specialist work, and the price of getting the architecture wrong dwarfs the fee for getting it right the first time.
Monitoring and reporting
Once several shops share one install, you need reporting that can both roll up and break down. Group-level dashboards tell you how the whole portfolio is performing, while per-shop views catch a single storefront underperforming before it drags on the total. Native PrestaShop stats cover the basics, but most groups layer an analytics platform on top with a distinct property or view per shop.
Set this up before launch, not after. Retrofitting per-shop tracking onto a live multistore means reprocessing historical data and reconciling numbers that never lined up, which erodes trust in the figures at exactly the moment leadership starts asking whether the consolidation paid off. Clean, shop-aware reporting from day one is how you prove the business case.
Comparison: multistore versus separate installs
| Factor | PrestaShop multistore | Separate installs |
|---|---|---|
| Catalog maintenance | One product record shared across shops | Duplicated per install |
| Updates and patches | Applied once for all shops | Repeated per install |
| Isolation | Shared database, shared risk | Fully isolated, one failure stays local |
| Hosting cost | Single footprint, lower total | Multiple bills, higher total |
| Customization freedom | Constrained by shared codebase | Unlimited per shop |
| Best for | Shops sharing operations | Truly independent businesses |
Comparison: which shops belong together
| Scenario | Same shop group | Separate group | Separate install |
|---|---|---|---|
| Country variants of one brand | Yes | No | No |
| Two brands, shared warehouse and team | Sometimes | Yes | No |
| B2B and B2C of same catalog | No | Yes | No |
| Brands with nothing in common | No | No | Yes |
| Radically different tech needs | No | No | Yes |
A working playbook for retail groups
If you have decided multistore fits, the sequence below keeps projects out of trouble. It front-loads the decisions that are expensive to reverse and defers the ones that are cheap to change. Work through it in order, because several later steps depend on choices locked in earlier, and treat each step as a gate that must pass before the next begins.
- Map the group and shop hierarchy on paper before any configuration, deciding what is shared at group level and what is isolated.
- Decide catalog scope per shop: which products, which categories, which prices, and where stock is shared or separate.
- Set carriers, taxes and payment per shop to match each market’s rules and buyer expectations, and validate tax handling with real transactions on staging.
- Choose a shared base theme with per-shop styling, and justify every deviation rather than defaulting to bespoke designs.
- Load-test the combined footprint and audit every module for multistore compatibility before launch.
- Migrate on staging with real data, map all redirects, and only cut over production once search and checkout are verified end to end.
Follow that order and multistore behaves. Skip the early steps and you will spend the project retrofitting decisions that should have been made on day one. As with any platform choice, the architecture you pick up front shapes what your team can do for years, which is why it pays to revisit the fundamentals in our guide on how to choose the right e-commerce platform for your store before committing.
Frequently asked questions
Is PrestaShop multistore free to use?
Yes. Multistore is a native feature of the open-source PrestaShop software at no extra license cost. Your real costs are hosting, any premium modules you add, and the development time to configure and maintain the setup, all of which scale with the number and complexity of your shops.
How many shops can one PrestaShop install handle?
There is no hard technical limit, but practical limits arrive well before any theoretical one. Most stable production setups run a handful to a couple of dozen shops. Beyond that, the shared database and codebase make performance tuning and testing progressively harder, and separate installs may become the saner choice.
Can each shop have its own domain?
Yes. PrestaShop supports a separate domain per shop or subdirectories under one domain. Use distinct domains for brands that need their own identity and search presence, and subdirectories for closely related shops such as language variants where consolidating domain authority helps.
Do shops share customers and orders?
It depends on the shop group. Shops in the same group can share customers, carriers and orders, while shops in different groups are isolated. You control this through your group structure, which is exactly why mapping that hierarchy first is so important.
Can I set different prices per shop?
Yes. Prices are configurable per shop, so the same product can sell at different prices across brands or countries. You can also run per-shop specific prices, discounts and currency settings, which is essential for cross-border selling where markets bear different price points.
Is multistore good for cross-border selling?
It is one of the strongest reasons to use it. Per-shop language, currency, tax rules, carriers and payment methods let you run a properly localized storefront per country while maintaining one catalog. That removes most of the duplication that makes cross-border expansion painful on separate installs.
Will migrating to multistore hurt my SEO?
Only if you rush it. URL structures change during migration, so unmanaged redirects can lose rankings. Map every old URL to its new one, implement permanent redirects, and verify on staging before cutover. Handled carefully, migration is SEO-neutral and sometimes positive when you consolidate authority under one domain.
When should I choose separate installs instead?
Choose separate installs when shops share no operations, need radically different technology or customization, or when full isolation between them matters more than shared maintenance. If a problem on one shop must never touch another, separate installs give you that guarantee at the cost of duplicated work.