WPML im Betrieb: Spracharchitektur, hreflang und Übersetzungsprozesse in WordPress

Eine mehrsprachige Website ist kein Übersetzungsprojekt mit Enddatum, sondern Dauerbetrieb. WPML, ein kommerzielles WordPress-Plugin zum Erstellen und Betreiben mehrsprachiger Websites, hält Seiten, Beiträge und Kategorien als verknüpfte Sprachversionen innerhalb einer einzigen WordPress-Installation zusammen. Das ist die Stärke des Plugins und zugleich der Grund, warum Fehler selten lokal bleiben: Eine falsch gesetzte Feldoption oder ein nachträglich geänderter URL-Modus wirkt sofort in allen Sprachen.

Dieser Text setzt eine lauffähige Installation voraus und beschreibt, was danach kommt: Architekturentscheidungen, Workflow, SEO-Kontrolle, Shop-Betrieb und die Fehler, die erst Monate später auffallen.

Spracharchitektur vor der ersten Übersetzung festlegen

Sprache ist nicht gleich Markt. Deutsch bedient Deutschland, Österreich und die Schweiz, aber Preise, Ansprechpartner und Rechtstexte unterscheiden sich womöglich. Umgekehrt braucht dieselbe Sprache für Großbritannien und die USA unter Umständen eigene Inhalte. Bevor jemand übersetzt, gehören fünf Punkte schriftlich fixiert:

• Ist eine Sprachversion eine reine Übersetzung oder eine Marktvariante mit eigenen Inhalten?
• Welche Sprache ist verbindliche Ausgangssprache, und zwar für alle Inhaltstypen?
• Müssen wirklich alle Inhalte in jeder Sprache existieren?
• Welche Custom Post Types und Taxonomien werden übersetzt, welche nur kopiert, welche gar nicht angezeigt?
• Wer übersetzt, wer prüft, wer gibt frei?

Die Ausgangssprache sollte stabil bleiben. Wird sie später gewechselt oder pflegt ein Team Originale auf Deutsch und ein anderes auf Englisch, verlieren die Verknüpfungen zwischen Original und Übersetzung ihre Ordnung, und niemand kann mehr zuverlässig sagen, welche Fassung führend ist.

Referenzen, Standorte, Leistungen und Produktmerkmale gehören ausdrücklich in diese Planung. Genau dort entstehen später halb übersetzte Archivseiten.

Das URL-Modell entscheidet über Aufwand und Sichtbarkeit

WPML bietet drei Grundvarianten für Sprach-URLs. Die Wahl ist eine Architekturentscheidung, keine Einstellung.

Für die meisten Projekte ist das Sprachverzeichnis die praktikabelste Wahl. Getrennte Domains lohnen sich, wenn Länder wirklich eigenständig arbeiten, kosten aber dauerhaft mehr Pflege.

Entscheidend ist der Zeitpunkt: vor dem produktiven Start. Eine spätere Umstellung verändert jede URL der Website und verlangt ein vollständiges Weiterleitungskonzept. Ohne das entstehen 404-Fehler, verlorene Rankings und widersprüchliche Signale.

Slugs gehören übersetzt, nicht übernommen. Aus /de/leistungen/seo-beratung/ wird /en/services/seo-consulting/. Ein englischer Pfad mit deutschem Slug wirkt in der Suche wie ein halb fertiger Import.

hreflang und Canonical erfüllen verschiedene Aufgaben

WPML gibt für verknüpfte Übersetzungen hreflang-Verweise aus. Jede Seite verweist dabei auf sich selbst und auf alle Alternativen:

<link rel="alternate" hreflang="de-DE" href="https://example.com/de/leistung/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en/service/" />

Automatische Ausgabe ersetzt keine Kontrolle. Nach jeder neuen Sprache, jedem Domainwechsel und jedem Update des SEO-Plugins lohnt eine Stichprobe im Quelltext:

• Sind die Verweise wechselseitig, verweist also jede Seite auf jede andere?
• Zeigen alle hreflang-URLs auf erreichbare Seiten ohne zwischengeschaltete Weiterleitung?
• Stimmen Sprach- und Regionscodes, also de-AT statt de-at oder at?
• Ist jede Sprachversion indexierbar?
• Zeigt der Canonical auf die jeweilige Sprachseite selbst?

Der häufigste und teuerste Fehler in diesem Bereich ist ein Canonical von allen Übersetzungen auf das Original. Die übersetzte Seite gilt dann als Duplikat und wird oft nicht eigenständig indexiert. hreflang ersetzt weder Canonical noch Weiterleitung. Ein x-default gehört auf eine neutrale Startseite oder eine echte Sprachauswahl, nicht pauschal auf die Lieblingssprache des Unternehmens.

Ein Übersetzungsworkflow, der Änderungen aushält

Spontane Übersetzungen tragen bis etwa zwanzig Seiten. Sobald mehrere Personen, Sprachen und regelmäßige Aktualisierungen zusammenkommen, braucht es einen festen Ablauf:

1. Der Inhalt wird in der Ausgangssprache final freigegeben, nicht im Entwurf übersetzt.
2. Die Seite wird einem Übersetzer oder einer Übersetzungsmethode zugewiesen.
3. Terminologie, Pflichtangaben und Rechtstexte werden gegen das Glossar geprüft.
4. Die Übersetzung wird im Frontend kontrolliert, nicht nur im Editor.
5. Veröffentlichung und Folgeänderungen werden dokumentiert.

