Mehrsprachiges SEO

TL;DR — Multilingual SEO ist die Optimierung einer Website, die in mehr als einer Sprache verfügbar ist, damit die richtige Version für die richtige Person angezeigt wird. Es geht um Sprache, nicht um Land – das ist das Erste, was man klarstellen muss. Sie geben jeder Sprache ihre eigene URL, teilen Google mit, welche URLs Versionen voneinander sind, mit hreflang, und lassen Google die Sprache anhand des tatsächlichen Texts auf der Seite erkennen.

Multilingual vs. multi-regional – zuerst klären

Diese beiden werden ständig verwechselt, und das gesamte Thema ergibt mehr Sinn, sobald man sie trennt:

• Multilingual = Ihre Website bedient mehr als eine Sprache. Eine Schweizer Website auf Deutsch, Französisch und Italienisch ist multilingual – drei Sprachen, ein Land.
• Multi-regional = Ihre Website zielt auf Nutzer in mehr als einem Land ab. Eine Website mit separaten US- und UK-englischen Versionen ist multi-regional – eine Sprache, zwei Regionen.

Viele Websites sind beides (denken Sie an eine globale Marke mit Englisch, Spanisch und Französisch, jeweils nach Land getrennt). Aber die Signale und die Probleme sind unterschiedlich, daher hilft es zu wissen, womit man es tatsächlich zu tun hat. Diese Seite behandelt die Sprachseite.

Was “Sprach-Targeting” tatsächlich bedeutet

Wenn Ihre Website dieselbe Seite in mehreren Sprachen hat, möchten Sie, dass Google:

1. Weiß, dass jede Sprachversion existiert.
2. Versteht, dass sie Versionen derselben Sache sind.
3. Die deutsche Version deutschen Suchenden und die französische Version französischen Suchenden zeigt.

Das erreichen Sie mit einer Handvoll Signalen – hauptsächlich dem hreflang- Attribut, einem kleinen Tag, das besagt: “Diese URL ist die spanische Version, jene ist die französische Version, hier ist die Beziehung zwischen ihnen.” Google versucht dann, die passende Version auszuliefern.

Der Teil, der Anfänger überrascht: Google erkennt in welcher Sprache eine Seite ist, indem es die sichtbaren Wörter darauf liest – nicht durch irgendeine Einstellung in Ihrem Code. Eine Seite, die im Code Deutsch angibt, aber voller englischem Text ist, wird also als Englisch behandelt. Schreiben Sie echten Inhalt in der Zielsprache; das ist das Signal, das zählt.

Wo die verschiedenen Sprachversionen leben (URL-Struktur)

Sie benötigen eine separate URL für jede Sprache. Es gibt drei gängige Möglichkeiten:

• Unterverzeichnis – example.com/es/, example.com/fr/. Die übliche Wahl für die meisten Websites: einfach einzurichten, und alle Versionen teilen die Stärke Ihrer einen Domain.
• Subdomain – es.example.com, fr.example.com. Funktioniert, aber Suchmaschinen behandeln sie eher wie eine separate Website.
• Ländercode-Domain (ccTLD) – example.es, example.fr. Das stärkste Signal für das Targeting eines Landes, aber es ist eine komplett separate Website, für die Autorität aufgebaut werden muss.

Vermeiden Sie es, die Sprache in einen URL-Parameter wie example.com?lang=es zu packen – Google empfiehlt ausdrücklich davon ab.

Wann Sie tatsächlich Multilingual SEO benötigen (vs. nur Übersetzen)

Wenn Sie nur die Wörter übersetzen und auf derselben URL ablegen – oder alle automatisch nach ihrem Standort umleiten – haben Sie nicht wirklich Multilingual SEO, und Google findet Ihre anderen Sprachen möglicherweise nie. Sie benötigen das Echte (separate URLs + hreflang + Inhalt, den Google crawlen kann), sobald Sie tatsächlich mehrere Sprachen bedienen und möchten, dass jede rankt. Wenn Sie nur eine Sprache haben, können Sie das alles überspringen.

Möchten Sie die technische Tiefe – wie Googles Sprachalgorithmus funktioniert, die Bing-Unterschiede, die häufigen hreflang-Fehler und die Auto-Übersetzungs-Bedrohung von 2025? Wechseln Sie zum Erweitert-Tab.

