¶ Multiple domains - separate domains for languages and B2B
Multiple domains in Hummerce let you run several web addresses (domains) for a single store - e.g. a separate domain for a foreign version, your own brand, or B2B sales - on a shared panel, item catalog and customer base. Every domain leads to the same application and the same database, but can have its own starting language and its own set of views.
As of Hummerce 2.34 (shared login and cart between domains in newer browsers, several views on one domain), updated 2026-09-29.
¶ Benefits and use cases
- A separate domain for a foreign or language version - without building a separate store and a separate customer base.
- A separate domain for your own brand or sub-brand, sold from the same catalog and panel as the main brand.
- A separate domain for B2B sales (e.g.
b2b.example.com) alongside the retail store, with a different set of views.
- Shared customer login and cart between domains in the same group - a customer doesn't log in again after moving to a different domain.
- One application, one panel and one database for all domains - orders, customers and items are visible in one place regardless of which domain they were created on.
¶ Domains in store configuration
Every domain has:
- a primary address and a list of aliases - visiting an alias redirects (301) to the domain's primary address,
- a language that a new session on that domain starts in (regardless of the customer's browser settings),
- a list of views allowed on the domain, and the domain's default view,
- a domain group - domains in the same group share customer login and cart.
Visiting an address that is not one of the configured domains or aliases redirects to the store's main address.
¶ Views and language on a domain
- Optionally: when a customer's current view isn't allowed on the domain, the store switches them to the domain's default view.
- Optionally: when a customer changes language, the store redirects them to the domain assigned to that language.
- A link to another language version leads straight to that version's domain.
- A view's currency and language work independently of the domain - the domain only decides which views are available on it, and the starting language of a new session.
¶ Shared login and cart between domains
- Domains in the same group share customer login and cart.
- The mechanism relies on one-time tokens passed between domains at login, and on a cookie valid for 30 days that recognizes the customer on their next visit to another domain in the group - it also works in browsers that block third-party cookies (Safari, Firefox, newer Chrome).
- This requires all domains to be served by a single application server (one instance). In an environment with several servers and no shared sessions, a customer will need to log in separately on each domain.
| Area |
Who and where |
| Domains, aliases, languages, domain views, domain groups |
module configuration in the store, by the implementation team - not in the panel |
| DNS records for all domains and aliases |
the domain owner - all domains point to the same server |
| SSL certificates for every domain and alias |
the server admin or hosting provider |
| Web server configuration (routing domains to the store application) |
the server admin or hosting provider |
- The multiple domains module - in the platform's code since version 2.27.
- Shared login and cart between domains in browsers that block third-party cookies - from version 2.33-2.34.
- Several views on one domain, and a domain's default view - from version 2.34.
- The multiple domains module - not turned on in the standard configuration; we enable it during implementation.
- Shared login and cart between domains - a separate module, requiring the multiple domains module with domain groups configured.
- Views - a domain only restricts which views are available on it.
- A single application server instance for shared login and cart between domains - an environment with several servers and no shared sessions will not provide this.
- DNS and SSL certificates for all domains and aliases - outside the store, on the hosting side.
- Requires implementation - the module has no panel settings; every domain change is configuration in the store's files. Scope:
- configuring domains, aliases, languages and views in the store,
- setting up DNS for all domains and aliases to point to the store's server (on the client's side or their domain provider's),
- SSL certificates for every domain and alias, and web server configuration (on the hosting side),
- testing moving between domains, login and cart,
- going live.
- Minimum estimated time: from 8 h for two domains, excluding server- and hosting-side work (DNS, certificates, web server configuration - quoted and delivered separately).
- What the time depends on:
- the number of domains and aliases,
- the number of languages and views assigned to the domains,
- whether shared login and cart between domains is needed,
- the store's version - an older version needs an update first (quoted separately).
- No panel settings - every domain, alias or view-assignment change is work for the implementation team.
- The module does not generate hreflang tags or a separate sitemap for each domain - search engines get the canonical domain indication through a different mechanism.
- The store does not manage domains' DNS or SSL certificates - that's the hosting provider's job.
- Shared login and cart require a single application server instance - in an environment with several servers and no shared sessions, a customer logs in separately on each domain.
- One-time login tokens between domains are valid only briefly (30 seconds by default) - large network delays between domains can make a token expire before it's used.
- We do not verify the task for legal compliance (e.g. licenses of transferred materials, GDPR, the store's terms of service).
- Hreflang tags and a sitemap per domain.
- Domain configuration in the panel instead of in implementation files.
Can every language version of the store have its own domain?
Yes - the multiple domains module assigns a domain a starting language and a list of allowed views, with a shared catalog and panel.
Does a customer have to log in separately on every domain?
No, if the domains are in the same group - shared login and cart rely on one-time tokens and a cookie valid for 30 days, including in browsers that block third-party cookies.
Does multiple domains have panel settings?
No - domain, alias and view configuration is part of the implementation, not the panel.
Is every domain indexed separately by search engines?
Partly. The module does not generate hreflang tags or a separate sitemap per domain - see Limitations.
How long does implementing multiple domains take?
From 8 h for two domains, excluding server- and hosting-side work (DNS, certificates, web server configuration).
Do all domains share the same customer and order database?
Yes - all domains are one application and one database, with a shared panel, catalog, customers and orders.
Want to check whether multiple domains fits your store? Book a free demo (in Polish).
- None. Domains, aliases, languages, domain views and domain groups are configured by the implementation team in the store's configuration files - not in the admin panel.
¶ REST API and MCP
- No operations on domains in the REST API or through the AI assistant (MCP) - domain configuration is always implementation work.