Globale Content-Strategie mit WordPress: Mehr als nur Übersetzung

Die globale Expansion eines Unternehmens ist ein massives Unterfangen. Ihre Website ist die digitale Botschaft Ihrer Marke in jedem neuen Land, das Sie betreten.

Im Jahr 2026 geht es beim Eintritt in einen neuen Markt nicht nur um die Installation eines Übersetzungs-Plugins. Globale Content-Strategie steht bei uns auf drei parallel laufenden Schienen: Routing und Hreflang, Automatisierung rund um Translation-Memory-Prozesse sowie kulturelles QA bei Begriffen und UX-Templates.

Dieser Leitfaden untersucht, wie man eine WordPress-Architektur aufbaut, die globale Skalierung ohne operatives Chaos unterstützt. Die Suchregeln unten stammen aus Google Search Central, das Plugin-Verhalten aus der Dokumentation von Polylang und WPML.

#Unterverzeichnis, Subdomain oder ccTLD für mehrsprachige Websites

Die erste Entscheidung, die Sie treffen, ist die dauerhafteste URL-Struktur.

• Unterverzeichnisse (example.com/de/): Der Goldstandard. Am besten zur Konsolidierung von Link-Equity (SEO-Autorität) in einer einzigen Domain. Am einfachsten in einer einzigen WordPress Multisite- oder Polylang-Installation zu verwalten.
• Subdomains (de.example.com): Nützlich, wenn Ihr deutsches Team volle Autonomie benötigt oder wenn die deutsche Seite auf einem physisch anderen Server-Cluster läuft. Schwieriger, SEO-Autorität aufzubauen.
• ccTLDs (example.de): Google beschreibt eine Länderdomain als starkes Signal für die Ausrichtung auf ein Land, sie ist aber am teuersten zu unterhalten. Sie starten mit null SEO-Autorität für jedes neue Land.

#Vor- und Nachteile der drei Strukturen

Unterverzeichnisse halten die gesamte Website auf einer Domain, daher stützen Links, die eine Sprachversion gewinnt, auch die anderen. Die Verwaltung bleibt zentral, die Infrastrukturkosten sind am niedrigsten. In WordPress ist ein Multisite-Netzwerk mit Unterverzeichnis-Subsites ein üblicher Weg dafür: Jede Subsite hat eigene Inhalte, Theme-Einstellungen und Optionen, alle teilen sich eine WordPress-Installation.

Subdomains trennen die Sprachversionen klar. Jede Subdomain kann auf einem anderen Server oder in einer anderen Region laufen, was hilft, wenn getrennte Teams die Märkte betreuen. Der Preis dafür ist mehr Verwaltungsaufwand, und Links auf eine Subdomain nützen den anderen weniger als auf einem einzigen Host.

Länderdomains wie example.es, example.com.mx oder example.com.br senden das stärkste geografische Signal und können lokales Vertrauen gewinnen. Sinnvoll sind sie für Unternehmen mit rechtlicher Präsenz in jedem Land. Jede Domain startet ohne Autorität, die Kosten für Linkaufbau vervielfachen sich, der Betrieb wird komplexer.

#Was Googles Dokumentation zu jeder URL-Struktur sagt

Googles Leitfaden zu mehrsprachigen und länderspezifischen Websites vergleicht vier Optionen:

Dieselbe Seite verlangt unterschiedliche URLs für unterschiedliche Sprachversionen und rät davon ab, die Sprache einer URL per Cookie oder Browsereinstellung umzuschalten.

Empfehlung: Für die meisten Unternehmen sind Unterverzeichnisse die richtige Wahl.

#Wie Polylang und WPML Sprachen auf URLs abbilden

Beide großen Plugins unterstützen alle drei Strukturen, die Wahl ist also eine Einstellung und kein Neubau.

Die URL-Optionen von Polylang bieten den Sprachcode als Parameter (?lang=en) bei einfachen Permalinks, die Sprache als Verzeichnisname (/en/my-post/), Standard bei sprechenden Permalinks, sowie Subdomains oder mehrere Domains. Bei Subdomains oder Domains müssen alle Hosts auf dasselbe WordPress-Stammverzeichnis zeigen. Polylang kann den Sprachcode der Standardsprache ausblenden, was bestehende URLs auf einer älteren Website erhält.

