Eine Website in Dutzenden Sprachen: Praktische i18n für E-Commerce
Eine E-Commerce-Website für mehr als eine Handvoll Sprachen zu internationalisieren, legt jede Annahme offen, die in einer ursprünglich einsprachigen Codebasis steckt. Die nötigen Anpassungen – Texte aus dem Code auslagern, Formate an die jeweilige Sprach- und Regionsvariante anpassen, Layouts für Rechts-nach-links-Schriften überarbeiten – sind theoretisch gut verstanden und praktisch ausgesprochen mühsam. Weniger gut verstanden ist die Abfolge von Entscheidungen, die darüber bestimmt, ob das Ergebnis wirklich lokalisiert ist oder nur wie eine maschinell übersetzte Fassade wirkt, die zufällig in der richtigen Schrift angezeigt wird.
Nach solchen Projekten für Websites mit Dutzenden Sprach- und Regionsvarianten ist unsere wichtigste Erkenntnis: Die technische Umsetzung ist der kleinere Teil des Problems. Übersetzungspipeline, URL-Architektur und hreflang-Konfiguration sind lösbare technische Aufgaben. Die kulturelle Anpassung – zu verstehen, was eine Produktseite in Japan, Deutschland oder Brasilien glaubwürdig macht – bleibt bei den meisten Lokalisierungsprojekten hinter den Erwartungen zurück. Sie lässt sich nicht vollständig automatisieren und erfordert Wissen, dessen Erwerb aufwendig ist.
URL-Struktur: Die Entscheidung, die sich später am schwersten ändern lässt
Die URL-Struktur ist die erste Entscheidung bei einer mehrsprachigen Website und lässt sich am schwersten rückgängig machen. Drei Ansätze sind verbreitet: eigene Domains je Sprach- und Regionsvariante (example.de, example.fr), eigene Subdomains (de.example.com, fr.example.com) und eigene Unterverzeichnisse (example.com/de/, example.com/fr/). Ihre Folgen für die SEO-Autorität, die Komplexität von Deployments und den Betriebsaufwand unterscheiden sich erheblich.
Eigene Domains bieten die klarste Nutzererfahrung und erlauben unabhängiges Hosting je Markt. Sie verteilen jedoch die Domain-Autorität: Jahrelang aufgebaute Backlinks zu example.com kommen example.de nicht direkt zugute. Für Websites mit etabliertem organischem Traffic ist das ein erheblicher Nachteil. Bei neuen Websites für Märkte, in denen lokale Top-Level-Domains Vertrauen schaffen, fällt die Abwägung anders aus.
Unterverzeichnisse je Sprach- und Regionsvariante sind die häufigste Empfehlung für Websites, die ihre SEO-Autorität bündeln möchten. Für E-Commerce-Websites ohne zwingenden Grund, Märkte auf Domain-Ebene zu trennen, ist das meist die richtige Wahl. Der Nachteil: Alle Varianten teilen sich die Infrastruktur, sodass ein Deployment für eine Variante alle anderen beeinflussen kann. Für die meisten Teams ist diese betriebliche Einschränkung akzeptabel.
Entscheidend ist, die Wahl bewusst und früh zu treffen und dabei die Folgen für SEO und Betrieb vollständig zu berücksichtigen. Denn sobald eine Website eingehende Links und Suchmaschinenindexierung aufgebaut hat, ist eine Änderung der URL-Struktur so teuer, dass die ursprüngliche Entscheidung oft lange bestehen bleibt, nachdem ihre Schwächen sichtbar geworden sind.
Die Übersetzungspipeline
Eine Übersetzungspipeline für Dutzende Sprachen umfasst drei unterschiedliche Tätigkeiten, die oft vermischt werden: eine erste maschinelle Übersetzung als Ausgangsbasis, die menschliche Prüfung zur Fehlerkorrektur und Anpassung des Tons sowie die laufende Pflege bei Änderungen am Ausgangstext. Jede Tätigkeit hat eine andere Kostenstruktur und eine andere erreichbare Qualitätsgrenze.
Maschinelle Übersetzung ist inzwischen für die meisten westeuropäischen Sprachen eine belastbare Ausgangsbasis. Für Japanisch, Chinesisch und Sprachen mit komplexen Höflichkeitssystemen ist sie ebenfalls nutzbar, aber eingeschränkter. Unabhängig von der Ausgangsqualität muss das Ergebnis geprüft werden. Maschinelle Übersetzung ist nicht grundsätzlich falsch, erzeugt aber regelmäßig sprachlich korrekte Texte mit unpassendem Ton. Maschinell übersetzte Rechtstexte klingen auch so und schwächen damit genau die Glaubwürdigkeit, die lokalisierte Inhalte schaffen sollen.
Die Pflege von Übersetzungen bei Inhaltsänderungen ist die operative Herausforderung, die Expansionspläne regelmäßig unterschätzen. Jede Änderung des Ausgangstexts in einer Sprache erzeugt Aktualisierungsbedarf für alle anderen Varianten. Ohne ausdrücklich nachzuverfolgen, welche Übersetzungen aktuell sind, sammeln sich unbemerkt veraltete Inhalte an – bis ein Nutzer in einem nicht englischsprachigen Markt auf einer Produktseite Preise vom Vorjahr findet oder eine eingestellte Funktion als verfügbar beschrieben sieht.
Die Werkzeugwahl – Übersetzungsmanagementsystem, dateibasierter Ansatz oder datenbankgestützte Inhaltsverwaltung – sollte sich nach diesem Pflegeprozess richten, nicht nach dem anfänglichen Übersetzungsvolumen. Ein dateibasierter Ansatz lässt sich schnell aufsetzen, wird bei größerem Umfang aber zur Belastung, wenn Werkzeuge fehlen, um ausstehende Übersetzungsaktualisierungen zu erkennen und zu priorisieren.
hreflang: Implementierung und häufige Fehler
hreflang-Tags zeigen Suchmaschinen, welche Sprach- und Regionsversion einer Seite sie welchen Nutzern ausspielen sollen. In der Dokumentation wirkt die Umsetzung einfach: Jede Seite erhält einen Satz von <link rel="alternate">-Tags, einen pro Variante, mit den richtigen Sprachcodes (einem ISO-639-1-Sprachcode, optional gefolgt von einem ISO-3166-1-Alpha-2-Regionscode, etwa de oder de-AT). In der Praxis gibt es so viele mögliche Fehler, dass eine fehlerhafte hreflang-Implementierung eher die Regel als die Ausnahme ist.
Der häufigste Fehler sind unvollständige hreflang-Sätze. Jede Variante muss in ihren hreflang-Tags auf jede andere Variante und auf sich selbst verweisen. Führt eine Seite nur sieben von acht Varianten auf, fehlt für das ausgelassene Seitenpaar die wechselseitige Verknüpfung. Google ignoriert hreflang-Verweise zwischen Seiten, die nicht beide aufeinander verweisen. Die programmatische Erzeugung aus einer gemeinsamen Liste unterstützter Varianten verhindert das – sofern diese Liste beim Hinzufügen oder Entfernen von Varianten korrekt gepflegt wird.
Ein weiterer häufiger Fehler sind widersprüchliche hreflang-Verweise: Das Tag auf der englischen Seite verweist auf /de/product-name, die kanonische URL der deutschen Seite lautet aber /de/produktname. Das passiert, wenn Slugs übersetzt werden – was für SEO in Märkten mit relevanten lokalen Suchbegriffen sinnvoll ist –, ohne die hreflang-Verweise anzupassen. Automatisierte Prüfungen, die die Website crawlen und sicherstellen, dass jedes hreflang-Tag auf eine existierende kanonische URL verweist, sind die einzige zuverlässige Methode, solche Abweichungen bei großem Umfang zu finden.
Der hreflang-Wert x-default wird häufig missverstanden. Er bedeutet nicht „Standardsprache“, sondern „für Nutzer, die zu keiner der ausdrücklich angegebenen Sprach- und Regionsvarianten passen“. Bei den meisten Websites sollte er auf die Hauptsprachversion verweisen. Bei Websites mit einer Sprachauswahl oder standortbasierten Weiterleitungen kann ein anderes Ziel korrekt sein.
RTL: Mehr als das Umkehren des Layouts
Die Unterstützung von Rechts-nach-links-Schriften (RTL) – Arabisch, Hebräisch, Persisch (Farsi), Urdu und andere Rechts-nach-links-Schriften – wird in vielen Projekten als CSS-Aufgabe behandelt: dir="rtl" am Wurzelelement setzen, Flex-Richtungen umkehren, Innen- und Außenabstände spiegeln, fertig. Tatsächlich macht RTL-Unterstützung Layoutannahmen sichtbar, die erst auffallen, wenn sich die Schreibrichtung ändert.
Am häufigsten wird die Richtung von Symbolen übersehen. Navigationspfeile, Fortschrittsanzeigen und nach links oder rechts weisende Symbole haben eine Bedeutung, die im RTL-Kontext gespiegelt werden sollte. Ein Zurück-Pfeil, der bei Links-nach-rechts-Schrift (LTR) nach links zeigt, sollte bei RTL nach rechts zeigen. CSS mit transform: scaleX(-1) übernimmt die Spiegelung technisch. Trotzdem muss jedes Richtungssymbol in der Oberfläche geprüft werden, damit es nur dort gespiegelt wird, wo das sinnvoll ist.
Ziffern, Telefonnummern und Postleitzahlen werden auch in RTL-Texten von links nach rechts gelesen und dürfen nicht gespiegelt werden. Da der Unicode-Algorithmus für bidirektionalen Text Ziffern und ihre Trennzeichen als schwache oder neutrale Zeichen behandelt, hängt ihre Position vom umgebenden Text ab. Deshalb müssen diese Werte häufig isoliert werden, etwa mit <bdi> oder dir="ltr". Werden LTR- und RTL-Inhalte in einem Textblock gemischt – etwa eine Produktbeschreibung mit Modellnummer –, sind eine ausdrückliche Unicode-Steuerung der bidirektionalen Darstellung oder sorgfältig gesetzte HTML-dir-Attribute erforderlich. Sonst kann der bidirektionale Algorithmus des Browsers eine fehlerhafte Ausgabe erzeugen.
Kulturelle Anpassung jenseits der Übersetzung
Lokalisierung und Übersetzung sind unterschiedliche Tätigkeiten. Übersetzung überträgt Wörter. Lokalisierung überträgt Bedeutung – und setzt voraus, den kulturellen Kontext zu verstehen, der bestimmt, was eine Botschaft für eine bestimmte Zielgruppe bedeutet.
Die wirtschaftlich wichtigsten Unterschiede liegen in den Vertrauenssignalen. Was eine Produktseite glaubwürdig macht, unterscheidet sich deutlich nach Markt: Deutsche Kunden legen Wert auf Prüfzeichen und technische Angaben, japanische auf Markenruf und Verpackungsqualität, amerikanische auf Erfahrungen anderer Kunden und gut sichtbare Rückgaberegeln. Eine Produktseite kann in einem Markt gut und in einem anderen schlecht konvertieren, obwohl die Übersetzungsqualität gleich ist, weil Layout und Gewichtung auf die falschen Vertrauenssignale ausgerichtet sind.
Zahlungsarten sind eine weitere kulturelle Dimension, die häufig nur als technische Integration behandelt wird. In Deutschland bleiben Überweisung und SEPA-Lastschrift wichtige Zahlungswege. In Japan werden Zahlungen in Convenience Stores weiterhin häufig genutzt. Wer in diesen Märkten nur Kreditkarten und PayPal anbietet, scheitert nicht an der sprachlichen Übersetzung, sondern an der praktischen Lokalisierung: Das Angebot passt nicht zu den Gewohnheiten der Kunden.
Die ehrliche Einschätzung lautet: Die meisten mehrsprachigen E-Commerce-Websites sind übersetzt, aber kaum lokalisiert. Der Text ist in der richtigen Sprache; das Nutzungserlebnis wurde nicht an den Markt angepasst. Für Unternehmen, die gegen lokale Anbieter antreten, entstehen Unterschiede bei den Konversionsraten aus organischem Traffic genau in dieser Lücke zwischen Übersetzung und Lokalisierung.
Weiterführende Beiträge
- SEO-Korrekturen, die wirklich wirken: Canonicals, Sitemaps und abschließende Schrägstriche – konkrete technische SEO-Änderungen, die mit besserer Indexierung und besseren Platzierungen mehrsprachiger Websites zusammenhängen.
- Astro i18n: Eine statische Website in neun Sprachen ohne CMS aufbauen – Details zur Umsetzung des i18n-Routings und des Übersetzungssystems dieser Website.
- Unsere Strategie für den Shopify-Ausstieg: Headless-E-Commerce-Alternativen bewerten – wie i18n-Anforderungen die Entscheidung beeinflussten, Headless-Plattformen als Alternativen zu Shopify zu prüfen.