Multilingual SEO-Fehler

lang als Googles Spracherkennung behandeln

Warum es scheitert: Google bestimmt die Sprache anhand des sichtbaren Seitentexts und nicht anhand des HTML-Attributs. Stattdessen tun: Stellen Sie sicher, dass der gerenderte Hauptinhalt konsistent die Zielsprache verwendet; behalten Sie korrekte Metadaten für Barrierefreiheit und Engines bei, die sie verwenden.

hreflang verwenden, um die Sprache einer Seite zu deklarieren

Warum es scheitert: hreflang ordnet alternative URLs zu; es ersetzt keinen sinnvollen übersetzten Inhalt. Stattdessen: Veröffentlichen Sie eine eigene, crawlbare URL mit sichtbarem Inhalt in der Zielsprache und verbinden Sie dann äquivalente Versionen mit reziprokem hreflang.

Besucher durch eine automatische Sprachweiterleitung zwingen

Warum es scheitert: Crawler und mehrsprachige Nutzer können in der angenommenen Version gefangen sein. Stattdessen: Halten Sie jede Version direkt zugänglich und bieten Sie einen sichtbaren Vorschlag sowie crawlbare Sprachlinks an.

Testen Sie sich: Mehrsprachiges SEO

TL;DR — Wenn Sie das mentale Modell verstehen, ergibt sich der Großteil des mehrsprachigen SEO von selbst. Google liest Ihr <html lang>-Attribut oder den Content-Language-HTTP-Header nicht, um die Sprache zu erkennen – es verwendet hauptsächlich sichtbaren Text. Andere Suchmaschinen verwenden möglicherweise andere Signale, prüfen Sie daher deren aktuelle Anleitungen. hreflang deklariert nicht die Sprache einer Seite; es ordnet zu, welche URLs Alternativen sind, damit Google die richtige austauschen kann – und es ist ein Hinweis, keine Anweisung. Es ist auch äußerst fehleranfällig: Meine Studie über 374 756 Domains ergab, dass 67 % hreflang-Probleme hatten. Verwenden Sie für die meisten Websites Unterverzeichnisse, leiten Sie Googlebot niemals automatisch weiter und übersetzen Sie nur Seiten mit einem echten geschäftlichen Nutzen.

Mehrsprachig ≠ multiregional

Die grundlegende Unterscheidung. Mehrsprachig bezieht sich auf Sprache; multiregional auf das Land. Eine Schweizer Website auf Deutsch, Französisch und Italienisch ist mehrsprachig, aber einregional. Eine US-/UK-englische Website ist multiregional, aber einsprachig. Sie überschneiden sich ständig, aber sie verwenden unterschiedliche Signale und erzeugen unterschiedliche Probleme, daher trenne ich sie in meinem Kopf – und Sie sollten es auch tun. Googles eigene Darstellung: “A multilingual website is any website that offers content in more than one language,” (Übersetzung) „Eine mehrsprachige Website ist jede Website, die Inhalte in mehr als einer Sprache anbietet“, gegenüber “A multi-regional website is one that explicitly targets users in different countries.” (Übersetzung) „Eine multiregionale Website ist eine, die explizit Nutzer in verschiedenen Ländern anspricht.“

Wie Google die Seitensprache tatsächlich erkennt (das ist das Wichtigste)

Hier ist das am meisten missverstandene Thema in diesem gesamten Bereich, und es lohnt sich, es zu übertreiben, weil so viele es falsch verstehen:

Google ignoriert Ihr <html lang>-Attribut. Google ignoriert Ihren Content-Language-HTTP-Header. Es liest den sichtbaren Text.

Direkt aus der Dokumentation: “Google uses the visible content of your page to determine its language. We don’t use any code-level language information such as lang attributes, or the URL.” (Übersetzung) „Google verwendet den sichtbaren Inhalt Ihrer Seite, um deren Sprache zu bestimmen. Wir verwenden keine sprachlichen Informationen auf Code-Ebene wie lang-Attribute oder die URL.“ Und auf der hreflang-Seite: “Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” (Übersetzung) „Google verwendet weder hreflang noch das HTML-lang-Attribut, um die Sprache einer Seite zu erkennen; stattdessen verwenden wir Algorithmen, um die Sprache zu bestimmen.“