Die Sprach-URL-Formate von WPML sind Sprachen in Verzeichnissen, eine eigene Domain pro Sprache (getrennte Domains oder Subdomains) und der Sprachname als Parameter. Verzeichnisse brauchen sprechende Permalinks und das Rewrite-Modul von Apache. WPML warnt davor, echte Verzeichnisse anzulegen oder WordPress mehrfach zu installieren, und davor, eigene Weiterleitungsregeln in die .htaccess zu schreiben, weil WPML seine eigenen Weiterleitungen erzeugt. Eine Domain pro Sprache braucht DNS- und Serverkonfiguration. Das Parameterformat braucht keine Serveränderung, und genau dieses Format empfiehlt Google nicht.

#Unterschied zwischen Lokalisierung und Übersetzung

Übersetzung ist das Ändern von Wörtern. Lokalisierung ist das Ändern von Bedeutung.

• Währung: Rechnen Sie nicht einfach 100 $ in 92 € um. Machen Sie 99 € draus. Psychologische Preisgestaltung zählt.
• Daten: 05/04/2026 ist in den USA der 4. Mai, aber in Polen der 5. April. Verwenden Sie ISO (2026-05-04) oder ausgeschriebene Monate im Code.
• Bildsprache: Verwenden Sie Fotos, die die lokale Demografie widerspiegeln. Ein Foto eines American Football-Spiels wird in Brasilien nicht ankommen.

#Checkliste für Formate, Währung und kulturelle Anpassung

Formate und Konventionen, die pro Markt zu prüfen sind:

• Datumsformate: TT/MM/JJJJ in weiten Teilen Europas und Lateinamerikas, MM/TT/JJJJ in den USA
• Zahlentrenner: 1.000,50 in vielen europäischen Ländern, 1,000.50 in den USA und im Vereinigten Königreich
• Währung: Symbol, Position und Format ändern sich je Region
• Schreibrichtung: links nach rechts für lateinische Schriften, rechts nach links für Arabisch und Hebräisch
• Maßeinheiten: metrisch oder imperial

Kulturelle Anpassungen, die einzuplanen sind:

• Farbpaletten und ihre lokale Bedeutung
• Bilder und Models, die das lokale Publikum zeigen
• Ton und Förmlichkeit (tú oder usted im Spanischen, du oder Sie im Deutschen)
• Lokale Bezüge, Beispiele und Vergleiche
• Regulatorische Vorgaben (DSGVO, CCPA oder LGPD, je nach Region)

#Die fünf Ebenen der Website-Lokalisierung

1. Sprachliche Ebene: Übersetzung des Textes mit seinen kulturellen Nuancen.
2. Visuelle Ebene: Bilder, Farben und Layout.
3. Funktionale Ebene: Währungen, Zahlungsarten, lokale Formate.
4. SEO-Ebene: lokale Keywords, Hreflang, strukturierte Daten.
5. Regulatorische Ebene: Einhaltung lokaler Vorschriften.

#Häufige Hreflang-Fehler in WordPress

Hreflang ist das HTML-Tag, das Google sagt: “Diese Seite ist die deutsche Version jener englischen Seite.”

#Fehlende Rückverweise, Canonical-Konflikte und x-default

1. Fehlende reziproke Links: Einen Link von EN zu DE erstellen, aber den Link von DE zurück zu EN vergessen. Google ignoriert unterbrochene Ketten.
2. Kanonische Konflikte: Die kanonische URL der deutschen Seite auf die englische Version zeigen lassen. Damit bitten Sie Google, statt der deutschen die englische Seite zu indexieren. Die kanonische Selbstreferenz muss auf die deutsche URL zeigen.
3. x-default: Vergessen, einen Fallback für Benutzer festzulegen, die eine Sprache sprechen, die Sie nicht unterstützen (z.B. ein Benutzer aus Japan, der Ihre Seite besucht).

#Beispiel für Hreflang-Tags mit x-default

Jede Seite listet alle Sprachversionen auf, sich selbst eingeschlossen:

<link rel="alternate" hreflang="es" href="https://example.com/es/pagina/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="pt" href="https://example.com/pt/pagina/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/strona/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />

hreflang="es" steht für Spanisch allgemein, hreflang="es-MX" für Spanisch in Mexiko und hreflang="es-ES" für Spanisch in Spanien.

#Hreflang-Regeln aus Google Search Central

Googles Seite zu lokalisierten Versionen Ihrer Seiten legt die Regeln fest, die die meisten Audits prüfen:

• Es gibt drei gleichwertige Wege, Alternativen anzugeben: <link rel="alternate">-Elemente im Head, ein HTTP-Link-Header (nützlich für PDFs und andere Nicht-HTML-Dateien) oder xhtml:link-Einträge in einer XML-Sitemap. Alle drei gleichzeitig bringen keinen Zusatznutzen.
• Jede Sprachversion muss sich selbst und alle anderen Sprachversionen auflisten.
• Wenn zwei Seiten nicht gegenseitig aufeinander verweisen, werden die Tags ignoriert.
• Alternative URLs müssen vollständig sein, mit Protokoll, also https://example.com/foo und nicht //example.com/foo oder /foo. Sie müssen nicht auf derselben Domain liegen.
• Der Sprachcode folgt ISO 639-1, die optionale Region ISO 3166-1 Alpha 2. Eine Region allein ist ungültig, reservierte Codes wie UK oder EU wirken nicht (das Vereinigte Königreich ist GB).
• x-default ist der Fallback für Nutzer, deren Sprache zu keiner Ihrer Versionen passt, und war für Sprachauswahlseiten gedacht.

Google schreibt außerdem, dass es weder Hreflang noch das HTML-Attribut lang nutzt, um die Sprache einer Seite zu erkennen. Es liest den sichtbaren Inhalt. Ein deutsches Template mit englischem Fließtext ist für Google eine englische Seite, egal was die Tags sagen.

#Wie Polylang und WPML Hreflang ausgeben

In WordPress verantwortet meist das Mehrsprachigkeits-Plugin die Hreflang-Tags, nicht das SEO-Plugin. Polylangs eigener Artikel zu Hreflang-Attributen sagt, dass es die Tags automatisch setzt. Die Codes entstehen aus dem WordPress-Locale, der Unterstrich wird zum Bindestrich, aus en_ZA wird en-ZA. Polylang erzeugt x-default nur für die Startseite. Für andere Seiten fügen Sie es über den Filter pll_rel_hreflang_attributes hinzu.

WPMLs Anleitung zum Hinzufügen von Hreflang in WordPress sagt, dass WPML Hreflang-Tags automatisch einfügt und bei Änderungen an der Website aktualisiert. Ein regionaler Code wie fr-ca gehört in das Hreflang-Feld der Sprachzeile unter WPML, Settings, Languages. WPML warnt nicht vor ungültigen Werten, prüfen Sie sie daher selbst gegen die ISO-Listen.

In beiden Fällen stimmen die Tags nur, wenn jede Übersetzung im Plugin mit ihrem Original verknüpft ist. Ein übersetzter Beitrag, der als eigenständiger Beitrag angelegt wurde, bekommt gar kein Hreflang.

#Hreflang in der CI/CD-Pipeline validieren

Bauen Sie automatische Prüfungen in Ihre Deployment-Pipeline ein, die bestätigen:

• jede Seite hat einen vollständigen, wechselseitigen Hreflang-Satz
• jede referenzierte URL liefert 200
• das x-default-Tag ist vorhanden
• Sprach- und Regionscodes sind gültig

#WordPress-Übersetzung mit einem TMS automatisieren

Vorbei sind die Zeiten, in denen Word-Dokumente per E-Mail an Übersetzer geschickt wurden.

#WordPress mit Phrase, Lokalise oder Crowdin verbinden

Modernes WordPress verbindet sich direkt über APIs mit Systemen wie Phrase, Lokalise oder Crowdin.

1. Redakteur schreibt auf Englisch in Gutenberg.
2. Klick auf “Übersetzung anfordern”: Der Inhalt wird per API an das TMS gesendet.
3. KI + Mensch: DeepL macht den ersten Durchgang (sofort). Ein menschlicher Redakteur in Berlin prüft es (1 Stunde).
4. Auto-Import: Der genehmigte deutsche Text wird als Entwurf zurück in WordPress gepusht und benachrichtigt den Herausgeber.

Dies reduziert die Durchlaufzeit von Wochen auf Stunden.

Ein Translation Memory speichert jedes freigegebene Segment. Taucht ein ähnlicher Satz in einem späteren Artikel auf, schlägt es die frühere Übersetzung vor, und die Prüfer verbringen ihre Zeit mit neuem Text. Muttersprachliche Prüfer achten auf das, was maschinelle Übersetzung übersieht: kulturelle Nuancen, Branchenterminologie, Markenton und das passende Register.

#Übersetzungs-Plugins für WordPress

• WPML: das ausgereifteste Übersetzungs-Plugin, mit Anbindung an professionelle Übersetzungsdienste.
• TranslatePress: visuelle Übersetzung direkt im Frontend der Website.
• Weglot: ein SaaS-Dienst, der automatisch übersetzt und manuelle Prüfung erlaubt.
• DeepL API mit eigenem Plugin: für volle Kontrolle über den Übersetzungsablauf.

