PrestaShop Multistore: Mehrere Shops über ein Admin-Panel verwalten

Zuletzt überprüft im Juni 2026, das Modell aus Shop-Gruppe / Shop / Shop-URL und die Seite Erweiterte Einstellungen → Multistore gelten für PrestaShop 1.7, 8 und 9.

PrestaShop Multistore ist die Funktion, zu der Händler greifen, wenn aus einem Shop drei werden: ein deutscher Shop, ein französischer, ein Großhandelsbereich. Das Versprechen klingt attraktiv, alle über ein einziges Admin-Panel verwalten, einen Produktkatalog teilen, nur einmal einloggen. Und im Großen und Ganzen hält Multistore dieses Versprechen. Aber Multistore ist kein Sprachumschalter und auch keine Methode, beliebige, voneinander unabhängige Unternehmen zusammenzukleben. Es ist ein bestimmter Teil der PrestaShop-Architektur mit eigenem Kontextmodell, eigenen Stolperfallen und einer Entscheidung, die Sie einmal treffen und jahrelang mittragen: Was wird geteilt, was bleibt getrennt? In diesem Leitfaden geht es um genau diese Architektur und den Arbeitsalltag damit, was Ihnen das Backoffice tatsächlich bietet, wo der Shop-Kontext gefährlich wird und wann Multistore schlicht das falsche Werkzeug ist.

Was Multistore strukturell wirklich ist

Unter der Oberfläche besteht PrestaShop Multistore aus drei verschachtelten Ebenen. Wer sie versteht, verwaltet sicher; wer sie nicht versteht, riskiert versehentliche Änderungen über mehrere Shops hinweg:

• Shop-Gruppen (die Tabelle shop_group, id_shop_group). Eine Gruppe bildet die Grenze für geteilte Daten. Kunden, Bestellungen, verfügbare Bestände und Warenkörbe können innerhalb einer Gruppe geteilt werden, aber niemals zwischen Gruppen. Wenn zwei Shops denselben Kundenlogin nutzen sollen, müssen sie in derselben Gruppe liegen.
• Shops (die Tabelle shop, id_shop). Der einzelne Shop im Frontoffice, mit eigenem Theme, eigener Katalogauswahl und eigenen Konfigurationswerten.
• Shop-URLs (die Tabelle shop_url). Jeder Shop ist über eine oder mehrere Kombinationen aus Domain und physischer URI erreichbar, myshop.de, myshop.fr oder shop.example.com/de. Darüber wird eine eingehende Anfrage dem richtigen Shop zugeordnet.

Sie aktivieren das gesamte System unter Erweiterte Einstellungen → Multistore (in älteren Installationen mit PrestaShop 1.6 lag diese Option unter Einstellungen → Allgemein → Multistore aktivieren). Danach erscheint auf fast jeder Backoffice-Seite links oben ein Shop-Kontext-Wähler. Dieser Wähler ist das wichtigste Steuerelement in einer Multistore-Installation: Er bestimmt, ob die Änderung, die Sie gleich speichern, für alle Shops, eine Shop-Gruppe oder einen einzelnen Shop gilt.

Das Modell aus geteilt und überschrieben

Das Freigabemodell ist kein einheitlicher Mechanismus, es funktioniert bei Katalogobjekten anders als bei der Konfiguration, und dieser Unterschied ist wichtig. Für Katalogdaten wie Produkte, Kategorien und Versanddienste hält PrestaShop einen Basisdatensatz vor und ergänzt eine Zuordnungstabelle pro Shop, product_shop, category_shop, carrier_shop und so weiter. Damit kann ein bestimmter Shop einzelne Felder überschreiben (bei einem Produkt zum Beispiel Preis, Aktiv-Status, Weiterleitung oder sogar den Namen) und den Rest erben. Sie verwalten also tatsächlich ein Produkt, während sich sein Preis im französischen Shop und seine Sichtbarkeit im Großhandels-Shop unterscheiden können. Einstellungen sind dagegen keine verknüpften Zeilen: Sie liegen in der Tabelle configuration mit Gültigkeit für Shop und Shop-Gruppe. Ein Wert kann also global, pro Gruppe oder pro Shop gespeichert werden. Genau diese gestuften Überschreibungen sind der eigentliche Vorteil von Multistore gegenüber getrennten Installationen: einmal bearbeiten, bewusst abweichen.

Wann Multistore das richtige Werkzeug ist

Länderspezifische Shops auf unterschiedlichen Domains

