Ein praktischer Leitfaden für mehrsprachige Websites: URLs, Rückfallsprachen, Prioritäten

Eine zweite Sprache hinzuzufügen wird meist als Übersetzungsproblem beschrieben. Tatsächlich ist es ein Strukturproblem: wo die übersetzten Seiten liegen, was passiert, solange noch nicht alles übersetzt ist, und welche Seiten sich die Arbeit zuerst verdienen. Stimmt die Struktur, ist Übersetzen nur noch Tippen. Stimmt sie nicht, indexieren Suchmaschinen doppelte oder halbleere Seiten – egal wie gut die Übersetzung selbst ist.

Der Website-Baukasten im Olmira-Adminbereich

Wo die übersetzten Seiten tatsächlich liegen

Es gibt eine Handvoll gängiger Wege, denselben Inhalt in mehreren Sprachen auszuliefern, und sie sind für die Suche nicht austauschbar:

Unterverzeichnisseexample.com/es/page — das am häufigsten empfohlene Muster. Alle Sprachen teilen sich eine Domain, sodass sich die gesamte Autorität und das Vertrauen der Website an einer Stelle ansammeln und Suchmaschinen jede Sprache von derselben Wurzel aus crawlen können.

Subdomainses.example.com — trennt die Sprachen technisch, aber Suchmaschinen können eine Subdomain als halbwegs eigenständige Einheit behandeln, was das Signal verwässern kann, dass all diese Seiten zu einer Website gehören.

Separate Domainsexample.es, example.de — vollständige Trennung, üblich bei großen multinationalen Marken, die pro Land eine wirklich lokale Präsenz wollen, aber es vervielfacht die SEO-Arbeit: Jede Domain baut ihre Autorität unabhängig auf, bei null beginnend.

Ein Query-Parameterexample.com?lang=es — billig umzusetzen, aber Suchmaschinen gehen uneinheitlich damit um, ob sie URLs mit Parametern als vollständig eigenständige Seiten behandeln, und es ist das Muster, das am ehesten zu Verwirrung durch doppelte Inhalte führt.

Gar keine eigene URL — eine clientseitige Sprachumschaltung, die die Adresszeile nicht verändert. Das ist das Muster, das Sie bei allen Inhalten vermeiden sollten, die indexiert werden sollen: Ändert sich die URL nicht, gibt es nichts, was eine Suchmaschine als „die spanische Seite“ indexieren könnte, und nichts, worauf ein hreflang-Tag verweisen könnte.

Die Standardsprache: mit Präfix oder ohne?

Eine verbreitete und vernünftige Konvention ist, die Standardsprache ohne Präfix auf der Wurzel zu belassen (/pricing) und jede andere aktive Sprache mit einem Präfix zu versehen (/es/pricing, /de/pricing). Das liest sich natürlich, es bedeutet, dass Ihre bestehenden Links und jedes eingehende SEO-Kapital auf den Wurzel-URLs unberührt bleiben, wenn Sie eine zweite Sprache hinzufügen, und es gibt Ihnen eine eindeutige „Standard"-URL als Rückfallebene, wenn nichts anderes passt — was für das hreflang-Tag x-default wichtig ist (behandelt im begleitenden Leitfaden zu hreflang).

Was passieren sollte, wenn eine Übersetzung fehlt

Irgendjemand schaltet immer eine Sprache ein, bevor auch nur die letzte Seite fertig ist – entscheidend ist, was an dieser Lücke passiert. Eine gut gebaute Fallback-Kette versucht der Reihe nach: die exakt angefragte Locale, dann deren Basissprache (ein es-MX-Besucher kann trotzdem eine es-Seite lesen), dann die Standardsprache der Website, und erst dann irgendetwas, das überhaupt existiert. Was sie niemals tun darf: einen leeren Abschnitt oder eine kaputte Seite anzeigen – ein Besucher soll immer vollständigen Inhalt sehen, auch wenn ein Teil davon in der Fallback-Sprache statt in der gewünschten ankommt.