In Search Off the Record (Juli 2024) gab Gary Illyes dem einen Namen: LDCP – Language Demotion, Country Promotion. Seine Erklärung: “if someone is searching in German and your page is in English, then you would get a demotion.” (Übersetzung) „Wenn jemand auf Deutsch sucht und Ihre Seite auf Englisch ist, erhalten Sie eine Herabstufung.“ Das ist ein Ranking-Mechanismus und grundlegender als hreflang – wenn Ihre Seite nicht wirklich in der Sprache des Suchenden verfasst ist, stuft LDCP sie unabhängig von Ihren Tags herab. (Illyes deutete auch an, dass diese Art manueller Signalisierung ausläuft, und merkte an, dass Google bereits Systeme habe, die „automatisch lernen“, alternative Sprachversionen zu paaren – Auto-Erkennung ist die Richtung, in die es geht.)

Warum misstraut Google <html lang> so sehr? Weil es ständig falsch ist. Gary erzählte die Joomla-Geschichte: Das CMS “came with the Lang attribute set to English, and there was no way to override it… And then you looked at the page, and it was 100% German. So it was like you can’t trust that.” (Übersetzung) „kam mit dem Lang-Attribut auf Englisch gesetzt, und es gab keine Möglichkeit, es zu überschreiben … Und dann sah man sich die Seite an, und sie war zu 100 % Deutsch. Also war es so, dass man dem nicht vertrauen kann.“ John Mueller hat dasselbe gesagt – das HTML-lang-Attribut ist “something we don’t use at all” (Übersetzung) „etwas, das wir überhaupt nicht verwenden“ und “almost always wrong. So we tend to ignore that.” (Übersetzung) „fast immer falsch. Deshalb neigen wir dazu, es zu ignorieren.“

Das Fazit: Spracherkennung ist ein Inhaltsproblem, kein Markup-Problem. Schreiben Sie echten Inhalt in der Zielsprache. Das lang-Attribut ist dennoch wichtig für Barrierefreiheit (Screenreader) und für Bing – nur nicht für Googles Spracherkennung.

Bing macht es umgekehrt

Bing unterstützt kein hreflang. Und wo Google Ihre codeebenen Sprachhinweise ignoriert, ist Bing auf sie angewiesen. Bings Prioritätsreihenfolge:

1. <meta http-equiv="content-language" content="en-us"> – das primäre Signal.
2. <html lang="">-Attribut – sekundär.
3. Textinhalt auf der Seite.

Bings Format ist ein 2-Buchstaben-ISO-639-Sprachcode, ein Bindestrich, dann ein ISO-3166-Geografiecode (en-us, es-mx). Eine ordentlich internationalisierte Website, die auf beiden Engines läuft, möchte also Inhalte mit unterschiedlichen URLs plus hreflang (für Google/Yandex) plus das content-language-Meta-Tag (für Bing). Sie sind nicht redundant; sie speisen verschiedene Engines.

Was hreflang tatsächlich tut (und was nicht)

hreflang ist eine Beziehungskarte, kein Spracherkenner. Es sagt Google nicht, welche Sprache eine Seite hat – das bekommt Google bereits aus dem Inhalt. Es sagt Google, welche URLs Alternativen zueinander sind und für welche Sprach-Region-Zielgruppe, damit Google pro Suchendem die richtige einfügen kann. Google: “Use hreflang to tell Google about the variations of your content, so that we can understand that these pages are localized variations of the same content.” (Übersetzung) „Verwenden Sie hreflang, um Google über die Variationen Ihres Inhalts zu informieren, damit wir verstehen, dass diese Seiten lokalisierte Variationen desselben Inhalts sind.“

Drei Dinge müssen stimmen, sonst wird der Cluster ignoriert:

• Bidirektional. “If two pages don’t both point to each other, the tags will be ignored.” (Übersetzung) „Wenn nicht beide Seiten aufeinander verweisen, werden die Tags ignoriert.“ Englisch verweist auf Italienisch, Italienisch muss zurückverweisen.
• Selbstreferenzierend. Jede Seite listet sich selbst plus alle anderen auf.
• x-default als Fallback für nicht übereinstimmende Sprachen (empfohlen, nicht streng erforderlich).