Der sauberste Anwendungsfall. myshop.de, myshop.fr und myshop.es als drei Shops in einer Gruppe, mit gemeinsamen Produkten und Kunden, jeweils eigenem Theme, Standardwährung, Standardsprache und eigenen Steuerregeln. Der Bestand wird geteilt, sodass Sie nicht drei Lagerbestände abgleichen müssen. So arbeitet Multistore genau wie vorgesehen, aber beachten Sie die klare Grenze: Multistore verwaltet die Shop-Frontends, sorgt aber nicht von allein für korrekt lokalisierte Währungen, länderspezifische Bruttopreis-Anzeige oder hreflang. Das sind separate Aufgaben, die wir in Verkaufen in Europa: Sprachen, Währungen und Steuern und hreflang-Tags behandeln.

Premium- und Budgetmarken, ein Lager

Dieselben physischen Produkte, zwei Shop-Frontends mit unterschiedlichen Namen, Themes und Preispunkten, aber ein gemeinsamer Bestand. Die Preisüberschreibung pro Shop und der Produktname pro Shop machen daraus ein paar Klicks statt eines duplizierten Katalogs.

B2B und B2C nebeneinander

Ein Endkundenshop mit Bruttopreisen und ein Großhandels-Shop mit Nettopreisen, Mindestbestellmengen und Zahlung auf Rechnung, beide auf derselben Produktdatenbank. Kundengruppen plus ein zweiter Shop in derselben Gruppe ermöglichen gemeinsamen Bestand bei vollständig unterschiedlichen Geschäftsregeln.

Mehrere Nischen-Shops mit teilweiser Produktüberschneidung

Garten-, Küchen- und Badshops, die einen Teil des Katalogs teilen, aber eigenständiges Branding haben. Die Überschneidung rechtfertigt Multistore; die gemeinsamen Produkte zahlen sich jedes Mal aus, wenn Sie eines aktualisieren und die Änderung weitergegeben wird.

Wann Multistore das falsche Werkzeug ist

Sie wollen nur mehr Sprachen

Das ist der häufigste Fehler. PrestaShop ist in einem einzelnen Shop mehrsprachig. Jedes übersetzbare Feld (Produktname, Beschreibung, CMS, Meta) wird pro Sprache in _lang-Tabellen gespeichert, und Sprachen fügen Sie unter International → Lokalisierung → Sprachen hinzu. Wenn Sie nur englische und französische Texte zu denselben Preisen brauchen, bringt Multistore lediglich unnötiges Kontext-Handling. Nutzen Sie den Standardweg, siehe Einrichtung eines mehrsprachigen Shops.

Die Shops haben wirklich nichts miteinander zu tun

Tierfutter und Elektronik, keine gemeinsamen Produkte, keine gemeinsamen Kunden, keine gemeinsamen Abläufe. In diesem Fall bringt Multistore nur zusätzliche Komplexität, aber keinen Nutzen durch geteilte Daten. Zwei getrennte Installationen sind leichter zu verstehen, einfacher unabhängig zu sichern und können nicht durch eine Änderung im falschen Kontext gegenseitig verunreinigt werden. Multistore lohnt sich durch Überschneidung; ohne jede Überschneidung ist es reiner Ballast.

Eine Person, ohnehin schon am Limit

Jede Multistore-Änderung stellt die Frage: "In welchem Kontext bin ich gerade?" Ein Einzelbetreiber, der den Wähler einmal übersieht, kann einen Preis oder einen deaktivierten Status in alle Shops übertragen. Wenn das Team klein ist und die notwendige Disziplin noch fehlt, kann die kognitive Last teurer werden als getrennte Installationen.

Der Shop-Kontext: wo Multistore wirklich zubeißt

Der Kontext-Wähler ist keine Komfortfunktion. Er ist ein aktiver Gültigkeitsbereich, der verändert, was Ihr Speichern-Button tut:

Auf Produkt-, Kategorie- und Konfigurationsseiten im Einzelshop-Kontext sehen Sie neben vielen Feldern ein kleines Kontrollkästchen. Das ist der Schalter für die Überschreibung. Aktivieren Sie ihn, wird dieses Feld nur für diesen Shop vom geteilten Wert gelöst. Lassen Sie ihn deaktiviert, erbt der Shop den Wert. Unsere praktische Regel lautet: Lesen Sie den Kontext-Wähler laut vor, bevor Sie auf Speichern klicken. Im Modus "Alle Shops" zu bearbeiten, obwohl Sie nur einen Shop meinten, ist der teuerste Multistore-Fehler überhaupt. Und er erzeugt keine Fehlermeldung, PrestaShop tut einfach still und genau das, was Sie ihm gesagt haben, überall.

Datenfreigabe: die Entscheidung, die Sie einmal treffen

