Magento’s multi-store architecture is one of its genuine superpowers - and one of its most misunderstood. A single installation can run multiple brands, countries and languages with shared or separate catalogs, carts and customers. The whole model hangs on three levels: websites, stores and store views. Getting the hierarchy right at the start is cheap; fixing it later is not.
The Three Levels
Website - the top level. A website has its own:
- customers (customer accounts can be scoped per website or shared globally)
- base currency, payment methods, shipping methods
- prices and tax configuration
- separate shopping carts and orders
Store - a catalog partition within a website. Stores share the website’s customers and checkout, but have their own root category - their own navigation and product structure. One website with a “Retail” store and an “Outlet” store, different root categories, shared cart, is a classic pattern.
Store View - a presentation variant of a store: typically language. Same catalog, same prices, translated interface and content. English/French/German views of one German store is the canonical example.
The rule of thumb: different prices or customers = website; different catalog = store; different language = store view.
Scope Inheritance
Nearly every configuration value in Magento can be set at default, website or store view scope, with lower scopes inheriting unless overridden. This is powerful and treacherous in equal measure:
- Check the scope switcher (top-left in admin config) before changing anything - editing “Default Config” when you meant one website is a classic incident
- Catalog attributes have their own scope (global/website/store view): a store-view-scoped description can be translated; a global SKU cannot
- “Use Default Value” checkboxes are inheritance made visible - untick only with intent
Planning a Multi-Country Setup
For a typical UK merchant expanding to EU and US:
- Websites per region when tax, currency or legal entity differs (UK website with GBP and UK VAT; EU website with EUR and EU VAT; US website with USD)
- One store per website unless you genuinely partition catalogs
- Store views per language within each store
Domain mapping: each website/store view gets its own base URL (example.co.uk, example.de), set in web server config via the MAGE_RUN_CODE / MAGE_RUN_TYPE environment variables.
The Costs to Respect
Multi-store is not free:
- Every website multiplies price and stock index dimensions - a 50k SKU catalog with 4 websites indexes like 200k
- Content management effort scales with store views unless you use shared CMS blocks carefully
- Some extensions licence per store view - check before buying
- Admin complexity rises; document which team owns which website’s config
The architecture is worth it: one codebase, one deployment pipeline, shared products where useful, separation where required. Model the hierarchy from the business structure - entities, catalogs, languages - not from what seems convenient today, and the setup will carry you from two storefronts to twenty.