Mehrsprachige Websites sollen in Deutschland deutsch, in Frankreich französisch und in der Schweiz idealerweise die passende Variante ausspielen. In der Praxis landen Nutzer:innen aber häufig auf der falschen Sprachversion. Ursache sind selten „schlechte Rankings“, sondern unklare Signale: Welche URL ist für welche Sprache (und welches Land) gedacht?
hreflang ist dafür ein bekanntes Werkzeug. Es ist aber nicht die einzige Möglichkeit – und manchmal nicht die beste, etwa bei kleinen Websites, fehleranfälligen Setups oder wenn das CMS die Pflege erschwert. Wichtig ist: Suchmaschinen brauchen eindeutige, konsistente Hinweise. Dieser Leitfaden erklärt praxistaugliche Alternativen und zeigt, wie sie sauber kombiniert werden.
Warum Sprachsignale überhaupt nötig sind
Das typische Problem: ähnliche Inhalte, falsche Ausspielung
Mehrsprachige Seiten sind oft sehr ähnlich aufgebaut. Das ist normal: Ein Produkt, eine Dienstleistung oder ein Ratgeber wird übersetzt, Struktur und Bilder bleiben ähnlich. Für Suchmaschinen sehen solche Seiten dann wie „nahe Duplikate“ aus (sehr ähnliche Inhalte auf mehreren URLs). Ohne klare Zuordnung kann es passieren, dass Google eine Version bevorzugt und in mehreren Ländern ausspielt.
Das führt zu zwei praktischen Problemen:
- Nutzer:innen landen auf einer Sprache, die sie nicht verstehen.
- Die falsche URL sammelt Sichtbarkeit, während die „richtige“ Sprachversion schwach bleibt.
Was Suchmaschinen am Ende entscheiden
Suchmaschinen treffen eine URL-Auswahl pro Suchanfrage und Kontext. Dafür werden viele Signale zusammengeführt: Sprache des Inhalts, Länderrelevanz, interne Verlinkung, technische Einstellungen und externe Signale (z. B. Links). Je widersprüchlicher die Hinweise, desto wahrscheinlicher sind Fehlzuordnungen.
Stabile URL-Struktur als Grundlage für saubere Zuordnung
Welche URL-Modelle sich bewährt haben
Bevor Alternativen zu hreflang greifen, braucht es ein sauberes Fundament: eine klare, dauerhafte URL-Struktur. In der Praxis funktionieren drei Modelle gut:
- Sprachverzeichnisse (z. B. /de/, /en/): einfach zu pflegen, zentral in einer Domain, klare interne Signale.
- Subdomains (z. B. de.beispiel.de): technisch getrennt, aber oft mehr Aufwand bei Tracking, Templates und Verlinkung.
- Länderdomains (z. B. beispiel.de, beispiel.fr): sehr starkes Länder-Signal, aber hoher Pflegeaufwand und oft schwieriger Linkaufbau.
Für viele Teams sind Sprachverzeichnisse der pragmatischste Weg. Wichtig ist weniger „das perfekte Modell“ als Konsistenz: einmal entscheiden und dann durchziehen.
Was Parameter-URLs in der Regel schlechter machen
Sprachvarianten per Parameter (z. B. ?lang=en) sind häufig fehleranfällig: Nutzer:innen teilen Links, Parameter gehen verloren, interne Links werden gemischt. Außerdem entstehen leicht viele URL-Varianten. Wenn ein solches Setup existiert, lohnt sich eine mittelfristige Migration auf Verzeichnisse oder Subdomains.
Alternativen zu hreflang, die im Alltag funktionieren
Sprache im Inhalt konsequent sichtbar machen
Das klingt banal, ist aber zentral: Suchmaschinen erkennen Sprache vor allem aus dem Text. Eine „englische“ Seite mit vielen deutschen Elementen (z. B. Navigation, Footer-Texte, Rechtliches, Formularlabels) sendet gemischte Signale.
- Navigation, Buttons und Systemtexte pro Sprache übersetzen.
- Keine Sprachmischung in Überschriften und Haupttext.
- Eigene Rechts-/Kontaktseiten pro Sprache, wenn sie ranken sollen.
Auch Metadaten wie Title und Description sollten zur jeweiligen Sprache passen. Das ist kein Ersatz für technische Signale, aber ein wichtiger Stabilitätsfaktor.
Locale-Signale über HTML und Server: lang-Attribut & Header
Ein klarer Hinweis ist das HTML-lang-Attribut (z. B. lang=“de“ oder lang=“en“). Es hilft Suchmaschinen und assistiven Technologien (z. B. Screenreadern), die Sprache zu erkennen. Zusätzlich kann der Server einen Content-Language-Header senden. Wichtig ist Konsistenz: Wenn HTML „de“ sagt, sollte die Seite nicht überwiegend englisch sein.
Diese Signale ersetzen hreflang nicht 1:1, reduzieren aber Missverständnisse, vor allem bei klar getrennten Sprachverzeichnissen.
Interne Verlinkung als stärkstes Steuerungsinstrument
Viele Sprachprobleme entstehen durch gemischte interne Links. Wenn die deutsche Navigation auf englische URLs zeigt (oder umgekehrt), wird der Zusammenhang für Suchmaschinen unscharf.
Bewährte Regeln:
- Alle Menüs, Footer-Links und In-Content-Links pro Sprache auf die gleiche Sprache verlinken.
- Sprachwechsel-Links nur zwischen äquivalenten Seiten setzen (Startseite zu Startseite, Produkt A zu Produkt A).
- Konsequent sprachliche Ankertexte verwenden (kein „Contact“ auf einer deutschen Seite).
Wer die interne Linkstruktur systematisch plant, kann viele Fehl-Ausspielungen schon ohne zusätzliche Technik reduzieren. Dazu passt der Leitfaden Interne Links für SEO planen.
Canonical, Weiterleitungen und Geotargeting: was hilft – und was schadet
Canonical Tag: nur bei echten Duplikaten, nicht zwischen Sprachen
Ein Canonical sagt: „Diese URL ist die Hauptversion.“ Zwischen Sprachversionen ist das fast immer falsch. Wenn die englische Seite einen Canonical auf die deutsche setzt, kann die englische aus dem Index gedrängt werden. Canonicals sind sinnvoll bei technischen Duplikaten innerhalb derselben Sprache (z. B. Druckversionen, Tracking-Parameter).
Wer Canonicals sauber einsetzen will, sollte das Prinzip wirklich verstehen, sonst werden Probleme „wegkanonisiert“. Passend dazu: Canonical Tag für SEO.
Automatische Weiterleitung nach IP: mit Vorsicht
IP-basierte Weiterleitungen (Besucher aus Frankreich landen immer auf /fr/) sind aus SEO-Sicht riskant. Suchmaschinen crawlen oft aus anderen Regionen und können dann Inhalte nicht zuverlässig abrufen. Besser ist:
- Keine harte Weiterleitung, sondern ein Hinweis-Banner („Diese Seite gibt es auch auf Französisch“).
- Sprachwahl merken (Cookie) – aber weiterhin Zugriff auf alle Versionen ermöglichen.
- Immer einen sichtbaren Sprachwechsler anbieten.
Wenn Weiterleitungen nötig sind (z. B. nach Relaunch), sollten sie klar und ohne Ketten umgesetzt werden. Dafür hilft SEO-Redirects richtig nutzen.
Geotargeting in Tools: nur ein ergänzendes Signal
Bei länderspezifischen Setups (z. B. /de-de/ und /de-at/) ist das Länderziel relevant. Tool-Einstellungen können helfen, sind aber niemals die einzige Grundlage. Ohne klare Inhalte, saubere URLs und klare interne Links bleibt die Zuordnung wackelig.
Sprachwechsel richtig umsetzen: UX und SEO zusammen denken
Der Sprachwechsler sollte Seiten-Paare verbinden
Ein häufiger Fehler: Der Sprachwechsler führt immer auf die Startseite der anderen Sprache. Für Nutzer:innen ist das mühsam – und für Suchmaschinen ein schwaches Signal, weil die inhaltliche Entsprechung fehlt.
Besser ist eine Zuordnung auf URL-Ebene: Jede Seite kennt ihre Entsprechungen. Beispiel: /de/leistungen/seo/ ↔ /en/services/seo/.
Wording und Sichtbarkeit: klein, aber wirksam
Sprachcodes (DE/EN) sind ok, besser verständlich sind Sprach-Namen („Deutsch“, „English“). Flaggen allein sind ungenau (Englisch ist nicht nur UK/USA). Für SEO ist vor allem wichtig: Der Sprachwechsler ist crawlbar (normale Links) und nicht nur ein Script-Event.
Entscheidungshilfe für typische Setups
- Nur 2–3 Sprachen, überschaubare Website
- Empfehlung: Sprachverzeichnisse, lang-Attribut, starke interne Verlinkung, sauberer Sprachwechsler.
- Wenn hreflang schwer pflegbar ist: auf Konsistenz und Linkstruktur setzen, keine IP-Weiterleitung.
- Viele Länder mit gleicher Sprache (z. B. es-ES, es-MX)
- Empfehlung: Inhalte klar lokalisieren (Währung, Versand, Kontakt), separate URLs pro Landvariante.
- Zusatzsignale: interne Verlinkung pro Markt, lokale Kontakt-/Versandinfos auf jeder Variante.
- Internationaler Shop mit Filtern, Parametern und vielen Varianten
- Empfehlung: URL-Struktur vereinheitlichen, Parameter begrenzen, interne Links stabilisieren.
- Technik prüfen: Canonicals nur für echte Duplikate, keine Sprach-Canonicals.
Praxis-Notizen: typische Fehlerbilder und schnelle Prüfungen
Wenn die falsche Sprache rankt
Dann lohnt sich eine systematische Prüfung der Signale. Häufige Ursachen:
- Interne Links zeigen in die „falsche“ Sprachwelt (z. B. Footer gemischt).
- Viele Template-Texte sind nicht übersetzt.
- Mehrere URLs liefern identische Inhalte (z. B. /en/ und /en-us/ sind gleich).
- Canonicals verweisen auf eine andere Sprache.
Wenn Suchmaschinen zu wenig Seiten pro Sprache finden
Dann liegt das Problem oft nicht an „mehrsprachig“, sondern an Indexierung: Seiten sind blockiert, liefern Fehler oder sind zu ähnlich. Eine saubere Kontrolle der Indexierung hilft, bevor an Sprachsignalen geschraubt wird. Dazu passt SEO-Indexierung steuern.
So lässt sich das Setup in 30 Minuten grob absichern
- Stichprobe von 10 URLs pro Sprache: Ist wirklich alles in der richtigen Sprache (auch Navigation/Footer)?
- Sprachwechsler klicken: führt er auf die jeweilige Entsprechung oder nur auf die Startseite?
- Interne Suche auf der Website: liefert sie gemischte Sprachen in den Ergebnissen?
- Quellcode-Check: ist das lang-Attribut passend gesetzt?
- Canonical prüfen: zeigt er auf sich selbst (oder zumindest in die gleiche Sprache)?
Wann hreflang trotzdem sinnvoll bleibt
Bei sehr ähnlichen Seiten und klaren Länder-/Sprachvarianten
Wenn Inhalte sehr ähnlich sind und es echte Varianten pro Land gibt, ist mehrsprachige Website-SEO ohne hreflang möglich, aber weniger robust. hreflang ist dann ein zusätzlicher Sicherheitsgurt. Entscheidend ist: Nur einsetzen, wenn die Pflege dauerhaft zuverlässig klappt.
Wenn das CMS die Pflege automatisiert
Ein gutes Setup erzeugt Sprachverweise automatisch und fehlerfrei. Dann ist hreflang kein „Extra-Aufwand“, sondern Teil der Infrastruktur. Wer damit zu kämpfen hat, sollte zuerst die Grundlage vereinfachen: stabile URLs, klare Templates, konsistente Verlinkung.
Kurze Umsetzungsliste für saubere Sprachversionen
- Sprachversionen mit klarer URL-Struktur abbilden (z. B. /de/, /en/).
- HTML-lang pro Seite korrekt setzen und Template-Texte übersetzen.
- Interne Verlinkung strikt sprachrein halten (Menü, Footer, Content-Links).
- Sprachwechsler als normale Links umsetzen und auf Seiten-Entsprechungen verlinken.
- Redirects nicht automatisch nach IP erzwingen; lieber Hinweis-Banner und Wahlmöglichkeit.
- Canonicals nur für echte technische Duplikate nutzen, nicht zwischen Sprachen.
