Magento is one of the few mainstream e-commerce platforms that treats “more than one store” as a first-class structural concept rather than an add-on. That is a genuine advantage if you sell into several countries or run several brands off one codebase. It is also the reason so many Magento projects end up with a structure nobody can explain two years later.
The core of a Magento multi store setup is a three-level hierarchy: website, store, store view. Those three words sound interchangeable. They are not. Each one sits at a different configuration scope, and the scope you pick determines which prices, which catalog, which currency, which tax rules and which URLs a customer sees. Change your mind later and you are looking at data migration, not a settings toggle.
This piece walks the decisions in the order you actually have to make them, before the build starts. If you are still choosing between platforms rather than configuring one, start with our broader guide on how to choose the right e-commerce platform for your store and come back when Magento is confirmed.
In short
- Website is the scope that owns customer accounts, the root catalog and the base currency. It is the heaviest boundary and the hardest to undo.
- Store groups store views under one root category. It is an organisational layer with almost no customer-visible effect of its own.
- Store view is the language and presentation layer. One view per language per market is the normal pattern.
- Price scope is a global setting with two values, global or website, and it quietly decides whether you can price differently per country at all.
- Hreflang and canonicals are the step teams skip. Without reciprocal annotations, several near-identical store views compete with each other in search instead of serving different markets.
Websites, stores and store views defined
Magento’s hierarchy is strict. A single installation contains one or more websites. Each website contains one or more stores. Each store contains one or more store views. Configuration values can be set at the default (global) level and then overridden at website level, store level or store view level, depending on the setting.
The practical skill is knowing which settings can be overridden where. Base currency is website scope. Locale is store view scope. Product price is either global or website scope, depending on one global switch. Inventory, in a default single-source install, is global. Those four facts alone decide most architectures.
What website scope actually controls
Website is the boundary for customer accounts, the shopping cart, the root catalog assignment and the base currency. By default, a customer account is shared across the whole installation, but you can set account sharing to per-website, which means an account created on your German website does not exist on your French one.
That single choice has downstream consequences for support, for loyalty programmes and for email marketing. Teams that split accounts per website often discover later that their customer service tooling assumes one account per person. Decide deliberately, and write the decision down.
Where stores earn their keep
The store level is the one people struggle to justify. Its job is to own the root category, which is the top of the category tree a set of store views will render. If your German and Austrian views should show the same category tree, they belong under the same store. If your outlet brand needs a completely different tree, it needs its own store.
Most installations end up with one store per website and treat the level as ceremonial. That is fine. Do not invent stores you have no catalog reason for, because every extra node multiplies the configuration surface you have to test.
Store views and the language layer
Store views are what customers switch between. A view carries its own locale, its own translated content, its own CMS blocks, its own display currency and its own theme assignment. This is where you put language. It is not where you put a different product range, because catalog visibility at view level is a per-product flag you have to maintain by hand.
A reliable pattern for a European rollout: one website per currency zone, one store per catalog tree, one store view per language. If you sell in Belgium in both Dutch and French, that is one website, one store, two views.
| Setting | Lowest scope available | What this means in practice |
|---|---|---|
| Base currency | Website | Separate currencies require separate websites, not just views |
| Display currency | Store view | You can show a converted price without splitting websites |
| Product price | Global or website (one switch) | Country-specific pricing is impossible until price scope is set to website |
| Locale and translations | Store view | Language is cheap to add once the structure is right |
| Root category | Store | A different category tree is the only real reason to add a store |
| Customer account sharing | Global switch, per-website option | Decided once, painful to reverse after launch |
| Theme | Store view | Per-market branding does not need a second website |
How should you structure URLs for each country?
Magento can serve store views from path segments, from subdomains or from entirely separate domains. The platform does not care much. Search engines and your operations team care a great deal, and they tend to want different things.
Subfolders on one domain
Serving example.com/de/ and example.com/fr/ from one domain concentrates all of your link equity and authority on a single host. It is the cheapest option to run: one certificate, one DNS record, one CDN configuration, one set of analytics properties if you want it that way.
The cost is that geotargeting becomes a signal you have to send through hreflang and content language rather than through the domain itself. For most mid-market retailers this trade is worth making, and it is the default we would argue for unless something specific overrides it.
Subdomains per market
Subdomains such as de.example.com sit awkwardly in the middle. They give you cleaner operational separation, including the option of different hosting regions, but they fragment some of the signals that a single host would have pooled. They also double your certificate and redirect surface.
Pick subdomains when there is a technical or organisational reason, for example a regional team that owns its own infrastructure, rather than because they feel tidier.
Separate country domains
Country-code domains such as example.de send the strongest possible geotargeting signal and carry real trust weight with shoppers in markets where local domains are the norm. They are also the most expensive path: each domain builds authority from zero, and each needs its own monitoring, certificates and legal pages.
Running ccTLDs from one Magento installation is entirely possible. You point each domain at the same application and map it to a website or store view through the base URL settings. The engineering is not the hard part; the marketing budget to make five domains rank is.
| Approach | Geotargeting strength | Authority consolidation | Operational overhead | Best fit |
|---|---|---|---|---|
Subfolders (/de/) |
Moderate, via hreflang | Strongest, one host | Lowest | Most multi-country retailers |
Subdomains (de.) |
Moderate | Partial | Medium | Regional teams with separate stacks |
Country domains (.de) |
Strongest | None, each starts fresh | Highest | Mature brands with per-market budgets |
| One domain, language switcher only | Weak | Strongest | Lowest | Single-market sites with bilingual audiences |
Worth noting: this decision is not unique to Magento. Shopify merchants face a structurally identical choice, which we unpacked in Shopify Markets versus separate stores for selling in two countries. The reasoning transfers; only the configuration screens differ.
Shared catalog or separate catalogs?
Once the hierarchy is set, the next question is how many times you want to maintain a product. The honest answer for most teams is once, and the structure should bend to make that possible.
The shared catalog default
In a standard setup, products live in one catalog and are assigned to one or more websites. Attributes marked as global hold one value everywhere. Attributes marked as store view scope, which typically includes name, description and meta fields, hold a different value per view. That is exactly what you want for translation.
This default gets you a long way. One product, one SKU, one set of images, seven translated descriptions. Inventory stays consistent because, in a single-source install, stock is tracked globally rather than per website.
When separate catalogs are the right call
Separate catalogs make sense when the product ranges genuinely diverge: different suppliers, different compliance requirements, different brands that must never appear alongside each other. Regulated categories are the clearest case, because a product that cannot legally be listed in one market should not merely be hidden there.
The warning sign that you have over-split is a spreadsheet that maps SKUs between catalogs. If that file exists, you have created a reconciliation job that will outlive everyone involved.
Multi-source inventory as the middle path
Magento’s multi-source inventory lets you keep one catalog while assigning stock to different sources and linking sources to stocks, and stocks to websites. A German warehouse and a Polish warehouse can serve the same SKU with different availability. This is usually a better answer than duplicating the catalog, and it is the option teams forget exists.
For a sense of where Magento sits relative to the hosted alternatives before you commit to this complexity, our analysis of Magento in 2026 and who still needs Adobe Commerce is the honest version.
Currency, tax and price scope per store
This is the section where architectures quietly fail. Two settings do most of the damage, and both live at global level even though their effects are per-market.
Price scope: the switch that decides everything
Magento has a single configuration value, catalog price scope, with two options: global or website. Global means a product has one price across the entire installation. Website means each website holds its own price for each product.
If you launch with global price scope and later need different prices in different countries, you can change the setting, but every product then needs per-website prices populated. On a 40,000 SKU catalog that is a data project with a reindex at the end of it. Set this before you load the catalog, not after.
Base currency versus display currency
Base currency is the currency your orders are stored and reported in, and it sits at website scope. Display currency is what the shopper sees, and it sits at store view scope with an exchange rate applied. The two are often conflated, and the difference matters for accounting.
Showing a converted price with a live rate is convenient and looks cheap to implement. It also produces prices ending in awkward fractions and moves them without warning when rates shift. Most serious cross-border retailers set deliberate price points per market instead, a discipline we covered in country price lists that survive currency swings.
Tax configuration, and what to verify elsewhere
Magento’s tax engine works on tax classes, tax rates tied to country and region, and tax rules that combine the two. Tax rates are global records; which rules apply, and whether prices are shown including or excluding tax, is configurable down to store view. That gives you enough flexibility to display gross prices in a European view and net prices in a business-to-business view of the same catalog.
What Magento cannot tell you is which obligations you actually have. Whether you need to register in a given market, whether an EU-wide scheme such as the VAT One Stop Shop applies to your sales, and what the registration thresholds are, are questions answered by the European Commission’s taxation and customs pages, by the relevant national tax authority, or in the United States by individual state revenue departments following the economic nexus standards that developed after the Supreme Court’s 2018 South Dakota v. Wayfair decision. Thresholds, rates and filing deadlines change, often annually, so treat any figure you find in a blog post, including this one, as a prompt to check the official source rather than as a current rate.
A reasonable division of labour: your advisor determines where you owe tax and at what rate, and your Magento configuration reflects that determination. Do not let the platform’s defaults become the policy by accident.
Who maintains the translations?
Language in Magento lives in three different places, and the ownership question is different for each. Teams that skip this discussion end up with a German store view that is 80 percent translated forever.
Where translated strings actually live
Interface strings, meaning the buttons, labels and system messages, come from language packs installed as Composer packages and from CSV translation dictionaries in the theme. Catalog content, meaning product names, descriptions and meta fields, lives in the database at store view scope. Marketing content, meaning CMS pages and blocks, is a separate per-view record.
These three layers are maintained by three different kinds of people: developers, merchandisers and marketers. Pretending one person covers all three is how partial translations happen.
A workflow that survives staff turnover
The pattern that holds up: install a community or vendor language pack for the interface layer so nobody is hand-translating “Add to Cart”; export catalog attributes per store view to a translation vendor on a scheduled cadence; and keep CMS content in a documented list so a new hire can see at a glance which pages exist in which languages.
Build a report, even a crude one, that counts products with an untranslated name per store view. A number on a dashboard gets fixed. An unmeasured gap does not.
Machine translation as a floor, not a ceiling
Automated translation is now good enough for long descriptions on low-value SKUs, and it is a defensible way to launch a market before you know whether it will pay. It is not good enough for the twenty pages that carry your commercial message, and it is a liability on anything with safety, sizing or compliance language.
Getting hreflang and canonical tags right
A multi-language Magento install produces a large number of near-duplicate pages by design. The same product, nineteen times, with a translated description. Search engines handle this well when you tell them what is going on and badly when you do not.
The reciprocity rule
Hreflang annotations declare that a set of URLs are alternate language or regional versions of each other. According to Google’s documentation on localized versions of a page, the annotations must be reciprocal: if page A points to page B as an alternate, page B must point back to A, and every page in the set should list every other page including itself.
Magento can emit these automatically for store views, but only for views you have configured as alternates, and third-party extensions vary in how correctly they do it. Validate the output on a real product page and a real category page, in both directions, before you declare the job done.
Do not forget x-default
The x-default value marks the page to serve when no listed language or region matches the user. A global English view, or a market selector page, is the usual choice. Omitting it is not fatal, but it leaves the engine to guess for every visitor outside your mapped markets.
Canonicals across store views
The common failure is a canonical tag that points from a store view back to the default view. That tells search engines the translated page should not be indexed at all, which is precisely the opposite of the intent. Each store view’s pages should be self-canonical, with hreflang describing the relationship between them.
Magento’s own canonical settings for categories and products operate at store view scope, so check them per view rather than assuming the default carried over. Also confirm that layered navigation and sort parameters are not generating indexable duplicates in every language at once, because the problem multiplies by the number of views you run.
Admin permissions across multiple brands
If your installation serves several brands or several country teams, the admin side needs the same thought as the storefront. Magento Open Source gives you admin roles with resource-level permissions, which controls what a user can do but not which website’s data they can see.
Restricting an administrator to a specific website, so that a Spanish merchandiser sees Spanish orders and nothing else, is a feature of the commercial edition rather than the open source one. That single line item is a recurring reason teams end up on Adobe Commerce, and it belongs in the licence conversation early. We compared the two editions feature by feature in Magento Open Source versus Adobe Commerce.
Practical mitigations on open source
If you are staying on open source, the usual mitigations are process rather than technology: narrow roles by function, separate the merchandising workflow into a product information management tool that does support per-brand access, and keep an audit log extension installed so mistakes are attributable. None of these are as clean as scope restriction, and you should be honest with stakeholders about that.
Two-factor authentication and shared logins
Magento ships two-factor authentication for the admin and enables it by default. Multi-brand teams are the ones most tempted to work around it with shared accounts, because onboarding five agencies is tedious. Shared admin logins destroy your audit trail at exactly the moment you need it, so budget the onboarding time instead.
What a wide store view matrix costs to operate
Every website, store and store view you add multiplies something. Understanding what, before you commit to twelve views, is the difference between a platform that scales and a deploy pipeline that takes an hour.
Static content deployment
Magento compiles theme assets per store view and per locale during static content deployment. Twelve views in six locales is a meaningfully longer build than one view in one locale, and that time appears in every production release. Teams running wide matrices usually move to parallel static deployment and accept a longer pipeline as the price of the structure.
Indexing and cache
Indexers write per-store data, so reindex duration grows with the number of store views and with catalog size at the same time. Full page cache is also partitioned by store view, which means your cache hit rate is spread across more variants and a cold cache after a deploy is colder than it looks on a single-view site.
The testing matrix nobody budgets for
The honest cost is quality assurance. A checkout change has to be verified in every currency, every tax configuration and every payment method combination you run, and the number of combinations grows faster than the number of views. Decide early which views are tier one, and test those exhaustively rather than testing everything badly.
These operating costs rarely appear in the initial quote, which is why the full picture only shows up in year two. Our breakdown of total cost of ownership for Magento puts numbers around the hosting, maintenance and agency lines, and the pattern holds: the structure you choose in week one sets the bill for the next three years.
A build-order checklist
- Decide catalog price scope (global or website) before any product data is imported.
- Decide customer account sharing (global or per-website) before any customers exist.
- Map markets to websites by currency, then to stores by catalog tree, then to views by language.
- Choose the URL structure and register the domains, because changing it later means a redirect map.
- Configure base URLs per scope and confirm each one resolves over HTTPS with its own certificate.
- Set locale, display currency and tax display per store view, then have an advisor confirm the tax policy itself.
- Install language packs, then validate hreflang and canonicals on a product page and a category page per view.
- Define admin roles and, if scope restriction is required, confirm which edition supplies it.
One caveat before you act on any of this. Everything above is general information about how Magento is structured and what the trade-offs tend to be, not legal, tax or customs advice. Cross-border selling touches registration obligations, consumer law and import rules that differ by market and change regularly, so for your own situation take the architecture questions to a Magento solution specialist and the tax and compliance questions to a licensed customs broker, trade attorney or tax advisor before you rely on a configuration. The platform will happily let you set something that is wrong for your jurisdiction. Magento, now maintained as Adobe Commerce and the Magento Open Source project, is a toolkit, not a compliance product.
For the wider platform picture, including when a multi-store build is the wrong answer entirely, our guide to choosing the right e-commerce platform covers the alternatives side by side.
FAQ on Magento multi-store
Do I need separate websites or just separate store views?
Use separate store views when the difference is language, theme, displayed currency or translated content. Use separate websites when the difference is base currency, per-country product pricing, or a requirement that customer accounts and carts do not cross markets. Base currency and website-scope pricing are the two hard triggers for a second website.
Can one Magento installation serve several different domains?
Yes. You map each domain to a website or store view through its base URL configuration and point the DNS at the same application. The usual complications are certificate coverage for every hostname, cookie domain configuration so sessions behave, and making sure the web server passes the correct host header through to Magento.
Is inventory shared between websites?
In a default single-source installation, stock is tracked once and shared across every website and view. If you need different availability per market, multi-source inventory lets you assign sources to stocks and stocks to websites while keeping one catalog. Duplicating the catalog to achieve the same thing creates a reconciliation problem you do not need.
How many store views is too many?
There is no hard limit, but the practical ceiling is set by static content deployment time, reindex duration and your testing capacity rather than by the software. Teams running more than roughly a dozen views usually need parallel asset deployment and a tiered QA policy. If you cannot name an owner for a view’s content, that view is already too many.
Does a multi-store setup hurt SEO through duplicate content?
Not if the annotations are right. Near-identical pages in different languages are expected and handled, provided hreflang annotations are reciprocal and complete and each store view’s pages are self-canonical. The damage comes from canonicals pointing across views, missing reciprocity, or layered navigation parameters generating indexable duplicates in every language simultaneously.
Can I restrict an admin user to one website only?
Resource-level admin roles exist in Magento Open Source, but restricting a user’s visibility to a specific website or store view is a feature of the commercial Adobe Commerce edition. On open source the workarounds are procedural: narrow roles by function, move merchandising into a system that supports per-brand access, and keep an audit log so actions are attributable.
Should prices be converted automatically or set manually per market?
Automatic conversion from a base currency is quick to launch and acceptable for low-value or long-tail items. Manual price points per market give you clean psychological pricing, protect your margin when rates move, and avoid prices changing without a commercial decision behind them. Most retailers selling seriously in a market move to manual price lists within the first year.
What is the single most expensive mistake to fix later?
Catalog price scope. Launching on global price scope and later needing per-country prices means populating website-level prices for every product in the catalog, followed by a full reindex. Customer account sharing is a close second, because changing it after launch means deciding what happens to accounts that already exist in more than one market.
Where do I verify the tax and VAT rules for a new market?
Go to the primary source rather than to platform documentation. For the European Union, the European Commission’s taxation and customs pages and the relevant national tax authority; in the United Kingdom, HM Revenue and Customs; in the United States, the individual state revenue departments, since obligations follow state-level economic nexus rules. Rates and thresholds change, so confirm the current figures at the point of registration and have an advisor review your specific position.