Multi-Brand-Magento auf einem Frontend: Ein Showcase

Wenn du ein Marken-Portfolio auf Magento oder Adobe Commerce betreibst, kennst du das Muster: Jede Marke bekommt ihr eigenes Theme, ihren eigenen Frontend-Backlog und ihren eigenen Release-Zyklus. Ein neuer Kampagnen-Hero, der bei Marke A live geht, erreicht Marke B erst nach einem zweiten Build. Dieser Showcase zeigt, wie das Setup aussieht, wenn ein einziges geteiltes Frontend alle Marken bedient, ohne Rebuild pro Marke und ohne Migration weg von Magento. Den Konsolidierungs-Fall haben wir schon in ein Frontend für mehrere Magento-Shops beschrieben; hier zeigen wir die Architektur in der Praxis.

Das Showcase-Setup: drei Marken, ein Frontend-Layer

Damit es konkret bleibt, stell dir ein illustratives Portfolio vor: eine Mittelstands-Gruppe mit drei Consumer-Marken. Alle drei sitzen auf demselben Magento-Backend, abgebildet in Magentos nativer Hierarchie aus Websites, Stores und Store Views. Historisch trug jede Marke ein separates Frontend-Theme, also wurde eine geteilte Funktion wie eine Größentabellen-Komponente oder ein neues Checkout-Upsell dreimal gebaut. Das Ziel des Showcases ist einfach: das Magento-Backend genau so lassen, wie es ist, und einen geteilten Frontend-Layer vor alle drei Marken-Storefronts setzen.

Die Zahlen und Marken hier sind illustrativ, gewählt, um die Mechanik zu zeigen, nicht um ein bestimmtes Kundenergebnis zu berichten.

Die Architektur: geteiltes Frontend, viele Store Views

Das geteilte Frontend verbindet sich mit Magentos GraphQL-API und liest die bestehende Struktur aus Websites, Stores und Store Views direkt aus. Jede Marken-Storefront wird auf eine Store View gemappt, sodass Katalog-Scope, Preise, Währung und Sprache dort bleiben, wo sie in Magento bereits liegen. Am Produktdatenmodell ändert sich nichts.

Was sich ändert, ist der Präsentations-Layer. Statt drei parallel gepflegter Themes gibt es eine Komponenten-Bibliothek und ein Content-Modell, mit einem Marken-Kontext, der pro Request aufgelöst wird. Wer auf der Domain von Marke A landet, bekommt die Theme-Tokens, den Katalog-Scope und den Content von Marke A, alles aus demselben Frontend-Deployment. Das ist das Frontend as a Service-Betriebsmodell, angewendet auf ein Marken-Portfolio: Die Storefront wird zentral komponiert und betrieben, auf dem Commerce-Backend, das du bereits einsetzt. Der Headless-Frontend für Magento 2- und der Adobe-Commerce-Pfad sind dieselbe Architektur, sie unterscheiden sich nur darin, welche Backend-Edition die Daten liefert.

Marken-Theming: eine Komponenten-Bibliothek, Tokens pro Marke

Im Theming-Layer zeigt sich der Multi-Brand-Nutzen. Jede Marke ist ein Token-Set: Farben, Typografie, Abstände, Logo und Bild-Regeln, dazu markenspezifische Komponenten-Varianten. Eine Produktkarte ist eine Komponente in der Bibliothek; Marke A rendert sie mit ihren eigenen Tokens, Marke B mit ihren, und keine Marke braucht dafür eine geforkte Komponente.

So bleibt Design-Konsistenz durchsetzbar statt nur angestrebt. Wenn die Gruppe die Größentabellen-Komponente aktualisiert, landet die Änderung einmal und jede Marke erbt sie, jeweils in ihrer eigenen visuellen Identität. Brand Consistency wird zur Eigenschaft der geteilten Bibliothek statt zur manuellen Checkliste, die pro Theme wiederholt wird. Tiefer in die Design-Token-Mechanik sind wir in Brand Consistency über Multi-Brand-Storefronts gegangen.

Geteilte Komponenten, markenspezifische Daten

