Magento runs many storefronts from one installation through a four-level scope hierarchy: global, website, store, and store view. A website controls customers, currency, and payments and can carry its own domain. A store controls the catalog. A store view controls language. On Hyva, each store view can run its own theme, and a single Hyva license covers all the domains of one business entity.
For a brand running a US and an EU storefront, or a parent company with three sub-brands, this is the difference between one lean codebase and three separate builds to maintain. Done well, a multi-store Hyva development project shares one catalog, one admin, and one fast frontend. Done badly, it multiplies your cron, cache, and QA work without the benefit. This guide covers the scopes, the decisions, and what multi-store actually costs on Hyva.
The four scopes, and what each one controls
The whole system rests on understanding which setting lives at which level. Magento resolves configuration from the most specific scope up: a store view value overrides a store, which overrides a website, which overrides global. This four-level scope hierarchy is the backbone of every multi-store build.
| Scope | What it controls | Typical use |
|---|---|---|
| Global | Defaults for everything, base data | Product data, order statuses, base settings |
| Website | Customers, base currency, payment and shipping methods, prices | A separate brand or region with its own domain and accounts |
| Store (store group) | Root category, so the catalog and main menu | A distinct catalog under one website |
| Store view | Language and locale, storefront presentation | One language or currency display of a store |
The two that confuse teams most are website and store view. A website is a hard boundary: separate customers, separate carts, its own currency and payment methods, usually its own domain. A store view is a soft boundary: the same catalog and customers, presented in a different language. If a customer should log in once and see one account across two storefronts, those storefronts are store views under one website. If each storefront needs its own customers, currency, and checkout, they are separate websites.
Getting this boundary right at the start is the single most important architectural decision in a multi-store build, because moving a storefront from store view to website later means migrating customers and orders, which is expensive.
When to use each: a decision guide
Merchants usually arrive with a goal (multiple brands, multiple countries, B2B and B2C side by side) rather than a scope in mind. Here is how the common goals map to the structure.
- Multiple languages, one brand and catalog. Use one website, one store, multiple store views, one per language. Customers, prices, and catalog stay shared. This is the lightest setup.
- Multiple countries with different currencies and payments. Use multiple websites, one per country, so each has its own base currency, payment methods, and tax rules. Share the catalog at the product level and diverge pricing per website.
- Multiple distinct brands. Use multiple websites, one per brand, each with its own domain, theme, customers, and often a different catalog. This is the heaviest setup and the one that most resembles running separate stores.
- B2B and B2C from one catalog. Often a website split, so the B2B site can carry company accounts, shared catalogs, and net terms while the B2C site stays simple. Our Hyva for B2B guide covers how the B2B frontend differs.
A useful rule: diverge at the website level only when you must, because every website multiplies the operational surface. Where a store view will do, use a store view.
What multi-store means on a Hyva theme
Hyva changes almost nothing about how Magento scopes work, and a few things about how you build and license the frontend.
Theme per store view. You assign a theme in the admin under Content, then Design Configuration, per store view. Most of the settings that diverge across storefronts live in the same admin configuration surface, which Adobe documents in its store configuration guide. Each store view can run a different Hyva theme or a child theme of a shared parent. So your EU store view can look different from your US one while both inherit a common Hyva base. This is the mechanism that lets multiple brands share a codebase and still look distinct.
Licensing across domains. A Hyva license covers one Magento installation and its store views and domains, as long as they belong to the same business entity. So a parent company running several brand domains off one install is covered by a single license. Confirm the current terms for your situation, but the model is designed for exactly this multi-store case rather than charging per domain.
One Tailwind build, or several. This is the practical Hyva decision. If your brands share a design language, you build one Hyva parent theme and thin child themes per store view, so the Tailwind build and component library stay shared. If brands are visually unrelated, you may build separate themes, which multiplies the frontend build and maintenance. Most multi-brand groups are better served by a shared parent theme with per-brand tokens (colors, fonts, spacing) than by fully separate themes.
Per-store content and CMS. Blocks, pages, and design still scope per store view, so localized content, currency formatting, and brand-specific homepages all work the way they always have, now rendered in Alpine and Tailwind instead of Luma.
The performance and operations reality
The appeal of one installation is a shared catalog, admin, and infrastructure. The cost is that some heavy operations scale with the number of scopes, and you need to plan for it.
- Reindexing and cron scale with store views. Price, catalog, and search indexes are per scope, so a store with ten store views reindexes more than a single-store site. Keep indexers on Update on Schedule and watch queue health, because a stuck reindex now affects every storefront.
- Full page cache multiplies. Each store view caches separately, so your cache warming and Varnish sizing have to account for the total page count across all storefronts, not one. Plan cache memory accordingly.
- Images and CDN. A shared catalog means shared product images, which is efficient, but a CDN in front of all storefronts is close to mandatory at multi-store scale to keep Largest Contentful Paint low across regions.
- Deployment is all-or-nothing. One install means one deploy affects every storefront. That raises the value of a proper staging environment and a release pipeline you can actually audit, so a change for one brand does not break another.
None of this is a reason to avoid multi-store. It is a reason to size the infrastructure and the build pipeline for the real scope count from the start, rather than discovering the cost after the third brand goes live.
Multi-store SEO: avoid competing with yourself
Running several storefronts off one catalog raises duplicate-content and targeting questions that a single store never faces.
Use hreflang tags to tell search engines which store view serves which language and region, so your EU English and US English pages are understood as regional variants rather than duplicates. Set the correct base URL per website, and keep canonical tags scoped correctly so each store view points at its own canonical, not a sibling’s. If two websites sell overlapping products to overlapping audiences, be deliberate about which one should rank for a given query, because otherwise your own storefronts split the traffic. This is the same self-cannibalization risk that good Magento development planning heads off before launch.
Where this fits in a platform decision
Magento’s multi-store model is one of its genuine strengths, and a reason merchants with several brands or regions stay on Adobe Commerce rather than running a separate store per brand elsewhere. The Bemeir technology partners ecosystem connects a multi-store install to the payment, tax, and ERP systems each region needs, and the about Bemeir page covers the team that has shipped these builds as the first US Hyva Gold Partner.
Platform still matters. A group of genuinely independent brands with no shared catalog sometimes fits better as separate stores, where Shopify or BigCommerce can be simpler per brand, while Shopware has its own sales-channel model for multi-store. When the brands share a catalog, customers, or operations, one Magento install with Hyva is usually the leaner answer. For the build side of running several storefronts cleanly, our Magento and Hyva CI/CD pipeline guide covers deploying one install without breaking any brand. If you are weighing a multi-store build, that architecture conversation is exactly what Bemeir exists to get right the first time.
FAQ
What is the difference between a website, a store, and a store view in Magento?
A website is the top boundary: it controls customers, base currency, payment and shipping methods, and usually a domain. A store (store group) sits under a website and controls the catalog through its root category. A store view sits under a store and controls language and locale. Website is a hard boundary with separate customers; store view is a soft boundary sharing them.
Do I need separate websites or just store views for different languages?
For different languages of the same brand and catalog, use store views under one website. Customers, prices, and catalog stay shared, and it is the lightest setup. Use separate websites only when you need different customers, currencies, payment methods, or catalogs, such as for different countries or distinct brands.
Can each store run a different theme on Hyva?
Yes. You assign a theme per store view under Content, then Design Configuration. Each store view can run a different Hyva theme or a child of a shared Hyva parent, so brands can look distinct while sharing one codebase. A shared parent theme with per-brand tokens is usually better than fully separate themes.
Does a Hyva license cover multiple domains and stores?
A Hyva license covers one Magento installation, including its store views and domains, when they belong to the same business entity. A parent company running several brand domains off one install is generally covered by a single license. Confirm the current terms for your specific structure, since the model is built for the multi-store case.
Does running multiple stores slow Magento down?
It adds operational load rather than inherently slowing pages. Reindexing, cron, and full page cache scale with the number of store views, so you size infrastructure for the total scope count and keep indexers on Update on Schedule. A CDN in front of all storefronts keeps Core Web Vitals low across regions. Well-provisioned, a Hyva multi-store site stays fast.
How do I avoid duplicate content across multiple stores?
Use hreflang to mark regional and language variants, set the correct base URL per website, and scope canonical tags so each store view points at its own canonical rather than a sibling’s. Where two storefronts target overlapping queries, decide deliberately which should rank, so your own stores do not split the traffic.
Multi-store is where Magento earns its complexity. The scope hierarchy is powerful, but the boundary decisions made on day one shape every deploy, index, and cache warm afterward. Get the website-versus-store-view calls right, share a Hyva parent theme across brands, and size the infrastructure for the real scope count, and one install can run a whole portfolio fast. That is the architecture work Bemeir does before the first storefront goes live.