Drei Bereitstellungsmethoden: HTML-<link>-Tags im <head>, der HTTP-Link-Header (nützlich für Nicht-HTML-Dateien wie PDFs) oder eine XML-Sitemap mit dem xhtml:link-Namespace. URLs müssen vollständig qualifiziert sein, einschließlich https://.

Und entscheidend: hreflang ist ein Hinweis, keine Anweisung. Googles eigene Aussage ist, dass “hreflang annotations are a hint to Google, not a directive.” (Übersetzung) „hreflang-Anmerkungen sind ein Hinweis für Google, keine Anweisung.“ Es kann und wird Sie überstimmen, wenn kanonische Tags, Inhaltssignale oder Indexierungsstatus widersprechen.

Der wertvolle, wenig behandelte Aspekt: hreflang beschleunigt die Indexierung neuer Sprachen

Hier ist ein Vorteil, über den fast niemand spricht. In derselben SOTR-Episode sagte Gary Illyes, dass das Entdecken von hreflang einen Verifizierungs-Crawl der Alternativen auslöst: “There is a dependency crawl triggering when we discover Hreflang, like we want to verify that.” (Übersetzung) „Es gibt einen Abhängigkeits-Crawl, der ausgelöst wird, wenn wir Hreflang entdecken, denn wir wollen das verifizieren.“ Einfach ausgedrückt – wenn Google hreflang auf einer Seite findet, crawlt es die anderssprachigen Versionen, um die Beziehung zu verifizieren, was die Indexierung Ihrer neuen Sprachseiten beschleunigt. hreflang dient also nicht nur der Auslieferung der richtigen Version; es ist ein Entdeckungsbeschleuniger für neu gestartete Sprachen.

Warum Ihre GSC-hreflang-Daten dünn aussehen (und das normal ist)

Ein weiterer Illyes-Punkt, den man verinnerlichen sollte: “Search Console only reports canonicals… the vast majority of the Hreflang clusters… are not canonical.” (Übersetzung) „Die Search Console meldet nur Kanonische… die überwiegende Mehrheit der Hreflang-Cluster… ist nicht kanonisch.“ Die meisten hreflang-Alternativen sind keine kanonischen URLs, daher tauchen sie nicht einzeln in der Abdeckungsberichterstattung der GSC auf. Wenn Ihre Dashboards so aussehen, als wären Ihre Sprachseiten „nicht indexiert“, ist das oft nur die GSC, die Kanonische meldet – kein echtes Problem. Verifizieren Sie mit dem URL-Inspektionstool und Live-SERPs, anstatt der aggregierten Zahl zu vertrauen.

Doppelte Inhalte: es-MX vs. es-ES

Eine häufige Sorge ist, dass zwei spanische Varianten als Duplikate gekennzeichnet werden. Googles tatsächliche Regel: “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” (Übersetzung) „Lokalisierte Versionen einer Seite werden nur dann als Duplikate betrachtet, wenn der Hauptinhalt der Seite unübersetzt bleibt.“ Zwei wirklich spanische Seiten mit echten regionalen Unterschieden (Währung, Wortschatz, lokale Referenzen) sind verschieden. Aber zwei es-ES- und es-MX-URLs mit identischem Text und ohne regionale Differenzierung werden als Duplikate behandelt – hreflang allein trennt sie nicht; unterschiedlicher regionaler Inhalt tut das. Innerhalb eines gültigen hreflang-Clusters können sich Signale auch über die Alternativen konsolidieren, was im Allgemeinen hilfreich ist.

URL-Struktur, interne Verlinkung und Spracherkennung

Struktur. Unterverzeichnisse (/es/, /fr/) für die meisten Websites – sie erben die Autorität der Root-Domain und sind wartungsarm. Subdomains werden eher wie separate Websites behandelt. ccTLDs sind das stärkste Länder-Geotargeting-Signal, bedeuten aber separate Eigenschaften und separaten Linkaufbau. URL-Parameter werden ausdrücklich „nicht empfohlen“.

