Headless WordPress wird mehrsprachig, indem ein Übersetzungs-Plugin wie Polylang oder WPML die Sprachversionen im Backend verwaltet und das Frontend pro Sprache eine eigene Route mit korrekten hreflang-Angaben rendert — die Daten kommen über REST oder WPGraphQL, das Sprach-Routing und hreflang gehören ins Frontend. In Schweizer Projekten ist das kein Randfall: Deutsch ist für 61,4 %, Französisch für 22,6 % und Italienisch für 8,2 % der Bevölkerung Hauptsprache (BfS, Sprachenlandschaft, 2023). Eine Site, die nur Deutsch spricht, kann je nach Markt einen erheblichen Teil des Heimmarkts links liegen lassen. Für Firmen mit nennenswertem Umsatz aus der Romandie oder dem Tessin sind Französisch und Italienisch keine Kür — und für international verkaufende Häuser kommt oft Englisch dazu. Genau diese Realität macht Mehrsprachigkeit zum stärksten einzelnen Kostentreiber in jedem Headless-Projekt, wie schon die Aufstellung zu den Kosten eines Headless-WordPress-Projekts zeigt. Dieser Beitrag geht eine Ebene tiefer: Wie funktioniert Mehrsprachigkeit im Headless-Setup wirklich — von der Wahl des Übersetzungs-Plugins über die API bis zu den hreflang-Tags im Frontend?
Der kurze Mehrsprachigkeits-Abschnitt zur Sprachfilterung über die API hat die Schnittstellen-Frage angerissen. Hier vertiefen wir den ganzen Pfad — und sagen ehrlich, ab wann Mehrsprachigkeit den Aufwand wirklich treibt und wann eine zweite Sprache schlicht nicht lohnt.
Warum ist Mehrsprachigkeit in der Schweiz der teuerste Treiber?
Mehrsprachigkeit ist in einem Schweizer Headless-Projekt der teuerste einzelne Kostentreiber, weil sie nicht nur Übersetzung bedeutet, sondern parallele Inhaltsbäume, sprachgebundenes Routing, korrekte hreflang-Auszeichnung und sprachspezifische Sitemaps. Jede dieser technischen Ebenen zieht zusätzliche Komplexität ein — und drei der vier Landessprachen sind für eine national auftretende Site geschäftsrelevant.
Die Schweiz hat vier Landessprachen, und drei davon — Deutsch, Französisch, Italienisch — sind für eine national auftretende Site geschäftsrelevant. Wenn ein relevanter Teil Ihres Umsatzes aus der Romandie oder dem Tessin kommt, führt an FR oder IT kaum ein Weg vorbei — eine Versicherung, ein Industriezulieferer oder eine Kanzlei mit Westschweizer Mandantschaft braucht die französische Fassung. Ist Ihr Markt faktisch die Deutschschweiz oder international-englisch, kann eine Sprache aber die ehrlichere Wahl sein. Dass die Sprachen im Alltag tatsächlich nebeneinander leben, zeigt die BfS-Erhebung: 68 % der Bevölkerung nutzen regelmässig mehr als eine Sprache (BfS, Sprache und Religion, 2019/2021). Wo mehrere Sprachen zusammenkommen, ist das Resultat: mehrere parallele Inhaltsbäume statt einem.
Der Aufwand entsteht nicht nur durch die Übersetzung der Texte. Teuer wird die technische Mechanik dahinter: ein mehrsprachiges Datenmodell, sprachgebundenes Routing, korrekte hreflang-Auszeichnung, sprachspezifische Sitemaps und ein Redaktions-Workflow, der Übersetzungen sauber verknüpft hält. Jede dieser Ebenen zieht zusätzliche Komplexität ein.
Die gute Nachricht: Über die mehrsprachigen Schweizer Builds, die wir 2024 bis 2026 ausgeliefert haben — durchweg DE/FR, teils mit IT —, landet der technische Mehraufwand für eine zweite Sprache erfahrungsgemäss bei etwa 15 bis 25 % auf den Frontend-Aufwand obendrauf — nicht bei 100 %, sofern das Datenmodell von Anfang an mehrsprachig gedacht ist. Gemeint ist die Mechanik: Sprach-Routing, hreflang-Verdrahtung, das Auflösen des Sprachumschalters und sprachspezifische Sitemaps. Die Übersetzung der Texte ist ein separater, redaktioneller Posten und in der Praxis oft der grössere. Die teure Variante ist die nachträgliche — eine einsprachige Site rückwirkend mehrsprachig zu machen bedeutet, Routing, hreflang und Workflow neu einzuziehen, und dieser technische Anteil kann sich verdoppeln. Mehrsprachigkeit ist deshalb die eine Architekturentscheidung, die man am besten am Tag null trifft, nicht im zweiten Jahr.
Polylang oder WPML für Headless WordPress?
Polylang und WPML eignen sich beide für Headless WordPress, die Wahl hängt am Redaktions-Workflow, nicht an der Technik: Polylang passt für klar getrennte Sprachen mit schlanker Pflege und einer frei verfügbaren WPGraphQL-Erweiterung, WPML für redaktionsintensive Setups mit Übersetzungsdiensten und granularer String-Übersetzung. Beide exponieren ihre Sprachdaten über REST und WPGraphQL.
Im klassischen WordPress sind Polylang und WPML die zwei etablierten Übersetzungs-Plugins. Im Headless-Setup zählt vor allem eine Frage: Wie gut exponieren sie ihre Sprachdaten über die API, die das Frontend anspricht — REST oder WPGraphQL?
Vorab eine ehrliche Einordnung: Polylang und WPML sind nicht die einzigen Wege. Man kann pro Sprache eine WordPress-Multisite betreiben, oder die Übersetzung ganz aus WordPress heraushalten und sie im Frontend mit next-intl pflegen, während WordPress einsprachig bleibt. Beides ist valide. Wir fokussieren hier auf Polylang und WPML, weil sie Redaktion und Übersetzungsrelationen im Backend halten — was bei mehr als einer Handvoll Seitentypen und laufender redaktioneller Pflege meist gewinnt, weil Übersetzungen dann an den Inhalten hängen und nicht in einem zweiten System leben.
Polylang headless
Polylang filtert die WordPress-Query standardmässig auf die aktuelle Sprache. Über die REST API funktioniert das lang-Argument für Beiträge und Taxonomien, unabhängig vom Inhaltstyp — man fragt also gezielt die französische oder italienische Variante ab (Polylang REST API-Dokumentation, 2026). Für WPGraphQL gibt es die frei verfügbare Polylang-Erweiterung von Valu Digital, die das GraphQL-Schema um Sprachdaten ergänzt. Interessantes Detail: Polylang beschränkt die Query normalerweise auf die Standardsprache — die Erweiterung hebt das für die GraphQL-API gezielt wieder auf und erlaubt das Filtern per language-Argument, mit ALL als Vorgabe. Operativer Hinweis: Diese Erweiterung ist gratis, wird aber im Community-Tempo gepflegt. Nach grösseren WordPress- oder WPGraphQL-Releases lohnt es sich, Versionen zu pinnen und eine gelegentliche Kompatibilitätslücke einzuplanen, bis die Erweiterung nachzieht.
WPML headless
WPML ist das umfangreichere Plugin, mit stärkerem Fokus auf redaktionelle Übersetzungs-Workflows, Anbindung externer Übersetzungsdienste und granulare String-Übersetzung. Für Headless liefert die WPML-GraphQL-Erweiterung Übersetzungen für Beiträge, Taxonomien, Kommentare und Menüs und gibt zu jedem Inhalt die Sprachinformation zurück; sprachabhängige ACF-Options-Pages kommen über das separate ACFML-Modul dazu. Im Gegenzug ist WPML kein Gratis-Plugin: Es kostet eine jährliche Lizenz, dafür gibt es engeren Support — ein TCO-Posten, den man bei redaktionsintensiven Setups von Anfang an einrechnet.
Eine bekannte Grenze gehört in jede ehrliche Bilanz: Über GraphQL liefert eine Abfrage Inhalte pro Aufruf in einer Sprache. Wer in einem einzigen Request mehrere Sprachen braucht, nutzt den dokumentierten Workaround — entweder eine Abfrage ohne Sprachfilter, die alle Beiträge listet, oder mehrere aliasierte Teilabfragen pro Sprache im selben Request (WPML GraphQL, 2024). In der Praxis ist das selten ein Problem, weil ein Frontend ohnehin pro Seitenaufruf eine Sprache rendert — aber für einen Sprachumschalter, der alle Übersetzungs-Varianten kennen muss, ist es ein Punkt, den man im Datenmodell einplant.
| Kriterium | Polylang | WPML |
|---|---|---|
| REST-API-Sprachfilter | lang-Argument für Beiträge und Taxonomien | Sprachgebundene Endpunkte und Parameter |
| WPGraphQL-Erweiterung | frei, von Valu Digital gepflegt | offizielle WPML-GraphQL-Erweiterung |
| Übersetzungs-Workflow | schlank, manuell pro Sprache | umfangreich, mit Übersetzungsdiensten |
| String-Übersetzung | Basis | granular, eigenes Modul |
| Mehrere Sprachen pro GraphQL-Abfrage | eine Sprache pro Aufruf | eine Sprache pro Aufruf, Workaround dokumentiert |
| Passt für | klar getrennte Sprachen, schlanke Pflege | redaktionsintensive Übersetzungs-Prozesse |
Welche Schnittstelle — REST oder WPGraphQL für Mehrsprachigkeit — überhaupt zum Projekt passt, ist eine eigene Entscheidung, die der Vergleich von WPGraphQL und REST API im Detail behandelt. Für Mehrsprachigkeit gilt vereinfacht: Bei verschachtelten, datenreichen Frontends mit Sprachumschalter spielt WPGraphQL seine Stärke aus; bei schlanken Sites genügt die REST-Sprachfilterung.
Wie kommt hreflang in eine Headless-Site?
In einer Headless-Architektur gehört hreflang ins Frontend, nicht ins Backend: Das Übersetzungs-Plugin liefert die Information, welche Beiträge zueinandergehören, aber die <link rel="alternate" hreflang>-Tags, die Google sagen, welche Sprachversion für welchen Markt gilt, rendert das Frontend-Framework — bei Next.js über die Metadata-API. Genau an diesem Punkt scheitern mehrsprachige Headless-Projekte am häufigsten.
Bei Next.js läuft das über die Metadata-API. Pro Seite gibt man unter alternates.languages eine Zuordnung von Sprach-Region-Code zur jeweiligen URL an — plus einen x-default für den Fall, dass keine Sprache passt:
export const metadata = {
alternates: {
canonical: "https://example.ch/de/leistungen",
languages: {
"de-CH": "https://example.ch/de/leistungen",
"fr-CH": "https://example.ch/fr/prestations",
"it-CH": "https://example.ch/it/servizi",
"x-default": "https://example.ch/de/leistungen",
},
},
};Next.js erzeugt daraus die hreflang-Tags im <head> jeder Seite (Next.js generateMetadata-Referenz, 2026). Den Wert für languages baut man dynamisch aus den Übersetzungsrelationen, die das Plugin liefert — die fr- und it-Variante eines Beitrags samt ihrer übersetzten Slugs. x-default ist dabei nicht Pflicht, aber dringend empfohlen: Google führt ihn als Fallback für nicht zugeordnete Sprachen — besonders auf Sprachwählern und automatisch umleitenden Startseiten — und empfiehlt ihn ausdrücklich; ohne ihn überlässt man Google die Wahl der Default-Version. Der Punkt, an dem hreflang in Googles Sinne tatsächlich bricht, ist ein anderer: Verweisen die Sprachvarianten nicht wechselseitig aufeinander, ignoriert Google die Auszeichnung (Google Search Central, lokalisierte Versionen, 2026).
next-intl: Routing und hreflang zusammen
Mit dem App Router hat Next.js die früher eingebaute i18n-Konfiguration entfernt. Sprach-Routing wird heute über ein [locale]-Segment plus eine Bibliothek wie next-intl gelöst, die Routing, Übersetzungs-Strings und Metadata zusammenhält — die alternates.languages aus dem Code oben entstehen dann pro Locale aus derselben Quelle wie das Routing, statt von Hand gepflegt zu werden.
Wann braucht eine Schweizer Site de-CH statt nur de?
Eine Schweizer Site braucht den Region-Code de-CH erst, wenn dieselbe Sprache mehrere Märkte bedient — etwa wenn Deutsch sowohl die Schweiz als auch Deutschland adressiert. Für eine Site, die ausschliesslich den Schweizer Heimmarkt anspricht, genügt laut Google oft die reine Sprache (de, fr, it); der Region-Code ist dann optional.
Ein hreflang-Wert besteht aus einem Sprachcode (ISO 639-1) und optional einer Region (ISO 3166-1 Alpha-2). Für die Schweiz sind die relevanten Codes de-CH, fr-CH, it-CH und — wo zutreffend — en-CH. Die Region ist laut Google optional und wird genau dann wichtig, wenn dieselbe Sprache über Ländergrenzen hinweg ausgespielt wird (Google Search Central, lokalisierte Versionen, 2026): Eine deutschsprachige Site, die sowohl die Schweiz als auch Deutschland adressiert, sollte de-CH und de-DE als getrennte Varianten führen — sonst riskiert man, dass Google die deutsche Fassung im Schweizer Markt zeigt oder umgekehrt.
hreflang sorgt dafür, dass Google jedem Nutzer die richtige Sprach- und Regionsvariante zeigt und die Ranking-Signale echter Alternativen bündelt — nicht dafür, eine Duplikat-Strafe abzuwenden. Verschiedene Sprachen sind für Google ohnehin keine Duplikate.
Adressiert eine Site dagegen ausschliesslich den Schweizer Heimmarkt, genügt für die Sprachtrennung oft die reine Sprache (de, fr, it) — die Region-Angabe schadet nicht, bringt aber nur dann echten Nutzen, wenn ein zweiter Markt mit derselben Sprache existiert. Die Faustregel: Region-Code, sobald dieselbe Sprache zwei Märkte bedient; sonst reicht die Sprache. Für die meisten Schweizer KMU mit nationalem Fokus ist die saubere DE/FR/IT-Trennung der Kern — de-CH, de-DE und de-AT kommen ins Spiel, sobald der DACH-Raum als Ganzes adressiert wird und dieselbe Sprache in mehreren Ländern ausgespielt werden soll. Genau hier — gleiche Sprache, mehrere Länder — liegt übrigens der einzige echte Duplikat-Fall: de-CH und de-DE zeigen weitgehend identischen Text, und ohne saubere hreflang-Trennung kann Google die falsche regionale Fassung ausspielen. Verschiedene Sprachen dagegen sind nie Duplikate.
Wie funktioniert Sprach-Routing, Umschalter und Redaktion?
Aus den Übersetzungsdaten wird eine benutzbare mehrsprachige Site über drei Bausteine: ein Sprach-Routing (meist das Unterverzeichnis /de/, /fr/, /it/ auf einer .ch-Domain), einen Language-Switcher, der pro Seite die übersetzte Variante auflöst, und einen klaren Redaktions-Workflow für verknüpfte Sprachversionen. Der dritte Baustein ändert am meisten für die Menschen, die täglich damit arbeiten.
Sprach-Routing: Verzeichnis, Subdomain oder ccTLD
Zuerst die Struktur-Entscheidung. Für eine Schweizer Site mit mehreren Sprachen ist das Sprach-Unterverzeichnis (/de/, /fr/, /it/ auf einer .ch-Domain) fast immer die richtige Wahl: Es bündelt die Autorität auf einer Domain und ist im Frontend am einfachsten zu routen. Subdomains (fr.example.ch) und länderspezifische Domains (example.fr) sind aufwendiger zu pflegen und lohnen sich erst, wenn pro Markt eigene Infrastruktur, Hosting-Standorte oder rechtlich getrennte Einheiten dahinterstehen — bei einem Schweizer KMU selten der Fall. Das Frontend leitet anhand des Präfixes auf den richtigen Inhaltsbaum. Saubere, sprechende Slugs pro Sprache (/fr/prestations statt /fr/leistungen) sind dabei kein Detail, sondern ein SEO-Faktor: Französische Nutzer und französische Suchmaschinen-Resultate erwarten französische URLs. Achtung bei Akzenten in FR-Slugs — WordPress wandelt é, à und Co. beim Speichern in ASCII um (/fr/securite statt /fr/sécurité); das Frontend muss diese sanitisierten Slugs aus dem Plugin übernehmen und nicht selbst neu erzeugen, sonst laufen Switcher und hreflang auf unterschiedliche URLs.
Language-Switcher: die aktuelle Seite auflösen
Der Umschalter darf nicht einfach auf die Startseite der anderen Sprache springen, sondern muss für die aktuelle Seite die übersetzte Variante auflösen — von /de/leistungen zu /fr/prestations. Genau hier braucht das Frontend die Übersetzungsrelationen aus dem Plugin: Welcher französische Beitrag ist die Übersetzung dieses deutschen? Über WPGraphQL lässt sich das als verschachtelte Abfrage formulieren, in der man pro Sprache eine aliasierte Teilabfrage schreibt (de: post(language: DE){…} fr: post(language: FR){…}); über REST sind es meist mehrere sprachgebundene Aufrufe. Ein Stolperstein aus der Praxis: Polylangs Default-Sprachfilter lässt FR- oder IT-Beiträge in einer ungeprüften Abfrage stillschweigend wegfallen — taucht eine Sprache im Build plötzlich nicht auf, ist fast immer der fehlende language: ALL- oder Sprach-Parameter die Ursache. Existiert für eine Seite keine Übersetzung, sollte der Umschalter das ehrlich abbilden — entweder ausblenden oder klar auf die Sprachhauptseite verweisen.
Der Redaktions-Workflow
Für die Redaktion ändert sich am meisten. Statt eines Beitrags pflegen sie pro Inhalt mehrere verknüpfte Sprachversionen. Polylang und WPML bilden diese Verknüpfung im Backend ab, aber der redaktionelle Prozess muss klar sein: Wer übersetzt? Wird zuerst Deutsch finalisiert und dann übersetzt, oder pflegen verschiedene Sprachteams parallel? Was passiert, wenn die deutsche Version aktualisiert wird — gibt es eine sichtbare Markierung, dass die französische Übersetzung veraltet ist? WPML bringt für solche Workflows mehr Werkzeuge mit; Polylang setzt auf einen schlankeren, manuelleren Ansatz. Wer die redaktionelle Seite des Headless-Setups grundsätzlich verstehen will, findet im Beitrag zur Redaktions- und Editor-Erfahrung in Headless WordPress die Einordnung.
Wann lohnt Mehrsprachigkeit den Aufwand nicht?
Mehrsprachigkeit lohnt den Headless-Aufwand nicht, wenn die Site unter etwa 15 Seiten hat, sich selten ändert und nur DE plus FR braucht — dann ist klassisches WordPress mit Polylang oft die günstigere, völlig ausreichende Lösung. Und auch wo Headless passt, lohnt eine zweite Sprache nur bei echter Marktrelevanz und gesicherter dauerhafter Pflege.
Zuerst der grössere Punkt: Wenn Ihre Site unter etwa 15 Seiten hat, sich selten ändert und nur DE plus FR braucht, ist klassisches WordPress mit Polylang — ohne Headless — oft die günstigere und völlig ausreichende Lösung. Ein Standard-Theme bedient beide Sprachen, hreflang und Sitemap erledigt das Plugin, und Sie sparen sich die komplette Frontend-Schicht. Headless-Mehrsprachigkeit zahlt sich erst aus, wenn mehrere Faktoren zusammenkommen: viele Seitentypen oder Inhaltsmodelle, hohe Redaktionsfrequenz, ein echter Performance- oder Interaktivitäts-Anspruch im Frontend, oder die Integration mehrerer Datenquellen. Fehlt das, kaufen Sie mit Headless Komplexität, die der Markt nicht zurückzahlt.
Und auch wo Headless passt, lohnt nicht jede zweite oder dritte Sprache. Sie lohnt nur, wenn dahinter echte Marktrelevanz und die Bereitschaft zur dauerhaften Pflege steht. Eine französische Version, die einmal übersetzt und dann zwei Jahre nicht aktualisiert wird, schadet mehr als sie nützt: Sie zeigt veraltete Inhalte, kann für überholte Informationen ranken und verwässert die Qualität Ihrer hreflang-Signale, weil Google Alternativen ausspielt, die nicht mehr stimmen. In solchen Fällen ist eine fokussierte, gepflegte einsprachige Site die bessere Wahl — kombiniert mit einer einzelnen, hochwertigen Übersichtsseite in der Zweitsprache, die auf Kontaktaufnahme statt auf vollständige Spiegelung setzt.
Auch die Reihenfolge zählt. Wer noch am Anfang steht und unsicher ist, ob die zweite Sprache je kommt, baut das Datenmodell mehrsprachig-fähig, startet aber einsprachig. Das hält die Tür offen, ohne sofort die volle Komplexität zu zahlen. Die teure Falle ist die umgekehrte: einsprachig bauen ohne Vorkehrung und später alles umstellen müssen. Ob ein Headless-Setup für Ihre Ausgangslage überhaupt der richtige Weg ist — mit oder ohne Mehrsprachigkeit —, klärt der Beitrag wann sich Headless WordPress lohnt grundsätzlicher.
| Profil | Empfehlung | Warum |
|---|---|---|
| Nationale CH-Site, DE/FR/IT geschäftsrelevant, laufende Pflege gesichert | Vollständige Mehrsprachigkeit mit Polylang oder WPML | Marktrelevanz und Pflege rechtfertigen den Aufwand; Datenmodell von Tag null mehrsprachig |
| Redaktionsintensiv, externe Übersetzungsdienste, granulare Strings | WPML + GraphQL-Erweiterung | Übersetzungs-Workflow und String-Management sind der Engpass, nicht die Technik |
| Klar getrennte Sprachen, schlanke Pflege, wenige Seitentypen | Polylang + REST oder WPGraphQL | Leichtgewichtige API-Anbindung, weniger Konfigurations-Overhead |
| DACH-weit, dieselbe Sprache für CH und DE | hreflang mit de-CH / de-DE getrennt | Region-Codes verhindern, dass Google die Märkte vermischt oder als Duplikate wertet |
| Unsicher, ob Zweitsprache kommt; geringe Pflege-Ressourcen | Einsprachig starten, Datenmodell mehrsprachig-fähig halten | Tür offen halten, ohne sofort volle Komplexität und Pflegelast zu zahlen |
Mehrsprachigkeit: Empfehlung nach Projektprofil, Stand Mitte 2026. Quelle: eigene Projekterfahrung, Plugin-Dokumentation und Google Search Central.
Die Matrix ersetzt kein Architektur-Review, gibt aber eine belastbare Vorab-Tendenz. In Grenzfällen gibt fast immer die Pflege-Frage den Ausschlag: Eine zweite Sprache, die monatlich aktualisiert wird, trägt; eine, die nach dem Launch liegen bleibt, kostet Vertrauen und SEO-Signalqualität, ohne neuen Markt zu erschliessen.
Nächster Schritt
Ob Ihre Site eine, zwei oder vier Sprachen braucht — und wie ein mehrsprachiges Datenmodell von Anfang an sauber aufgesetzt wird —, lässt sich in einem kurzen Gespräch einordnen. Wenn Sie ein mehrsprachiges Headless-Projekt planen oder eine bestehende Site erweitern wollen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos. In dieser Zeit klären wir Sprachen, Märkte, Übersetzungs-Workflow und die passende Plugin- und API-Strategie.
Wer zuerst die grössere Linie verstehen will, findet auf der Themenseite zu Headless WordPress die Einordnung, wie Backend, API und Frontend zusammenspielen — die Basis, auf der Mehrsprachigkeit sauber aufsetzt. Und wenn Sie wissen wollen, wo Ihre aktuelle Site bei Performance und SEO steht, gibt der kostenlose Website-Check in unter einer Minute eine erste Orientierung.