Wie verwaltet ein Headless CMS mehrsprachige Inhaltsverknüpfungen für globale Websites?

Wenn eine globale Website mehrsprachig veröffentlicht wird, bestehen häufige Probleme nicht darin, dass Übersetzungen fehlen. Vielmehr ist nach einer Aktualisierung der englischen Produktseite unklar, was auf der deutschen Seite angepasst werden muss; beim Sprachwechsel werden Nutzer auf die Startseite zurückgeleitet; oder nicht mehr veröffentlichte Übersetzungen erscheinen weiterhin in der Sprachnavigation. Um diese Beziehungen zu verwalten, sollten die Sprachversionen über eine stabile Kennung für Inhaltsgruppen miteinander verknüpft werden. Sprache, Region, Veröffentlichungsstatus und Quellversion sollten separat erfasst werden, statt die Zuordnung anhand von Titeln oder URLs zu erraten.

Bei der Bewertung einer Headless CMS for global websites solution sollten das Inhaltsmodell, der Übersetzungsprozess und die Frontend-Ausgabe gemeinsam geprüft werden. Dass ein CMS Verknüpfungen speichert, bedeutet nicht automatisch, dass die Website die Sprache korrekt wechselt oder hreflang erzeugt. Die API für die Bereitstellung muss genügend Informationen liefern, damit das Frontend erkennen kann, „welche Sprachversionen desselben Inhalts öffentlich zugänglich sind“.

Zuerst definieren, was „derselbe Inhalt“ ist, und dann entscheiden, wie Übersetzungen gespeichert werden

Englische und deutsche Beschreibungen desselben Produkts gehören in der Regel zu derselben Inhaltsgruppe. Eine Aktionsseite für einen bestimmten Markt mit abweichenden Angebotsbedingungen ist jedoch nicht unbedingt lediglich eine Übersetzung. Vor der Modellierung sollte geklärt werden, welche Seiten dieselbe geschäftliche Identität teilen und welche eigenständige Marktinhalte darstellen. Andernfalls kann eine erzwungene Zuordnung Nutzer zu einer inhaltlich nicht gleichwertigen Seite führen.

Es empfiehlt sich, die geschäftliche Identität von der Identität der Sprachversion zu trennen, damit Verknüpfungen bei Änderungen von Sprachtiteln oder Pfaden nicht ungültig werden:

• contentGroupId: Kennzeichnet denselben Inhalt über verschiedene Sprachen hinweg und ändert sich nicht durch Übersetzung oder Umbenennung.
• variantId und locale: Kennzeichnen die konkrete Version und ihr Sprachgebiet, zum Beispiel de-DE; innerhalb derselben Gruppe sollte für gleiche locale-Werte eine Eindeutigkeitsbedingung gelten.
• sourceVariantId und sourceRevision: Erfassen, auf welcher Version und welchem Änderungsstand die Übersetzung beruht, damit ihre Aktualität beurteilt werden kann.
• slug, Status und Veröffentlichungszeitpunkt: Werden für jede Sprachversion eigenständig verwaltet. Der Veröffentlichungsstatus der Quellsprache wird nicht automatisch übernommen.

Sprachcodes sollten dem Format BCP 47 entsprechen. Ob eine Unterscheidung zwischen en-US und en-GB erforderlich ist, sollte von den inhaltlichen Unterschieden abhängen und nicht allein davon, ob ein bestimmtes Zielland vorliegt. Marktkennungen in Geschäftssystemen können separat gespeichert werden und sollten nicht mit dem Sprachfeld vermischt werden.

Feldlokalisierung oder eigenständige Spracheinträge – wie trifft man die Wahl?

Beide Modelle können Verknüpfungen herstellen. Sie unterscheiden sich darin, wie granular Bearbeitung und Veröffentlichung erfolgen.

Produktmodelle und technische Daten können gemeinsam genutzt werden, während Titel, Beschreibungen und SEO-Texte sprachspezifisch gepflegt werden. Preise, Zertifizierungshinweise und Lieferbedingungen müssen dagegen möglicherweise marktbezogen angepasst werden. Nicht jedes Feld sollte pauschal übersetzt werden, und „gemeinsam genutzte Felder“ sollten tatsächliche regionale Unterschiede nicht verschleiern.

Die Verknüpfung muss außerdem referenzierte Inhalte umfassen. Wenn eine deutsche Produktseite auf englische Downloadmaterialien verweist, sollte das System ausdrücklich kennzeichnen, ob es sich um ein zulässiges gemeinsam genutztes Asset oder um eine fehlende deutsche Version handelt. Es reicht nicht aus, nur den Haupttext der Seite zu prüfen.

Übersetzungsverknüpfungen in den Veröffentlichungsprozess integrieren – nicht nur in die Bearbeitungsoberfläche

