Subshop / Multishop

Was ist ein Subshop technisch?

In JTL-Wawi lässt sich unter einem Mandanten mehr als ein Shop-Objekt anlegen. Jeder dieser Shops bekommt eine eigene Anbindung über den JTL-Worker, eine eigene Domain und ein eigenes Template — greift aber auf denselben zentralen Artikelstamm, dieselbe Bestandsführung und teils denselben Kundenstamm zu. Das unterscheidet den Subshop von einer komplett eigenständigen Installation: Die Trennung findet auf Ebene von Darstellung, Preislogik und Kanal statt, nicht auf Ebene der Datenhaltung selbst.

Konkret lassen sich pro Subshop unter anderem eigenständig konfigurieren:

• Domain und Design — eigenes Template, eigene Markenoptik
• Preise — über Kundengruppen, etwa Netto- vs. Brutto-Darstellung oder Sonderkonditionen
• Sortiment — Sichtbarkeit einzelner Kategorien oder Artikel je Shop
• Sprache und Land — eigene Übersetzung, Währung, Versand- und Zahlungsarten

Typische Anwendungsfälle für Subshops

Die drei häufigsten Szenarien in der Praxis:

Ein B2B/B2C-Split ist der klassischste Fall: Der B2C-Shop zeigt Bruttopreise ohne Login-Zwang, der B2B-Subshop verlangt eine Anmeldung, zeigt Nettopreise und individuelle Staffelkonditionen — beide greifen aber auf denselben Artikelbestand zu, damit Lagerbestand und Verfügbarkeit nicht doppelt gepflegt werden müssen. Für internationale Händler ist der Länder-Split ähnlich verbreitet: Statt eine Domain mit mehreren Sprachversionen zu betreiben, bekommt jedes Zielland einen eigenen Subshop mit lokaler Sprache, Währung und angepassten Versandkonditionen, während die Artikeldaten zentral gepflegt bleiben.

Subshop vs. komplett getrennte Installation

Nicht jede organisatorische Trennung rechtfertigt einen Subshop — manchmal ist eine vollständig separate JTL-Wawi-Installation die sauberere Lösung. Ein Subshop passt, wenn Artikelstamm, Bestand und im Kern auch der Kundenstamm gemeinsam geführt werden sollen und nur Darstellung, Preise oder Sprache sich unterscheiden. Eine getrennte Installation ist dagegen sinnvoller, wenn Marken oder Ländergesellschaften rechtlich, buchhalterisch oder organisatorisch vollständig unabhängig sind — etwa bei getrennten Firmen mit eigener Buchhaltung, eigenem Nummernkreis und eigenem Lager, die zufällig dasselbe Warenwirtschaftssystem nutzen, aber sonst nichts teilen. Wer diese Grenze vorab nicht klärt, landet leicht in einem Subshop-Setup, das eigentlich eine getrennte Installation gebraucht hätte — mit entsprechendem Nachbesserungsaufwand.

Grenzen und Komplexität im Alltag

Mit jedem weiteren Subshop steigt der Pflegeaufwand spürbar, und zwar überproportional zur Anzahl der Shops:

• Bestandsrisiko: Da sich alle Subshops denselben Bestand teilen, kann bei knapper, schnell drehender Ware ein Overselling entstehen, wenn die Synchronisation über den JTL-Worker nicht eng genug getaktet ist.
• Preislogik-Komplexität: Je mehr Kundengruppen und Subshops, desto leichter schleichen sich Fehler in die Preisregeln ein — eine falsch zugeordnete Kundengruppe zeigt schnell Netto- statt Bruttopreise oder umgekehrt.
• Duplicate-Content-Risiko: Zeigen mehrere Subshops identische Produkttexte unter verschiedenen Domains, drohen SEO-Nachteile durch doppelten Inhalt — hier braucht es entweder differenzierte Texte oder saubere kanonische Verweise.
• Wachsender Testaufwand: Änderungen an Vorlagen, Preisregeln oder Versandkonditionen müssen bei jedem weiteren Subshop einzeln geprüft werden, statt einmalig für einen einzelnen Shop.

