Sie haben eine deutsche Version Ihrer Website gelauncht. Oder eine französische. Geld in Übersetzungen investiert, die Navigation aktualisiert, vielleicht sogar jemanden die Texte gegenlesen lassen.
Sechs Monate später ist der organische Traffic aus Deutschland flach. Französische Besucher sind immer noch ein statistischer Ausreißer. Ein Blick in Google Search Console zeigt: Die deutschen Seiten sind nicht indexiert. Oder schlimmer: Sie sind indexiert, aber Google zeigt deutschen Suchenden die englischen Inhalte.
Das ist der stille Fehlermodus der meisten mehrsprachigen Websites. Im Dashboard sieht alles in Ordnung aus. In der Realität funktioniert nichts.
Warum die meisten mehrsprachigen Websites nicht performen
Die Probleme lassen sich in drei Kategorien einteilen: falsche URL-Struktur, fehlerhafte hreflang-Implementierung und Übersetzungsqualität, die sowohl Suchmaschinen als auch Nutzer erkennen.
Technisches Versagen 1: Maschinenübersetzung ohne Nachbearbeitung
DeepL und Google Translate haben sich stark verbessert. Aber unbearbeitete Maschinenübersetzung liest sich noch immer wie unbearbeitete Maschinenübersetzung. Muttersprachler merken es nach zwei Sätzen. Entscheidender noch: Suchmaschinen messen Engagement-Signale wie Absprungrate, Verweildauer und Scrolltiefe. Texte schlechter Qualität drücken alle drei.
Technisches Versagen 2: fehlerhafte hreflang-Tags
Hreflang ist das HTML-Attribut, das Google mitteilt, welche Seitenversion welchem Nutzer angezeigt werden soll. Gleichzeitig ist es das am häufigsten falsch konfigurierte SEO-Element auf mehrsprachigen Websites. Fehlende selbstreferenzielle Tags, nicht übereinstimmende URLs, unvollständige Sets: Jeder dieser Fehler macht das gesamte System unbrauchbar.
Technisches Versagen 3: JavaScript-gesteuerter Sprachwechsel
Einige Websites erkennen die Browsersprache per JavaScript und tauschen Inhalte clientseitig aus. Googlebot sieht dabei häufig nur die Standardsprache. Die französischen Inhalte bleiben für Googles französische Crawler unsichtbar. Das Ergebnis: eine mehrsprachige Website, die Google als rein englischsprachig indexiert.
URL-Struktur: Das Fundament, das sich später nicht mehr ändern lässt
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 Fehler hier erfordert später eine vollständige Redirect-Migration.
| Struktur | Beispiel | Empfohlen für |
|---|---|---|
| Unterverzeichnis | example.com/de/ | Die meisten Unternehmen: beste SEO-Konsolidierung, eine Domain zu pflegen |
| Subdomain | de.example.com | Große Organisationen mit getrennten Teams pro Region |
| Länder-TLD | example.de | Unternehmen mit starker lokaler Markenidentität und Budget für mehrere Domains |
| Query-Parameter | example.com?lang=de | Vermeiden: Von Google nicht empfohlen, schlechte Crawlbarkeit |
Für die meisten Unternehmen ist die Unterverzeichnis-Struktur die richtige Wahl. Die Domain-Autorität bleibt konsolidiert. Es gibt nur eine Domain zu verwalten. Hreflang lässt sich einfacher implementieren. Die Hostingkosten bleiben planbar.
Länderspezifische TLDs (example.de, example.fr) rechtfertigen sich nur, wenn lokales Marktvertrauen ein entscheidender Conversion-Faktor ist. Das ist typischerweise bei Finanzdienstleistungen oder im Gesundheitsbereich der Fall, wo Nutzer aktiv nach Signalen einer lokalen Zulassung suchen.
Hreflang: Das Attribut, das bei Fehlern alles kaputtmacht
Hreflang-Tags teilen Suchmaschinen mit: "Diese Seite auf Deutsch ist das Äquivalent zu jener Seite auf Englisch." Fehlen sie, rät Google. Und rät meistens falsch.
Die vier häufigsten hreflang-Fehler
- Fehlender selbstreferenzieller Tag: Jede Seite muss sich in ihrem eigenen hreflang-Set selbst referenzieren. Fehlt dieser Tag, ignoriert Google unter Umständen das gesamte Set.
- Nicht übereinstimmende URLs: Verweist hreflang auf example.com/de/seite/, lautet die tatsächliche URL aber example.com/de/seite (ohne abschließenden Slash), ist der Tag defekt.
- Unvollständige Sets: Referenziert die englische Seite eine deutsche Version, muss die deutsche Seite ebenfalls die englische Version referenzieren. Unidirektionale 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 bewirkt, dass deutschsprachige Österreicher die auf Deutschland ausgerichtete Seite angezeigt bekommen.
Eine valide hreflang-Implementierung für eine dreisprachige Website sieht so aus: Jede Seite in jeder Sprache enthält 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 ergibt das 450 hreflang-Deklarationen, die alle konsistent sein müssen.
Diese Menge manuell zu verwalten ist die Ursache für Fehler. Automatisierung auf Framework-Ebene ist der Weg, sie zu vermeiden.
Übersetzungsqualität: Was wirklich den Unterschied macht
Nicht jede Übersetzung ist gleichwertig. Der richtige Ansatz hängt vom Seitentyp, dem Markt und dem Budget ab.
| Ansatz | Qualität | Kosten | Empfohlen für |
|---|---|---|---|
| Reine Maschinenübersetzung | Funktional, erkennbar | Nahezu null | Interne Dokumente, Archivseiten mit geringem Traffic |
| Maschine + redaktionelle Bearbeitung | Gut für die meisten Kontexte | Niedrig bis mittel | Blogbeiträge, Produktbeschreibungen, Unterseiten |
| Professionelle Übersetzung | Hoch, präzise | Mittel bis hoch | Rechtstexte, Case Studies, zentrale Serviceseiten |
| Native Texterstellung | Höchste Qualität, kulturell resonant | Hoch | Startseite, Landingpages, konversionsstarke Seiten |
Der häufigste Fehler: Unternehmen setzen reine Maschinenübersetzung gleichmäßig über die gesamte Website ein und fragen sich, warum die deutsche Startseite nicht konvertiert. Eine Startseite ist ein Verkaufsdokument. Sie braucht native Texterstellung.
Ein Blogbeitrag auf Position 8 für ein Nischen-Keyword kommt mit Maschine-plus-Bearbeitung aus. Die primäre Serviceseite nicht.
Kulturelle Anpassung: Was Übersetzungstools nicht leisten können
Derselbe Satz kann auf Deutsch grammatikalisch korrekt sein und trotzdem nicht konvertieren. Kulturelle Register, Argumentationsstil und Vertrauenssignale unterscheiden sich erheblich zwischen europäischen Märkten.
DACH (Deutschland, Österreich, Schweiz)
Deutschsprachige Märkte erwarten formellen Register (Sie, nicht du, außer Sie sprechen eine sehr spezifische Startup-Zielgruppe an). Sie erwarten technische Tiefe. Vage Aussagen wie "die beste Lösung" sind aktiv kontraproduktiv: Belegen Sie alles mit konkreten Zahlen. Datenschutz (DSGVO) ist sowohl rechtliche Pflicht als auch Vertrauenssignal. Stellen Sie ihn gut sichtbar dar.
Frankreich
Französische Zielgruppen erwarten Förmlichkeit und einen Nachweis von Expertise, bevor Vertrauen entsteht. Case Studies und Referenzen zählen. Durchgehend Vous-Form. Zu lockere Texte wirken unprofessionell.
Spanien und Lateinamerika
Spanischsprachige Märkte sind tendenziell wärmer und beziehungsorientierter. Vertrauen entsteht genauso über den Ton wie über Referenzen. Dennoch: Spanien und Lateinamerika sind grundverschieden. Vokabular, Idiome und Formalitätsnormen unterscheiden sich erheblich. Eine einzige spanische Übersetzung wird keinem der beiden Märkte vollständig gerecht.
Niederlande
Niederländische Zielgruppen sind ausgesprochen direkt und preistransparent. Corporate-Floskeln kommen schlecht an. Klingt der niederländische Text wie eine Pressemitteilung, wird er underperformen. Konkrete Angaben zu Kosten und Leistungsumfang sind Pflicht. Das Konkrete schlägt das Abstrakte.
Polen
Polnische B2B-Käufer sind werteorientiert. ROI-Argumente zünden gut. Der Markt ist im Vergleich zu Westeuropa preissensibel, aber Qualitätssignale zählen. Polnische Käufer sind anspruchsvoller geworden, da der Markt gereift ist. Polnische Inhalte sollten nicht wie eine nachträgliche Übersetzung wirken.
Das WordPress-Mehrsprachigkeitsproblem
Die meisten Unternehmen, die Mehrsprachigkeit auf WordPress umsetzen wollen, greifen zu WPML oder Polylang. Beide Plugins sind ausgereift. Beide haben bei größerem Umfang reale Probleme.
Performance-Overhead
WPML führt bei jedem Seitenaufruf zusätzliche Datenbankabfragen durch, um die korrekte Sprachversion zu ermitteln und auszuliefern. Bei einer Website mit 10.000 Beiträgen in 5 Sprachen wird dieser Overhead messbar. Eine ohnehin performance-begrenzte Architektur wird zusätzlich belastet.
Komplexität der Übersetzungsverwaltung
Übersetzungen in WordPress zu verwalten bedeutet, parallele Beitrags-Hierarchien synchron zu halten. Wer die englische Serviceseite aktualisiert, muss jede Sprachversion manuell markieren und neu übersetzen lassen. Wird eine vergessen, liefert die Website veraltete Inhalte im Live-Betrieb aus.
Hreflang-Fehler
WPML und Polylang generieren hreflang automatisch, aber ihre Ausgabe ist nur so gut wie die Vollständigkeit der Übersetzungen. Fehlt eine deutsche Übersetzung, ist das hreflang-Set jeder englischen Seite, die darauf verweist, unvollständig. Plugin-generiertes hreflang erfordert plugin-perfekte Übersetzungsabdeckung.
Plugin-Abhängigkeitsrisiko
Die gesamte mehrsprachige Infrastruktur liegt auf einem Drittanbieter-Plugin, das mit dem WordPress-Core, dem Theme und allen anderen Plugins kompatibel gehalten werden muss. WPML-Updates haben in der Vergangenheit Regressionen verursacht. Fehler können alle Sprachvarianten gleichzeitig betreffen und erhöhen so die Auswirkung eines einzelnen fehlerhaften Updates.
Der Next.js-Ansatz für Mehrsprachigkeit
Next.js löst Internationalisierung auf Framework-Ebene, nicht auf Plugin-Ebene. Der Unterschied ist architektonischer Natur.
Routing auf Framework-Ebene
In Next.js sind `/de/services` und `/en/services` vollwertige Routen. Das Framework kennt sie bereits zur Build-Zeit. Kein clientseitiger Sprachwechsel, keine Laufzeiterkennung. Google crawlt jede URL als vollständig eigenständige Seite mit eigenem Inhalt.
Automatische hreflang-Generierung
Bei einem korrekt konfigurierten Next.js-i18n-Setup werden hreflang-Tags aus der Routing-Konfiguration generiert. Ein neues Locale hinzufügen, und alle Seiten erhalten automatisch die richtigen Tags. Ein Locale entfernen, und verwaiste Referenzen verschwinden. Kein manueller Aufwand, keine stillen Fehler.
Konsistente Performance über alle Locales
Deutsche und französische Versionen zu einer Next.js-Website hinzuzufügen erzeugt keine zusätzlichen Datenbankabfragen, keinen Plugin-Overhead, keine PHP-Komplexität. Jedes Locale ist ein Satz statischer Dateien, der von einem CDN-Edge ausgeliefert wird. Ein Nutzer in München empfängt die Seite typischerweise von einem nahe gelegenen Edge-Node in deutlich unter 100 ms (abhängig von CDN-Abdeckung und Routing), unabhängig von der Anzahl der Sprachvarianten.
Strukturierte Inhalte ohne 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 werden versionskontrolliert gemeinsam mit dem Code verwaltet.
Pre-Launch-Checkliste für mehrsprachige Websites
Vor dem Go-live einer neuen Sprachversion sollten Sie diese Liste durcharbeiten.
- Im Google des Ziellandes testen: Prüfen Sie per VPN oder dem URL-Inspektionstool von Google Search Console, ob für Suchanfragen aus diesem Land die korrekte Sprachversion zurückgegeben wird.
- hreflang mit einem dedizierten Tool validieren: Screaming Frog oder Ahrefs Site Audit deckt falsch konfigurierte oder fehlende hreflang-Tags über den gesamten URL-Bestand auf.
- PageSpeed für jedes Locale separat prüfen: Eine deutsche Seite mit einem schwereren Schrift-Stack oder anderen Bildern kann andere Werte erzielen als die englische Baseline.
- Native-Speaker-Review vor dem Launch: Tippfehler, Ton, Register und die Frage, ob der Text einen lokalen Kunden tatsächlich konvertieren würde, gehören geprüft.
- Rechtliches und Impressum lokalisieren: DACH-Märkte erfordern ein deutschsprachiges Impressum und eine DSGVO-konforme Datenschutzerklärung. Frankreich verlangt spezifische rechtliche Hinweise. Das sind rechtliche Anforderungen, keine optionalen Extras.
- Spracherkennung bei direktem URL-Aufruf prüfen: Ruft ein Nutzer /de/services direkt auf, soll er Deutsch erhalten, keine Weiterleitung zu Englisch auf Basis seiner Browsereinstellungen.
Was "funktioniert" wirklich bedeutet
Eine mehrsprachige Website, die funktioniert, hat in jedem Zielmarkt eigenständige organische Rankings. Google Search Console zeigt Impressionen und Klicks aus den richtigen Ländern auf den richtigen Sprachseiten. Die Absprungraten sind über alle Locales vergleichbar und nicht signifikant höher auf den übersetzten Versionen. Gibt ein Nutzer in München Ihr Ziel-Keyword in Google.de ein, findet er die deutsche Seite, nicht die englische.
Dieses Ergebnis erfordert eine von Anfang an korrekte URL-Struktur, eine fehlerfreie hreflang-Implementierung, eine der Seitenrelevanz angemessene Übersetzungsqualität und einen technischen Stack, bei dem all das automatisch und nicht manuell gepflegt wird.
Die meisten Unternehmen setzen nicht alle diese Dimensionen beim ersten Versuch richtig um. Iteration ist normal. 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. Die Website war schlicht nicht so gebaut, dass sie ihn erreicht.
Kostenlosen Website-Health-Report anfordern
Performt Ihre mehrsprachige Website nicht, oder planen Sie eine und möchten die Architektur vor dem Bau richtig aufsetzen: webvise kann Ihr aktuelles Setup kostenlos prüfen.
Der kostenlose Website-Health-Report deckt hreflang-Implementierung, URL-Struktur, PageSpeed je Locale und Übersetzungsqualitätssignale ab. Sie erhalten eine konkrete, handlungsorientierte Übersicht, was defekt ist und was zuerst behoben werden sollte.
Ihren kostenlosen Report erhalten Sie unter webvise.io/wp-health-report. Kein Verkaufsgespräch erforderlich.