Interne Verlinkung zwischen den Versionen. Verlinken Sie die Sprachversionen sinnvoll miteinander (der Sprachumschalter gehört dazu), aber behandeln Sie nicht jede Alternative als primären Navigationslink. Lassen Sie hreflang die formale Beziehung tragen; lassen Sie den Umschalter den Nutzern dienen.

Spracherkennungs-UX – und die Crawlbarkeitsfalle. Hier brechen Websites sich leise selbst. Googlebot „sendet HTTP-Anfragen, ohne Accept-Language im Request-Header zu setzen“ und crawlt hauptsächlich von US-IPs (obwohl es auch einige Nicht-US-IPs verwendet). Wenn Sie Benutzer basierend auf IP oder Accept-Language automatisch auf eine Sprachversion umleiten, sieht Googlebot möglicherweise nur Ihre englische Version und entdeckt den Rest nie. Googles unmissverständliche Anweisung: „Vermeiden Sie es, Benutzer automatisch von einer Sprachversion einer Website auf eine andere Sprachversion umzuleiten.“

Tun Sie stattdessen Folgendes: Stellen Sie eindeutige URLs bereit, annotieren Sie mit hreflang, und wenn Sie Benutzern helfen möchten, zeigen Sie ein unaufdringliches Hinweisbanner („Diese Seite ist auf Englisch verfügbar – wechseln?“), das sie auf ihrer aktuellen URL hält und ihre Wahl per Cookie oder localStorage speichert. Verwenden Sie Accept-Language als Vorschlag, niemals als Umleitungsauslöser. Und verwenden Sie keine Flaggen als Sprachkennungen – Flaggen sind Länder, keine Sprachen.

Übersetzungsqualität und maschinelle Übersetzung

Maschinelle Übersetzung selbst ist nicht verboten. Googles eigene Definition: „Skalierter Inhaltsmissbrauch liegt vor, wenn viele Seiten mit dem Hauptzweck erstellt werden, Suchrankings zu manipulieren und nicht den Nutzern zu helfen.“ Zum Zitat springen Übersetzung wird als ein Beispiel für eine automatisierte Transformation genannt, die von dieser Richtlinie abgedeckt wird – „einschließlich automatisierter Transformationen wie Synonymisierung, Übersetzung oder anderer Verschleierungstechniken“, insbesondere „wenn den Nutzern nur wenig Wert geboten wird“. Zum Zitat springen Das Urteil betrifft den Wert, nicht die Produktionsmethode. Rohe MT, die in großem Umfang ohne redaktionelle Aufsicht veröffentlicht wird, ist das eigentliche Risiko; MT mit menschlicher Überprüfung und Kuratierung (ein Workflow, der oft als MTPE bezeichnet wird) ist ein standardmäßiger, skalierbarer Weg, um dem zu entgehen. Beurteilen Sie eine übersetzte Seite so, wie Sie jede Seite beurteilen würden – dient sie der echten Suchintention für diesen Markt – und übersetzen Sie nicht nur Ihre englischen Keywords: Führen Sie echte Keyword-Recherche pro Sprache durch, denn Absicht und Formulierung unterscheiden sich von Markt zu Markt. (Mehr Tiefe: maschinelle Übersetzung und SEO.)

Schema für mehrsprachige Websites

Verwenden Sie die inLanguage-Eigenschaft in Ihrem Article/Product/FAQPage-Schema, um die Sprache des Inhalts anzugeben, und geben Sie jeder Sprachversion ihren eigenen Schema-Block in dieser Sprache. Schema und hreflang erfüllen unterschiedliche Aufgaben: hreflang ordnet alternative URLs zu; Schema klärt Inhaltsbedeutung und Sprache. Sie sind komplementäre Ebenen.

Die Fehlerquote: meine 374 756-Domain-Studie

Ich habe eine Studie über 374 756 Domains mit hreflang durchgeführt. Das Ergebnis: über 67 % hatten Probleme. Die Aufschlüsselung, nach Häufigkeit geordnet: fehlendes x-default (56,3 %), fehlende selbstreferenzierende Tags (18 %), defekte/weitergeleitete Referenzen (16,9 %), fehlende reziproke Tags (15,3 %), nicht-kanonische Referenzen (8 %), falsche ISO-Codes (4,6 %), inkonsistentes HTML-lang vs. hreflang (3,2 %), doppelte Spracheinträge (2,5 %) und dieselbe Seite für mehrere Sprachen deklariert (2,5 %).

