Multi-Website vs. Multi-Store in a Hyvä Theme: Choosing the Right Strategy

1. The core question: cart separation or just variants

In a lot of projects the choice between multi-website and multi-store gets treated as a pure theme question, when it's really a business logic question first. A separate website in Magento means a separate cart, a separate root category, and potentially a separate checkout flow. A store view inside the same website, on the other hand, shares its cart with every other store view of that website and usually only differs in language, currency, or catalog scope.

Anyone who only needs a second language variant of the same catalog rarely needs a second website, just an additional store view. Only once legal separation, country-specific pricing logic, or a fully separated B2B and B2C experience are required does the extra effort of a dedicated website with its own root catalog and checkout become justified.

2. Website, store, and store view: the technical difference

Magento's scope model has three levels: website as the top level with its own cart and its own root category, store as an organizational middle layer that rarely has technical effects of its own, and store view as the bottom level, usually tied to a language or market. Configuration values can be set at any of these three levels, with the store view level overriding the website level, which in turn overrides the global default.

For the theme decision, what matters is that the design/theme/theme_id setting can also be set at any of these levels. That means a Hyvä theme can be assigned globally across every website, per website, or even per individual store view, regardless of whether a second website exists at all. That flexibility is one of the reasons the theme question isn't automatically a website question.

bin/magento config:show design/theme/theme_id
bin/magento config:show design/theme/theme_id --scope=stores --scope-code=store_de
bin/magento config:show design/theme/theme_id --scope=websites --scope-code=base

3. When a separate website is actually needed

A dedicated website makes sense when customers shouldn't share a single cart experience across the two areas, for example because a B2C shop and a separate B2B wholesale area need different price lists, minimum order quantities, and payment methods. A separate website is likewise the right call when two domains have to operate as legally distinct entities, and a mixed cart across both areas would create data protection or tax problems.

Plain language switches, currency displays, or regional pricing tweaks within the same legal jurisdiction can almost always be handled with additional store views instead. The deciding test is whether a customer would plausibly expect to see products from both areas in the same cart. If the answer is yes, a store view is enough. If the answer is no, a dedicated website is the technically cleaner solution.

4. Theme assignment per scope level and its inheritance

A Hyvä theme can be assigned independently of the scope structure. In practice that means two websites can share the same Hyvä theme, while different store views inside a single website can still get different themes, for instance a dedicated B2B theme for one store view even though both belong to the same website. The inheritance follows the scope hierarchy strictly: a theme set at the store view level always wins over the website value or the default.

For developers, what matters is that every additional theme assignment at the store view level creates another theme-and-locale combination that has to be compiled and deployed separately. The scope structure itself doesn't force additional theme variety, but it enables it, and that possibility gets used in practice far more often than its downstream cost gets calculated up front.

5. Catalog price scope and its collision with the theme decision

An often-overlooked factor is the catalog/price/scope setting, which globally fixes either website-based or global price scope and can't be configured more granularly at the store view level. Switching this setting to website scope after multiple store views with different price requirements are already live in production requires a full reindex and, in many cases, a price migration.

This setting should therefore be part of every multi-website decision from the start, not something addressed only after a Hyvä theme is already live across several store views. Anyone who knows upfront that different price lists per website will be needed should configure price scope correctly at website setup time to avoid a costly migration later.

6. The impact on caching: cache key, FPC, and indexers

Magento's full page cache factors the store code into the cache context, so every additional store view automatically creates its own cache entries, regardless of whether it belongs to a dedicated website or just a plain store view. The real difference shows up at the indexer level: certain indexers, such as the price indexer, operate per website, so an additional website increases indexer runtime far more than an additional store view within an existing website does.

For a Hyvä setup running Redis as the cache backend, that translates into a concrete difference: more websites mean more parallel price indexer runs and potentially more cache fragmentation inside the Redis keyspace, while additional store views within the same website mostly grow the full page cache footprint but only moderately increase indexer load.

7. The deployment matrix: theme times locale times store

Every additional combination of theme and language has to be generated separately through static-content-deploy. With two websites, each with two store views and two different themes, the deployment matrix quickly grows to four or more combinations, each with its own build step and its own storage footprint under pub/static.

In practice it pays to estimate deployment time realistically before finalizing a multi-website decision, especially when the CI pipeline is already tight. An additional website with its own theme can noticeably lengthen static-content-deploy runtime, while an additional store view with the same theme only adds one more locale combination.

bin/magento setup:static-content:deploy \
  de_DE de_AT en_US \
  -t Mironsoft/default \
  -t Mironsoft/b2b \
  -f

8. A practical decision framework

A pragmatic approach starts with three questions: do customers expect a shared cart across both areas, do the price lists differ structurally and permanently, and is there a legal requirement for separate entities. If all three questions get a no, an additional store view within an existing website almost always suffices and saves substantial effort on caching, indexing, and deployment.

Only once at least one of those questions gets a yes does the extra effort of a dedicated website pay off. The added complexity shouldn't be underestimated, because it touches not just the theme but also price scope, indexer load, and the entire deployment pipeline equally.

9. Summary of the key differences

The table below sets the key technical and organizational differences between an additional store view and an additional website side by side, so the decision can be made against concrete criteria instead of a vague guess about future effort.

It matters that this decision is rarely fully reversible: converting a store view into a dedicated website later requires, among other things, a price scope change and usually a full reindex, which is why a clean upfront analysis pays off in every project.

10. Summary

11. FAQ: Multi-Website vs. Multi-Store: Key Facts at a Glance