Multi-Website vs. Multi-Store im Hyvä-Theme: Die richtige Strategie wählen

1. Die Grundfrage: Warenkorb-Trennung oder nur Varianten

Die Entscheidung zwischen Multi-Website und Multi-Store wird in vielen Projekten fälschlich als reine Theme-Frage behandelt, dabei ist sie zuerst eine Frage der Geschäftslogik. Eine eigene Website in Magento bedeutet einen eigenen Warenkorb, eine eigene Root-Kategorie und potenziell einen eigenen Checkout-Flow. Eine Store View innerhalb derselben Website teilt sich dagegen den Warenkorb mit allen anderen Store Views derselben Website und unterscheidet sich meist nur in Sprache, Währung oder Katalogausschnitt.

Wer nur eine zweite Sprachvariante desselben Sortiments benötigt, braucht in aller Regel keine zweite Website, sondern lediglich eine zusätzliche Store View. Erst wenn rechtliche Trennung, unterschiedliche Preislogik pro Land oder eine vollständig getrennte B2B- und B2C-Erfahrung gefordert sind, rechtfertigt das den zusätzlichen Aufwand einer eigenen Website mit eigenem Root-Katalog und eigenem Checkout.

2. Website, Store und Store View: der technische Unterschied

Magentos Scope-Modell besteht aus drei Ebenen: Website als oberste Ebene mit eigenem Warenkorb und eigener Root-Kategorie, Store als organisatorische Zwischenebene, die selten eigene technische Auswirkungen hat, und Store View als unterste, meist sprach- oder marktbezogene Ebene. Konfigurationswerte lassen sich auf jeder dieser drei Ebenen setzen, wobei die Store-View-Ebene den Wert der Website-Ebene überschreibt und diese wiederum den globalen Default-Wert.

Für die Theme-Entscheidung ist relevant, dass die Konfiguration design/theme/theme_id ebenfalls auf jeder dieser Ebenen gesetzt werden kann. Das bedeutet, ein Hyvä-Theme lässt sich global für alle Websites, pro Website oder sogar pro einzelner Store View festlegen, unabhängig davon, ob überhaupt eine zweite Website existiert. Diese Flexibilität ist einer der Gründe, warum die Theme-Frage nicht automatisch eine Website-Frage ist.

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. Wann eine getrennte Website wirklich nötig ist

Eine eigene Website lohnt sich, wenn Kunden zwischen den Bereichen keine gemeinsame Warenkorb-Erfahrung erwarten sollten, etwa weil ein B2C-Shop und ein separater B2B-Großhandelsbereich unterschiedliche Preislisten, Mindestbestellmengen und Zahlungsarten benötigen. Ebenso ist eine eigene Website sinnvoll, wenn zwei Domains rechtlich als getrennte Rechtseinheiten auftreten müssen und ein gemischter Warenkorb aus beiden Bereichen datenschutz- oder steuerrechtlich problematisch wäre.

Reine Sprachwechsel, Währungsanzeigen oder regionale Preisanpassungen innerhalb desselben Rechtsraums lassen sich dagegen fast immer über zusätzliche Store Views abbilden. Der entscheidende Test ist die Frage, ob ein Kunde plausibel Produkte aus beiden Bereichen im selben Warenkorb erwarten würde. Ist die Antwort ja, reicht eine Store View. Ist die Antwort nein, ist eine eigene Website die technisch sauberere Lösung.

4. Theme-Zuweisung je Scope-Ebene und ihre Vererbung

Ein Hyvä-Theme lässt sich unabhängig von der Scope-Struktur zuweisen. In der Praxis bedeutet das: Zwei Websites können dasselbe Hyvä-Theme nutzen, während innerhalb einer Website unterschiedliche Store Views trotzdem unterschiedliche Themes bekommen können, etwa ein eigenes B2B-Theme für eine Store View, obwohl beide zur selben Website gehören. Die Vererbung folgt dabei streng der Scope-Hierarchie: Ein an der Store-View-Ebene gesetztes Theme gewinnt immer gegenüber dem Website- oder Default-Wert.

Für Entwickler ist wichtig, dass jede zusätzliche Theme-Zuweisung auf Store-View-Ebene eine weitere Kombination aus Theme und Locale erzeugt, die eigenständig kompiliert und deployt werden muss. Die Scope-Struktur selbst erzwingt also keine zusätzliche Theme-Vielfalt, aber sie ermöglicht sie, und diese Möglichkeit wird in der Praxis häufig genutzt, ohne die Folgekosten vorher zu kalkulieren.

5. Catalog Price Scope und die Kollision mit der Theme-Entscheidung

