Cross-Border E-Commerce mit Shopware 6: Multi-Country-Shop richtig aufsetzen

Ein Großhändler aus Nordrhein-Westfalen, drei Jahre auf Shopware 6, sauberer DE-Shop, solide Zahlen. Im Q2-Kick-off fällt der Satz: „Wir wollen ab Herbst auch nach Österreich, in die Schweiz und in die Niederlande verkaufen. Das ist doch nur ein Sprachschalter, oder?"

Sechs Monate später: drei Storefronts live, ein vierter in Vorbereitung, OSS-Anmeldung durch — und am Samstag des Black-Friday-Wochenendes bekommt ein eingeloggter CH-Kunde plötzlich EUR-Preise auf der .ch-Domain angezeigt, weil ein Custom-Plugin den Varnish-Cache-Key-Cookie filtert. Mehrere Bestellungen mit falschen Beträgen, drei verärgerte Telefonate vor der Kaffeepause, ein Compliance-Hinweis vom externen Datenschutz-Anwalt am Montag. Niemand hatte das auf der Rechnung. Genau dort, zwischen „nur ein Sprachschalter" und „zerschossener Cache-Key", liegt dieser Artikel.

Shopware 6 macht Cross-Border technisch leichter als jedes andere mittelständische Shopsystem im DACH-Raum. Aber zwischen „funktioniert technisch" und „verkauft in vier Ländern rechtssicher, suchmaschinen-tauglich und ohne Logistik-Albtraum" liegt eine Reihe Architektur- und Prozess-Entscheidungen, die du besser am Anfang triffst, nicht im Black-Friday-Wochenende.

Warum Cross-Border jetzt?

Der EU-Binnenmarkt funktioniert 2026 endlich so, wie er 1993 sollte: ein Online-Shop, viele Länder, kaum noch rechtliche Hürden an den Grenzen. Wer einen sauberen DE-Shop betreibt, sitzt auf einer Pipeline für rund 120 Millionen kaufkraftstarke Einwohner in DACH plus Niederlanden. Die Frage ist nicht mehr „ob", sondern „wie ohne Reibungs-Verlust".

Wichtig ist nur, dass Cross-Border nicht „Übersetzung im Footer" heißt. Wer in Österreich verkauft, verkauft an österreichische Verbraucher mit österreichischer Rechtsprechung, leicht anderen Steuerregeln und einem anderen Zahlungsmix. Das gilt umso mehr für die Schweiz, wo du formal ins Nicht-EU-Ausland verkaufst — mit eigenem Steuerregime, eigener Logistik-Realität und einer Versandhandelsregelung, die viele DE-Händler bis heute nicht auf dem Schirm haben (dazu später mehr).

Architektur-Entscheidung: Multi-Sales-Channel vs. Multi-Instance

Das ist die Grundsatzfrage, die alle weiteren Entscheidungen prägt. Shopware 6 unterstützt von Haus aus mehrere Sales Channels, mehrere Sprachen pro Sales Channel und mehrere Währungen — alles in einer Instanz, einer Datenbank, einem Admin. Die Alternative: pro Land eine eigene Shopware-Installation, eigene DB, eigene Domain, eigenes Deployment.

Aus unserer Beratungspraxis: Von den letzten zwölf Cross-Border-Setups, die wir begleitet haben, sind elf Multi-Sales-Channel. Genau eines ist Multi-Instance — eine Schweizer Tochterfirma mit eigener Buchhaltung, eigenem Lager und eigener Geschäftsleitung. Diese Verteilung erzählt mehr als jede theoretische Empfehlung: Multi-Sales-Channel ist der Default, Multi-Instance die begründete Ausnahme. Hier ist, warum.

Multi-Sales-Channel — der Default

• Ein Produktstamm. Pflege, Imports, ERP-Anbindung passieren an einer Stelle. Bild-, Preis- oder Lagerstand-Updates propagieren über alle Storefronts.
• Ein Kundenstamm pro Sales Channel, gemeinsame Plattform. Kundengruppen, B2B-Logik, Newsletter-Zustimmung sind sales-channel-spezifisch konfigurierbar, ohne manuelle Synchronisation.
• Ein Update-Pfad. Shopware-Major-Updates, Sicherheits-Patches, Plugin-Updates: einmal. Drei separate Shopware-Instanzen bedeutet dreimal Regressions-Tests.
• Native Sprach- und Währungs-Unterstützung. Translations werden im Admin gepflegt, Currency-Conversion ist eingebaut, Tax-Provider lassen sich pro Sales Channel zuweisen.

