Headless Frontend für mehrsprachige, internationale Shops

Ein Headless Frontend für mehrsprachige, internationale Shops trennt die Präsentationsebene sauber von Backend, CMS und PIM und rendert pro Markt eine eigene Locale-Variante aus einer zentralen Storefront-Struktur. Der Schlüssel ist nicht die Übersetzung allein, sondern die Frage, aus welchem System welcher Inhalt kommt: Produktdaten aus dem PIM, redaktioneller Content aus dem CMS, Preise und Verfügbarkeit aus dem Commerce-Backend. Wenn diese Grenzen sauber gezogen sind, skaliert ein neuer Markt in Tagen statt Monaten.

Was heißt i18n bei einem Headless Frontend?

i18n (Internationalisierung) beschreibt die Architektur, mit der ein Storefront mehrere Sprachen, Währungen, Rechtsräume und Sortimente bedient, ohne für jeden Markt ein eigenes Projekt zu forken. Multi-Market geht einen Schritt weiter: unterschiedliche Kataloge, Steuerlogik, Zahlungsarten und Content-Hierarchien pro Land. In einer Composable-Architektur ist das Frontend die Ebene, die diese Unterschiede orchestriert. Die Backends liefern strukturierte Daten, das Frontend entscheidet, welche Locale, welcher Katalog und welche Content-Slots pro Anfrage zusammenkommen.

Der häufige Denkfehler: Sprache wird als reines Text-Overlay behandelt. In der Praxis unterscheiden sich Märkte in Attributsätzen, Media, SEO-Struktur, rechtlichen Pflichttexten und sogar in der Reihenfolge der Kaufargumente. Ein tragfähiges Setup modelliert deshalb Locale als erstklassige Dimension, nicht als nachträglichen Filter.

Das Problem, das viele aktuell haben

Die meisten Teams starten mit einem Markt und einer Sprache. Der zweite Markt kommt per Copy-Paste-Fork, der dritte per manuellem Nachpflegen. Nach vier Ländern steht ein Wildwuchs aus divergierenden Templates, doppelt gepflegten Produkttexten und drei verschiedenen Wahrheiten für denselben Preis. Jede PIM-Änderung muss an mehreren Stellen nachgezogen werden, und niemand traut sich mehr, das Locale-Routing anzufassen.

Das Ergebnis kennst Du wahrscheinlich: hohe Time-to-Market pro Markt, inkonsistente SEO-Signale (fehlende oder falsche hreflang-Angaben) und ein Redaktionsteam, das mehr Zeit mit Synchronisation als mit Content verbringt. Der Kern des Problems ist nicht die Übersetzung. Es ist die fehlende klare Zuständigkeit zwischen Frontend, CMS und PIM.

Der Integrations-Blueprint: CMS und PIM sauber anbinden

Ein belastbares Multi-Market-Frontend folgt vier Prinzipien. Wir nutzen sie in der Frontend Management Platform (FMP, die Kategorie, die Laioutr als Frontend-Steuerungsebene besetzt) als Standard-Schnitt.

1. Datenhoheit trennen. Das PIM ist die Single Source of Truth für Produktattribute, Varianten und Media. Das CMS besitzt redaktionellen Content, Kampagnen und Story-Module. Das Commerce-Backend besitzt Preise, Bestand und Checkout. Das Frontend besitzt keine Daten, es komponiert sie. Diese Regel entscheidet später darüber, ob ein neuer Markt sauber skaliert.

2. Locale als Query-Dimension. Jede Datenanfrage trägt die Locale als Parameter. Das PIM liefert die marktspezifischen Attribute (Akeneo oder Pimcore geben lokalisierte Werte pro Channel aus), das CMS liefert die passende Content-Variante, das Backend die richtige Preisliste. Das Frontend löst pro Request genau eine Kombination auf. Details zur Anbindung findest Du auf der PIM-Integrationsseite.

3. Ein Template-Set, viele Locales. Statt pro Markt zu forken, definierst Du Sections und Blocks einmal und bindest sie an die Locale-Query. Redakteure arbeiten pro Markt im Composable Visual Page Builder, ohne den Code zu berühren. Fallback-Ketten (Markt-Sprache, dann Basissprache) verhindern leere Seiten, wenn eine Übersetzung fehlt.

