How to Set Up PrestaShop Multistore: Complete Guide
Everything about PrestaShop Multistore — planning, configuration, catalog sharing, module behavior, SEO considerations, and common pitfalls.
What Is PrestaShop Multistore?
PrestaShop Multistore lets you run multiple online stores from a single installation and one back office. Shared codebase, shared database, shared module ecosystem, but separate storefronts for your customers. The feature has been in PrestaShop since version 1.5 and has matured significantly in 8.x and 9.x — though it still demands careful planning.
When You Actually Need Multistore
Multiple brands from one back office. You sell electronics under "TechDirect" and audio under "SoundElite." Both share your warehouse and some products, but each has its own site, theme, and pricing. Your team manages everything from one admin panel.
Different countries with separate catalogs. Your German and French stores share some products but differ in range, pricing, shipping rules, and CMS content. Multistore lets each shop maintain its own catalog while sharing the overlap.
B2B and B2C from one installation. Retail shows tax-included prices with standard shipping. Wholesale shows net prices, requires minimum quantities, and has negotiated rates. One product catalog, two completely different shopping experiences.
Outlet or clearance store. A separate storefront for discounted products with its own theme, drawing from the same product database.
When Multistore Is NOT the Answer
- Unrelated businesses: Pet supplies and industrial machinery share nothing. Separate installations are simpler.
- Different PS versions needed: Multistore requires all shops on the same version.
- Conflicting module requirements: If stores need incompatible modules, separate installations avoid conflicts.
- Risk isolation: A database issue in multistore affects all shops. Separate installations contain the blast radius.
- You only need multiple languages: PrestaShop handles multilingual natively within a single shop — no multistore needed.
Before enabling multistore, list what you want to share between shops and what must be separate. If the "shared" list is short and the "separate" list is long, you're better off with independent installations.
Planning Your Architecture
Store Groups
PrestaShop organizes multistore as Shop Group → Shop. Groups define sharing rules that are hard to change later:
- Share customers: Can a customer who registers on Shop A also log in to Shop B?
- Share available quantities: Does a sale on Shop A reduce stock visible on Shop B?
Shared vs. Separate Catalogs
Products can be associated with all shops or specific shops only. Even shared products can have different prices, descriptions, images, and SEO metadata per shop. Categories work the same way — shared or shop-specific, with per-shop names and descriptions.
URL Strategy
- Separate domains (
brand-a.com,brand-b.com) — best for distinct brands. Requires individual SSL certs or a multi-domain certificate. - Subdomains (
de.myshop.com,fr.myshop.com) — natural for regional variants. Can use a wildcard SSL cert. - Subdirectories (
myshop.com/wholesale/) — simplest setup, one SSL cert, but limits SEO flexibility.
Database Architecture
Multistore uses a single database with id_shop columns differentiating data. One backup covers all shops, but corruption also affects all shops and queries carry shop-filtering overhead.
Enabling and Configuring Multistore
Step 1: Enable the Feature
Go to Advanced Parameters → General (PS 1.7.x) or Advanced Parameters → Multistore (PS 8.x/9.x). Set Enable Multistore to Yes. A shop context selector appears in the back office header.
Step 2: Create a Shop Group
In Advanced Parameters → Multistore, click Add a new shop group. Set the group name and the sharing options (customers, quantities). Remember: these are hard to change later.
Step 3: Add a New Shop
Click Add a new shop. Choose the name, group, root category, and optionally import data from an existing shop to save setup time.
Step 4: Configure URLs
Click the shop name and add a URL. Examples:
# Separate domain
Domain: www.my-second-shop.com
Physical URI: /
Virtual URI: (empty)
# Subdomain
Domain: shop2.myshop.com
Physical URI: /
Virtual URI: (empty)
# Subdirectory
Domain: www.myshop.com
Physical URI: /
Virtual URI: wholesale/
Step 5: Server Configuration
For separate domains/subdomains, all domains must point to the same PrestaShop directory in your web server config. For virtual URLs (subdirectories), no extra server config is usually needed — PrestaShop handles routing via .htaccess.
After configuring URLs, always clear the PrestaShop cache. URL routing is cached aggressively, and stale entries cause redirect loops.
Managing Content Across Stores
The Shop Context Selector
The dropdown at the top of the back office controls which shop your changes apply to: All shops, a specific group, or a specific shop. The golden rule: always work in the most specific context possible. Editing in "All shops" when you meant to change one shop is the most common multistore mistake.
Configuration Inheritance
Values set in "All shops" become defaults. Individual shops can override them. In the configuration page, checkboxes next to fields control whether the field uses the inherited value or a shop-specific override. Uncheck to set a custom value for the current shop.
The inheritance checkbox behavior has changed between PrestaShop versions. Always test with your specific version to understand which state means "inherited" and which means "custom."
Products and Categories
Key behaviors:
- Creating a product in "All shops" context makes it available everywhere.
- Creating in a specific shop context limits it to that shop. You can associate it with others later.
- Disabling a product in one shop doesn't affect other shops.
- Deleting in "All shops" removes it permanently from everywhere.
- Stock behavior depends on group sharing settings.
Theme, Language, and Currency Per Shop
Each shop can have its own theme, its own set of enabled languages, and its own currencies. Select the shop context first, then configure in Design → Theme & Logo or International → Localization.
Module Behavior in Multistore
How Multistore-Aware Modules Work
A properly built module stores configuration per shop (using Configuration::updateValue() which respects shop context), checks Shop::getContextShopID() in hooks, and handles the "All shops" context correctly. The ps_configuration table stores per-shop values with an id_shop column.
Common Module Pitfalls
- Global-only config: Module saves settings without
id_shop— changing one shop changes all. - Hardcoded shop ID: Module assumes
id_shop = 1, ignoring secondary shops. - Missing shop filter in queries: Returns mixed data from all shops.
- Cache collisions: Cache keys without shop ID serve wrong shop's data.
Checking Module Multistore Support
- Does the description mention "multistore compatible"?
- Is there documentation on per-shop configuration?
- After installing, does the config page show inheritance checkboxes when in a specific shop context?
- Test: set different configs on two shops, verify both front ends reflect the difference.
A non-multistore-aware module won't necessarily break things — but all shops will share its settings. That may or may not be acceptable depending on the module's function.
SEO Considerations
Canonical URLs
Every page on every shop must have a canonical URL pointing to itself. Verify that a product on shop-a.com canonicalizes to shop-a.com, not shop-b.com. For identical content across shops, decide on one primary source and implement cross-domain canonicals.
Hreflang for Multi-Language Stores
If shops target different languages/regions, hreflang tags tell search engines which version to show each audience:
<link rel="alternate" hreflang="de" href="https://de.myshop.com/produkt" />
<link rel="alternate" hreflang="fr" href="https://fr.myshop.com/produit" />
<link rel="alternate" hreflang="x-default" href="https://www.myshop.com/product" />
PrestaShop handles hreflang for language variants within a single shop but not across separate shops. You'll need a module or template modifications for cross-shop hreflang. Tags must be bidirectional — if Shop A references Shop B, Shop B must reference Shop A.
Sitemaps and Duplicate Content
Each shop needs its own sitemap.xml with only its own URLs. Register each shop separately in Google Search Console. To avoid duplicate content penalties: customize product descriptions per shop, use canonical tags for shared content, and differentiate category pages with unique descriptions.
For multi-language shops on separate domains, hreflang tags are required, not optional. Without them, search engines may index the wrong language for each market.
Performance Implications
Multistore adds overhead in three areas:
- Configuration tables: N rows per setting (one per shop) instead of one. More data in every config lookup.
- SQL queries: Nearly every query gains a
WHERE id_shop = Xclause. Without proper indexes, this slows down as the database grows. - Cache footprint: Each shop has its own cache entries for templates, configs, and listings. Memory scales with shop count, and cache warm-up takes longer.
For Redis/Memcached, verify cache key prefixes include the shop ID to prevent cross-shop data leaks. Monitor the database with these queries:
# Check table sizes
SELECT table_name, ROUND(data_length/1024/1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'prestashop'
ORDER BY data_length DESC LIMIT 20;
# Find missing indexes on id_shop columns
SELECT t.table_name, c.column_name
FROM information_schema.columns c
JOIN information_schema.tables t
ON c.table_schema = t.table_schema AND c.table_name = t.table_name
WHERE c.table_schema = 'prestashop' AND c.column_name = 'id_shop'
AND c.column_name NOT IN (
SELECT column_name FROM information_schema.statistics
WHERE table_schema = 'prestashop' AND table_name = c.table_name
);
Common Multistore Problems
Products in the Wrong Shop
Cause: Product created in "All shops" context. Fix: Switch to the unwanted shop's context and disable/remove the product association. Verify with:
SELECT ps.id_product, ps.id_shop, ps.active
FROM ps_product_shop ps WHERE ps.id_product = 123;
Config Changes Affecting All Shops
Cause: You were in "All shops" context, or the module stores values globally. Check the storage:
SELECT id_shop, name, value FROM ps_configuration
WHERE name = 'MODULE_SETTING_NAME' ORDER BY id_shop;
If there's only one row with id_shop = NULL, the module stores globally. Contact the vendor or manually create per-shop entries.
Module Not Saving Per-Shop Settings
Cause: Module uses Configuration::updateGlobalValue() instead of Configuration::updateValue(). Requires a code fix in the module or a vendor update.
Mixed Cart Across Shops
Cause: Cookie domain set too broadly (e.g., .myshop.com instead of shop-a.myshop.com). Fix in Shop Parameters → General — set cookie domain to the specific subdomain per shop.
Import Putting Products in Wrong Shop
Cause: The import tool respects the current context. Always select the target shop before opening the import page. After importing, verify ps_product_shop entries.
Redirect Loops After Adding a Shop
Cause: Incorrect URL config or stale .htaccess. Fix: regenerate .htaccess from Performance settings, verify ps_shop_url entries, and ensure SSL config is consistent:
SELECT s.name, su.domain, su.domain_ssl, su.physical_uri, su.virtual_uri
FROM ps_shop s
JOIN ps_shop_url su ON s.id_shop = su.id_shop AND su.main = 1;
Multistore Maintenance Checklist
Weekly
- Verify each shop's storefront loads (no redirects, no errors)
- Check recent orders are assigned to the correct shop
- Test checkout flow on each shop
Monthly
- Audit product associations — any products in wrong shops?
- Review per-shop configs by switching to each context
- Check error logs per shop
- Verify sitemaps are current and accessible
- Test email delivery from each shop
- Monitor database size growth
After Module Updates
- Check the module config page in each shop context
- Verify front-end behavior per shop
- Confirm per-shop settings save independently
- Clear caches for all shops
After PrestaShop Updates
- Test all shops immediately — multistore regressions are common
- Re-check URL configuration
- Regenerate
.htaccess - Test full checkout on every shop
Final Thoughts
PrestaShop Multistore centralizes operations when it matches your needs, but adds complexity everywhere. The merchants who succeed treat it as an architecture decision, not a feature toggle. Plan it right, maintain it carefully, and always keep backups.
More guides available
Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.