Aber: Wenn AT und DE das gleiche Sortiment haben, NL aber ein deutlich anderes (andere Marken, andere Produktgruppen), bläht der gemeinsame Produktstamm mit Sales-Channel-Filtern die Listing-Queries auf. Wenn das NL-Team eigene Features will, die DE nicht haben darf, brauchst du Sales-Channel-Bedingungen quer durch die Codebasis. Und: Ein Plugin-Bug, der den Checkout in DE killt, killt ihn potenziell auch in AT, CH und NL gleichzeitig.

Multi-Instance — die begründete Ausnahme

Sinnvoll, wenn Länder-Setups wirklich grundverschieden sind oder regulatorisch getrennt sein müssen:

• Schweiz als Sonderfall. Eigene CH-GmbH oder Niederlassung mit eigener UID, eigener Buchhaltung, eigenen Lagerbeständen — die rechtliche Trennung will technisch sauber abgebildet sein.
• B2B vs. B2C parallel. DE primär B2B, NL primär B2C? Sortimente, Preislogiken und Checkout-Flows können so verschieden sein, dass eine zweite Instanz weniger Komplexität als ein zweiter Sales Channel bedeutet.
• Unabhängige Release-Zyklen. Wenn Länderteams autonom releasen sollen, ohne dass DE auf das NL-Deployment wartet.

Kosten: nicht „doppelte Infrastruktur", aber Faktor 1,6 bis 1,8, weil Wissen, CI/CD-Setup und Monitoring-Infrastruktur sich teilen lassen. Trotzdem signifikant teurer.

Wann ein Headless-Ansatz sinnvoll ist

Headless (Shopware 6 Store-API plus eigenes Frontend in Next.js, Nuxt oder Vue Storefront) ist kein Cross-Border-Selbstzweck, aber löst zwei spezifische Probleme elegant: sehr unterschiedliche Frontend-Erfahrungen pro Land, ohne dass du mit dem Twig-Theme-Layer kämpfst, sowie composable-commerce-Setups, in denen PIM (z. B. Akeneo), CMS (z. B. Storyblok), Search (z. B. Algolia) und Personalisierung pro Land unterschiedlich konfiguriert sind, während das Shopware-Backend als Commerce-Engine im Hintergrund läuft.

Bei Bike-Discount hatten wir genau diese Frage auf dem Tisch: Reicht das klassische Storefront, oder geht der Shop perspektivisch headless? Im konkreten Fall war der Auslöser nicht die Internationalisierung selbst, sondern ein PIM-Wechsel und der Wunsch nach einem deutlich performanteren Produkt-Listing. Die Entscheidung lief auf einen hybriden Pfad: Storefront bleibt für die Mehrzahl der Seiten, performance-kritische Listings und ein paar markenspezifische Landing-Pages laufen über Custom-Frontends gegen die Store-API. Lehre für die Cross-Border-Frage: Headless ist eine eigene strategische Entscheidung mit eigenen Kosten — sie pauschal an „wir gehen jetzt international" zu koppeln, mischt zwei Roadmaps, die unterschiedliche Treiber haben sollten.

Wer „nur" vier Länder mit ähnlichen Anforderungen launchen will, fährt mit dem klassischen Twig-Storefront plus Sales Channels in aller Regel schneller, günstiger und mit weniger Maintenance-Surface zum Ziel.

Sprache und Content-Strategie

Wenn die Architektur steht, kommt die Frage, die in 80 % der Cross-Border-Projekte unterschätzt wird: Wie übersetzen wir das eigentlich? Und „unterschätzt" heißt: Es wird zu spät angefasst, zu billig gemacht und zu spät korrigiert.

Übersetzungsqualität: maschinell, manuell, hybrid

Maschinelle Übersetzung über DeepL oder GPT-4o ist 2026 deutlich besser als noch vor drei Jahren — aber gut genug für deine Conversion-Hebel ist sie selten. Drei realistische Stufen:

1. Vollmaschinell für interne Felder, Kategorie-Filter, Long-Tail-Produkte ohne Ranking-Ambition, und für Erstbestand bei Sortiments-Großimporten. Faustregel: alles, was nicht auf der ersten Seite Google ranken muss, kann maschinell starten.
2. Maschinell mit Lektorat — der häufigste Default. Eine Maschine macht den ersten Wurf, eine muttersprachliche Fachredaktion korrigiert Tonalität, Branchen-Begriffe und SEO-Keywords. Pro Sprache und Produktseite in unseren Projekten typisch 5–15 Minuten statt 30–45 Minuten Komplett-Übersetzung. Gut investiert für Top-Produkte, Kategorie-Texte und Service-Seiten.
3. Manuell durch Native Speaker — Pflicht für AGB, Widerruf, Datenschutz, Versandbedingungen und für die Brand-Stimme tragende Inhalte. Hier ist die maschinelle Übersetzung das größte Risiko, weil ein juristisch verschobener Halbsatz abmahnfähig wird.

