SEO für mehrsprachige Websites: Der vollständige Leitfaden
Eine übersetzte Website und eine mehrsprachige SEO-Strategie sind nicht dasselbe. Viele Seiten schicken jede Seite durch ein Übersetzungstool, veröffentlichen sie und bleiben trotzdem außerhalb des Heimatmarkts unsichtbar — weil Suchmaschinen nie erfahren haben, welche Seite welches Publikum bedient, und weil die Formulierungen nicht dem entsprechen, wie in diesem Markt tatsächlich gesucht wird.
Dieser Leitfaden behandelt, was wirklich darüber entscheidet, ob übersetzte Inhalte ranken: URL-Struktur, korrekte Hreflang-Implementierung (mit echtem Code), der Unterschied zwischen Lokalisierung und Übersetzung, sowie marktspezifische Keyword-Recherche, die kein Übersetzungstool für Sie erledigt.
Was ist mehrsprachiges SEO, und was unterscheidet es von klassischem SEO?
Mehrsprachiges SEO ist die Optimierung einer Website, damit jede Sprachversion in den Suchergebnissen ihres eigenen Marktes rankt — nicht nur existiert, sondern tatsächlich für die Suchanfragen erscheint, die Menschen in dieser Sprache stellen. Es kombiniert drei Ebenen, über die klassisches einsprachiges SEO nicht nachdenken muss: eine URL-Struktur, die Sprachen klar trennt, technische Signale (Hreflang, Sitemaps), die Suchmaschinen mitteilen, welche Version welches Publikum bedient, und Keyword-Recherche, die pro Markt separat erfolgt, statt aus einer Quellliste übersetzt zu werden.
Der Einsatz ist real: rund die Hälfte aller Webinhalte ist auf Englisch, während Englisch die Muttersprache eines deutlich kleineren Anteils der Internetnutzer weltweit ist — eine Lücke, die echte Suchnachfrage darstellt, die niemand in der Sprache der Besucher bedient.
URL-Struktur wählen: Subdirectory, Subdomain oder ccTLD
Diese Entscheidung ist praktisch dauerhaft, sobald Content darauf aufgebaut ist — sie lohnt sich, bevor auf weitere Sprachen skaliert wird.
| Struktur | Beispiel | Am besten für |
|---|---|---|
| Subdirectory | example.com/de/ | Die meisten Seiten — alle Versionen bleiben unter einer Domain, was Linkkonsolidierung, Wartung und Hreflang-Setup vereinfacht |
| Subdomain | de.example.com | Teams, die einen wirklich separaten Tech-Stack oder ein eigenes CMS pro Markt brauchen; Google kann eine Subdomain der Hauptdomain zuordnen, aber Links und Rankingsignale werden nicht automatisch geteilt wie innerhalb einer einzigen Domain |
| ccTLD | example.de | Marken mit starker länderspezifischer Identität oder einem regulatorischen Grund, die Domain zu lokalisieren — jede ccTLD braucht eigenen Linkaufbau, eigene Promotion und eigene technische Pflege |
Subdirectories gewinnen bei den meisten Seiten aus einem praktischen, nicht mystischen Grund: Alle Sprachen unter einer Domain zu halten bedeutet eine Website zu pflegen, einen Ort, an dem sich Links konsolidieren, und das einfachste mögliche Hreflang-Setup. Eine Subdomain oder ccTLD wird nicht dafür abgestraft, separat zu sein — aber es bedeutet, praktisch jede Off-Page-Maßnahme (Links, Einträge, lokale Vertrauenssignale) für diese Version erneut aufzubauen.
Hreflang-Tags: Was sie wirklich tun, und wie man sie schreibt
Hier ein Detail, das die meisten Ratgeber leicht falsch darstellen: Google nutzt Hreflang nicht, um zu erkennen, in welcher Sprache eine Seite geschrieben ist — das bestimmt Google algorithmisch anhand des tatsächlichen Inhalts. Was Hreflang tut: Google mitteilen, welche Ihrer Seiten gleichwertige Versionen voneinander sind, damit die passende Version dem jeweiligen Suchenden ausgespielt wird — statt etwa die französische Seite jemandem zu zeigen, der auf Deutsch sucht. Googles eigene Dokumentation ist bei dieser Unterscheidung eindeutig.
Eine einfache HTML-Implementierung im <head> jeder Version sieht so aus:
<link rel="alternate" hreflang="en" href="https://example.com/en/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />Jede Version braucht den vollständigen Satz an Tags, einschließlich eines Tags, das auf sich selbst verweist — die deutsche Seite listet die deutschen, englischen und x-default-Tags, und ebenso die englische Seite.
Sprach- versus Regionscodes
Ein Sprachcode allein (en, de) zielt auf alle Sprecher dieser Sprache, unabhängig vom Standort. Ein Regionscode grenzt das ein: en-US zielt speziell auf englischsprachige Nutzer in den USA, en-GB auf englischsprachige Nutzer in Großbritannien. Bedienen Sie sowohl ein US- als auch ein UK-Publikum mit unterschiedlichen Preisen oder Schreibweisen, nutzen Sie die regionsspezifischen Codes für diese beiden plus ein generisches en als Auffangoption für englischsprachige Nutzer anderswo. Codes müssen ISO 639-1 für die Sprache und ISO 3166-1 Alpha-2 für die Region folgen — reservierte oder informelle Codes wie “EU” oder “UK” (der tatsächliche Code ist “GB”) sind ungültig und werden stillschweigend ignoriert.
x-default: die Ausweichoption
x-default teilt Google mit, welche Version einem Besucher gezeigt werden soll, dessen Sprache zu keiner angebotenen Version passt — besonders nützlich auf einer Startseite mit Sprach-/Länderauswahl, um nicht zugeordnete Besucher sinnvoll weiterzuleiten statt zu raten.
Jede Implementierung braucht diese drei Dinge, um tatsächlich zu funktionieren:
- Rückverweise auf jeder Seite. Verlinkt Ihre deutsche Seite auf die englische Version, muss die englische Version zurück auf die deutsche verlinken. Google ignoriert einseitige Hreflang-Annotationen vollständig — das ist die häufigste Ursache dafür, dass Hreflang “nicht funktioniert”.
- Gültige Sprach- und Regionscodes, wie oben beschrieben.
- Eine konsistente Methode. Hreflang kann über HTML-Tags, HTTP-Header oder ein XML-Sitemap deklariert werden — alle drei sind für Google gleichwertig gültig, aber mehrere Methoden gleichzeitig auf derselben Website erhöhen das Risiko, dass sie sich widersprechen. Eine Methode wählen und überall konsequent nutzen.
Hreflang und Canonical-Tags
Jede lokalisierte Seite sollte in der Regel ein selbstreferenzierendes Canonical-Tag verwenden. Die deutsche Seite sollte auf die deutsche URL kanonisieren, die englische Seite auf die englische URL. Wenn jede übersetzte Seite auf die ursprüngliche englische Seite verweist, kann Google die lokalisierten URLs als Duplikate behandeln und die daran hängenden Hreflang-Signale ignorieren.
Nur indexierbare, kanonische URLs sollten in einem Hreflang-Cluster enthalten sein. Weitergeleitete, blockierte, noindex- oder nicht-kanonische URLs können verhindern, dass die Implementierung wie erwartet funktioniert.
Eine Sprache pro Seite
Eine Seite mit übersetztem Fließtext, aber englischem Navigationsmenü, oder ein Kommentarbereich mit drei gemischten Sprachen, sendet ein verwirrendes Signal darüber, welche Sprache die Seite tatsächlich hat — und wirkt auf menschliche Besucher genauso schlecht. Halten Sie Navigation, Footer, Pop-ups und nutzergenerierte Inhalte in derselben Sprache wie die Seite selbst, soweit Sie das moderieren können. Interne Links sollten auf gleichsprachige Seiten verweisen: Ein deutscher Blogbeitrag, der auf eine englische Ressourcenseite verlinkt, bricht das Sprachsignal sowohl für Besucher als auch für den Crawler.
Für die Sprachauswahl selbst: Nutzen Sie Sprachnamen (“Deutsch”, “Français”) statt Flaggen, da eine Flagge ein Land repräsentiert, keine Sprache — Französisch wird weit außerhalb Frankreichs gesprochen, Deutsch weit außerhalb Deutschlands. Und stellen Sie sicher, dass die Links der Sprachauswahl echte, crawlbare HTML-Links sind, keine reinen JavaScript-Klick-Handler, denen ein Crawler nicht folgen kann.
Übersetzung ist keine Lokalisierung
Eine Seite kann grammatikalisch perfekt in der Zielsprache sein und trotzdem am Markt vorbeigehen — weil die Formulierungen, die in einer Sprache konvertieren, keine direkte Übersetzung der Formulierungen sind, die in einer anderen konvertieren. Das Suchverhalten selbst variiert je nach Markt: Manche Zielgruppen reagieren auf direkte Vergleiche und Fakten, andere erwarten mehr Kontext und Sozialbeweise, bevor sie einer Aussage vertrauen. Eine wörtliche Übersetzung überträgt die Sätze; sie überträgt nicht, welche Aussagen die Leserschaft zuerst sehen muss.
In der Praxis skaliert der Workflow ohne explodierende Kosten so: maschinelle Übersetzung als Basis, mit menschlicher Prüfung konzentriert auf die Seiten, die tatsächlich über Conversions entscheiden — Startseite, wichtigste Kategorie- oder Serviceseiten, und alles, was für kommerziell intendierte Begriffe rankt. Die Basisübersetzung deckt Long-Tail-Inhalte ab; das Prüfbudget wird dort eingesetzt, wo es Ergebnisse verändert.
Keyword-Recherche pro Markt — nicht übersetzte Keywords
Die eigene bestperformende Keyword-Liste direkt zu übersetzen, ist einer der häufigsten Gründe, warum mehrsprachiges SEO unterperformt, weil Suchvolumen und Suchintention sich über Sprachen hinweg nicht gemeinsam bewegen. Ein Begriff kann perfekt übersetzt sein und dennoch ein komplett anderes Suchvolumen tragen oder auf eine völlig andere Intention im Zielmarkt verweisen — manchmal wird eine technisch korrekte Übersetzung kaum gesucht, während eine lockerere, natürlichere lokale Formulierung das eigentliche Volumen trägt. Der einzige Weg, das herauszufinden, ist frische Keyword-Recherche in jeder Zielsprache mit einem lokalen Keyword-Tool statt einer übersetzten Seedliste — und die tatsächlichen Suchergebnisse für diesen Begriff zu prüfen, bevor Content darauf aufgebaut wird.
Metadaten und strukturierte Daten müssen auch übersetzt werden
Title-Tags, Meta-Beschreibungen und Alt-Texte sind genau das, was Suchende vor dem Klick sehen — ein unübersetzter Titel neben übersetztem Fließtext signalisiert auf einen Blick, dass diese Seite nicht für sie gemacht wurde, und die Klickrate spiegelt das sofort wider. Zeichenlimits verschieben sich zudem je nach Sprache: Deutsche Titel brauchen routinemäßig mehr Zeichen als englische, um dasselbe zu sagen, und CJK-Sprachen verhalten sich wieder anders — Metadaten brauchen also einen eigenen Durchgang pro Sprache statt einer einmaligen Längenprüfung in der Ausgangssprache.
Strukturierte Daten folgen derselben Logik, mit einer Nuance, die es wert ist, präzise zu sein: Die Property-Namen von Schema.org — name, description, offers — bleiben unabhängig von der Seitensprache auf Englisch, da sie Teil des Vokabulars selbst sind, nicht Inhalt. Es sind die Werte, die diesen Properties zugewiesen werden, die zur Seite passen müssen: Eine deutsche Produktseite sollte einen deutschen Produktnamen und eine deutsche Beschreibung als Wert von name und description haben, nicht englische. Und halten Sie die Erwartungen an das, was Schema leisten kann, realistisch — nicht jeder Schema.org-Typ entspricht tatsächlich einem von Google unterstützten Rich Result, prüfen Sie also Googles Liste unterstützter Features, bevor Sie annehmen, ein bestimmtes Markup ändere die Darstellung in der Suche.
Technisches Fundament: Sitemaps
Ein XML-Sitemap mit eingebetteten Hreflang-Annotationen ist eine von drei gleichwertigen Methoden, Hreflang zu deklarieren — neben HTML-Tags und HTTP-Headern —, nützlich vor allem, wenn Sie Sprachsignale lieber in einer zentralen Datei verwalten als jeden Seiten-<head> einzeln zu bearbeiten. Technisch steht sie nicht über den beiden anderen Methoden; wählen Sie, was zu Ihrer Website passt, und bleiben Sie dabei — mehrere Methoden gleichzeitig zu nutzen ist meist genau das, was Widersprüche zwischen ihnen verursacht.
Für das Monitoring gilt: Die Google Search Console teilt Ihre Sprachversionen nicht automatisch in separate Properties auf — das ist ein Einrichtungsschritt, den Sie selbst vornehmen. Für einfacheres sprachspezifisches Monitoring können Sie separate URL-Präfix-Properties für einzelne Sprachverzeichnisse oder Subdomains anlegen (eine für example.com/de/, eine weitere für example.com/en/), womit Sie Indexierung und Performance pro Sprache unabhängig verfolgen können.
Funktioniert Ihr Hreflang-Setup tatsächlich?
Klucco prüft Ihr internationales SEO-Setup — Hreflang, URL-Struktur und Indexierung — über jede Sprachversion hinweg und macht daraus einen priorisierten Plan.
Autorität in jedem Markt aufbauen
Links tragen thematische und sprachliche Relevanz, die sich nicht automatisch über Märkte hinweg überträgt — ein Link von einem bekannten Publisher in Ihrem Heimatmarkt wird schlicht nicht vom selben Publikum gesehen wie ein Link von einer mittelgroßen Branchenseite in Ihrem Zielmarkt, und Relevanz für die Leserschaft dieses Marktes ist es, was für die Sichtbarkeit dieser Version zählt. Ihren bestperformenden Content für einen neuen Markt neu zu veröffentlichen und ihn den eigenen Publikationen, Foren und Branchenblogs dieses Marktes anzubieten, bringt meist Links, die eine Quelle in Ihrer Ausgangssprache nie gebracht hätte. Halten Sie Hreflang dabei sauber: Eine Seite, die starke lokale Links gewinnt, aber Besucher durch ein falsch konfiguriertes Tag zur falschen Sprachversion schickt, verschwendet genau den Linkwert, den sie gerade gewonnen hat.
Ladezeit über jede Sprachversion hinweg
Mehrsprachige Websites tragen Geschwindigkeitsrisiken, die einsprachige Seiten nicht haben: zusätzliches Seitengewicht durch Übersetzungsskripte oder Plugins, Hosting, das geografisch weit von manchen Zielgruppen entfernt ist, und lokalisierte Bilder, die nicht separat von der Ausgangsversion optimiert wurden. Testen Sie Core Web Vitals pro Sprachversion statt einmalig in der Ausgangssprache — die Performance kann sich zwischen Versionen derselben Website tatsächlich unterscheiden, besonders wenn ein CDN nicht so konfiguriert ist, dass es jede Region gleich gut bedient.
Aus unserer Erfahrung: Hreflang und zweisprachiger Content für DACH- und US-Märkte
Wir übernehmen Hreflang-Implementierung und den Aufbau zweisprachiger Inhalte für Kunden, die sowohl im DACH- als auch im US-Markt tätig sind — zwei Zielgruppen, die selbst dann unterschiedlich suchen, wenn eine wörtliche Übersetzung auf der Seite identisch aussehen würde. Das wiederkehrende Muster, das wir sehen: Websites, die die deutsche Version als reinen Übersetzungsdurchgang der englischen Seite behandeln, performen durchgehend schlechter als Websites, bei denen der deutsche Content von Anfang an als eigener Markt recherchiert und strukturiert wurde — mit eigener Keyword-Recherche und eigener interner Verlinkung, korrekt über Hreflang verbunden, statt als zwei getrennte Websites zu bleiben, die zufällig dieselbe Domain teilen.
Checkliste vor dem Launch
| Prüfpunkt | Wie man es überprüft |
|---|---|
| Jede Sprachversion hat vollständige Hreflang-Tags inklusive Selbstverweis | Quellcode ansehen oder einen Hreflang-Validator auf jeder Sprachstartseite nutzen |
| Rückverweise bestehen in beide Richtungen | Prüfen, dass die englische Seite zurück auf Deutsch verlinkt und umgekehrt, nicht nur eine Richtung |
| Nur eine Hreflang-Methode wird sitewide genutzt | Prüfen, dass Hreflang nicht auf manchen Seiten per HTML-Tag und auf anderen per Sitemap deklariert wird |
| Metadaten sind übersetzt, nicht nur der Fließtext | Title-Tags und Meta-Beschreibungen in der Suchvorschau jeder Sprache prüfen, nicht nur auf der Seite selbst |
| Links der Sprachauswahl sind crawlbares HTML | JavaScript deaktivieren und prüfen, ob die Umschalt-Links weiterhin im Quellcode erscheinen |
| Jede Sprachversion ist in der Search Console registriert | URL-Präfix-Properties pro Sprachverzeichnis oder Subdomain einrichten, falls separates Reporting gewünscht ist |
| Keyword-Ziele wurden pro Markt recherchiert, nicht übersetzt | Suchvolumen für Zielkeywords im eigenen Keyword-Tool dieses Marktes bestätigen, nicht aus der Quellliste übernehmen |
Häufige Fehler bei mehrsprachigem SEO
- Hreflang nur auf neuen Seiten hinzufügen, ohne ältere Seiten mit Rückverweis zu aktualisieren (fehlende Rückverweise).
- Hreflang über mehr als eine Methode deklarieren (HTML-Tags und Sitemap) und beide auseinanderlaufen lassen.
- Eine Keyword-Liste direkt übersetzen statt Suchvolumen und Intention pro Markt zu recherchieren.
- Navigation, Footer oder Pop-ups auf einer sonst übersetzten Seite unübersetzt lassen.
- Flaggen statt Sprachnamen in der Sprachauswahl verwenden.
- Besucher automatisch per IP oder Browsersprache umleiten, ohne crawlbare alternative URLs dahinter.
- Metadaten (Titel, Meta-Beschreibungen, Alt-Texte) unübersetzt lassen, während der Fließtext vollständig lokalisiert ist.
Unsicher, welche Sprachversion Sichtbarkeit verliert?
Schicken Sie uns Ihr Hreflang-Setup, und wir sagen Ihnen im Gespräch genau, was kaputt ist — keine generische Checkliste, sondern Ihre tatsächliche Implementierung.