Für jeden Datentyp entscheiden Sie beim Anlegen des Shops, ob er geteilt oder getrennt wird. Später umzudenken bedeutet Migrationsarbeit. Die ehrlichen Standardannahmen:

• Produkte, meistens geteilt. Ein Katalog, mit Überschreibungen pro Shop für Preis, Name und Sichtbarkeit. Das ist der zentrale Effizienzgewinn.
• Kunden und Warenkörbe, innerhalb einer Gruppe geteilt, wenn dieselbe Person sich über Ihre Märkte hinweg anmelden können soll; getrennt (verschiedene Gruppen) bei wirklich eigenständigen Marken, bei denen eine gemeinsame Identität keinen Sinn ergibt.
• Bestellungen, behalten immer ihren ursprünglichen Shop (jede Bestellung trägt ihre id_shop). Wenn die Shop-Gruppe für das Teilen von Bestellungen konfiguriert ist, können sie innerhalb dieser Gruppe sichtbar und geteilt sein; andernfalls bleibt eine Bestellung auf ihren eigenen Shop beschränkt. So oder so können Sie die Bestellungen aller Shops über eine zentrale Bestellungen-Liste anzeigen und bearbeiten. Das ist der Vorteil zentraler Auftragsabwicklung.
• Verfügbare Mengen (Bestand). Können innerhalb einer Shop-Gruppe geteilt werden, wenn die Option "verfügbare Mengen teilen" der Gruppe aktiviert ist. Genau das macht Szenarien mit einem gemeinsamen Lager möglich; andernfalls bleibt der Bestand pro Shop getrennt.
• Kategorien und CMS. Teilbar, aber oft sollen sie getrennt sein: ein gemeinsamer Produktbaum, aber lokalisierte Rechtstexte und eine länderspezifische Startseite.

Das Problem der Modulkompatibilität

Das ist das größte praktische Risiko, und es ist real. Multistore-Fähigkeit ist bei einem Modul nicht automatisch vorhanden. Der Entwickler muss sie einbauen. Ein Modul, das Multistore ignoriert, wird:

• den Shop-Kontext ignorieren und jede Änderung auf alle Shops anwenden, weil es Konfigurationen mit Configuration::get() / Configuration::updateValue() liest und schreibt, ohne die Shop-ID zu übergeben oder Shop::CONTEXT_SHOP zu berücksichtigen.
• Einstellungen global speichern, sodass Sie zwei Shops keine unterschiedlichen Werte geben können, der zweite Shop überschreibt den ersten.
• eigene Datenbanktabellen ohne eine id_shop-Spalte anlegen, sodass seine Daten zwangsläufig geteilt werden, auch wenn sie pro Shop getrennt sein sollten.
• im Hauptshop einwandfrei funktionieren und in jedem anderen Shop-Kontext brechen oder still Daten durchsickern lassen.

Ein sauber gebautes Modul liest seine Einstellungen mit der Shop-ID (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop) über den Shop-Kontext), ergänzt seine Tabellen um id_shop und registriert Hooks pro Shop. Bevor Sie sich auf Multistore festlegen, sollten Sie jedes Modul, von dem Sie abhängen, genau darauf prüfen. Lesen Sie die Dokumentation, fragen Sie den Entwickler direkt und, nicht verhandelbar, testen Sie in einer Staging-Installation mit mindestens zwei Shops, bevor Sie das echte System aufbauen. Nach dem Einrichten von drei Live-Shops festzustellen, dass ein kritisches Modul nicht Multistore-fähig ist, ist ein wirklich schlechter Nachmittag.

Genau deshalb bauen wir unsere Module so, wie wir sie bauen. Unsere Modul-Suiten sind von der Datenschicht an shop-kontextfähig geschrieben. Eine Einstellung, die Sie im französischen Shop ändern, bleibt also im französischen Shop, und die Tabellen eines Moduls tragen ihre id_shop, statt Daten über alle Shops zu verschmieren. Das ist der Unterschied zwischen einer Multistore-Installation, der Sie vertrauen können, und einer, bei der jedes Speichern der Konfiguration ein kleines Risiko ist, relevant, egal ob Sie SEO-Verwaltung, Rechnungsstellung oder Inhalte im Shop über mehrere Shops hinweg betreiben. Prüfen Sie immer jedes Modul einzeln, aber genau darin liegt der Sinn, bei einem Entwickler zu kaufen, der Multi-Shop-Szenarien testet: Sie erben das oben beschriebene Kompatibilitätsproblem nicht.

Währungen, Flaggen und shop-spezifische Frontoffice-Details