Zwei Einschränkungen relativieren das Bild. Erstens sind die beiden häufigsten – x-default und selbstreferenzierend – empfohlen, nicht strikt erforderlich, sodass die tatsächliche Schwere weniger dramatisch ist, als die 67 % vermuten lassen. Zweitens: Google korrigiert vieles davon für Sie. Gary Illyes hat gesagt, dass hreflang-Fehler in seiner Implementierungsära “keine Probleme verursacht” hätten, und meine eigene langjährige Position (aus meinem Enterprise SEO Chaos SMX-Vortrag) ist, dass es möglicherweise nicht den Aufwand wert ist, jedem hreflang-Fehler nachzujagen, weil Google viele davon wahrscheinlich automatisch korrigiert. Aber die strukturellen Fehler – fehlende reziproke Links, defekte URLs – brechen das Cluster und sollten behoben werden. Triage: strukturelle Fehler beheben, verhaltensbezogene überwachen.

Die Bedrohung 2025: Googles translate.goog-Proxy

Eine neuere Besonderheit, die man kennen sollte (Motoko Hunts Artikel vom Juni 2025 bei Search Engine Land): Wenn Google feststellt, dass keine hochwertigen Inhalte in der Landessprache verfügbar sind, übersetzt es Inhalte automatisch über einen translate.goog-Proxy. Der Browser spielt eine Rolle – Chrome-Nutzer werden zur ursprünglichen URL des Publishers weitergeleitet (Traffic bleibt erhalten), aber Safari/Firefox-Nutzer laufen über translate.goog (Traffic geht verloren). Ahrefs-Daten beziffern dies auf 6,2 Millionen KI-Übersichts-Erscheinungen mit übersetzten URLs und Hunderte Millionen Klicks an Exposition. Die strategische Schlussfolgerung: Das Veröffentlichen von nativen Inhalten in der Landessprache ist sowohl die Verteidigung (Google wird nicht per Proxy übersetzen, was Sie bereits bereitstellen) als auch der Angriff (Sie ranken selbst für diese Märkte). Behandeln Sie automatisch übersetzte SERPs als Signal für ungedeckte Nachfrage.

Muellers Warnung: nicht alles übersetzen

