Mehrsprachige Websites: hreflang, i18n-Architektur und CMS-Lokalisierung für globale Marken

Die meisten Enterprise-Webprojekte beginnen als Einzelmarkt-Website. Dann expandiert das Unternehmen, und jemand sagt: „Wir müssen es einfach übersetzen." Genau dieser Satz ist der Ausgangspunkt, an dem die meisten internationalen Webprojekte scheitern.

Die Übersetzung ist der einfache Teil. Der schwierige Teil ist die Infrastruktur darunter – die Routing-Architektur, die hreflang-Implementierung, das CMS-Datenmodell, der redaktionelle Workflow. Wer diese Elemente falsch umsetzt, verbringt Jahre damit, Probleme zu bekämpfen: Traffic landet in der falschen Locale, übersetzte Seiten sind für Suchmaschinen unsichtbar, Redakteure veröffentlichen in fehlerhafte Content-Strukturen. Die mehrsprachige Website-Entwicklungspraxis von PixelEruption existiert genau deshalb, weil diese Probleme struktureller, nicht redaktioneller Natur sind – und von Anfang an einen Engineering-first-Ansatz erfordern.

hreflang: Das Implementierungsdetail, das Millionen an organischem Traffic kostet

hreflang ist das HTML-Attribut, der HTTP-Header oder der XML-Sitemap-Tag, der Google signalisiert, welche Version einer Seite an welche Zielgruppe ausgeliefert werden soll. Googles offizielle hreflang-Dokumentation beschreibt die Syntax klar genug – doch die eigentliche Komplexität liegt in der Implementierungsdisziplin, die im großen Maßstab erforderlich ist.

Die zwei häufigsten Enterprise-Fehler sind fehlende x-default-Tags und unvollständige gegenseitige Verlinkung. Jedes hreflang-Set muss einen x-default-Wert enthalten, der auf die Fallback-Version für Nutzer verweist, die keiner expliziten Locale entsprechen. Fehlt dieser Wert, hat Google kein Signal für nicht zugeordnete Zielgruppen. Gegenseitige Verlinkung bedeutet: Wenn die en-US-Seite auf de-DE verweist, muss die de-DE-Seite ihrerseits auf en-US verweisen – und auf jede andere Locale im Set. Eine unvollständige Implementierung, die regelmäßig entsteht, wenn verschiedene Regionalteams für unterschiedliche Seiten zuständig sind, signalisiert Google, dass das Signal-Set korrupt ist, und wird vollständig ignoriert.

Ein subtileres Problem ist die Genauigkeit der Regionscodes. en-GB und en-AU sind unterschiedliche Tags; en allein zu verwenden, wenn britisches Englisch gemeint ist, erzeugt keinen Fehler, den Google anzeigt – der Inhalt wird schlicht falsch ausgeliefert. Für Marken, die in ganz LATAM tätig sind, ist die Unterscheidung zwischen es-MX, es-CO und es-AR sowohl für die Suchrelevanz als auch für die rechtliche Compliance in regulierten Branchen von Bedeutung.

i18n-Architektur: Die Routing-Schicht

Internationalisierung (i18n) ist kein Plugin, das man nach dem Launch hinzufügt. Es ist eine Architekturentscheidung, die das gesamte Routing-Modell, die Komponentenbibliothek und das CMS-Datenschema prägt. In einem Next.js App Router-Projekt – dem Standard, den wir für die meisten Enterprise-Builds verwenden – bedeutet dies ein dynamisches [lang]-Segment an der Wurzel des app/-Verzeichnisses. Jede Route wird dann unter diesem Segment eingeordnet: app/[lang]/page.tsx, app/[lang]/products/[slug]/page.tsx und so weiter.

Die Routing-Schicht übernimmt die Locale-Erkennung über eine Middleware-Funktion, die den Accept-Language-Header liest, ihn mit der Liste der unterstützten Locales abgleicht und entsprechend weiterleitet – dabei wird ein explizites Locale-Cookie für Nutzer respektiert, die manuell gewechselt haben. Entscheidend ist, dass diese Weiterleitung ein 307 (temporär) und kein 301 (dauerhaft) sein muss, damit Suchmaschinen jede Locale direkt crawlen, anstatt der Weiterleitungskette zu folgen.

