WordPress mehrsprachig ohne Plugin: Multisite, hreflang und Abwägungen

WordPress mehrsprachig ohne Plugin zu betreiben ist möglich und in manchen Projekten sogar die sauberere Lösung. Der WordPress-Kern bringt keine Übersetzungsverwaltung mit, wohl aber Multisite: Damit läuft auf einer Installation für jede Sprache eine eigene Website. Ergänzt um ein kleines Stück Code, das die Übersetzungen verknüpft und hreflang-Tags ausgibt, entsteht ein mehrsprachiger Auftritt ohne zusätzliche Übersetzungsschicht eines Drittanbieters. Dieser Leitfaden erklärt den Aufbau, zeigt ein getestetes Snippet, vergleicht die Alternativen und sagt offen, wann ein Übersetzungs-Plugin mehr Zeit spart, als es kostet.

WordPress mehrsprachig ohne Plugin: was abgedeckt sein muss

Bevor Sie sich für einen Weg entscheiden, sollten Sie auflisten, was eine mehrsprachige Website tatsächlich braucht. Übersetzungs-Plugins bündeln diese Funktionen; ohne Plugin lösen Sie jede davon selbst:

• Eigene URLs je Sprache, etwa /de/ und /en/, damit jede Version indexiert und geteilt werden kann.
• Eine Verknüpfung der Übersetzungen, damit das System weiß, welche deutsche Seite zu welcher englischen gehört.
• Ein Sprachumschalter, der zur übersetzten Seite führt und nicht zur Startseite der anderen Sprache.
• hreflang-Angaben, die Suchmaschinen sagen, welche Version wem angezeigt wird.
• Übersetzte Menüs, Widgets, Theme-Texte und Slugs, nicht nur Beitragsinhalte.
• Ein redaktioneller Ablauf, der regelt, wer was übersetzt und wie fehlende Übersetzungen auffallen.

Jeder Ansatz, der diese sechs Punkte erfüllt, funktioniert. Entscheidend ist, wie viel Aufwand Aufbau und Pflege jeweils kosten. Die folgenden Abschnitte vergleichen drei Wege genau unter diesem Gesichtspunkt.

Weg 1: WordPress Multisite mit einer Website pro Sprache

Multisite macht aus einer WordPress-Installation ein Netzwerk von Websites, die Code, Themes und Plugins teilen, aber eigene Inhalte, Einstellungen und Medien haben. Jeder Sprache eine eigene Website zu geben, ist der robusteste Weg zu Mehrsprachigkeit ohne Übersetzungs-Plugin, denn Menüs, Widgets, Slugs und Website-Sprache sind dadurch automatisch getrennt.

WordPress Multisite einrichten

1. Website und Datenbank sichern, bevor Sie etwas ändern.
2. In der wp-config.php die Zeile define( 'WP_ALLOW_MULTISITE', true ); ergänzen, wie in der offiziellen Anleitung Create A Network beschrieben.
3. Unter Werkzeuge, Netzwerk-Einrichtung zwischen Unterverzeichnissen (example.com/de/) und Subdomains (de.example.com) wählen.
4. Die angezeigten Konfigurationszeilen in die wp-config.php und die Rewrite-Regeln in die .htaccess übernehmen, danach neu anmelden.
5. Für jede Sprache eine Website anlegen und unter Einstellungen, Allgemein die Sprache der Website festlegen.
6. Theme und benötigte Plugins netzwerkweit aktivieren.

Unterverzeichnisse halten alles auf einer Domain, was für SSL meist einfacher ist und Suchmaschinen eine Marke klar zeigt. Wer eine bestehende Website mit Inhalten und Besuchern umstellt, sollte wie bei jedem Relaunch vorgehen; unsere Website Relaunch SEO Checkliste beschreibt Weiterleitungen und Monitoring.

Was Sie gewinnen und worauf Sie verzichten

Sie gewinnen eine saubere Trennung: Jede Sprache kann eigene Menüs, Rechtstexte wie Impressum und Datenschutzerklärung oder sogar eigene Produkte haben, und Redakteure arbeiten in ihrer Sprache, ohne die andere zu berühren. Sie verzichten auf Komfort: Es gibt keine Übersetzungsansicht nebeneinander, Medien werden pro Website hochgeladen, und Plugins müssen Multisite unterstützen. Manche Hosting-Tarife schränken Multisite ein, prüfen Sie das vorab.