#Maschinelle Übersetzung und Googles Spam-Richtlinien

Googles Spam-Richtlinien definieren den Missbrauch skalierter Inhalte als viele Seiten, die vor allem erzeugt werden, um Rankings zu manipulieren, und nicht, um Nutzern zu helfen. Eines der genannten Beispiele sind fremde Inhalte, die durch automatische Umwandlungen, auch durch Übersetzen, zu vielen Seiten mit wenig Nutzen für die Leser werden. Eine geprüfte Übersetzung des eigenen Artikels ist ein anderer Fall, aber ungeprüfte Maschinenausgabe in jeder Sprache und in großer Menge rückt näher an diese Definition.

Der Leitfaden zu mehrsprachigen Websites ergänzt eine zweite Warnung: Übersetzen Sie nicht nur die Boilerplate (Menüs, Footer, Buttons), während der Hauptinhalt in einer Sprache bleibt. Google nennt das eine schlechte Nutzererfahrung, weil derselbe Inhalt dann in den Suchergebnissen unter verschiedenen Oberflächensprachen erscheint.

#Besucher automatisch per IP-Standort weiterleiten

Sie besuchen eine Seite. Sie erkennt, dass Sie in Frankreich sind. Sie leitet Sie sofort auf /fr/ weiter. Tun Sie das nicht.

#Warum IP-Weiterleitungen Googlebot und Reisenden schaden

1. Bot-Probleme: Der Googlebot crawlt normalerweise von einer US-IP-Adresse. Wenn Sie US-IPs auf Englisch umleiten, sieht der Googlebot möglicherweise niemals Ihre französischen Inhalte.
2. Reisende: Ich bin ein britischer Benutzer im Urlaub in Paris. Ich möchte auf Englisch lesen, aber Sie zwingen mich zu Französisch. Frustrierend.

Googles Seite zu länderspezifisch angepassten Seiten bestätigt den ersten Punkt: Die Standard-IP-Adressen des Googlebot scheinen in den USA zu liegen, und seine Anfragen enthalten keinen Accept-Language-Header. Google crawlt auch von einigen Nicht-US-IPs. Wer Inhalte nach Land sperrt, behandelt den Googlebot daher wie jeden Besucher aus diesem Land und hält Robots-Meta-Tags und robots.txt in allen Sprachversionen gleich. Googles Empfehlung sind getrennte URLs pro Sprachversion mit Hreflang. Der Leitfaden zu mehrsprachigen Websites sagt es kürzer: keine IP-Analyse zur Anpassung von Inhalten, keine automatischen Weiterleitungen zwischen Sprachversionen.

Die Lösung: Ein “Global Gateway”-Banner. “Wir glauben, Sie sind in Frankreich. Weiter zur Seite oder zur französischen Version wechseln?” Lassen Sie den Benutzer wählen.

#Was die Browser-Weiterleitungen von WPML und Polylang tun

Die Browser-Sprachweiterleitung von WPML ist aus, bis Sie sie einschalten. Sie hat zwei Modi: nur weiterleiten, wenn eine Übersetzung existiert, oder immer weiterleiten, mit der Startseite der Standardsprache als Ausweichziel. Sie läuft als clientseitiges JavaScript, die Seite lädt beim ersten Besuch also zweimal, und sie greift einmal pro Sitzung, standardmäßig alle 24 Stunden zurückgesetzt. WPMLs Dokumentation weist selbst darauf hin, dass Google auch JavaScript-Weiterleitungen folgt, was Google dazu bringen kann, Ihre Inhalte als auf eine andere Sprache weitergeleitet zu behandeln.

Die Browser-Spracherkennung von Polylang ist enger gefasst. Sie schickt Erstbesucher auf die Startseite in einer Sprache, die zu den Browsereinstellungen passt, nur wenn Sprachen per Verzeichnis oder Subdomain gesetzt sind, und setzt ein Cookie, damit wiederkehrende Besucher auf der Startseite in der zuletzt genutzten Sprache landen. Inhaltsseiten werden nicht weitergeleitet.

Wenn Sie eine der beiden Optionen aktiv lassen, begrenzen Sie sie auf die Startseite und testen Sie mit gelöschten Cookies.

#Best Practices für den Sprachumschalter

• Ein sichtbarer Umschalter im Header oder Footer, mit Sprachnamen in der jeweiligen Sprache (Español, English, Deutsch) statt Flaggen.
• Browser-Spracherkennung, die die passende Version vorschlägt, ohne sie zu erzwingen.
• Eine gespeicherte Wahl im Cookie.
• Lesbare URLs, die die Sprache zeigen (/es/, /en/, /de/).