Hreflang-Tags richtig setzen — die häufigsten Fehler

Wenn du in mehreren Sprachen oder Ländern verkaufst, sagt dir Google über die hreflang-Annotation, welche Version für welche Region und Sprache gedacht ist. Falsch gesetzt: Google rankt deinen DE-Shop in Österreich, deinen AT-Shop in Deutschland, oder gar keinen.

Die häufigsten Fehler aus unseren Migrations-Audits:

• Sprache und Land verwechselt. hreflang="de-DE" für den österreichischen Sales Channel ist falsch — korrekt wäre hreflang="de-AT". Wir hatten einen Kunden, dessen AT-Storefront ein halbes Jahr in Wien praktisch unsichtbar war, weil der Sales Channel als de-DE getaggt und von Google als Duplikat des DE-Shops eingestuft wurde. Recovery: vier Monate nach Korrektur, davon sechs Wochen, bis die ersten organischen Klicks wieder kamen.
• Fehlender x-default. Ohne hreflang="x-default" weiß Google nicht, was es ausspielt, wenn weder Sprache noch Region matchen.
• Asymmetrische Verweise. Wenn die DE-Seite auf die AT-Seite verweist, muss die AT-Seite zurück auf die DE-Seite verweisen. Einseitige hreflang-Verweise ignoriert Google in der Regel.
• Hreflang auf 301-Ziele. hreflang verweist auf eine URL, die via 301 weiterleitet — funktioniert nicht zuverlässig, Google folgt der Annotation nur, wenn die Ziel-URL direkt antwortet.
• Hreflang im JS gerendert. Funktioniert eingeschränkt, ist aber fragil — sicherer ist die Server-Side-Auslieferung im <head> oder in der XML-Sitemap.

Shopware setzt hreflang im Storefront-Theme automatisch, wenn Sales Channels mit Domain-Mappings sauber konfiguriert sind. Verlasse dich trotzdem nicht blind darauf — prüfe mit Screaming Frog oder Sitebulb nach jedem Go-Live jede Sprach-/Land-Kombination.

Lokalisierung ≠ Übersetzung

Eine Übersetzung sagt das Gleiche in einer anderen Sprache. Eine Lokalisierung sagt das, was lokal funktioniert.

• Maßeinheiten und Größen. Schuhgrößen, Konfektionsgrößen, Inch vs. Zentimeter. NL gibt Fahrradrahmen in Zentimetern an, Reifengrößen in Zoll — Mischformen, die ein Deutscher Versand pro Land sauber abbilden muss.
• Produktnamen. Eine Marke, die in DE als „Power-Tool 3000" läuft, kann in NL einen halb-vulgären Beiklang haben. Pflichtprüfung durch Native Speaker.
• Bildsprache. Schwarzwald-Hütte verkauft in Bayern. In Amsterdam wirkt sie exotisch im falschen Sinn. Sales-Channel-spezifische Mediathek-Zuweisung plus Bild-Briefing pro Land sollten von Anfang an einkalkuliert sein.
• Datums-, Zeit-, Währungs-Formatierung. 1.234,56 € in DE, € 1.234,56 in NL, CHF 1'234.55 in CH. Klingt detailverliebt, ist aber das Vertrauenssignal, an dem internationale Käufer priorisieren.
• Service-Erwartungen. NL erwartet schnelle Antworten auf Niederländisch. FR erwartet detailliertere Produkterklärungen und ausgeprägteren Service auf Französisch. Wer Cross-Border launcht, ohne den Customer-Service-Workflow für die neuen Sprachen vorzubereiten, baut sich Retouren und schlechte Bewertungen.

Steuer und Recht pro Land

Hier wird es trocken, aber teuer, wenn man es ignoriert. Und vor allem: hier wird festgelegt, ob die spätere Architektur und das Caching überhaupt rechtssicher operieren können — der Grund, warum dieser Artikel mit einem Black-Friday-Cache-Bug beginnt, hat seine Wurzeln in genau diesem Kapitel.

OSS-Verfahren (One-Stop-Shop) für EU-Fernverkäufe

Seit 1. Juli 2021 gilt für grenzüberschreitende B2C-Verkäufe innerhalb der EU die OSS-Regelung:

• EU-weite Schwelle von 10.000 EUR Netto-Umsatz pro Jahr für alle Fernverkäufe zusammen. Bis dahin: deutscher Mehrwertsteuersatz. Darüber: Mehrwertsteuersatz des Bestimmungslandes.
• Statt Registrierung in jedem EU-Land: Anmeldung beim Bundeszentralamt für Steuern (BZSt), quartalsweise Meldung aller EU-Umsätze zentral.
• OSS deckt nicht alles. Lagerhaltung in einem anderen EU-Land (Amazon FBA Niederlande, Fulfillment-Center in Belgien) erzeugt in der Regel weiterhin eine Registrierungspflicht im jeweiligen Land.

Aus einem Audit: Ein Kunde fakturierte bis Q3 mit dem Argument „wir sind doch noch unter der Schwelle" weiter mit deutscher USt — die 10.000-EUR-Schwelle war aber bereits im April gerissen. Die Quartalsmeldung wurde zur Nachversteuerung. Vermeidbarer Schmerz: rund 23.000 EUR USt nachzuzahlen, dazu der Vertrauensbruch beim Steuerberater. Wer expandiert, sollte den OSS-Trigger im ERP oder einem dedizierten Monitoring sauber tracken.

Für Shopware heißt das praktisch: Steuersätze pro Land sauber gepflegt, korrekte Logik für B2C vs. B2B mit gültiger USt-ID (reverse charge), und eine OSS-konforme Rechnungs-/Reporting-Mimik. Sales-channel-spezifische Tax-Provider und Custom-Rules-Engines liefern das technisch — die Konfiguration ist aber nicht trivial. Plane einen halben Tag mit Steuerberater plus Entwickler ein. Das spart später Monate Klärung.

Schwellenwerte und Mehrwertsteuersätze (Stand Mai 2026)

• DE: 19 % Standard, 7 % ermäßigt
• AT: 20 % Standard, 10 % / 13 % ermäßigt (Hinweis: zum 1.7.2026 sinkt der 10-%-Satz auf bestimmte Grundnahrungsmittel — für Lebensmittel-Sortimente relevant)
• NL: 21 % Standard, 9 % ermäßigt
• FR: 20 % Standard, 10 % / 5,5 % / 2,1 % ermäßigt
• CH: 8,1 % Standard (seit 1.1.2024), 2,6 % ermäßigt, 3,8 % Sondersatz — und CH ist nicht im OSS, weil Nicht-EU

Die Sätze verschieben sich gelegentlich. Wer Shopware-Steuersätze hardcodet und nicht jährlich überprüft, riskiert systematisch falsche Rechnungen.

Schweiz: die Versandhandelsregelung, von der niemand redet

Seit dem 1. Januar 2019 gilt in der Schweiz die Versandhandelsregelung für ausländische Online-Händler: Wer mit Kleinsendungen nach Schweiz pro Jahr mehr als 100.000 CHF Umsatz macht (Kleinsendungen = Bestellungen unterhalb der Einfuhrsteuer-Freigrenze), gilt ab Erreichen der Schwelle als steuerpflichtiger Versandhändler und muss sich bei der Eidgenössischen Steuerverwaltung (ESTV) registrieren und auf allen folgenden Bestellungen Schweizer MwSt direkt an der Kasse erheben — auch auf Kleinsendungen, die zuvor steuerfrei eingeführt wurden.

Die Einfuhrsteuer-Freigrenze selbst: Postsendungen aus dem Ausland sind von der Schweizer Einfuhrsteuer befreit, wenn der zu entrichtende Steuerbetrag unter 5 CHF liegt. Beim Normalsatz von 8,1 % entspricht das einem Warenwert (inklusive Versandkosten) von rund 62 CHF, beim ermäßigten Satz von 2,6 % rund 193 CHF (Quelle: BAZG / ESTV).

Für die Shopware-Konfiguration heißt das: Wenn du die 100.000-CHF-Schwelle reißt (was bei ernsthaftem CH-Engagement schnell passiert), brauchst du eine CHF-MwSt-Logik im Checkout — du erhebst die Schweizer Mehrwertsteuer direkt an der Kasse, ähnlich wie im OSS-Verfahren auf EU-Seite, aber als „registrierter Versandhändler" gegenüber der ESTV. Das ist die Konstellation, die viele DE-Händler beim ersten CH-Launch ignorieren, weil sie aus dem DE-Recht keine Entsprechung kennen.