Multistore gibt jedem Shop seine eigene Standardwährung und seine eigenen aktivierten Sprachen. Die kundensichtbaren Teile, der Währungsumschalter, die Sprachflaggen, die Frage, wie ein wiederkehrender Besucher im richtigen Shop landet. Sind jedoch Frontoffice-Arbeit, die auf Multistore aufsetzt, nicht Teil von Multistore selbst. Diese kleinen Details richtig umzusetzen, verhindert, dass internationale Besucher abspringen. Wir behandeln sie in Währungsumschalter und Sprachflaggen und die vollständige Mechanik mehrerer Währungen in unserem Leitfaden zur Einrichtung mehrerer Währungen.

Praktische Verwaltungstipps

• Lesen Sie den Kontext-Wähler vor jedem Speichern. Diese eine Gewohnheit verhindert den teuersten Multistore-Fehler. Behandeln Sie "Alle Shops" wie eine scharf geschaltete Einstellung.
• Benennen Sie shop-spezifische Assets nach dem Shop. banner-myshop-de.jpg, nicht banner.jpg. Wenn Sie Logos und Theme-Bilder pro Shop hochladen, ist der Dateiname oft der einzige Hinweis darauf, in welchem Shop Sie gerade arbeiten.
• Testen Sie im Kontext jedes Shops. Eine Theme-Anpassung, die in Shop A richtig aussieht, kann in Shop B mit anderem Theme oder anderer Modulkonfiguration brechen. Prüfen Sie nach einer Änderung das Live-Frontoffice jedes Shops, nicht nur das Haupt-Frontoffice.
• Sichern Sie vor strukturellen Änderungen. Eine Änderung im falschen Kontext kann sich gleichzeitig über alle Shops ausbreiten; ein aktueller Datenbank-Dump ist Ihr Rückgängig-Button.
• Dokumentieren Sie die Shop-Struktur. Welche Shops liegen in welcher Gruppe, was ist geteilt und was überschrieben, welche Module sind shop-spezifisch. Wenn etwas bricht oder jemand neu dazukommt, ist das genau das Dokument, das den Tag rettet.
• Achten Sie auf die shop_url-Zuordnung. SSL-Einstellungen, das Haupt-URL-Flag und die physische/virtuelle URI pro Shop sind schnell falsch konfiguriert und führen dann zu Weiterleitungsschleifen oder dazu, dass der falsche Shop geladen wird. Prüfen Sie sie unter Erweiterte Einstellungen → Multistore → in der URL-Konfiguration des jeweiligen Shops.

Performance-Aspekte

Jede Multistore-Abfrage trägt einen Shop-Filter, PrestaShop verknüpft bei den meisten Katalog- und Konfigurationsabfragen die _shop-Zuordnungstabellen und filtert nach id_shop. Bei zwei oder drei Shops mit normalen Katalogen ist dieser Aufwand vernachlässigbar. Bei mehr als zehn Shops mit großen Katalogen wird er messbar, und die Lösung ist solide Datenbankhygiene: Stellen Sie sicher, dass Indizes auf den id_shop-Spalten der großen Zuordnungstabellen vorhanden sind, halten Sie Kategorie- und Produktzahlen im Griff und setzen Sie auf Full-Page-Caching, damit das Frontoffice nicht bei jedem Aufruf erneut shop-gefilterte Abfragen ausführt. Messen Sie in Ihrer eigenen Installation, aktivieren Sie Multistore und beobachten Sie dann die Abfragezeiten im Debug-Profiler, bevor Sie ein Problem annehmen.

Häufig gestellte Fragen

Ist Multistore der richtige Weg, um weitere Sprachen hinzuzufügen?

Nein. Das ist der häufigste Fehler. PrestaShop ist innerhalb eines einzelnen Shops mehrsprachig: Jedes übersetzbare Feld wird pro Sprache in _lang-Tabellen gespeichert, und Sprachen fügen Sie unter International → Lokalisierung → Sprachen hinzu. Wenn Sie nur denselben Katalog zu denselben Preisen auf Englisch und Französisch brauchen, bringt Multistore lediglich unnötiges Kontext-Handling. Nutzen Sie die eingebauten mehrsprachigen Felder, siehe Einrichtung eines mehrsprachigen Shops. Greifen Sie erst dann zu Multistore, wenn Märkte wirklich unterschiedliche Kataloge, Preisstrukturen oder Markenauftritte brauchen.

Was ist der teuerste Multistore-Fehler?

