Mehrsprachige Website erstellen: Was wirklich funktioniert

Sie haben eine deutsche Version Ihrer Website gelauncht. Oder eine französische. Sie haben Geld für Übersetzungen ausgegeben, die Navigation angepasst und vielleicht sogar jemanden die Texte gegenlesen lassen.

Sechs Monate später ist der organische Traffic aus Deutschland unverändert. Sie öffnen die Google Search Console und stellen fest: Ihre deutschen Seiten sind gar nicht indexiert. Oder schlimmer - sie sind indexiert, aber Google zeigt deutschen Nutzern Ihre englischen Inhalte.

Das ist der stille Fehlermodus der meisten mehrsprachigen Websites. Im Dashboard sieht alles gut aus. In der Realität funktioniert nichts.

Warum die meisten mehrsprachigen Websites nicht performen

Die Probleme fallen in drei Kategorien: falsche URL-Struktur, fehlerhafte Hreflang-Implementierung und Übersetzungsqualität, die sowohl Suchmaschinen als auch echte Nutzer erkennen.

Technischer Fehlermodus 1: Maschinelle Übersetzung ohne Nachbearbeitung

DeepL und Google Translate haben sich stark verbessert. Aber unbearbeitete maschinelle Übersetzungen lesen sich noch immer wie unbearbeitete maschinelle Übersetzungen. Deutschsprachige Nutzer merken das nach zwei Sätzen. Wichtiger noch: Suchmaschinen messen Engagement-Signale - Absprungrate, Verweildauer, Scroll-Tiefe - und schlechte Textqualität verschlechtert alle drei.

Technischer Fehlermodus 2: Fehlerhaftes Hreflang

Hreflang ist das HTML-Attribut, das Google mitteilt, welche Sprachversion einer Seite welchem Nutzer angezeigt werden soll. Es ist gleichzeitig das am häufigsten falsch konfigurierte SEO-Element auf mehrsprachigen Websites. Fehlende Self-Referential-Tags, nicht übereinstimmende URLs, unvollständige Sets - jeder einzelne dieser Fehler bricht das gesamte System.

Technischer Fehlermodus 3: JavaScript-gesteuertes Sprachumschalten

Manche Websites erkennen die Browser-Sprache per JavaScript und tauschen den Inhalt clientseitig aus. Googlebots sehen dann oft nur die Standardsprache. Ihre deutschen Inhalte sind für Googles deutsche Crawler unsichtbar. Sie haben eine mehrsprachige Website gebaut, die Google als rein englischsprachig indexiert.

URL-Struktur: Das Fundament, das Sie später nicht mehr ändern können

Bevor Sie eine einzige Übersetzung anfassen, müssen Sie entscheiden, wie Ihre mehrsprachigen URLs strukturiert sein sollen. Diese Entscheidung lässt sich kaum rückgängig machen. Ein späterer Wechsel erfordert eine vollständige Redirect-Migration.

Für die meisten Unternehmen ist die Unterverzeichnis-Struktur die richtige Wahl. Die Domain Authority bleibt konsolidiert. Sie verwalten eine einzige Domain. Hreflang ist einfacher zu implementieren. Hosting-Kosten bleiben planbar.

Länder-TLDs (beispiel.de, beispiel.fr) sind nur sinnvoll, wenn lokales Marktvertrauen ein kritischer Conversion-Faktor ist - häufig bei Finanzdienstleistungen oder im Gesundheitsbereich, wo Nutzer aktiv nach lokalen Registrierungssignalen suchen.

Hreflang: Das Attribut, das alles zerstört, wenn es falsch ist

Hreflang-Tags teilen Suchmaschinen mit: „Diese Seite auf Deutsch ist das Äquivalent zu jener Seite auf Englisch." Ohne sie rät Google. Und rät meistens falsch.

Die vier häufigsten Hreflang-Fehler