Flaggen stehen für Länder, nicht für Sprachen. Spanisch wird in mehr als 20 Ländern gesprochen, Portugiesisch in Brasilien und in Portugal. Ein versteckter Umschalter macht das mehrsprachige Angebot unbrauchbar, auch wenn alles andere stimmt.

#Internationales SEO für jedes Land umsetzen

Übersetzte Inhalte reichen nicht, um in lokalen Märkten zu ranken. Jeder Markt braucht eigene SEO- und GEO-Arbeit.

#Lokale Keyword-Recherche

Wörtlich übersetzte Keywords treffen selten das, was lokale Nutzer eintippen. Die englische Suchanfrage “WordPress developer” taucht im Spanischen als “desarrollador WordPress” und als “programador WordPress” auf, “website speed optimization” als “optimizar velocidad web” oder “acelerar página web”. Muttersprachliche Keyword-Recherche pro Markt berücksichtigt:

• Dialektvarianten (Spanisch in Spanien, Mexiko und Argentinien)
• lokale Fachbegriffe gegenüber englischen Lehnwörtern
• Suchintentionen, die sich zwischen Kulturen unterscheiden
• andere lokale Wettbewerber

#Signale, mit denen Google das Zielland ermittelt

Der Leitfaden zu mehrsprachigen Websites nennt die Signale, mit denen Google bestimmt, auf welches Land eine Website zielt: die ccTLD, Hreflang in Tags, Headern oder Sitemaps und den Serverstandort (nicht eindeutig, weil CDNs ihn verwischen). Weitere Signale sind lokale Adressen und Telefonnummern auf den Seiten, lokale Sprache und Währung, Links von lokalen Websites und ein Google-Unternehmensprofil. Standort-Meta-Tags wie geo.position und andere Geotargeting-Attribute im HTML ignoriert Google, sie bringen also nichts.

#Lokaler Linkaufbau

Wer in einem lokalen Markt ranken will, braucht Links von lokalen Websites: nationale Medien, regionale Branchenverzeichnisse, Berufsverbände und Fachblogs in der Landessprache.

#Welche Inhalte übersetzen und welche lokal erstellen

Nicht alles muss übersetzt werden.

• Globaler Content: Wertversprechen, Produktfunktionen, “Über uns”. (In alle Regionen übersetzen).
• Lokaler Content: Fallstudien lokaler Kunden, lokale Veranstaltungen, regulatorische Seiten. (Spezifisch für diesen Markt erstellen).

Lokale Inhalte pro Markt können Fallstudien lokaler Unternehmen abdecken, landesspezifische Vorschriften, lokale Events und Konferenzen, Integrationen und Tools, die in diesem Markt verbreitet sind, sowie Preise in der Landeswährung.

Fallback-Strategie: Wenn ein Blogbeitrag noch nicht ins Deutsche übersetzt wurde, sollten Sie einen 404 zeigen? Nein. Zeigen Sie die englische Version mit einem Hinweis: “Dieser Artikel ist noch nicht auf Deutsch verfügbar.”

#Welche Kennzahlen eine mehrsprachige Website messen sollte

Richten Sie für jede Sprachversion eigene Dashboards ein und verfolgen Sie:

1. Organischen Traffic nach Sprache und Land
2. Keyword-Positionen in jedem Markt
3. Conversion-Raten nach Region
4. Absprungrate, die auf Probleme mit der Übersetzungsqualität hinweisen kann
5. Verweildauer, wo geringes Engagement auf lokal irrelevante Inhalte hindeuten kann
6. Ladezeit nach Region (CDN und regionales Hosting)

Eine globale Content-Strategie hat kein Enddatum. Sie braucht eine monatliche Auswertung pro Markt, Aktualisierungen auf Basis lokaler Daten, schrittweise Expansion in neue Märkte nach Chance und Ressourcen und laufende Verbesserung des Übersetzungsablaufs.

#Fazit

Eine globale Content-Strategie geht nicht darum, mehr Menschen zu erreichen; es geht darum, tief mit ihnen zu resonieren. Indem Sie ihre Sprache, Kultur und technischen Vorlieben (Geschwindigkeit, Währung) respektieren, verwandeln Sie sich von einem “ausländischen Unternehmen” in einen lokalen Partner.

Bauen Sie eine globale WordPress-Architektur auf? WPPoland ist auf Mehrmarkt-Skalierung spezialisiert.

Mehr zur SEO- und GEO-Optimierung.