Neu hinzu kam zum 1. Januar 2025 die Plattformbesteuerung (Art. 20a MWSTG): Elektronische Plattformen, die als Vermittler zwischen Anbieter und Käufer auftreten, werden unter bestimmten Bedingungen selbst zum Leistungserbringer im Sinne der CH-MwSt — relevant, wenn du nicht nur über deinen eigenen Shopware-Shop, sondern auch über Marktplätze in die Schweiz verkaufst. Für klassische Direkt-Verkäufer über den eigenen Shop ändert sich durch die Plattformregel zunächst wenig; wer Multichannel mit Schweiz-Komponente plant, sollte die Regel aber kennen.

Länderspezifische Rechtstexte (AGB, Widerruf, DSGVO)

Jedes Land hat eigene Pflichtangaben, eigene Widerrufsbelehrungen, eigene Anforderungen an Impressum und Datenschutzhinweise. AT und DE sehen ähnlich aus, sind aber im Detail nicht identisch. NL hat eigene Anforderungen an „algemene voorwaarden". CH hat keine gesetzliche Widerrufspflicht für Fernabsatzgeschäfte im EU-Sinn — was du als Händler nicht automatisch ausnutzen solltest, weil die Service-Erwartung der CH-Kunden eine andere ist.

Investiere in landesspezifische Rechtstexte über einen anerkannten Anbieter (Trusted Shops, eRecht24 mit Länder-Modulen, Händlerbund). Die Hosting-Frage — gleicher Vertrag oder pro Land separat? — solltest du mit deiner Kanzlei klären, nicht über Templates aus dem Netz.

BFSG gilt auch für EU-Kunden

Häufiges Missverständnis: Das Barrierefreiheitsstärkungsgesetz (BFSG, anwendbar seit 28. Juni 2025) ist deutsches Recht — aber es greift, sobald du Verbraucher in Deutschland adressierst. Das gilt für jeden Sales Channel, der DE-Kunden bedient, unabhängig davon, ob daneben AT, CH oder NL bedient werden. Wer einen Multi-Country-Shopware-Shop launcht, muss alle Storefronts, die DE-Kunden bedienen, BFSG-konform aufsetzen.

Für die anderen EU-Länder: Der European Accessibility Act ist in den meisten Mitgliedstaaten 2025 in nationales Recht überführt worden, in einzelnen Ländern war die Umsetzung 2025 noch lückenhaft. Praktisch bedeutet das, dass die BFSG-Konformität nicht nur eine DE-Sonderbaustelle ist, sondern die Baseline für jeden EU-Storefront. Wenn du jetzt für Cross-Border ohnehin umbaust, baust du BFSG am besten direkt mit ein.

Payment und Checkout lokalisieren

Wer in NL mit nur Kreditkarte und PayPal launcht, verliert Bestellungen. Wer in CH ohne TWINT launcht, ebenso. Lokale Payment-Präferenzen sind eines der unterschätztesten Conversion-Themen.

Grobe Orientierung (Marktanteilszahlen sind Branchenangaben, je nach Quelle und Erhebung schwankend):

• DE: Rechnung (besonders B2B und höherwertige Bestellungen), PayPal, Kreditkarte, Klarna (Ratenkauf wächst). SEPA-Lastschrift bleibt relevant.
• AT: Ähnlich DE, mit etwas stärkerem Anteil Kreditkarte und EPS-Überweisung.
• CH: TWINT ist Pflicht — laut Swiss Payment Monitor 2025 deutlich über 60 % der mobilen Transaktionen. Daneben: Kreditkarte, PostFinance, Rechnung via POWERPAY (MF Group). Ohne TWINT verlierst du Mobile-Conversion strukturell.
• NL: iDEAL ist mit Abstand führend (iDEAL-eigene Angaben ~70 %, Branchenquellen meist 55–65 % Online-Anteil), Klarna „Achteraf Betalen", Bancontact bei BE-Crossover.
• BE: Bancontact (Branchenangaben ~40–50 % Online-Anteil), Kreditkarte, PayPal, Klarna.
• FR: Kreditkarte (Carte Bancaire — Achtung: nicht jede Kreditkarten-Integration deckt CB ab!), PayPal, Klarna, Apple Pay/Google Pay wachsend, alma für Ratenkauf.

Wero ist 2026 das wichtigste Payment-Detail, das viele übersehen. Die niederländische iDEAL-Marke wird ab Januar 2026 schrittweise in das paneuropäische Wero-System (EPI) überführt; die vollständige Migration soll Ende 2027 abgeschlossen sein. Bancontact-Payconiq wird seit 2024 ebenfalls schrittweise durch Wero verdrängt. Wer 2026 launcht, sollte Wero von Anfang an einplanen — nicht als „nice to have", sondern als strategische Karte für die nächste Payment-Generation in NL und BE.