• Fehlender Self-Referential-Tag - jede Seite muss sich in ihrem eigenen Hreflang-Set selbst referenzieren. Fehlt dieser, ignoriert Google unter Umständen das gesamte Set.
• Nicht übereinstimmende URLs - wenn Ihr Hreflang auf beispiel.com/de/seite/ verweist, die tatsächliche URL aber beispiel.com/de/seite ist (kein abschließender Schrägstrich), ist es fehlerhaft.
• Unvollständige Sets - wenn Ihre englische Seite auf eine deutsche Version verweist, muss diese deutsche Seite auch auf die englische verweisen. Einseitige Tags werden als Fehler gewertet.
• Falsche Sprachcodes - `de` bedeutet Deutsch weltweit. `de-DE` bedeutet Deutsch für Deutschland. `de-AT` bedeutet Deutsch für Österreich. Der falsche Code führt dazu, dass deutschsprachige Österreicher Ihre für Deutschland ausgerichteten Seiten sehen.

Eine korrekte Hreflang-Implementierung für eine dreisprachige Website sieht so aus: Jede Seite in jeder Sprache hat einen vollständigen Tag-Set, der auf alle drei Versionen verweist - einschließlich sich selbst. Das sind drei Tags pro Seite pro Sprache. Bei 50 Seiten in drei Sprachen sind das 450 Hreflang-Deklarationen. Alle müssen konsistent sein.

Die manuelle Verwaltung im großen Maßstab ist der Weg, auf dem Fehler entstehen. Automatisierung auf Framework-Ebene ist der Weg, sie zu vermeiden.

Übersetzungsqualität: Was wirklich den Unterschied macht

Nicht alle Übersetzungen sind gleich. Der richtige Ansatz hängt vom Seitentyp, dem Zielmarkt und Ihrem Budget ab.

Der häufigste Fehler: Unternehmen wenden reine Maschinenübersetzung gleichmäßig auf die gesamte Website an und fragen sich dann, warum ihre deutsche Homepage nicht konvertiert. Eine Homepage ist ein Verkaufsdokument. Sie benötigt native Texterstellung.

Ein Blogartikel auf Position 8 für ein Nischen-Keyword kann mit Maschine-plus-Nachbearbeitung auskommen. Ihre primäre Leistungsseite nicht.

Kulturelle Anpassung: Was Übersetzungstools nicht leisten können

Derselbe Satz kann auf Deutsch grammatikalisch korrekt sein und trotzdem nicht konvertieren. Register, Argumentationsstil und Vertrauenssignale unterscheiden sich erheblich zwischen europäischen Märkten.

DACH (Deutschland, Österreich, Schweiz)

Der deutschsprachige Markt erwartet formales Register (Sie, nicht du - außer bei Startups, die eine sehr spezifische Zielgruppe ansprechen). Er erwartet technische Tiefe. Vage Aussagen wie „die beste Lösung" wirken aktiv kontraproduktiv - belegen Sie alles mit konkreten Zahlen. Datenschutz (DSGVO) ist nicht nur eine gesetzliche Anforderung, sondern ein Vertrauenssignal: Stellen Sie ihn prominent dar.

Frankreich

Französische Zielgruppen erwarten Formalität und einen Nachweis von Expertise, bevor Vertrauen entgegengebracht wird. Fallstudien und Referenzen zählen. Vous-Form durchgehend. Zu lockere Texte wirken unprofessionell.

Spanien und Lateinamerika

Spanische Märkte tendieren zu einer wärmeren, beziehungsorientierten Kommunikation. Vertrauen wird durch Ton genauso aufgebaut wie durch Referenzen. Dabei sind Spanien und Lateinamerika grundverschieden - Vokabular, Idiome und Formalitätsnormen unterscheiden sich erheblich. Eine einzige spanische Übersetzung wird beiden nicht gleich gut dienen.

Niederlande