Der Advanced Translation Editor hilft dabei, weil er die HTML-Struktur schützt und Translation Memory sowie Glossar einbezieht. Automatisch übersetzte Texte sollten trotzdem nie ungeprüft live gehen. Kritisch sind Überschriften, Buttons, Formulare, Produktvorteile, Fachbegriffe und alles mit rechtlicher Wirkung.

Der zweite Teil des Workflows ist der wichtigere: der Umgang mit Änderungen am Original. Schon eine korrigierte Telefonnummer markiert Übersetzungen als aktualisierungsbedürftig. Ohne feste Zuständigkeit sammeln sich diese Hinweise, bis niemand mehr unterscheiden kann, welche Änderung sprachlich relevant war und welche nicht.

Festlegen, wo Inhalte bearbeitet werden dürfen

Je nach Konfiguration lassen sich Übersetzungen im Übersetzungseditor oder direkt im WordPress-Editor pflegen. Der unkontrollierte Wechsel zwischen beiden Wegen ist die stille Ursache vieler Datenverluste: Was direkt in der übersetzten Seite geändert wurde, kann bei der nächsten Synchronisierung überschrieben werden.

Pro Inhaltstyp gehört deshalb verbindlich geregelt, welcher Editor gilt, wer Originale bearbeiten darf, wer Übersetzungen freigibt und wie Layoutänderungen in die Sprachversionen kommen. Besonders betroffen sind Page Builder, globale Elemente und benutzerdefinierte Felder.

Bei Feldern entscheidet die Bedeutung, nicht der technische Name. Steht ein Feld fälschlich auf Kopieren, überschreibt das Original einen bewusst lokalisierten Wert, etwa eine landesspezifische Telefonnummer. Steht ein rein technisches Feld auf Übersetzen, entsteht Doppelpflege ohne Nutzen.

WooCommerce: Produkte, Währungen und Shop-URLs

Für internationale Shops erweitert WPML Multilingual & Multicurrency for WooCommerce den Prozess um übersetzte Produkte und mehrere Währungen. Sprachversionen können dabei unterschiedliche Shop-URLs bekommen, und die Erweiterung ist auf das Zusammenspiel mit anderen WooCommerce-Erweiterungen ausgelegt. Übersetzte Produkte bleiben technisch verknüpft, Preise und Bestände lassen sich je nach Einstellung synchronisieren.

Vor dem Livegang gehört pro Sprache geprüft:

• Produkttitel, Beschreibungen, Kurzbeschreibungen
• Varianten und übersetzbare Attribute
• Kategorien, Schlagwörter, Versandklassen
• Warenkorb, Kasse und Systemmeldungen
• Transaktions-E-Mails, Steuertexte, Lieferzeiten
• Währungsumschaltung, Rundungsregeln, Zahlungsarten je Land
• Produkt-URLs und strukturierte Daten

Bei Attributen ist Konsequenz wichtiger als Vollständigkeit: Begriffe wie Farbe oder Material werden übersetzt, Größencodes und technische Kennungen meist nicht. Diese Regel gilt für den gesamten Katalog oder für keinen.

Testen Sie außerdem den Wechsel mitten im Kauf. Ob der Warenkorb beim Sprach- oder Währungswechsel erhalten bleibt, ist konfigurierbar. Entscheidend ist, dass Preis, Variante und Verfügbarkeit danach noch stimmen. Ein vollständiger Testkauf je Sprache ersetzt keine Checkliste, aber keine Checkliste ersetzt ihn.

Fehler, die erst im Betrieb sichtbar werden

Die meisten Probleme entstehen nicht bei der Einrichtung, sondern durch Updates und Redaktionsalltag:

• veröffentlichte Seiten ohne vollständige Übersetzung
• Sprachumschalter, die auf die Startseite statt auf das Gegenstück springen
• Übersetzungen mit Canonical auf das Original
• nicht übersetzte Kategorien, Formular- und Fehlertexte
• abweichende Menüstrukturen ohne redaktionelle Absicht
• gelöschte Originale mit weiter erreichbaren Übersetzungen
• unübersetzte SEO-Titel, Meta-Descriptions und Slugs
• gemischte Sprachen in Warenkorb und Kasse
• veraltete Übersetzungen nach Änderung des Originals
• Caches, die eine Seite in der falschen Sprache ausliefern

Nach Updates von WordPress, WPML, WooCommerce, Theme, Page Builder oder SEO-Plugin lohnt ein kurzer Regressionstest über Startseite, Navigation, wichtigste Landingpages, Formulare, Sprachwechsel und, falls vorhanden, den kompletten Kaufprozess.

Eine Betriebsroutine etablieren

Monatlich gehören offene Übersetzungsaufträge, fehlerhafte URLs, Indexierungsstatus und die zentralen Conversion-Seiten geprüft. Nach größeren Inhaltsänderungen kommt ein sprachübergreifender Abgleich dazu. Die Kontrolle findet im Frontend statt, auf Desktop und Mobilgerät, und umfasst neben dem Text auch Navigation, Formulare, Suche und lokale Pflichtangaben.

WPML übernimmt die technische Verknüpfung zuverlässig. Die Qualität über Jahre entsteht woanders: in einer klaren Spracharchitektur, in verbindlichen redaktionellen Regeln und in regelmäßiger SEO-Kontrolle. Wer diese drei Bereiche gemeinsam führt, verhindert, dass aus einer mehrsprachigen Website mehrere voneinander abweichende Teilauftritte werden, die sich gegenseitig Sichtbarkeit nehmen.