Mehrsprachige Website richtig aufbauen — ohne Plugin-Wildwuchs

Eine mehrsprachige Website klingt nach einer Plugin-Frage. In Wirklichkeit ist es zuerst eine Architekturentscheidung — und die solltest du treffen, bevor du auch nur einen Beitrag schreibst. Ich habe das für Wickie in vier Sprachen (DE, EN, FR, IT) und für Lipold in zwei Sprachen (DE, EN) durchgezogen. Hier ist, was ich dabei gelernt habe.

URL-Struktur: Subdomain oder Unterverzeichnis?

Die häufigste Frage zuerst. Du hast drei echte Optionen:

• Unterverzeichnis (example.com/de/, example.com/en/) — empfohlen für die meisten Projekte
• Subdomain (de.example.com, en.example.com) — vertretbar, aber SEO-technisch aufwendiger
• Separate Domain (example.de, example.com) — sinnvoll nur bei wirklich eigenständigen Marken

Google behandelt Subdomains als eigenständige Websites. Das bedeutet, Link-Autorität verteilt sich auf mehrere Hosts, und du brauchst für jede Subdomain eine eigene Search Console Property. Unterverzeichnisse teilen sich Domain-Autorität, sind einfacher zu konfigurieren und bei den meisten Setups die bessere Wahl. Für Wickie und Lipold war Unterverzeichnis gesetzt — keine Diskussion.

hreflang: Das unterschätzte Pflichtfeld

hreflang teilt Suchmaschinen mit, welche Seite für welche Sprache und Region gedacht ist. Die Fehlerquote hier ist erschreckend hoch — selbst bei Projekten, die sonst sauber aufgebaut sind.

Die häufigsten Fehler:

• Einseitige hreflang-Tags: Wenn Seite A auf Seite B zeigt, muss Seite B auch auf Seite A zurückzeigen. Fehlt die Gegenseite, ignoriert Google das Tag.
• x-default fehlt: Wenn ein Nutzer aus einer Region kommt, für die keine Sprachvariante existiert, brauchst du ein Fallback. Ohne x-default würfelt Google.
• Inkonsistente URLs: hreflang mit Trailing Slash, kanonische URL ohne — das gibt Konflikte.

WPML und Polylang generieren hreflang automatisch. Bei einem Gettext-Ansatz bist du selbst dafür verantwortlich.

WPML vs. Polylang vs. Gettext — der echte Tradeoff

Diese Frage hat keine universelle Antwort, aber eine klare Entscheidungslogik:

WPML ist mächtig und gut gepflegt. Es deckt WooCommerce, Custom Post Types, Taxonomien, Strings in Themes und Plugins ab — alles out of the box. Der Preis ist real (ca. 99 EUR/Jahr für Multilingual CMS), und WPML schreibt eigene Datenbankstrukturen, die Migrationen komplizieren können. Für Kundenwebsites mit Redakteuren, die nicht technisch sind, ist WPML trotzdem oft die vernünftigste Wahl.

Polylang ist günstiger (kostenloses Core-Plugin, PRO für ~99 EUR/Jahr für volle String-Translation). Es ist schlanker als WPML, hat aber Lücken bei komplexen String-Übersetzungen aus Plugins. Für Projekte ohne WooCommerce und ohne viele Plugin-Strings ist Polylang vollkommen ausreichend.

Gettext / Theme-Level-Übersetzungen — also .pot-Dateien, __( )-Aufrufe im Theme-Code und Sprachdateien — funktionieren ohne Plugin und ohne Datenbank-Overhead. Das ist der saubere Ansatz für Theme-Strings, Buttons und UI-Labels. Für redaktionelle Inhalte (Beiträge, Seiten, ACF-Felder) reicht es aber nicht allein.

Mein Ansatz bei Wickie und Lipold war eine Kombination: Polylang für Post/Page-Übersetzungen, Gettext für Theme-Strings. Das hält die Plugin-Abhängigkeit klein und gibt Redakteuren trotzdem ein sauberes Interface.

Übersetzungs-Workflow für Redakteure

Technik ist die eine Hälfte, Workflow die andere. Was ich empfehle:

• Originalsprache ist immer die Hauptquelle. Übersetzungen sind Ableitungen — nie umgekehrt.
• ACF-Felder müssen explizit für Übersetzungen konfiguriert sein (WPML: Field Groups synchronisieren; Polylang: Custom Fields in den Einstellungen freigeben).
• Permalinks pro Sprache übersetzen — /de/ueber-uns/ statt /de/about/. Das ist SEO-Aufwand, aber Benutzer und Suchmaschinen danken es.
• Einen "Translations pending"-Status oder zumindest eine Checkliste einrichten, damit nichts auf Englisch live geht, das auf Französisch stehen soll.

SEO-Fallstricke, die ich konkret gesehen habe

Duplicate Content durch fehlende Kanonisierung: Wenn dein Plugin beide Sprachversionen einer Seite ohne korrekte rel=canonical und hreflang indexiert, kämpfen sie gegeneinander.

Sitemaps: Jede Sprachvariante muss in der Sitemap stehen, idealerweise mit hreflang-Annotation. Yoast SEO und RankMath machen das automatisch, wenn das Sprachplugin korrekt integriert ist.

Robots.txt und Staging: Wenn du Sprachverzeichnisse auf Staging-Umgebungen mit noindex blockierst, prüf sorgfältig, dass das in Produktion nicht versehentlich stehen bleibt.

Performance: Mehrsprachige Plugins, insbesondere WPML, können DB-Abfragen vervielfachen. Caching (z. B. WP Rocket mit sprachspezifischen Cache-Verzeichnissen) ist bei mehrsprachigen Sites keine Option, sondern Pflicht.

Fazit

Eine saubere mehrsprachige Website ist lösbar — aber die Entscheidungen am Anfang (URL-Struktur, Plugin-Wahl, hreflang-Implementierung) bestimmen, wie viel Schmerz du später hast. Wer diese Entscheidungen nachlässig trifft, verbringt Monate damit, SEO-Probleme zu debuggen, die von Anfang an vermeidbar gewesen wären.

Wenn du ein mehrsprachiges WordPress-Projekt planst und eine ehrliche Einschätzung deiner Optionen willst, schreib mir gerne. Ich helfe dir, die richtige Architektur für dein konkretes Setup zu finden — ohne Umwege.