Schließlich: Zurückhaltung. John Mueller warnt vor dem Alles-Sprachen-Reflex – “Let’s create all languages! Let’s make pages for all countries! What if someone in Japan wants to read it in Swahili?” – und merkt an, “it’s easy to dig into endless pits of complexity with hreflang.” Sein Rat, dem ich mich anschließe: “first… limit the number of pages you create to those that are absolutely critical & valuable.” Priorisieren Sie Seiten mit hohem Traffic und hoher Conversion in Märkten mit nachgewiesener Nachfrage (nutzen Sie GSC, um Suchanfragen zu finden, die in einer Zielsprache bereits Impressionen erzielen). Jede Sprachversion, die Sie erstellen, bedeutet Crawl-, Indexierungs-, Kanonisierungs- und Wartungsaufwand – investieren Sie nur dort, wo ein echter Return besteht.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Mehrsprachig ≠ multiregional. Mehrsprachig betrifft die Sprache (Schweizer Website in 3 Sprachen, 1 Land); multiregional betrifft das Land (US/UK-Englisch). Sie überschneiden sich, nutzen aber unterschiedliche Signale.
• Google erkennt die Sprache anhand des sichtbaren Textes — nicht <html lang>, nicht der Content-Language-Header, nicht die URL. Gary Illyes nannte den Ranking-Mechanismus LDCP (Language Demotion, Country Promotion): Seiten in der falschen Sprache werden herabgestuft.
• Bing ist das Gegenteil: Es unterstützt kein hreflang und verwendet <meta http-equiv="content-language"> als primäres Signal (Priorität: content-language meta > html lang > content).
• hreflang ist eine Beziehungskarte, kein Spracherkenner, und es ist ein Hinweis, kein Befehl. Muss bidirektional + selbstreferenzierend sein; x-default empfohlen.
• Zusätzlicher Vorteil: Das Entdecken von hreflang löst einen Verifizierungs-Crawl aus, was die Indexierung neuer Sprachseiten beschleunigt (Illyes). Die meisten Alternativen sind nicht kanonisch, daher meldet die GSC sie unterrepräsentiert — das ist normal.
• es-MX vs. es-ES sind nur Duplikate, wenn der Hauptinhalt unübersetzt ist; echte regionale Unterschiede trennen sie.
• URL-Struktur: Unterverzeichnisse für die meisten Websites; ccTLDs am stärksten für das Länder-Targeting; URL-Parameter vermeiden. Niemals automatisch weiterleiten per IP/Accept-Language — Googlebot crawlt ohne Accept-Language und meist von US-IPs, daher könnte er Ihre anderen Sprachen übersehen.
• Maschinelle Übersetzung ist nicht verboten. Googles Richtlinie zu skalierbarem Content-Missbrauch nennt Übersetzung als ein Beispiel für eine “automatisierte Transformation”, aber der Verstoß besteht darin, viele minderwertige Seiten zu veröffentlichen, um Rankings zu manipulieren — das Urteil betrifft den Wert, nicht die Methode. Rohe MT, die in großem Umfang ohne redaktionelle Aufsicht veröffentlicht wird, ist das eigentliche Risiko; MT mit menschlicher Überprüfung (MTPE) ist ein standardmäßiger, skalierbarer Workflow.
• Fehlerquote: Meine Studie mit 374 756 Domains fand 67 % mit hreflang-Problemen, aber Google korrigiert viele automatisch — beheben Sie strukturelle Fehler, überwachen Sie den Rest.
• Bedrohung 2025: Googles translate.goog-Proxy kann Traffic kapern, wo nativer Inhalt fehlt; nativer lokaler Inhalt ist sowohl Verteidigung als auch Angriff.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• Verwaltung von multiregionalen und mehrsprachigen Websites — das grundlegende Dokument: Definitionen, URL-Struktur-Optionen, Locale-Signale, die Warnung vor automatischen Weiterleitungen.
• Lokalisierte Versionen Ihrer Seiten — die hreflang-Referenz: die drei Implementierungsmethoden, Bidirektionalität, Selbstreferenzierung, x-default und die Duplikat-Inhaltsregel.
• Internationale SEO-Übersicht — der Einstiegspunkt für Sprach-/Länder-/Regionsoptimierung.
• So crawlt Google locale-adaptive Seiten — warum das Ausliefern unterschiedlicher Inhalte je nach wahrgenommenem Locale Crawl-/Indexierungslücken riskiert, und die Accept-Language-Anmerkung.

Bing / Microsoft

• So teilen Sie Bing Land und Sprache Ihrer Website mit — das content-language-Meta-Tag, sein Format und die Prioritätsreihenfolge, die Bing verwendet (immer noch die primäre technische Referenz).
• Bing-Webmaster-Richtlinien — die allgemeinen Richtlinien, einschließlich Sprach-/Länder-Targeting.

Zitate aus der Quelle

Offizielle Aussagen von Google und Bing zu mehrsprachigem SEO.

Google — wie Sprache erkannt wird

• “Google uses the visible content of your page to determine its language. We don’t use any code-level language information such as lang attributes, or the URL.” — Google Search Central docs. Zum Zitat springen
• “Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” Zum Zitat springen

Google – hreflang und Duplikate

• “Use hreflang to tell Google about the variations of your content, so that we can understand that these pages are localized variations of the same content.” Zum Zitat springen
• “If two pages don’t both point to each other, the tags will be ignored.” Zum Zitat springen
• “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” Zum Zitat springen

Google – Weiterleitungen und Definitionen

• “Avoid automatically redirecting users from one language version of a site to a different language version.” Zum Zitat springen
• “A multilingual website is any website that offers content in more than one language.” Zum Zitat springen

Gary Illyes, Google (Search Off the Record, „Internationalization & hreflang“, 25. Juli 2024)