Shopware unterstützt diese Methoden über die offiziellen Plugins der PSPs. Mollie und PayPal decken den Großteil mit einer Integration ab; für TWINT und CH-spezifische Methoden brauchst du in der Regel einen Schweizer PSP wie Datatrans oder Wallee. Wichtig: Methodenfreigabe pro Sales Channel sauber konfigurieren — nichts ist peinlicher als ein CH-Kunde, dem iDEAL im Checkout angeboten wird.

Logistik und Fulfillment

Versand ist die andere Hälfte der Customer Experience. Drei Modelle:

1. Versand aus DE in alle Länder. Funktioniert für die meisten Sortimente: AT 1–2 Werktage, NL/BE 2–3 Werktage, FR 3–5 Werktage. Vorteil: eine Lagerhaltung, ein Operations-Team. Nachteil: längere Laufzeiten als lokale Wettbewerber, höhere Versandkosten ab einer gewissen Distanz, und CH ist ein eigener Fall (Verzollung, Risiko von Kunden-Frust durch Zollgebühren bei Bestellungen oberhalb der Einfuhrsteuer-Freigrenze — siehe Steuer-Kapitel).

2. Versand aus DE mit lokalem Carrier-Partner. DHL nach AT/CH, PostNL für NL/BE, Colissimo für FR. Meist der schnellste Hebel: zentrale Lagerlogik bleibt, lokal vertrauter Zusteller wird ergänzt. Im Storefront den Carrier pro Sales Channel anzeigen — niederländische Kunden sehen lieber PostNL als „DHL via Frankfurt".

