← Zurück zur Übersicht

Mehrsprachige Website: hreflang, URLs und typische Fehler

Eine mehrsprachige Website ohne klares URL-Schema und korrektes hreflang verliert oft Traffic: Suchmaschinen verwechseln Versionen, zeigen die falsche Sprache oder werten Seiten als Duplikate. Unten - wie Sie die Adressstruktur wählen, Locales verknüpfen und welche Fehler 2026 am häufigsten auftreten.

  • hreflang - Signal an die Suchmaschine, welche Sprach-/Regionsversion für welches Publikum gilt
  • URL - Pfadpräfix, Subdomain oder eigene Domain; das Schema muss einheitlich und vorhersehbar sein
  • Canonical - darf die Locale-Verknüpfung nicht zerstören
  • Inhalt - Übersetzung oder Lokalisierung, kein ungeprüftes Maschinen-Copy-Paste
  • Regel - jede Locale verweist auf alle anderen und auf sich selbst

Warum hreflang und ein URL-Schema wichtig sind

Nutzer in Deutschland sollen die deutsche Version sehen, in Brasilien die portugiesische, in den USA die englische. Ohne klare Signale rät die Suchmaschine anhand von IP, Browsersprache und Links - und liegt oft falsch.

hreflang rankt eine Seite nicht allein. Es hilft, unter gleichwertigen Seiten die richtige Version zu wählen. Das URL-Schema entscheidet, wie Menschen und Bots diese Versionen finden: über /de/, de.example.com oder example.de.

URL-Schemata für Mehrsprachigkeit

Schema Beispiel Vorteile Nachteile
Pfadpräfix example.com/de/blog/ Eine Domain, einfachere Analytics und Zertifikate Disziplin bei Routing und Sitemap nötig
Subdomain de.example.com/blog/ Flexibel für Hosting und Teams Gemeinsame Domain-Stärke schwieriger, mehr Infrastruktur
Eigene Domain example.de/blog/ Starkes lokales Signal Teurer in der Pflege, separate SEO-Kampagnen

Für die meisten Unternehmensseiten und Blogs ist 2026 ein Pfadpräfix die praktische Wahl: ein Stack, eine Analytics-Setup, einfacheres Deploy. Subdomains und ccTLDs lohnen sich bei starker lokaler Marke, eigenen Rechtsträgern oder einem eigenen Markt-Team.

Legen Sie die Standardsprache fest: entweder Root ohne Präfix (/) oder explizit /en/. Ein Mix aus «manchmal mit Präfix, manchmal ohne» führt zu Duplikaten.

So richten Sie hreflang richtig ein

  1. Listen Sie auf jeder Seite alle verfügbaren Äquivalente: hreflang="ru", hreflang="en", hreflang="de" usw.
  2. Fügen Sie eine Self-Reference hinzu: die Seite verweist auch auf sich selbst.
  3. Die Verknüpfung muss gegenseitig sein: wenn A auf B zeigt, zeigt B auf A.
  4. Nutzen Sie BCP-47-Codes: Sprache (en) oder Sprache-Region (en-GB, pt-BR).
  5. Bei Bedarf x-default setzen - Standardseite für nicht passende Locales (oft Sprachwahl oder EN).
  6. Dieselben Annotationen in HTML <link rel="alternate" hreflang="..."> und/oder in der XML-Sitemap spiegeln.

Beispiel-Fragment im <head>:

<link rel="alternate" hreflang="ru" href="https://example.com/blog/post/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/blog/post/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/blog/post/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/post/" />

Typische Fehler

1. Keine Gegenseitigkeit

Die russische Seite verlinkt auf EN, die englische hat keinen Rückverweis auf RU. Die Suchmaschine kann die ganze Gruppe ignorieren.

2. Canonical zeigt auf die «Hauptsprache»

Der Canonical der russischen Seite zeigt auf die englische «als Original». Locales wirken dann wie Duplikate, nicht wie Alternativen. Canonical muss auf sich selbst zeigen (oder auf die kanonische URL derselben Locale), nicht auf eine andere Sprache.

3. Auto-Redirect nach IP / Accept-Language