• Zum LDCP-Algorithmus: “if someone is searching in German and your page is in English, then you would get a demotion.”
• Warum das HTML-lang-Attribut unzuverlässig ist: “[Joomla] came with the Lang attribute set to English, and there was no way to override it… And then you looked at the page, and it was 100% German. So it was like you can’t trust that.”
• Zu hreflang und dem Auslösen eines Verifizierungs-Crawls: “There is a dependency crawl triggering when we discover Hreflang, like we want to verify that.”
• Zur GSC-Berichterstattung: “Search Console only reports canonicals… the vast majority of the Hreflang clusters… are not canonical.” Episode anhören

John Mueller, Google

• Zum HTML-lang-Attribut: “the language attribute within the HTML markup is something we don’t use at all” und “almost always wrong. So we tend to ignore that.”
• Zum Übererstellen von Sprachen: “It’s easy to dig into endless pits of complexity with hreflang.” / “My recommendation would be first to limit the number of pages you create to those that are absolutely critical & valuable.”

Die Entscheidungsrahmen

1. Benötigen Sie mehrsprachig oder mehrregional? (oder beides)

Führen Sie dies vor allem anderen aus – es bestimmt, welche Signale Sie heranziehen:

Are you serving more than one LANGUAGE?
├─ No  → not a multilingual problem. Stop here for language work.
└─ Yes → multilingual. You need: distinct URLs per language
         + hreflang (Google/Yandex) + content-language meta (Bing)
         + real content in each language.

Are you also targeting more than one COUNTRY?
├─ No  → single-region multilingual (e.g. Swiss DE/FR/IT).
│        Use language-only hreflang codes (es, fr, de).
└─ Yes → multi-regional too. Add region to hreflang (es-MX, es-ES,
         en-GB, en-US) and consider ccTLDs for the strongest
         country signal.

Die Falle: Sprache als Ländersignal zu behandeln. Wie Gary Illyes es formulierte: “the language is absolutely not a tell for what country you are targeting.” (Übersetzung) „Die Sprache ist absolut kein Indikator dafür, welches Land Sie ansprechen.“

2. Vergleich der URL-Strukturen

3. Content-Prioritätsmatrix – was zuerst übersetzen

Übersetzen Sie nicht alles. Bewerten Sie Kandidatenseiten und arbeiten Sie von oben nach unten:

Priority = (organic demand in target market)
         × (conversion value of the page)
         ÷ (translation + maintenance effort)

Praktische Reihenfolge:

1. Seiten mit nachgewiesener Nachfrage – nutzen Sie GSC, um URLs zu finden, die bereits Impressionen/Klicks aus einer zielsprachigen Suchanfrage oder einem Land erhalten. Die Nachfrage ist bereits da; nutzen Sie sie.
2. Kernseiten mit hohem Traffic / hoher Conversion – Geldseiten und Top-Cluster-Hubs.
3. Unterstützende Cluster-Seiten – sobald der Kernmarkt validiert ist.
4. Long-Tail – zuletzt, und nur wenn sich der Markt auszahlt.

Muellers Regel steht über allem: “limit the number of pages you create to those that are absolutely critical & valuable.” (Übersetzung) „Begrenzen Sie die Anzahl der Seiten, die Sie erstellen, auf diejenigen, die absolut kritisch und wertvoll sind.“ Jede zusätzliche Sprachversion ist laufende Crawl-, Indexierungs- und Wartungskosten – investieren Sie dort, wo es Rendite gibt.

Sprachsignale – was jede Engine tatsächlich verwendet

Die eine Tabelle, die Sie sich merken sollten. Google und Bing lesen fast gegensätzliche Signale.

Bing-Prioritätsreihenfolge: content-language-Meta-Tag > <html lang> > Seiteninhalt.

Google in einem Satz: Es liest den sichtbaren Text, um die Sprache zu erkennen; alles auf Code-Ebene (lang, Content-Language, URL) wird für diesen Zweck ignoriert.

hreflang-Nichtverhandelbares: bidirektional, selbstreferenzierend, vollständig qualifizierte URLs mit https://, x-default empfohlen. Hinweis, keine Anweisung.

Nicht: automatische Weiterleitung nach IP/Accept-Language (Googlebot crawlt ohne Accept-Language, meist von US-IPs – es übersieht Ihre anderen Sprachen); Flags für Sprachen verwenden; rohe, ungeprüfte maschinelle Übersetzung in großem Umfang ohne redaktionellen Mehrwert ausgeben.

Änderungsprotokoll