Internationales SEO: Warum eure übersetzte Website nur in einer Sprache rankt

Viele internationale Websites sind eine einzelne Website mit nachträglich aufgesetzter Übersetzungsschicht. Sie ranken in ihrer Ursprungssprache und sonst fast nirgends. Die verantwortlichen Teams schließen daraus meist, dass die Übersetzung nicht gut genug war. An der Übersetzung liegt es selten.

Das Problem ist, dass die Seiten einmal für einen einzigen Markt geplant und danach in andere Sprachen übertragen wurden. Eine Seite kann perfekt übersetzt sein und trotzdem eine Frage beantworten, die in diesem Markt niemand stellt.

Übersetzung ist keine Lokalisierung

Käufer in verschiedenen Märkten suchen nicht in anderen Worten nach denselben Dingen. Sie suchen nach anderen Dingen.

Ein deutscher Einkäufer in der Industrie sucht bei der Recherche zu einem Bauteil nach einer Norm, einem Datenblatt oder einer Toleranz. Ein amerikanischer Einkäufer sucht beim selben Bauteil nach einem Anwendungsfall und einer Kundenreferenz. Übersetzt ihr die amerikanische Seite ins Deutsche, entsteht ein flüssiger Text, der eine Frage beantwortet, die der deutsche Käufer nicht gestellt hat. Er wird für nichts ranken, weil er genau dafür gebaut wurde.

Das wird in den Keyword-Daten sichtbar, sobald ihr aufhört, eure Keyword-Liste zu übersetzen. Führt die Recherche in jedem Markt von Grund auf durch. Die beiden Listen überschneiden sich weitaus weniger, als die meisten erwarten. In unseren eigenen Recherchen für DACH haben die volumenstärksten deutschen Begriffe einer Kategorie regelmäßig keine sinnvolle englische Entsprechung. Umgekehrt gilt dasselbe.

Die praktische Konsequenz: Recherchiert Keywords in jedem Markt, in der Sprache dieses Marktes und mit der dort genutzten Suchmaschine. Entscheidet danach, welche Seiten ihr braucht. Manchmal ist die Antwort dieselbe Seite. Häufig ist es eine andere. Gelegentlich braucht der Markt diese Seite überhaupt nicht.

Hreflang ist ein Cluster, kein einzelnes Tag

Bei Hreflang scheitern die meisten Implementierungen. Und sie scheitern unbemerkt.

Die bekannte Regel lautet, dass jede Seite auf ihre Entsprechungen in anderen Sprachen verweist. Oft vergessen wird, dass diese Entsprechungen zurückverweisen müssen und jede Seite im Cluster auch auf sich selbst verweisen muss. Wenn eine Seite den Rückverweis nicht liefert, ist der Cluster nicht teilweise funktionsfähig. Google behandelt die gesamte Gruppe als unzuverlässig und beginnt wieder zu raten. Genau das sollte Hreflang verhindern.

Drei Fehler verursachen die meisten defekten Cluster:

Manuell gepflegte Tags. Jemand ergänzt eine vierte Sprache und aktualisiert drei von zwölf Seiten. Der Cluster verschlechtert sich unbemerkt.

Tags, die auf Weiterleitungen zeigen. Die URL der Entsprechung wurde geändert, Hreflang nennt noch die alte Adresse und das Signal zeigt nun auf einen Zwischenschritt statt auf eine Seite.

Tags, die auf nicht vorhandene Seiten zeigen. Für einen Markt gibt es noch keine entsprechende Seite, trotzdem wurde das Tag automatisch für alle Sprachen erzeugt.

Die Lösung besteht darin, Hreflang aus euren Inhalten zu generieren und nie von Hand zu schreiben. Gebt jedem Inhalt eine stabile Kennung, die in allen Sprachen gleich bleibt. Gruppiert anhand dieser Kennung und erzeugt den Cluster aus der Gruppe. Dann kann eine Seite, die in einer Sprache nicht existiert, auch nicht genannt werden. Und wenn eine Seite umzieht, zieht ihr Cluster mit. Auf dieser Website heißt diese Kennung translationKey. Der Build schlägt fehl, sobald ein Cluster nicht reziprok ist.

Entscheidet euch einmal für eine URL-Struktur, und zwar aus dem richtigen Grund

Unterverzeichnisse, Subdomains und Länderdomains funktionieren alle. Die Unterschiede, die in der Praxis zählen, sind meist nicht diejenigen, über die diskutiert wird.

