Multi-store setup in Magento 2 — architectuur en valkuilen

Multi-store setup in Magento 2 — architectuur en valkuilen

Eén Magento-installatie die vijf webshops aanstuurt. Op papier elegant. In de praktijk een architectuurkeuze met verstrekkende gevolgen voor performance, beheer en internationaliseringskosten.

De meeste problemen bij multi-store setups ontstaan niet bij de implementatie. Ze ontstaan zes maanden later, als je een prijsactie wil inrichten voor één markt maar merkt dat je structuur dat niet toelaat.

Dit artikel legt de architectuur uit. Inclusief de valkuilen die we bij klanten tegenkomen.

Wat je leert in dit artikel

• De hiërarchie van website, store en store view in Magento 2
• Wanneer je kiest voor multi-store versus aparte installaties
• Shared catalog en de impact op performance
• Internationalisering: talen, valuta en belastingregels
• Concrete configuratie-aanpak met codevoorbeelden

De drie-laags hiërarchie

Magento 2 werkt met drie niveaus. Veel developers begrijpen dit oppervlakkig, maar de implicaties zijn diepgaand.

Global (installatie)
└── Website A (NL)
│   ├── Store A1 (standaard)
│   │   ├── Store View: Nederlands
│   │   └── Store View: Engels
└── Website B (DE)
    ├── Store B1 (standaard)
        └── Store View: Duits

De valkuil: scope-misverstanden

Magento-configuratie kent de begrippen "global", "website" en "store view" scope. Een instelling op global niveau geldt voor alles. Een instelling op website niveau overschrijft de global waarde voor die website.

// Lees een config waarde op store view scope
$configValue = $this->scopeConfig->getValue(
    'general/locale/code',
    \Magento\Store\Model\ScopeInterface::SCOPE_STORE,
    $storeId
);

// Lees op website scope
$websiteValue = $this->scopeConfig->getValue(
    'payment/mollie/active',
    \Magento\Store\Model\ScopeInterface::SCOPE_WEBSITE,
    $websiteId
);

De valkuil: je past een instelling aan in de admin terwijl je een store view geselecteerd hebt. Magento slaat die waarde op voor die store view. Later snap je niet waarom de instelling op andere store views anders is.

Controleer altijd op welke scope je werkt. De URL in de admin bevat store/[id]/ als je op store view scope zit.

Multi-store versus aparte installaties

Dit is een strategische keuze die we te vaak te laat zien worden gemaakt.

De scheidslijn is operationeel: als marketing in Duitsland volledig autonoom moet kunnen werken zonder afhankelijk te zijn van een centrale deployment, zijn aparte installaties cleaner.

Multi-store klinkt efficiënt maar verhoogt de complexiteit van elke wijziging. Een template-aanpassing moet werken voor alle stores. Een extensie-update raakt alle markets tegelijk.

Shared catalog en B2B

Voor B2B multi-store setups is de Shared Catalog module relevant. Hiermee wijs je specifieke catalogi toe aan klantgroepen, inclusief klantspecifieke prijzen.

De performance-impact is merkbaar. Shared Catalog voegt joins toe aan vrijwel elke productquery.

// Shared catalog koppelen aan klantgroep via code
$sharedCatalog = $this->sharedCatalogManagement->getPublicCatalog();
$this->sharedCatalogManagement->assignCustomerGroups(
    $sharedCatalog,
    [$customerGroupId]
);

Benchmarks die wij zien: categoriepagina's laden 40-60% trager in installaties met Shared Catalog en meer dan 50.000 producten, zonder aanvullende caching strategie. Full Page Cache (FPC) dempt dit effect, maar vraag je af of je die complexiteit wil toevoegen als een andere architectuurkeuze het probleem vermijdt.

Internationalisering in de praktijk

Drie elementen die je vroeg moet inrichten: talen, valuta en belastingregels.

Talen en vertalingen

Magento haalt vertalingen op uit CSV-bestanden per module. Voor een taalwissel per store view volstaat dit in veel gevallen.