Im Kontext "Alle Shops" zu speichern, obwohl Sie nur einen Shop meinten. Der Kontext-Wähler (links oben) ist ein aktiver Gültigkeitsbereich: Im Modus "Alle Shops" schreibt ein Speichervorgang den Wert gleichzeitig in jeden Shop, ohne Fehlermeldung, PrestaShop tut still und genau das, was Sie ihm gesagt haben, überall. Die Gewohnheit, die das verhindert, ist einfach: Lesen Sie den Kontext-Wähler laut vor, bevor Sie auf Speichern klicken, und behandeln Sie "Alle Shops" wie eine scharf geschaltete Einstellung.

Können meine Shops Kunden und Bestand teilen?

Innerhalb einer Shop-Gruppe ja. Eine Shop-Gruppe bildet die Grenze für geteilte Daten. Kunden, Warenkörbe und verfügbare Bestände können innerhalb einer Gruppe geteilt werden, aber niemals zwischen Gruppen. Wenn zwei Shops also denselben Kundenlogin nutzen sollen, müssen sie in derselben Gruppe liegen. Und geteilter Bestand (wenn die Option "verfügbare Mengen teilen" der Gruppe aktiviert ist) macht Szenarien mit einem gemeinsamen Lager möglich. Bestellungen behalten immer die id_shop ihres Ursprungsshops, aber Sie können die Bestellungen aller Shops über eine einzige Bestellungen-Liste bearbeiten.

Woran erkenne ich, ob ein Modul sicher in mehreren Shops nutzbar ist?

Sie müssen es prüfen. Multistore-Fähigkeit ist nicht automatisch vorhanden, der Entwickler muss sie einbauen. Ein Modul, das den Shop-Kontext ignoriert, wendet jede Änderung auf alle Shops an, speichert Einstellungen global, sodass zwei Shops sich nicht unterscheiden können, oder legt Tabellen ohne eine id_shop-Spalte an, sodass seine Daten zwangsläufig geteilt werden. Ein sauber gebautes Modul liest Einstellungen mit der Shop-ID (Configuration::get('MY_KEY', null, $id_shop_group, $id_shop)), ergänzt seine Tabellen um id_shop und registriert Hooks pro Shop. Testen Sie jede Abhängigkeit in einer Staging-Installation mit mindestens zwei Shops, bevor Sie das echte System aufbauen. Unsere Modul-Suiten sind von der Datenschicht an shop-kontextfähig geschrieben, relevant, egal ob Sie SEO-Verwaltung, Rechnungsstellung oder Inhalte im Shop über Ihre Shops hinweg betreiben.

Übernimmt Multistore Währungen, Steuern und hreflang pro Land für mich?

Nein, Multistore verwaltet die Shop-Frontends. Jeder Shop erhält seine eigene Standardwährung und seine aktivierten Sprachen, aber korrekt lokalisierte Währungsanzeige, länderspezifische Bruttopreise und hreflang über getrennte Domains hinweg sind separate Aufgaben, die darauf aufsetzen. Siehe Verkaufen in Europa für Währungen und Steuern sowie hreflang-Tags für das domainübergreifende SEO-Signal, das der Core nicht automatisch über mehrere Shops hinweg zusammensetzt.

Weiterführende Lektüre

• Einrichtung eines mehrsprachigen Shops. Das richtige Werkzeug, wenn Sie nur mehr Sprachen brauchen, nicht mehr Shops.
• Verkaufen in Europa, die Ebene aus Währung, Steuern und OSS, die Multistore allein nicht löst.
• Hreflang-Tags. Domainübergreifende Gegenseitigkeit ist der schwierige Fall, sobald jeder Markt seinen eigenen Shop hat.

Das Fazit

Multistore ist die richtige Antwort, wenn sich Ihre Shops wirklich überschneiden, gemeinsame Produkte, gemeinsame Kunden, gemeinsamer Bestand, und Sie Frontend, Preise und Branding bewusst auf dieser gemeinsamen Basis variieren möchten. Es ist die falsche Antwort für "Ich brauche nur mehr Sprachen" (nutzen Sie die eingebauten mehrsprachigen Felder) und für wirklich getrennte Unternehmen (nutzen Sie getrennte Installationen). Treffen Sie die Entscheidung zwischen geteilt und getrennt gleich am Anfang richtig, respektieren Sie den Kontext-Wähler konsequent, prüfen Sie Ihre Module auf Shop-Fähigkeit, bevor Sie bauen, und Multistore macht aus dem Verwaltungsaufwand von drei Installationen eine einzige. Die Einrichtungsdisziplin ist der Preis; die tägliche operative Einfachheit ist das, was Sie dafür bekommen.

Eine Schritt-für-Schritt-Anleitung zum Anlegen Ihrer ersten Shop-Gruppe und Ihres ersten Shops finden Sie in unserem Knowledge-Base-Leitfaden PrestaShop Multistore einrichten.