Technische Voraussetzungen für Multishop-Betrieb

Jeder Subshop mit eigener Domain braucht eine eigene SSL/TLS-Absicherung, entweder über Einzelzertifikate oder ein Multi-Domain-Zertifikat. Die Synchronisation läuft über eine eigene Konfiguration des JTL-Workers je Shop, mit eigenen Intervallen und eigener Fehlerprotokollierung — ein Ausfall bei einem Subshop bleibt sonst leicht unbemerkt, während die anderen Shops normal weiterlaufen. Bei internationalen Länder-Subshops innerhalb der EU kommt zusätzlich die umsatzsteuerliche Seite ins Spiel, insbesondere die Meldung über das OSS-Verfahren, sobald länderübergreifend an Endkunden verkauft wird.

Duplicate Content zwischen Subshops vermeiden

Zeigen ein deutscher und ein österreichischer Subshop dieselben Produktbeschreibungen unter unterschiedlichen Domains, sieht Google technisch zwei separate Seiten mit identischem Inhalt — mit dem Risiko, dass keine der beiden Versionen optimal rankt. Für rein sprachlich identische Länder-Shops mit unterschiedlicher Zielregion ist das Werkzeug der Wahl das hreflang-Attribut, das Suchmaschinen mitteilt, welche Version für welche Sprache oder Region gedacht ist, ohne dass eine Version als „Duplikat" der anderen abgewertet wird. Bei wirklich identischen Inhalten ohne regionale Differenzierung — etwa ein reiner Test- oder Spiegel-Subshop — ist stattdessen ein kanonischer Verweis auf die Hauptversion die passendere Lösung. Wer beides vermischt oder ganz weglässt, riskiert, dass Suchmaschinen die Subshops gegeneinander ausspielen, statt sie als sinnvoll ergänzende Sprach- oder Länderversionen zu behandeln.

Migration von Einzelshop zu Multishop

Der Umstieg von einem einzelnen Shop auf ein Multishop-Setup ist selten ein reiner Konfigurationsschritt, sondern verlangt vorbereitende Arbeit an den Stammdaten: Artikeltexte müssen daraufhin geprüft werden, ob sie sich unverändert für alle geplanten Subshops eignen oder angepasst werden müssen, Kundengruppen und Preislogik müssen sauber definiert sein, bevor der zweite Shop live geht, und die Synchronisationsintervalle des JTL-Workers sollten vorab auf die zusätzliche Last getestet werden. In der Praxis bewährt es sich, zunächst einen zweiten Subshop in einer Testumgebung aufzusetzen, dort alle Preis-, Bestands- und Übersetzungsszenarien durchzuspielen und erst danach die Live-Domain zu schalten — ein nachträgliches Umbiegen einer bereits laufenden Multishop-Struktur ist deutlich aufwendiger als eine von Anfang an sauber geplante Trennung.

Typische Fehler bei Subshop-Setups

1. Subshop statt getrennter Installation gewählt — bei rechtlich oder buchhalterisch vollständig unabhängigen Einheiten reicht die gemeinsame Datenbasis eines Subshops nicht aus.
2. Preislogik nicht sauber je Kundengruppe getrennt — führt zu falschen Netto-/Bruttopreisen oder inkonsistenten B2B-Konditionen.
3. Bestandssynchronisation zu träge getaktet — bei knapper Ware entsteht Overselling zwischen den Subshops.
4. Identische Produkttexte über mehrere Domains — erzeugt Duplicate-Content-Risiken ohne kanonische Verweise oder differenzierte Inhalte.
5. Wachstum der Subshop-Zahl ohne Testkonzept — Änderungen werden nur in einem Shop getestet und wirken sich unbemerkt fehlerhaft auf die anderen aus.

Ob ein Subshop oder eine getrennte Installation die richtige Struktur ist, hängt stark vom konkreten Geschäftsmodell ab. Bei der Planung und technischen Umsetzung eines Multishop-Setups unterstützen wir bei der Einrichtung von JTL-Shop als JTL Agentur.