Eine zweite Sprache einführen, ohne die erste zu beschädigen

1

Übersetzen Sie zuerst die Navigation und die meistbesuchten Seiten

Ein Besucher verzeiht einen Blogbeitrag, der noch in der Ausweichsprache steht, weit eher als eine Startseite oder Preisseite, die nicht zu der von ihm gewählten Sprache passt. Fangen Sie dort an, wo der Traffic und die Kaufentscheidungen sind.

2

Als Nächstes die Rechts- und Richtlinienseiten

Seiten zu AGB, Datenschutz und Rückgabe haben echte Folgen, wenn sie falsch verstanden werden — sie sollten vor Long-Tail-Inhalten ordentlich übersetzt werden, auch wenn sie weniger Traffic bekommen.

3

Halten Sie Checkout- und Transaktionstexte im Gleichschritt mit dem Rest

Ein Shop, der überall die Sprache wechselt, nur nicht im letzten Zahlungsschritt, untergräbt das Vertrauen genau dann, wenn es am wichtigsten ist.

4

Erst danach arbeiten Sie den Long Tail ab

Alles andere – Archivinhalte, ältere Blogbeiträge, spezielle Hilfeartikel – kann in seinem eigenen Tempo übersetzt werden, ohne das Erlebnis für die meisten Besucher zu beeinträchtigen.

5

Veröffentlichen Sie eine Sprache erst, wenn die Kernseiten wirklich tragfähig sind

Eine Sprache seitenweit „einzuschalten“, bevor die Seiten fertig sind, auf die es ankommt, tauscht ein echtes Problem (unübersetzte Seiten) gegen ein schlimmeres (eine Sprachauswahl, die sichtbar in Lücken führt).

Wie Olmira das löst

Eine Olmira-Website läuft mit bis zu acht Sprachen — zwei in der Testphase, drei auf Starter, alle acht ab Pro — und die obige Struktur ist eingebautes Verhalten, keine Konfiguration:

URLs — die Standardsprache bleibt ohne Präfix, und jede andere aktive Sprache bekommt ihren eigenen // Pfad, mit hreflang- und x-default-Alternativen, die für jede Seite generiert werden, sobald eine zweite Sprache aktiv ist.

Fallbacks — Inhalte lösen sich zuerst über die exakte Sprache auf, dann über die Basissprache, dann über die Standardsprache der Website, sodass eine unfertige Übersetzung sanft degradiert, statt leer zu bleiben. Erstbesucher bekommen die Sprache, die ihr Browser anfragt (unter den von Ihnen aktivierten); eine explizite Wahl bleibt erhalten. Wenn Sie verkaufen, folgt auch der Shop — Katalognamen, Formularbeschriftungen, Buchungsbestätigungen, Live-Chat — der Sprache des Besuchers.

Die eigentliche Übersetzungsarbeit — ein Übersetzungen-Tab listet jeden Seitentitel, jede Meta-Beschreibung und jeden Textabschnitt pro Sprache mit einem einfachen Abdeckungsprozentsatz auf und entwirft die fehlenden Stellen auf Wunsch mit KI: eine Zeile, eine Sprache, oder die ganze Website auf einmal. Kein KI-Vorschlag wird gespeichert, bevor Sie ihn gelesen und auf Speichern geklickt haben, und eine Sprache, die Sie aktiviert, aber noch nicht fertiggestellt haben, bleibt von der veröffentlichten Website ausgeschlossen, bis ihr Inhalt tatsächlich ausgefüllt ist — die oben genannte Rollout-Regel, für Sie durchgesetzt statt der Disziplin überlassen. Vollständiger Baukasten: der Website-Baukasten.

Einmal bauen – in jeder Sprache, die Sie brauchen

Fügen Sie eine Sprache hinzu, und die URLs, hreflang und die Fallback-Struktur werden für Sie erledigt.