Länderspezifische Domains senden das stärkste geografische Signal und verursachen den höchsten Betriebsaufwand. Jede Domain beginnt beim Aufbau ihrer Autorität bei null. Fünf Märkte bedeuten also fünf Websites, die Backlinks verdienen müssen. Das ist die richtige Wahl, wenn die Märkte tatsächlich getrennte Unternehmen mit eigenen Rechtsträgern, Preisen und Sortimenten sind.

Unterverzeichnisse lassen die Autorität einer einzigen Domain für jeden Markt arbeiten. Ein Backlink zur englischen Website hilft auch den deutschen Seiten. Für die meisten Unternehmen unterhalb der Konzerngröße ist das die richtige Antwort. Deshalb verwenden wir sie auch hier.

Subdomains liegen ungünstig zwischen beiden Optionen. Für die Autorität werden sie fast wie separate Websites behandelt, ohne die geografische Klarheit einer Länderdomain zu bieten.

Teuer wird vor allem eine spätere Änderung. Entscheidet danach, wie getrennt die Geschäfte wirklich sind, nicht danach, welche Option ein Blogartikel zur besten erklärt hat.

Sprache und Markt sind zwei verschiedene Achsen

/de/ bezeichnet eine Sprache. Deutschland, Österreich und die Schweiz sind Märkte. Spanisch ist eine Sprache. Kolumbien, Mexiko und Spanien sind Märkte, die diese Sprache teilen und bei Wortschatz, Währung, Zahlungsmethoden und Recht voneinander abweichen.

Ihr braucht nicht für jeden Markt eine eigene Seite. Ihr müsst aber einmal entscheiden, für welchen Markt jede Sprachversion geschrieben wird. Danach schreibt ihr für diesen Markt und nicht für eine Sprache im Allgemeinen. Eine spanische Seite, die Regeln zur Werbetreibendenverifizierung im Finanzbereich, Nachnahme und Marktplatzprovisionen behandelt, richtet sich an Lateinamerika. Dieselbe Seite als Übersetzung eines europäischen spanischen Originals richtet sich an niemanden konkret.

Haltet diese Entscheidung ausdrücklich im Content-Briefing fest. Auf dieser Website richtet sich Englisch an die USA, Deutsch an DACH und Spanisch an Südamerika. Auch die Anrede unterscheidet sich: Die deutschen Seiten verwenden den informellen Plural, die spanischen Seiten das formelle usted, weil Geschäftskunden in diesen Märkten das erwarten. Das sind redaktionelle Entscheidungen. Kein Übersetzungswerkzeug trifft sie für euch.

Das Wartungsproblem, das niemand einplant

Eine Website in drei Sprachen bedeutet beim Launch nicht nur dreimal so viel Arbeit. Sie bedeutet für immer dreimal so viel Arbeit. Genau daran scheitert sie.

Jede Preisänderung, jede neue Leistung und jede rechtliche Aktualisierung muss nun dreimal umgesetzt werden. Den Launch bewältigen die Teams. Danach driften die Versionen auseinander: Die englische Website gewinnt im Laufe eines Jahres sechs Seiten hinzu, die deutsche eine, und der Cluster stimmt unbemerkt nicht mehr überein.

Zwei Prinzipien halten das System ehrlich. Behandelt Sprachversionen erstens als eigenständige Inhalte mit gemeinsamer Struktur, nicht als Übersetzungen, die immer synchron bleiben müssen. Ein Markt darf berechtigterweise eine Seite haben, die andere nicht brauchen. Macht die Abweichung zweitens sichtbar. Generiert die Hreflang-Cluster und lasst den Build fehlschlagen, wenn einer unvollständig ist. Dann ist eine Seite, die nur in einer Sprache existiert, eine bewusste Entscheidung statt eines ausgelieferten Fehlers.

Was ihr diese Woche auf eurer Website prüfen könnt

Vier Dinge, sortiert danach, wie häufig sie defekt sind:

1. Wählt eine Seite und prüft, ob jede Hreflang-Entsprechung zurückverweist und die Seite sich selbst nennt. Fehlt einer dieser Verweise, leistet der Cluster nichts.
2. Nehmt eure zwanzig wichtigsten Keywords im Hauptmarkt und prüft, ob die anderen Märkte von Grund auf recherchiert wurden oder nur Übersetzungen dieser Liste sind.
3. Prüft, ob ein Hreflang-Tag auf eine URL mit Weiterleitung zeigt.
4. Zählt die Seiten pro Sprache. Wenn eine Version den anderen weit voraus ist, entscheidet, ob das beabsichtigt war.

Für nichts davon braucht ihr einen Plattformwechsel. Die meisten Probleme im internationalen SEO sind strukturell. Sie wurden durch einen Prozess statt durch eine Technologie eingeführt. Und einen Prozess könnt ihr am Montag ändern.