Ein oft übersehener Faktor ist die Einstellung catalog/price/scope, die global entweder Website- oder globalen Preis-Scope festlegt und sich nicht auf Store-View-Ebene granularer konfigurieren lässt. Wird diese Einstellung erst nachträglich auf Website-Scope umgestellt, nachdem bereits mehrere Store Views mit unterschiedlichen Preisanforderungen produktiv liefen, ist ein vollständiger Reindex und in vielen Fällen eine Preis-Migration notwendig.

Diese Einstellung sollte deshalb am Anfang jeder Multi-Website-Entscheidung mitgedacht werden, nicht erst, wenn bereits ein Hyvä-Theme für mehrere Store Views produktiv im Einsatz ist. Wer von vornherein weiß, dass unterschiedliche Preislisten pro Website benötigt werden, sollte den Preis-Scope direkt beim Website-Setup korrekt konfigurieren, um eine spätere, aufwendige Migration zu vermeiden.

6. Auswirkungen auf Caching: Cache-Key, FPC und Indexer

Der Full Page Cache in Magento berücksichtigt den Store-Code als Teil des Cache-Kontexts, sodass jede zusätzliche Store View automatisch eigene Cache-Einträge erzeugt, unabhängig davon, ob eine eigene Website oder nur eine Store View dahintersteht. Der entscheidende Unterschied liegt bei den Indexern: Bestimmte Indexer wie der Preis-Indexer arbeiten Website-bezogen, sodass eine zusätzliche Website die Indexer-Laufzeit deutlich stärker erhöht als eine zusätzliche Store View innerhalb einer bestehenden Website.

Für ein Hyvä-Setup mit Redis als Cache-Backend bedeutet das konkret: Mehr Websites erzeugen mehr parallele Preis-Indexer-Läufe und potenziell mehr Cache-Fragmentierung im Redis-Keyspace, während zusätzliche Store Views innerhalb derselben Website vor allem den Full-Page-Cache-Bestand vergrößern, aber die Indexer-Last nur moderat erhöhen.

7. Die Deployment-Matrix: Theme mal Locale mal Store

Jede zusätzliche Kombination aus Theme und Sprache muss über static-content-deploy einzeln generiert werden. Bei zwei Websites mit jeweils zwei Store Views und zwei unterschiedlichen Themes wächst die Deployment-Matrix schnell auf vier oder mehr Kombinationen, jede mit eigenem Build-Schritt und eigenem Speicherbedarf unter pub/static.

In der Praxis lohnt es sich, die Deployment-Zeit vor der endgültigen Multi-Website-Entscheidung realistisch einzuschätzen, insbesondere wenn die CI-Pipeline ohnehin schon knapp bemessen ist. Eine zusätzliche Website mit eigenem Theme kann die static-content-deploy-Laufzeit spürbar verlängern, während eine zusätzliche Store View mit demselben Theme nur eine zusätzliche Locale-Kombination hinzufügt.

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

8. Ein praktischer Entscheidungsrahmen

Ein pragmatischer Ansatz beginnt mit drei Fragen: Erwarten Kunden einen gemeinsamen Warenkorb über beide Bereiche hinweg? Unterscheiden sich die Preislisten strukturell und dauerhaft? Gibt es eine rechtliche Notwendigkeit für getrennte Rechtseinheiten? Werden alle drei Fragen mit Nein beantwortet, reicht eine zusätzliche Store View innerhalb einer bestehenden Website nahezu immer aus und spart erheblichen Aufwand bei Cache, Indexierung und Deployment.

Erst wenn mindestens eine dieser Fragen mit Ja beantwortet wird, lohnt sich der Mehraufwand einer eigenen Website. Die zusätzliche Komplexität sollte dabei nicht unterschätzt werden, denn sie betrifft nicht nur das Theme, sondern auch Preis-Scope, Indexer-Last und die gesamte Deployment-Pipeline gleichermaßen.

9. Zusammenfassung der wichtigsten Unterschiede

Die folgende Tabelle stellt die wichtigsten technischen und organisatorischen Unterschiede zwischen einer zusätzlichen Store View und einer zusätzlichen Website gegenüber, damit die Entscheidung anhand konkreter Kriterien getroffen werden kann statt anhand einer vagen Einschätzung des künftigen Aufwands.

Wichtig ist, dass diese Entscheidung selten vollständig reversibel ist: Eine nachträgliche Umwandlung einer Store View in eine eigene Website erfordert unter anderem eine Anpassung des Preis-Scopes und meist einen vollständigen Reindex, weshalb sich die frühzeitige, saubere Analyse in jedem Projekt auszahlt.

10. Zusammenfassung

11. FAQ: Multi-Website vs. Multi-Store: Das Wichtigste auf einen Blick