Niederländische Zielgruppen sind besonders direkt und preistransparent. Sie schätzen kein Unternehmens-Blabla. Wenn Ihre niederländischen Texte wie eine Pressemitteilung klingen, werden sie underperformen. Seien Sie konkret über Kosten und Leistungsumfang. Konkretes schlägt Abstraktes.

Polen

Polnische B2B-Käufer sind wertorientiert. ROI-Argumente kommen gut an. Der Markt ist preissensitiver als Westeuropa, aber Qualitätssignale sind wichtig - polnische Käufer sind anspruchsvoller geworden. Vermeiden Sie, dass Ihre polnischen Inhalte wie eine nachträgliche Übersetzung wirken.

Das WordPress-Problem bei mehrsprachigen Websites

Die meisten Unternehmen, die Mehrsprachigkeit auf WordPress umsetzen wollen, greifen zu WPML oder Polylang. Beides sind ausgereifte Plugins. Beides hat im größeren Maßstab reale Probleme.

Performance-Overhead

WPML fügt bei jedem Seitenaufruf zusätzliche Datenbankabfragen hinzu, um die korrekte Sprachversion zu ermitteln und auszuliefern. Auf einer Website mit 10.000 Beiträgen in 5 Sprachen wird dieser Overhead messbar. Sie verschlimmern eine ohnehin performance-eingeschränkte Architektur.

Komplexität der Übersetzungsverwaltung

Übersetzungen in WordPress zu verwalten bedeutet, parallele Beitrags-Hierarchien synchron zu halten. Aktualisieren Sie Ihre englische Leistungsseite, müssen Sie jede Sprachversion manuell markieren und neu übersetzen lassen. Vergessen Sie eine, liefern Sie veraltete Inhalte an echte Nutzer aus.

Hreflang-Fehler

WPML und Polylang generieren Hreflang automatisch - aber ihre Ausgabe ist nur so gut wie Ihre Übersetzungsvollständigkeit. Fehlt eine deutsche Übersetzung, ist das Hreflang-Set für jede englische Seite, die darauf verweist, unvollständig. Plugin-generiertes Hreflang erfordert plugin-perfekte Übersetzungsabdeckung.

Plugin-Abhängigkeitsrisiko

Ihre gesamte mehrsprachige Infrastruktur hängt an einem Drittanbieter-Plugin, das mit WordPress Core, Ihrem Theme und Ihren anderen Plugins kompatibel gehalten werden muss. WPML-Updates haben Websites schon zum Absturz gebracht. Wenn es bricht, gehen alle Sprachversionen gleichzeitig offline.

Der Next.js-Ansatz für mehrsprachige Websites

Next.js verarbeitet Internationalisierung auf Framework-Ebene, nicht auf Plugin-Ebene. Der Unterschied ist architektonisch.

Routing auf Framework-Ebene

In Next.js sind `/de/leistungen` und `/en/services` erstklassige Routen. Das Framework kennt sie zur Build-Zeit. Es gibt kein clientseitiges Sprachumschalten, keine Laufzeiterkennung - Google crawlt jede URL als vollständig unabhängige Seite mit eigenem Inhalt.

Automatische Hreflang-Generierung

Mit einem korrekt konfigurierten Next.js i18n-Setup werden Hreflang-Tags aus Ihrer Route-Konfiguration generiert. Fügen Sie ein neues Locale hinzu, erhalten alle Seiten automatisch die korrekten Tags. Entfernen Sie ein Locale, werden verwaiste Referenzen aufgeräumt. Keine manuelle Verwaltung, keine stillen Fehler.

Konsistente Performance über alle Sprachversionen

Das Hinzufügen deutscher und französischer Versionen zu einer Next.js-Website fügt keine Datenbankabfragen, keinen Plugin-Overhead und keine PHP-Komplexität hinzu. Jedes Locale ist ein Set statischer Dateien, die von einem CDN-Edge ausgeliefert werden. Ein deutscher Nutzer in München erhält seine Seite von einem Frankfurter Edge-Node in unter 50 ms - unabhängig davon, wie viele Sprachen die Website unterstützt.