3. Lokales Lager / Fulfillment-Partner. In unseren Projekten ab rund 5.000 monatlichen Bestellungen pro Region prüfenswert, ab rund 15.000 typischerweise wirtschaftlich. Achtung: erzeugt umsatzsteuerliche Registrierungspflicht im Lagerland (OSS reicht dafür nicht) plus operative Komplexität bei Retouren-Steuerung. Der Trigger ist in der Praxis selten ein einzelner Schwellwert, sondern eine Kombination aus Servicelevel-Anspruch („Same-day in Amsterdam") und Frachtkosten pro Bestellung, die ab einem gewissen Punkt rechnerisch gegen die Fixkosten eines Lokal-Lagers schlechter wird.

Für CH ist eine eigene Logistik-Lösung (lokales Lager oder Fulfillment via Swiss Post, Planzer, Asendia) ab einem gewissen Volumen der saubere Weg. Alles aus DE inklusive Verzollung pro Sendung funktioniert für Pilot-Phasen, aber nicht für ernste Volumina.

Plane in Shopware außerdem die Retouren-Workflows pro Land: Rückversand-Adressen, ggf. mehrere RMA-Prozesse, lokale Rücksende-Etiketten. Der Shopware-Standard reicht für einfache Setups; bei komplexer Multi-Country-Logistik brauchst du in der Regel ein OMS (Order Management System) oder die direkte Anbindung ans ERP als Single Source of Truth — typischerweise SAP, Microsoft Dynamics oder branchenspezifische Systeme wie Sage oder pixi.

SEO für Multi-Country: Domain-Strategie

Wenn ihr ernsthaft drei oder mehr Länder bedient: ccTLDs. Punkt. Alles andere ist Test-Modus. In über 80 % unserer Cross-Border-Setups, die mittel- bis langfristig auf SEO setzen, landen wir bei eigenen Country-Code-Domains. Warum, und wann die anderen Varianten trotzdem Sinn machen:

ccTLDs: meinshop.at, meinshop.ch, meinshop.nl

Stärkstes Vertrauenssignal für lokale Nutzer und Google. Klare geografische Targeting-Information. Möglichkeit, Inhalte rechtlich und steuerlich klar zu trennen. Niederländische Kunden klicken auf .nl deutlich häufiger als auf .de/nl.

Nachteile: SEO-Authority muss pro Domain neu aufgebaut werden — du startest in jedem Land bei null. Mehr operativer Overhead (DNS, SSL-Zertifikate, Markenrecht-Anmeldungen pro Land). Höhere Initial-Investition in lokale Backlinks und Markenbekanntheit.

Subfolder: meinshop.de/at/, meinshop.de/ch/, meinshop.de/nl/

Alle Länder profitieren von der gleichen Domain-Authority. Schnellste SEO-Wirkung bei Launch. Einfachste Wartung. Eine SSL-Konfiguration.

Schwächeres lokales Vertrauenssignal, schwer kommunizierbar in der Schweiz, wo .de/ch/ für viele Kunden „die deutschen verkaufen halt auch zu uns" signalisiert — nicht „lokale CH-Adresse". Für schnelle Markt-Tests („funktioniert NL überhaupt?") ist Subfolder der pragmatische Einstieg, mit der bewussten Option, später auf eigene ccTLDs zu migrieren — wofür du allerdings einen sauberen 301-Migrations-Plan brauchst.

Subdomains: at.meinshop.de, ch.meinshop.de, nl.meinshop.de

Schwächste Variante in der Praxis. Google behandelt Subdomains tendenziell als separate Sites, die Authority transferiert sich nicht so gut wie bei Subfolders. Die kognitive Klarheit für Nutzer ist schwächer als bei einer ccTLD. In Ausnahmefällen sinnvoll (separate technische Setups, eigener CDN-Endpoint pro Land), aber selten der beste SEO-Pfad.

In Shopware werden alle drei Varianten über die Sales-Channel-Domain-Konfiguration abgebildet. Wichtig: TLS-Zertifikate für alle Domains automatisiert und überwacht erneuern — Let's Encrypt funktioniert problemlos, aber eine abgelaufene SSL-Konfiguration auf der CH-Domain während Black Friday will niemand erleben.

Varnish-Cache: der Punkt, an dem alles zusammenkommt

Zurück zum Hook. Der CH-Kunde mit den EUR-Preisen am Black-Friday-Samstag ist kein Einzelfall — sondern das typische Symptom, wenn ein Multi-Country-Shopware-Setup unter Last auf Caching trifft, das nicht alle Dimensionen sauber unterscheidet.

Shopware 6 unterstützt HTTP-Caching über Reverse Proxies, in den meisten produktiven Setups ist das Varnish. In einem einsprachigen Ein-Währungs-Shop ist das simpel: eine Page, ein Cache-Eintrag. Sobald mehrere Sales Channels, Sprachen und Währungen in derselben Instanz laufen, braucht der Cache eine Logik, die diese Dimensionen korrekt unterscheidet — sonst bekommt der österreichische Kunde plötzlich deutsche Preise, oder der niederländische Kunde sieht den AT-Versand-Banner.

Wie der Cache-Key in der aktuellen Shopware-VCL funktioniert

In der offiziellen varnish-shopware-VCL ist der zentrale Cache-Key-Treiber heute der sw-cache-hash-Cookie. Er bündelt Sales Channel, Sprache, Währung und weitere Kontext-Dimensionen in einen einzelnen Schlüssel, den Varnish in seiner vcl_hash-Subroutine in den Cache-Key aufnimmt. Der ältere sw-currency-Cookie wird laut Shopware-Dokumentation als deprecated geführt und mit Version 6.8.0.0 entfernt — wer noch eigene VCL-Anpassungen mit sw-currency betreibt, sollte vor dem Upgrade umstellen.

Ergänzend laufen sw-states-Cookies (z. B. für Logged-in-Status) als Bypass-Indikator, ESI-Komponenten ziehen personalisierte Bausteine nach dem ersten Render in den Output, und API-spezifische Header wie sw-language-id greifen im Store-API-Bereich, nicht im Storefront-Caching.

Wo es konkret schiefläuft

Wir haben in mehreren Audits dieses Muster gesehen: Ein Shop läuft auf den ersten Blick stabil, liefert aber unter Last plötzlich falsche Preise oder Versandbanner, weil ein Custom-Plugin den Cache-Key-Cookie filtert oder überschreibt — entweder durch eine falsche Response-Header-Manipulation, durch einen aggressiven Cookie-Banner, der serverseitig den Hash-Cookie verschluckt, oder durch eine falsch konfigurierte CDN-Schicht vor Varnish, die Cookies abräumt.

In einem konkreten B2B-Projekt mit Kundengruppen-Preisen hat ein selbstgebautes Analytics-Plugin den Cache-Key-Cookie aus dem Response gefiltert. Symptom: Über drei Wochen hinweg sahen anonyme CH-Besucher EUR-Listenpreise im Anonymous-Cache, bevor sie sich einloggten. Die CH-Conversion-Rate fiel in dem Zeitraum messbar unter den Vergleichswert, niemand brachte es mit dem Plugin in Verbindung — weil das Plugin in DE und NL völlig unauffällig lief. Erst die Cache-Hit-Rate pro Sales Channel im Monitoring zeigte den Bruch.

Das ist nicht nur ein Bug. Wenn ein eingeloggter CH-Kunde EUR-Preise sieht, dann eine Bestellung mit falscher Bepreisung getätigt wird, hast du einen Verstoß gegen die Preisangabenverordnung (PAngV) und einen Vertrauensbruch, der über das Compliance-Risiko hinausgeht.

Pragmatische Regeln für Multi-Country-Caching

• Stelle sicher, dass der sw-cache-hash-Cookie ungekürzt durch alle Schichten (CDN, WAF, Varnish) durchgereicht wird, und dass die vcl_hash-Subroutine ihn in den Cache-Key aufnimmt.
• Logged-in-Kunden (auch B2B mit kundengruppenspezifischen Preisen) bypassen den Anonymous-Cache.
• Personalisierte Komponenten (Warenkorb-Mini, Wishlist-Status) werden via ESI (Edge Side Includes) nachgeladen, nicht im HTML inline gerendert.
• Pre-Warming nach Cache-Invalidierungen pro Sales Channel — sonst sind die ersten Besucher nach einem Preis-Update die Verlierer, die die langsame DB-Antwort abbekommen.
• Monitoring: Cache-Hit-Rate pro Sales Channel separat tracken. Wenn der NL-Channel plötzlich 30 % weniger Hit-Rate hat als der DE-Channel, ist meistens ein Plugin schuld — und nicht selten erst Wochen später bemerkt.

Für komplexere Setups mit B2B-Kundengruppen-Preisen und individuellen Sortimenten kommst du nicht um eine maßgeschneiderte VCL plus dediziertes Monitoring (Tideways, Blackfire) herum. Das ist Aufwand. Aber genau dieser Aufwand entscheidet, ob dein Cross-Border-Shop sich anfühlt wie ein lokaler Anbieter — oder wie „der deutsche Versand mit niederländischer Fahne".

Was bleibt: Drei Punkte, die wir aus echten Cross-Border-Projekten mitnehmen

Zurück zum Großhändler aus Nordrhein-Westfalen. Sechs Monate nach dem Black-Friday-Cache-Bug läuft der Shop in vier Ländern stabil. Die OSS-Anmeldung ist durch, die Steuersätze pro Land sind sauber gepflegt, der CH-Sales-Channel rechnet seit dem Schwellen-Trigger korrekt mit Schweizer MwSt, und die Cache-Hit-Rate pro Channel ist in einem produktionsreifen Monitoring sichtbar. Nicht weil es einen weiteren Fix gegeben hätte — sondern weil die Architektur-Entscheidungen am Anfang von Anfang an für vier Länder gedacht waren, nicht für „den DE-Shop, plus drei".

Drei Take-aways aus den zwölf Cross-Border-Setups, die wir in den letzten drei Jahren begleitet haben:

1. Multi-Sales-Channel ist der Default, Multi-Instance die begründete Ausnahme. Wer zuerst die Architektur entscheidet — vor dem ersten Übersetzungsauftrag, vor der Payment-PSP-Wahl, vor dem ersten Marketing-Briefing — baut nicht zweimal. Wer es umdreht, lernt das mit acht Wochen Verspätung im Q3-Plan-Review.

2. Steuer und Recht sind Architektur-Treiber, keine Compliance-Hausaufgabe für die letzte Woche. OSS, BFSG, die CH-Versandhandelsregelung, AGB, Widerruf gehören in den Initial-Brief, nicht in den Final-Check. Was am Anfang trivial wirkt, wird unter Zeitdruck zur teuren Notlösung — siehe 23.000 EUR Nachversteuerung im OSS-Beispiel.

3. Caching und Performance sind land-spezifisch — und sichtbar nur in der land-spezifischen Metrik. Lade-Tests, Cache-Hit-Rates, Conversion-Rates müssen pro Sales Channel separat laufen. Was wochenlang im DE-Shop sauber lief, kann an einem Black-Friday-Samstag im CH-Sales-Channel brechen — und du erfährst es vom Kunden, nicht vom Monitoring.

Cross-Border E-Commerce mit Shopware 6 ist 2026 in DACH und Westeuropa eine ausgereifte E-Commerce-Lösung — vorausgesetzt, die Architektur sitzt von Anfang an, die Steuer- und Rechtsthemen sind früh integriert, und Lokalisierung wird als eigene Disziplin behandelt, nicht als Übersetzungsaufgabe. Wer diese drei Punkte ernst nimmt, baut nicht „den DE-Shop mit Sprachschalter", sondern eine echte Multi-Country-Pipeline — die Grundlage einer ehrlichen E-Commerce-Strategie und, je nach Marktansatz, auch eines tragfähigen Omnichannel-Commerce-Setups.

Und wer den Sprachschalter sucht: Den gibt es auch. Er sitzt rechts oben in der Topbar. Aber er ist die unwichtigste der vielen Entscheidungen, die wirklich darüber entscheiden, ob du in Wien, Zürich und Amsterdam Umsatz machst.