Sehen Sie den Baukasten selbst
Eine Website, bis zu acht Sprachen, mit hreflang und Fallback, die automatisch verwaltet werden, sobald Sie jede hinzufügen.
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.

Es gibt eine Handvoll gängiger Wege, denselben Inhalt in mehreren Sprachen auszuliefern, und sie sind für die Suche nicht austauschbar:
Unterverzeichnisse — example.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.
Subdomains — es.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 Domains — example.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-Parameter — example.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.
/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).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.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.
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.
Ein Shop, der überall die Sprache wechselt, nur nicht im letzten Zahlungsschritt, untergräbt das Vertrauen genau dann, wenn es am wichtigsten ist.
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.
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).
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.
Eine Website, bis zu acht Sprachen, mit hreflang und Fallback, die automatisch verwaltet werden, sobald Sie jede hinzufügen.
Warum Suchmaschinen manchmal die falsche Sprachversion ausliefern, und die Handvoll stiller Fehlerquellen, die hinter fast jedem Fall stecken.
Welche Inhalte sich mit einer leichten Prüfung sicher maschinell übersetzen lassen, und welche jedes Mal einen Menschen brauchen.