Die Externalisierung von Strings erfolgt in lokalen JSON-Dateien – eine pro Sprache – und wird über einen typisierten Übersetzungs-Hook bereitgestellt, der die Existenz von Schlüsseln zur Build-Zeit überprüft. Dadurch werden fehlende Übersetzungen erkannt, bevor sie in die Produktion gelangen. Datumsformatierung, Zahlenformatierung und Währungsdarstellung verwenden die Intl-Browser-API, die auf die aktive Locale beschränkt ist und Sprachen von rechts nach links (RTL) wie Arabisch und Hebräisch unterstützt, ohne separate Layout-Dateien zu benötigen.

CMS-Lokalisierung: Die Content-Architektur, die niemand rechtzeitig plant

Die technische Architektur ist nur die halbe Herausforderung. Die andere Hälfte besteht darin, wie das Content-Team übersetzte Inhalte tatsächlich in einem headless CMS verwaltet. Die meisten Enterprise-Teams unterschätzen dies, bis sie 2.000 Seiten und sechs Sprachen haben und ihre Redakteure manuell Inhalte zwischen Locale-Feldern in Contentful oder Sanity kopieren.

Die Muster, die im großen Maßstab funktionieren, teilen drei Merkmale. Erstens: ein einziges Content-Modell mit locale-spezifischen Feldüberlagerungen – keine doppelten Content-Typen pro Sprache. Zweitens: ein Übersetzungsworkflow, der Quellsprachen-Bearbeitungen kennzeichnet und sie durch ein Genehmigungstor leitet, bevor veröffentlichte Übersetzungen veralten. Drittens: Slug-Lokalisierung als erstklassiges Feld, nicht als nachträglicher Gedanke. Eine deutsche URL, die /de/unsere-leistungen/ lautet, konvertiert und rankt besser als /de/our-services/ – und das erfordert, dass Slugs unabhängige lokalisierte Werte sind und keine automatisch übersetzten Strings aus dem CMS.

Unsere Content-Strategie- und SEO-Dienste behandeln Slug-Architektur und Canonical-Konfiguration als Teil desselben technischen Briefings, da beide Systeme übereinstimmen müssen: hreflang-Tags, CMS-Slugs und Sitemap müssen alle auf dieselben kanonischen URLs verweisen – andernfalls bricht die Implementierung zusammen, egal wie sauber die einzelnen Komponenten sind.

Übersetzung vs. Transkreation: Eine strategische Entscheidung

Übersetzung ersetzt Wörter. Transkreation ersetzt Bedeutung. Für Produktbeschreibungen mag eine Übersetzung ausreichen. Für Headlines, CTAs und Markenbotschaften scheitert wörtliche Übersetzung häufig – die Formulierung verfehlt die Wirkung, der kulturelle Bezug existiert nicht, oder der rechtliche Kontext erfordert eine ganz andere Aussage.

Enterprise-Marken, die in neue Märkte eintreten, sollten jeden Content-Typ prüfen, bevor sie ihn einem Übersetzungs- oder Transkreations-Workflow zuweisen. Technische Dokumentation und Produktspezifikationen können maschinell übersetzt und anschließend von Menschen überarbeitet werden. Kampagnentexte, Hero-Texte auf der Homepage und alle Inhalte, die Konversionsentscheidungen treiben, erfordern menschliche Transkreation durch jemanden, der den Zielmarkt kennt – nicht nur die Sprache.

Von Anfang an richtig aufbauen

Internationale Web-Architektur ist kein Retrofit-Projekt. Jeder Monat, den ein Unternehmen auf einer Einzelmarkt-Infrastruktur läuft, während es in neue Märkte expandiert, ist ein Monat, in dem technische Schulden in Routing, CMS-Schema und SEO-Konfiguration anwachsen. Teams, die globale Websites erfolgreich betreiben, bauen die i18n-Schicht von Anfang an ein – auch wenn sie nur mit einer einzigen Sprache starten – denn eine zweite Locale zu einer korrekt internationalisierten Codebasis hinzuzufügen dauert Wochen, nicht Monate.

Wenn Ihr Unternehmen eine Marktexpansion, einen Site-Relaunch oder eine CMS-Migration plant und die internationale Architektur korrekt umgesetzt haben möchte, verfügt unser Team bei PixelEruption über die technische Tiefe, um sie von Anfang bis Ende zu konzipieren und umzusetzen. Sprechen Sie mit uns über Ihr mehrsprachiges Website-Projekt – wir beginnen mit einem Architektur-Review, nicht mit einer Angebotsvorlage.