4. SEO-Struktur pro Markt. Locale-Präfixe (/de/, /en/, /fr/), korrekte hreflang-Verknüpfungen und pro Markt eigene Meta-Struktur gehören ins Frontend, nicht ins Backend. So entsteht für jeden Markt eine sauber indexierbare, zitierfähige Seite, auch für AI-Overviews.

Wer die grundsätzliche Rollenverteilung zwischen Content-System und Frontend noch schärfen will: wir haben ausführlich beschrieben, warum ein CMS kein Frontend ist. Genau diese Trennung ist die Voraussetzung dafür, dass Multi-Market ohne Fork funktioniert.

Beispiel-Datenfluss für einen Request

Ein Kunde ruft die Produktdetailseite im französischen Markt auf. Das Frontend erkennt die Locale fr-FR, fragt das PIM nach den französischen Attributen und Media, das CMS nach den französischen Content-Modulen und das Backend nach Preis und Bestand für die französische Preisliste. Alle drei Antworten fließen in dasselbe Template. Kein Fork, kein Copy-Paste, eine Wahrheit pro System. Fällt eine Übersetzung im CMS aus, greift die Fallback-Kette auf die Basissprache, statt eine leere Section zu rendern.

Was Du gewinnst

• Dimension | Vorher (Fork pro Markt) | Mit Headless Multi-Market-Frontend
• Zeit | 2-4 Monate pro neuem Markt | Neuer Markt in Tagen, ein Template-Set
• Pflege | Produkttexte mehrfach pflegen | PIM zentral, Frontend zieht pro Locale
• Qualität | Divergierende Templates, SEO-Lücken | Konsistente Struktur, hreflang automatisch
• Redaktion | Sync statt Content | Redakteure arbeiten pro Markt im Editor

Die Frontend-Ebene ist dabei ein eigenständiges Betriebsmodell, kein Nebenprodukt des CMS. Mehr dazu auf der Seite zu Frontend as a Service und im Überblick zur Composable Digital Experience Platform, die die Cross-Channel- und Multi-Market-Perspektive zusammenführt. Für die reine Markt- und Marken-Logik lohnt der Blick auf Multi-Brand und Multi-Market.

FAQ

Brauche ich pro Markt ein eigenes Frontend-Projekt? Nein. Ein Template-Set mit Locale als Query-Dimension bedient beliebig viele Märkte. Ein Fork pro Markt ist genau das Anti-Pattern, das später die Pflegekosten explodieren lässt.

Wie kommen Produktdaten mehrsprachig ins Frontend? Über das PIM. Akeneo und Pimcore liefern lokalisierte Attribute pro Channel oder Locale. Das Frontend fragt pro Request die passende Locale ab, statt Übersetzungen im Code zu halten.

Was ist mit hreflang und internationalem SEO? Das gehört in die Frontend-Ebene. Locale-Präfixe und automatische hreflang-Verknüpfungen sorgen dafür, dass jede Marktseite sauber indexiert und in AI-Overviews zitierfähig bleibt.

Was kostet das? Das hängt von Marktzahl und Integrationstiefe ab. Die Tarife findest Du unter laioutr.com/pricing, konkrete Zahlen klären wir in einer Demo.

Wie lange dauert die Umsetzung? Das erste Setup mit einem Markt und den CMS- und PIM-Anbindungen liegt typisch bei wenigen Wochen. Jeder weitere Markt danach ist eine Frage von Tagen, weil das Template-Set steht.

Nächste Schritte

Wenn Du ein Multi-Market-Setup planst oder einen bestehenden Fork-Wildwuchs zurückbauen willst: buch eine Demo und wir gehen Deinen konkreten CMS- und PIM-Stack durch.

Über den Autor: Das Laioutr Team baut die Frontend Management Platform für Composable Commerce, mit Fokus auf schnell umgesetzte, mehrsprachige Storefronts und saubere Backend-Integration.