Dass eine Übersetzung vorhanden ist, bedeutet nicht, dass sie noch aktuell ist. Nach Änderungen am Quelltext sollten der bei der Übersetzung gespeicherte Quelländerungsstand und der aktuelle Änderungsstand verglichen werden. Betroffene Versionen sollten als „Überprüfung ausstehend“ markiert werden, statt bereits freigegebene Texte direkt zu überschreiben. Ob eine ältere Übersetzung zurückgezogen wird, sollte vom Änderungsrisiko abhängen: Eine Anpassung der Formulierung und eine Änderung sicherheitsrelevanter Parameter sollten nicht nach derselben Strategie behandelt werden.

1. Sobald der Quelltext zur Übersetzung freigegeben ist, wird ein Auftrag mit Inhaltsgruppe, Sprache, Feldpfad und Quelländerungsstand erstellt.
2. Beim Eingang der Übersetzung wird der Quelländerungsstand geprüft. Hat sich der Quelltext geändert, bleibt der Übersetzungsentwurf erhalten und es wird auf den Konflikt hingewiesen, statt ihn stillschweigend zu überschreiben.
3. Bei der Prüfung werden Terminologie, referenzierte Ressourcen, regionale Einschränkungen und lokalisierte SEO-Felder kontrolliert. Anschließend erfolgt die Veröffentlichung durch entsprechend berechtigte Personen.
4. Nach der Veröffentlichung oder Zurücknahme wird über Webhooks der Neuaufbau der Seite, die Cache-Invalidierung und die Aktualisierung der Sprachnavigation ausgelöst. Fehlgeschlagene Ereignisse werden erneut verarbeitet.

Rückmeldungen zu Aufträgen müssen idempotent verarbeitet werden, damit Wiederholungsversuche keine doppelten Einträge erzeugen. Die Vorschau-API und die API für die öffentliche Bereitstellung sollten ebenfalls voneinander getrennt sein, damit Entwürfe nicht über die Liste der Sprachverknüpfungen online offengelegt werden.

Fallback-Ergebnisse der API müssen eindeutig erkennbar sein

Wird eine französische Seite angefordert, aber englischer Inhalt zurückgegeben, entsteht ein Widerspruch zwischen der Sprachangabe und dem Seiteninhalt, wenn das Frontend den Inhalt weiterhin als Französisch kennzeichnet. Die API sollte die angeforderte Sprache, die tatsächlich zurückgegebene Sprache und die Information, ob ein Fallback ausgelöst wurde, zurückgeben – nicht nur den Inhaltstext.

Es empfiehlt sich, für den Inhalt, Menüs und gemeinsam genutzte Assets jeweils eigene Fallback-Regeln festzulegen. Fehlt eine Menüübersetzung, kann je nach Produktstrategie ein Fallback verwendet werden. Ist die Übersetzung einer ganzen Seite noch nicht veröffentlicht, sollte hingegen ausdrücklich festgelegt werden, ob der Spracheinstieg ausgeblendet, die Nichtverfügbarkeit angezeigt oder zur Quellsprachen-URL weitergeleitet wird. Der Quelltext sollte nicht ohne Hinweis unter einer URL der Zielsprache kopiert werden.

Cache-Schlüssel sollten mindestens nach Inhalt, Sprache und Bereitstellungsumgebung unterscheiden. Andernfalls können trotz korrekter Verknüpfungen in der Datenbank durch gemeinsam verwendete Cache-Einträge identische Seiteninhalte auf Anfragen in verschiedenen Sprachen zurückgegeben werden.

SEO-Verknüpfungen dürfen nur auf tatsächlich erreichbare Versionen verweisen

Für den Sprachwechsel und hreflang sollten dieselben Daten zu veröffentlichten Verknüpfungen verwendet werden. Beim Sprachwechsel sollte die Inhaltsgruppe erhalten bleiben, statt lediglich das Sprachpräfix im Pfad auszutauschen. Existiert die Zielversion nicht, sollte kein Link erzeugt werden, der nur scheinbar gültig ist.

• hreflang sollte die aktuelle Seite selbst sowie tatsächlich vorhandene zugehörige Versionen umfassen; die Sprach- und Regionscodes müssen außerdem einem von Suchmaschinen unterstützten Format entsprechen.
• Indexierbare eigenständige Sprachseiten verwenden üblicherweise ein auf sich selbst verweisendes canonical-Tag. Sie sollten nicht einheitlich auf die Seite in der Quellsprache verweisen, da dies widersprüchliche Signale zur Kanonisierung sendet.
• Nicht veröffentlichte, weitergeleitete, fehlerhaft antwortende oder auf noindex gesetzte Versionen sollten nicht weiterhin als für die Indexierung vorgesehene Sprachalternativen ausgegeben werden.

Bei der Abnahme lassen sich anhand derselben Inhaltsgruppe vier Fälle testen: „Quelltext geändert“, „Übersetzung nicht veröffentlicht“, „Sprachversion offline genommen“ und „slug umbenannt“. Dabei sollte beobachtet werden, ob sich API, Sprachnavigation, Cache und hreflang synchron ändern. Zeigt das Backend intakte Verknüpfungen an, während online weiterhin ungültige Adressen vorhanden sind, sollten zuerst der Veröffentlichungsprozess und die Frontend-Build-Pipeline untersucht werden, statt die Übersetzungsverknüpfungen neu anzulegen.