Übersetzungen verknüpfen und hreflang ohne Plugin ausgeben

Multisite weiß nicht, dass ein deutscher Beitrag die Übersetzung eines englischen ist. Die einfachste zuverlässige Verknüpfung ist ein gemeinsamer Wert in einem benutzerdefinierten Feld: Alle Übersetzungen eines Artikels erhalten denselben Gruppenschlüssel, etwa im Feld _acme_group. Das folgende Netzwerk-Plugin liest diesen Schlüssel, sucht den passenden Beitrag auf jeder Sprach-Website und gibt hreflang-Links aus, inklusive x-default für die Hauptseite. Die Regeln für diese Angaben beschreibt Google unter lokalisierte Versionen Ihrer Seiten.

<?php
/**
 * Plugin Name: Acme Network Hreflang
 * Description: Prints hreflang links between translated posts on a Multisite network with one site per language.
 * Network:     true
 * License:     GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

// Translations of one article share the same value in the "_acme_group" post meta.
add_action( 'wp_head', function () {
	if ( ! is_singular() ) {
		return;
	}
	$group = get_post_meta( get_queried_object_id(), '_acme_group', true );
	if ( '' === $group ) {
		return;
	}

	$links   = array();
	$default = '';
	foreach ( get_sites( array( 'public' => 1, 'number' => 20 ) ) as $site ) {
		switch_to_blog( (int) $site->blog_id );
		$ids = get_posts( array(
			'post_type'      => 'any',
			'post_status'    => 'publish',
			'meta_key'       => '_acme_group',
			'meta_value'     => $group,
			'fields'         => 'ids',
			'posts_per_page' => 1,
			'no_found_rows'  => true,
		) );
		if ( $ids ) {
			$locale = get_option( 'WPLANG' ) ?: 'en_US'; // empty WPLANG means English
			$lang   = strtolower( strtok( $locale, '_' ) );
			$url    = get_permalink( $ids[0] );
			$links[ $lang ] = $url;
			if ( is_main_site() ) {
				$default = $url;
			}
		}
		restore_current_blog();
	}

	if ( count( $links ) < 2 ) {
		return; // one language needs no hreflang
	}
	foreach ( $links as $lang => $url ) {
		printf( '<link rel="alternate" hreflang="%s" href="%s" />' . "\n", esc_attr( $lang ), esc_url( $url ) );
	}
	if ( $default ) {
		printf( '<link rel="alternate" hreflang="x-default" href="%s" />' . "\n", esc_url( $default ) );
	}
} );

Genau diese Datei haben wir mit php -l geprüft und in einer Testumgebung ausgeführt, die ein dreisprachiges Netzwerk nachbildet: Sie gibt jede Sprache plus x-default aus, überspringt Sprachen ohne Übersetzung, gibt bei einsprachigen Beiträgen und Archiven nichts aus und stellt den ursprünglichen Website-Kontext immer wieder her. Legen Sie sie in wp-content/mu-plugins ab oder aktivieren Sie sie netzwerkweit als Plugin.

Drei Hinweise für die Praxis. Erstens wird der Sprachcode aus der Spracheinstellung jeder Website gelesen, aus de_DE wird de. Bieten Sie zwei Varianten einer Sprache an, etwa de-DE und de-AT, erweitern Sie den Code so, dass die Region erhalten bleibt. Zweitens wechselt die Schleife bei jedem Aufruf zwischen den Websites; bei wenigen Sprachen ist das unproblematisch, in großen Netzwerken sollte das Ergebnis zwischengespeichert werden. Drittens kann ein Sprachumschalter dieselbe Abfrage nutzen, um direkt auf die übersetzte Seite zu verlinken.

Weg 2 und 3: getrennte Installationen oder eigener Code in einer Website

Getrennte WordPress-Installationen

Jede Sprache kann auch eine völlig eigenständige WordPress-Website sein, in einem Unterverzeichnis oder auf eigener Domain. Das ist die stärkste Trennung und läuft bei jedem Hoster, vervielfacht aber Updates, Backups und Benutzerkonten. Übersetzungen zu verknüpfen heißt dann, eine Zuordnung von Hand oder über eine Schnittstelle zu pflegen. Das passt zu Organisationen, in denen jedes Länderteam seine eigene Website betreut.

Eine Website mit eigenen Feldern pro Sprache

Theoretisch lassen sich alle Sprachen in einer Website speichern, etwa mit Zusatzfeldern pro Sprache und einem URL-Präfix über Rewrite-Regeln. In der Praxis wächst das schnell: Menüs, Widgets, Suche, Slugs, Sitemaps, Theme-Texte und Shopdaten müssen alle sprachfähig werden. Wenn es sauber läuft, haben Sie selbst ein Übersetzungs-Plugin geschrieben, nur ohne die jahrelangen Tests eines etablierten.

Menüs, Theme-Texte und Sprachumschalter

Beitragsinhalte sind nur ein Teil einer übersetzten Website. In einem Multisite-Netzwerk fügt sich der Rest leichter als in einer Einzelwebsite, braucht aber trotzdem einen Plan:

• Menüs und Widgets werden pro Website gespeichert, jede Sprache erhält also ihr eigenes Menü mit übersetzten Bezeichnungen und Links.
• Theme- und Plugin-Texte wie Buttons, Formularbeschriftungen und Datumsformate werden über Sprachdateien (.po und .mo) übersetzt. WordPress lädt anhand der Spracheinstellung jeder Website automatisch die richtige Datei, sofern das Theme eine Übersetzung mitbringt oder eine erhält.
• Slugs werden pro Beitrag festgelegt; übersetzte URLs wie /de/leistungen/ sind selbstverständlich und sollten genutzt werden, statt den Original-Slug zu kopieren.
• Der Sprachumschalter gehört ins Header-Template. Er kann dieselbe Gruppenschlüssel-Abfrage wie der hreflang-Code nutzen und nur dann auf die Startseite der anderen Sprache ausweichen, wenn keine Übersetzung existiert.

Legen Sie früh fest, wie sich der Umschalter bei fehlenden Übersetzungen verhält. Eine Sprache ohne passende Seite auszublenden, ist für Besucher meist klarer, als sie auf eine Startseite zu schicken, die sie nicht angefordert haben. Dasselbe gilt für Sitemaps: Jede Sprach-Website hat ihre eigene und sollte nur Seiten enthalten, die in dieser Sprache wirklich existieren.

Redaktioneller Ablauf: Übersetzungen synchron halten

Ohne Plugin gibt es kein Dashboard, das veraltete Übersetzungen markiert. Vereinbaren Sie stattdessen eine schlanke Routine:

1. Den Gruppenschlüssel vergeben, sobald der Originalartikel erscheint, auch wenn die Übersetzung noch fehlt.
2. Eine einfache Übersicht der Gruppenschlüssel und vorhandenen Sprachen führen, etwa als Tabelle oder kleinen Admin-Bericht.
3. Bei Änderungen am Original das Datum in der Übersicht vermerken, damit Übersetzer wissen, welche Versionen zu prüfen sind.
4. Titel, Beschreibungen und Slugs von Muttersprachlern prüfen lassen, weil Suchende genau diese zuerst sehen.
5. Nach jedem Release, besonders nach Theme- oder Plugin-Updates, die hreflang-Ausgabe einiger Seiten kontrollieren.

Diese Routine kostet pro Artikel wenige Minuten und verhindert das häufigste Problem mehrsprachiger Websites: dass eine Sprache unbemerkt zurückfällt, während die anderen gepflegt werden. Wächst die Zahl der Sprachen, lässt sich die Übersicht leicht in einen Admin-Bericht verwandeln, weil der Gruppenschlüssel ohnehin an jedem Beitrag hängt.

Wann ein Übersetzungs-Plugin die bessere Wahl ist

Der Weg ohne Plugin passt, wenn sich die Inhalte je Sprache unterscheiden, wenn getrennte Teams die Sprachen betreuen oder wenn Sie jede URL vollständig kontrollieren wollen. Ein Plugin ist meist besser, wenn derselbe Inhalt eins zu eins übersetzt wird, wenn Redakteure nebeneinander übersetzen möchten oder wenn ein WooCommerce-Shop übersetzte Produkte, Preise und Checkout braucht. Unser eigenes Plugin AYM Multilingual ist genau für diese zweite Gruppe entstanden, und beide Varianten setzen wir im Rahmen von mehrsprachigem WordPress um und betreuen sie.

Welchen Weg Sie auch wählen, die Suchmaschinenseite funktioniert gleich: eigene URLs, gegenseitiges hreflang und vollständig übersetzte Metadaten. Unsere hreflang Anleitung erklärt diese Regeln und die häufigsten Fehler.

Teilen:XLinkedInWhatsApp