Eine geteilte Komponente ist keine festgezurrte Komponente. Jede Marken-Storefront bindet dieselbe Komponente an ihre eigenen Daten und Inhalte. Der Hero auf der Startseite ist über die Marken hinweg derselbe Baustein, aber Kampagne, Bildwelt und Text werden pro Marke im Content-Modell gesetzt. Die Produktliste liest den Store-View-Scope jeder Marke, sodass Katalog und Preise korrekt bleiben, ohne Code pro Marke.

Das praktische Ergebnis: Eine Marketerin, die an Marke B arbeitet, komponiert eine Landing-Page aus der geteilten Bibliothek, im Theme von Marke B, mit dem Katalog von Marke B, ohne Dev-Ticket und ohne die anderen beiden Marken anzufassen. Diese Editor-Kontrolle über ein Portfolio hinweg ist der Kern von Multi-Brand und Multi-Market aus einem System, und das Ein-System-Modell haben wir in Multi-Brand und Multi-Market aus einem einzigen System durchgespielt.

Governance: Wer besitzt was

Viele Marken aus einem Frontend zu betreiben bleibt nur mit klaren Zuständigkeiten handhabbar. Im Showcase sieht der Schnitt so aus:

• Komponenten-Bibliothek. Owner: Zentrales Frontend-Team. Scope: Geteilte Bausteine, Barrierefreiheit, Performance-Budgets.
• Marken-Tokens. Owner: Brand-Design-Leads. Scope: Farben, Typo, Logo, Bildwelt pro Marke.
• Content und Kampagnen. Owner: Brand-Marketer. Scope: Seiten, Heroes, Texte pro Marke, innerhalb der geteilten Bibliothek.
• Katalog und Preise. Owner: Bestehendes Magento-Setup. Scope: Unverändert, pro Store View.

Das zentrale Team besitzt das geteilte Fundament einmal, also gelten Performance- und Barrierefreiheits-Regeln für jede Marke per Default. Die Brand-Teams besitzen, was ihre Storefront ausmacht, und können keine andere Marke versehentlich kaputt machen, weil sie in Tokens und Content arbeiten, nicht in geforktem Code.

Wie der Launch einer vierten Marke aussieht

Weil das Fundament geteilt ist, ist das Hinzufügen einer Marke eher Konfiguration als ein neuer Build. Die Schritte im Showcase: die Store View der neuen Marke in Magento anlegen, falls sie noch nicht existiert, ein Token-Set für die Marke definieren, die Domain mappen und die Launch-Seiten aus der bestehenden Bibliothek komponieren. Die neue Marke erbt die Komponenten-Bibliothek, das Performance-Budget und die Barrierefreiheits-Baseline ab Tag eins, statt von einem leeren Theme zu starten.

Wo das neben der Konsolidierungs-Story steht

Der frühere Konsolidierungs-Beitrag beantwortet, warum ein Portfolio auf ein einziges Frontend wechseln würde, ohne das Backend zu migrieren. Dieser Showcase beantwortet die Anschlussfrage, die ein Käufer als Nächstes stellt: Wie sieht das laufende System konkret aus und wer fasst welchen Teil an. Gleiche Architektur, andere Linse, Betrieb statt Begründung.

FAQ

Braucht das eine Migration weg von Magento oder Adobe Commerce? Nein. Das geteilte Frontend liest Magentos bestehende GraphQL-API und Store-View-Struktur. Backend, Katalog und Preise bleiben, wo sie sind.

Wie bleibt jede Marke visuell eigenständig? Jede Marke ist ein Token-Set auf einer geteilten Komponenten-Bibliothek. Gleiche Komponenten, andere Farben, Typo, Logos und Bildwelt, pro Marke zur Request-Zeit aufgelöst.

Können Brand-Marketer eigenständig arbeiten? Ja. Die Editoren jeder Marke komponieren Seiten aus der geteilten Bibliothek in ihrem eigenen Theme und Katalog-Scope, ohne Dev-Tickets und ohne die anderen Marken zu berühren.

Bedeutet eine geteilte Komponente geteilten Content? Nein. Komponenten sind geteilt; die daran gebundenen Daten und Inhalte sind pro Marke, gesetzt im Content-Modell und aus jeder Store View gelesen.

Nächster Schritt

Willst du das auf dein eigenes Marken-Portfolio auf Magento oder Adobe Commerce gemappt sehen? Sprich mit dem Laioutr-Team und wir skizzieren den geteilten Frontend-Layer für deine Shops.