Nutzer und Bots können die gewünschte Version nicht zuverlässig öffnen. Besser: eigene URL pro Locale + Sprachumschalter, ohne Zwangsredirect von der Root auf eine «geratene» Sprache für alle.

4. Unvollständiger Locale-Satz

Im Menü 5 Sprachen, in hreflang 2. Oder ein Artikel ist übersetzt, der nächste nicht - und die Karte zeigt trotzdem kaputte Alternates. Lieber ehrlich: nur URLs, die wirklich existieren.

5. Sprache und Region verwechseln

de ist Deutsch. de-AT ist Deutsch für Österreich. Wenn der Inhalt für DE/AT/CH gleich ist, erzeugen Sie keine drei nahezu identischen Seiten ohne echte Lokalisierung von Preisen, Versand und Rechtstexten.

6. Anderer Sinn unter einer «Übersetzung»

Die URL ist «übersetzt», Angebot, Währung und CTA gehören aber zu einem anderen Markt. Für SEO ist das kein Äquivalent mehr - hreflang kann hier schaden.

7. Sitemap und interne Links vergessen

Tags im <head> sind da, aber in der XML-Sitemap fehlt xhtml:link, und der Sprachlink im Footer führt immer zur Startseite statt zum Äquivalent des aktuellen Artikels. Interne Vernetzung der Locales verstärkt das Signal.

Checkliste vor dem Launch

  1. Ein URL-Schema für die gesamte Website.
  2. Jede indexierbare Seite hat einen vollständigen gegenseitigen hreflang-Satz plus Self.
  3. Canonical verklebt keine verschiedenen Sprachen.
  4. Kein aggressiver Geo-Redirect, der die Indexierung blockiert.
  5. Die Sitemap enthält alle Locales und Annotationen.
  6. Der Sprachumschalter führt zum Äquivalent, nicht nur zur Homepage.
  7. 404 und «noch nicht übersetzt» sind klar gelöst (sanfter Fallback oder ehrliche 404), ohne stillschweigend eine andere Sprache unter derselben URL auszuliefern.

Fazit

Eine mehrsprachige Website funktioniert, wenn jede Zielgruppe eine stabile URL hat und hreflang die Äquivalente ehrlich verknüpft. Wählen Sie ein Adressschema, halten Sie die Gegenseitigkeit der Annotationen, zerstören Sie Locales nicht mit Canonical oder Geo-Redirect - dann muss die Suchmaschine die Sprache nicht mehr für Sie erraten.

Wenn Sie ein URL-Schema, hreflang und Sitemap für Ihren Stack brauchen - oder Ihren aktuellen Auftritt auf diese Fehler prüfen lassen möchten - melden Sie sich.

Häufig gestellte Fragen

Brauche ich hreflang bei nur zwei Sprachen?

Ja, wenn beide Versionen in der Suche für ihr Publikum erscheinen sollen. Schon ein RU/EN-Paar ohne gegenseitige Annotationen zeigt oft die falsche Sprache oder wirkt wie Duplikate.

Was ist besser: /en/ im Pfad oder eine Subdomain?

Für die meisten Projekte - ein Pfadpräfix. Eine Subdomain lohnt sich bei getrenntem Hosting, Team oder starker Markttrennung. Eine eigene ccTLD - wenn Marke und Rechtsträger wirklich lokal sind.

Ist x-default Pflicht?

Nicht Pflicht, aber nützlich. Meist zeigt es auf die Sprachwahl oder die internationale Hauptversion (oft EN). Ohne es wählt die Suchmaschine den Fallback selbst.

Reicht hreflang nur in der Sitemap?

Ja, Google versteht Sitemap-Annotationen. In der Praxis ist die Doppelung in HTML und Sitemap robuster - leichter zu debuggen und weniger Drift bei Teil-Deploys.

Warum ist die Sprache in den SERPs nach hreflang immer noch falsch?

Oft sind nicht die Tags schuld, sondern die Signale drumherum: Canonical auf eine andere Sprache, Redirects, dünne/maschinelle «Übersetzung», kaputte URLs in der Gruppe oder fehlende interne Links zum Äquivalent. Prüfen Sie Gegenseitigkeit und ob beide Seiten wirklich indexiert sind.

Kontakt