Strukturierter Inhalt - kein Plugin-Risiko

Übersetzungsinhalte liegen in JSON-Dateien oder einem Headless CMS. Kein Plugin, das aktualisiert werden, brechen oder bezahlt werden muss. Keine Datenbankschema-Änderungen beim Hinzufügen einer Sprache. Inhalte sind zusammen mit dem Code versioniert.

Pre-Launch-Checkliste für mehrsprachige Websites

Bevor Sie eine neue Sprachversion live schalten, arbeiten Sie diese Liste durch.

• Im Google des Ziellandes testen - nutzen Sie ein VPN oder das URL-Prüftool der Google Search Console, um zu prüfen, ob die korrekte Sprachversion bei Suchanfragen aus diesem Land zurückgegeben wird
• Hreflang mit einem dedizierten Tool validieren - Screaming Frog oder der Ahrefs Site Audit deckt fehlkonfigurierte oder fehlende Hreflang-Tags in Ihrem gesamten URL-Set auf
• PageSpeed für jedes Locale unabhängig messen - eine deutsche Seite mit schwereren Schriften oder anderen Bildern kann anders abschneiden als Ihre englische Baseline
• Native Speaker Review vor dem Launch - nicht nur für Tippfehler, sondern für Ton, Register und ob der Text einen lokalen Kunden tatsächlich überzeugen würde
• Rechtliche Seiten und Impressum lokalisieren - DACH-Märkte erfordern ein deutschsprachiges Impressum und eine DSGVO-konforme Datenschutzerklärung. Das sind gesetzliche Anforderungen, keine optionalen Extras
• Spracherkennung bei direktem URL-Aufruf prüfen - wenn ein Nutzer direkt /de/leistungen aufruft, soll er Deutsch erhalten, nicht eine Weiterleitung zu Englisch basierend auf seinen Browser-Einstellungen

Was „funktioniert" wirklich bedeutet

Eine mehrsprachige Website, die funktioniert, hat unterschiedliche organische Rankings in jedem Zielmarkt. Die Google Search Console zeigt Impressionen und Klicks aus den richtigen Ländern auf den richtigen Sprachseiten. Absprungraten sind über alle Locales vergleichbar - nicht signifikant höher bei übersetzten Versionen. Und wenn ein deutscher Nutzer Ihr Ziel-Keyword in Google.de eingibt, findet er Ihre deutsche Seite, nicht Ihre englische.

Dieses Ergebnis erfordert: die URL-Struktur von Anfang an richtig zu wählen, Hreflang fehlerfrei zu implementieren, die Übersetzungsqualität der Seitenwichtigkeit anzupassen und einen technischen Stack zu verwenden, der all das automatisch und nicht manuell pflegt.

Die meisten Unternehmen erreichen das beim ersten Versuch nicht. Das übliche Muster: übersetzte Website launchen, keine Ergebnisse sehen, annehmen, der Markt wolle das Produkt nicht, internationale Expansion aufgeben.

Der Markt will das Produkt meistens schon. Die Website war nur nicht so gebaut, dass sie ihn erreicht.

Kostenlosen Website-Gesundheitscheck erhalten

Wenn Ihre mehrsprachige Website nicht die erwarteten Ergebnisse liefert - oder Sie eine planen und die Architektur von Anfang an richtig aufsetzen möchten - analysieren wir Ihr aktuelles Setup kostenlos.

Unser kostenloser Website-Gesundheitscheck deckt Hreflang-Implementierung, URL-Struktur, PageSpeed je Locale und Übersetzungsqualitätssignale ab. Sie erhalten eine konkrete, umsetzbare Aufstellung dessen, was kaputt ist und was zuerst behoben werden sollte.

Jetzt kostenlosen Bericht anfordern unter webvise.io/wp-health-report. Kein Verkaufsgespräch erforderlich.