# app/i18n/Vendor_Module/nl_NL.csv
"Add to Cart","Toevoegen aan winkelwagen"
"In stock","Op voorraad"
"Out of stock","Uitverkocht"

Productnamen en -beschrijvingen zijn store view-specifiek. Je beheert ze in de producteditor door de store view te wisselen. Dit werkt prima voor kleine catalogi. Bij 10.000+ producten wordt dit een importoperatie.

Valuta en prijzen

Prijzen in Magento zijn per website ingesteld. Je kunt de basisvaluta van de installatie instellen en automatisch omrekenen, maar wij raden dit af voor productieomgevingen. Gebruik altijd handmatig ingestelde prijzen per website.

Automatische omrekening fluctueert met wisselkoersen. Dat geeft klantenservice-problemen als een klant een prijs ziet die morgen anders is.

Belastingregels per markt

Elke markt heeft eigen btw-regels. Configureer deze via Stores > Tax Rules. Per rule koppel je een productklasse, klantklasse en belastingpercentage aan een geografische zone.

Voorbeeld voor NL B2C:
- Tax Rule: NL B2C 21%
- Customer Tax Class: Retail Customer
- Product Tax Class: Taxable Goods
- Tax Rate: Netherlands 21%
- Zone: Netherlands (postcode: *)

Vergeet niet dat digitale diensten binnen de EU onder het OSS-systeem (One Stop Shop) vallen. Dit heeft implicaties voor rapportage die buiten Magento native worden afgehandeld.

Performance bij multi-store

Elke store view voegt overhead toe aan cache-generatie. Magento genereert per store view aparte cache-entries voor pagina's en blocks.

Een installatie met 5 store views genereert 5x zoveel cache-entries als een single-store. Dit heeft impact op:

• Full Page Cache grootte: zorg dat je Varnish of Redis genoeg geheugen heeft
• Index-duur: reindex-jobs lopen voor elke store view
• Deploy-tijd: static content deploy genereert assets per store view en taal

# Static content deployen voor specifieke locales
php bin/magento setup:static-content:deploy nl_NL de_DE en_US -j 4

# Reindex uitvoeren
php bin/magento indexer:reindex catalog_product_price catalog_category_product

# Cache-grootte inspecteren
redis-cli info memory | grep used_memory_human

Wij zien in de praktijk dat een multi-store setup met vier store views de deploy-tijd verdubbelt tot verdriedubbelt ten opzichte van single-store. Plan dit in je deployment pipeline.

Veelgemaakte fouten

Als je Nederland en Duitsland in één website stopt met elk een store view, deel je betaalconfiguratie. Je kunt dan geen aparte betaalmethoden per markt instellen. Gebruik aparte websites voor aparte markten.

Wat op global scope staat, geldt voor alle websites. Pas dat aan voor één website en je hebt een override op website scope nodig. Dit stapelt zich op tot een ondoorzichtige configuratiematrix.

Een bulk-import zonder store_view_code kolom schrijft data naar de default store view, niet naar de beoogde taal. Voeg altijd de store view scope toe aan je importbestand.

sku,name,store_view_code
PROD-001,"Fietshelm rood",nl_NL
PROD-001,"Fahrradhelm rot",de_DE

Activeer Shared Catalog nooit zonder benchmarks op een representatieve dataset. De query-overhead is direct merkbaar op categoriepagina's.

Conclusie

Multi-store in Magento 2 is krachtig, maar de architectuurkeuzes aan het begin bepalen hoeveel vrijheid je later hebt. De website-store-store view hiërarchie is geen detail — het is het fundament van je beheer- en internationaliseringslogica.

Neem de tijd om dit goed in te richten voordat je begint met producten importeren. Eenmaal live is een herstructurering van de store-hiërarchie een grootschalige operatie.

Wij helpen regelmatig bij het opzetten of saneren van multi-store configuraties. Bekijk onze Magento 2 diensten of neem contact op als je voor deze keuze staat. De officiële Adobe Commerce documentatie bevat de volledige referentie voor multi-store configuratie.