Webentwicklung

Mehrsprachige persönliche Websites — Menschen und Maschinen zur richtigen Sprache führen

Geschrieben von Adam Muiz 19 Aug 2026 Aktualisiert: 19 Aug 2026 9 Min. gelesen

Eine Website kann eine englische Seite, eine indonesische Übersetzung und eine deutsche Übersetzung anbieten und dennoch eine wichtige Frage offenlassen: Woher wissen Besucher, Screenreader oder Suchmaschinen, dass diese drei URLs zusammengehören?

Die Antwort ist kein einzelnes magisches Tag. Eine mehrsprachige Website braucht mehrere kleine Signale mit unterschiedlichen Aufgaben: eine stabile URL für jede Übersetzung, die richtige Dokumentensprache, ausdrückliche Verknüpfungen zwischen gleichwertigen Seiten und eine sichtbare Auswahlmöglichkeit für Leser. Diese Aufgaben werden leicht verwechselt. Eine Seite kann lang="de" verwenden, aber keinen Weg zur englischen Version anbieten. Ebenso kann ein Sprachumschalter funktionieren, während die Metadaten der Seite eine falsche Beziehung beschreiben.

Dieser Leitfaden entwickelt ein überschaubares Modell für eine persönliche Website oder ein kleines CMS. Er verspricht keine Rankings und setzt nicht voraus, dass jede Website eine Ausrichtung auf einzelne Länder benötigt. Das Ziel ist einfacher: Jede Übersetzung soll ehrlich beschreiben, was sie ist, und deutlich zeigen, wo ihre Geschwisterseiten zu finden sind.

Vier Ebenen mit vier verschiedenen Aufgaben

Mehrsprachige Veröffentlichungen lassen sich leichter verstehen, wenn man sie in vier Ebenen aufteilt:

URL: gibt jeder vollständigen Übersetzung eine dauerhafte Adresse.
lang: beschreibt die Sprache des aktuellen HTML-Dokuments oder eines Elements darin.
hreflang: verknüpft gleichwertige lokalisierte URLs für Google Search.
Sprachumschalter: ermöglicht einer Person den Wechsel zu einer anderen Version.

Diese Ebenen unterstützen einander, ersetzen sich aber nicht. Die Internationalisierungsrichtlinien des W3C empfehlen, die Seitensprache am Element html anzugeben. Google erklärt dagegen, dass sichtbarer Seiteninhalt und nicht lang oder hreflang zur Spracherkennung verwendet wird. Das ist kein Widerspruch: Dokumentsemantik und die Spracherkennung eines Suchprodukts sind unterschiedliche Systeme.

Jede vollständige Übersetzung erhält eine stabile URL

Eine übersetzte Seite sollte direkt adressierbar sein. Für eine kleine Website unter einer Domain sind Unterverzeichnisse oft die unkomplizierteste Struktur:

https://example.com/quiet-web/
https://example.com/id/web-yang-tenang/
https://example.com/de/das-ruhige-web/

Subdomains oder getrennte Domains können ebenfalls funktionieren. Entscheidend ist nicht die Form selbst, sondern ihre Stabilität: Die URL sollte dieselbe Sprache ausliefern, ohne von einem Cookie, einem JavaScript-Zustand oder einer vermuteten Präferenz abzuhängen. Googles Richtlinien für mehrsprachige Websites empfehlen unterschiedliche URLs für verschiedene Sprachversionen. Sie warnen außerdem davor, dass dynamische Änderungen einer einzigen URL anhand der Browsersprache manche Varianten schwer crawlbar machen können.

Ein sprachspezifischer Slug ist sinnvoll, wenn er Lesern hilft, die Adresse zu verstehen. Daraus entsteht jedoch eine redaktionelle Verantwortung: Verknüpfungen zwischen Übersetzungen müssen aus gespeicherten Beziehungen stammen und dürfen nicht durch die Umformung eines Slugs in einen anderen erraten werden. Wörter in einer URL zu ersetzen ist keine Übersetzungsverwaltung.

Die Sprache des Dokuments angeben

Bei gewöhnlichem HTML, das als text/html ausgeliefert wird, gehört die Standardsprache auf das Wurzelelement:

<html lang="en">
<html lang="id">
<html lang="de">

Nach dem HTML Standard wird die Sprache eines Elements durch seine eigenen Sprachattribute und den geerbten Kontext bestimmt. Diese Angabe kann sprachabhängige Verarbeitung beeinflussen. MDN weist zudem auf ihre Bedeutung für die Barrierefreiheit hin: Assistive Technologien können anhand dieser Information eine passende Aussprache auswählen.

Wenn ein kurzer Abschnitt die Sprache wechselt, wird dieser Abschnitt ausgezeichnet, nicht das gesamte Dokument:

<p>The Indonesian phrase <span lang="id">pelan-pelan</span>
means doing something gradually or carefully.</p>

Die Sprache sollte nicht allein aus UTF-8, einem Flaggensymbol oder der URL abgeleitet werden. Eine Zeichenkodierung beschreibt, wie Zeichen dargestellt werden, nicht welche menschliche Sprache sie bilden. Eine Flagge steht für ein Land, während Sprachen regelmäßig Landesgrenzen überschreiten.

Sprachtags nur so genau wie nötig verwenden

Die oben verwendeten Werte sind Sprachtags, die durch BCP 47 und RFC 5646 definiert werden. Ein Tag beginnt mit einem Sprach-Subtag und kann zusätzliche Angaben wie Schrift oder Region enthalten, die durch Bindestriche getrennt sind. Beispiele sind de, en-GB und zh-Hant.

Mehr Details sind nicht automatisch richtiger. Wenn eine englische Übersetzung allgemein für englischsprachige Leser geschrieben ist, ist en klarer als eine erfundene regionale Unterscheidung. en-GB ist angebracht, wenn der Inhalt tatsächlich britischen Sprachgebrauch repräsentiert, nicht nur weil der Server in Europa steht. RFC 5646 erklärt, dass ein Regions-Subtag entfallen kann, wenn er keinen unterscheidenden Wert hinzufügt.

Groß- und Kleinschreibung ändern die Bedeutung eines BCP-47-Tags nicht. Die übliche Schreibweise verwendet jedoch Kleinbuchstaben für die Sprache, einen großen Anfangsbuchstaben für die Schrift und Großbuchstaben für die Region. Konsistenz bleibt wichtig, weil uneinheitliche Zeichenketten Templates und Tests schwerer verständlich machen.

Gleichwertige Seiten mit hreflang verbinden

Für Google Search können lokalisierte Versionen über HTML, HTTP-Header oder eine XML-Sitemap angegeben werden. Googles Dokumentation zu lokalisierten Versionen beschreibt die Methoden als gleichwertig und erklärt, dass ihre gleichzeitige Implementierung keinen Vorteil in der Suche bringt. Bei einer kleinen HTML-Website lassen sich Links im Dokumentenkopf meistens leicht prüfen:

<link rel="alternate" hreflang="en"
      href="https://example.com/quiet-web/">
<link rel="alternate" hreflang="id"
      href="https://example.com/id/web-yang-tenang/">
<link rel="alternate" hreflang="de"
      href="https://example.com/de/das-ruhige-web/">

Dasselbe vollständige Set gehört auf alle drei Versionen. Jede Seite führt sich selbst auf, jede alternative URL ist vollständig angegeben und jede Geschwisterseite verweist zurück. Google erklärt, dass Anmerkungen bei fehlenden Rückverweisen ignoriert werden können. Diese Gegenseitigkeit ist leichter zu pflegen, wenn ein CMS Übersetzungen als Mitglieder einer gemeinsamen Inhaltsgruppe behandelt und nicht als voneinander unabhängige Beiträge.

Ein optionales hreflang="x-default" kann auf eine neutrale Auswahl- oder Ausweichseite für nicht passende Spracheinstellungen verweisen. Es ist keine vierte gesprochene Sprache und nicht für jeden dreisprachigen Blog notwendig. Es sollte nur hinzugefügt werden, wenn eine echte Ausweichseite existiert.

Canonical- und Alternate-Beziehungen getrennt halten

Ein Canonical-Link beantwortet die Frage: „Welche URL ist unter doppelten oder nahezu doppelten URLs die bevorzugte Identität dieser Seite?“ Ein Link zu einer alternativen Sprache beantwortet dagegen: „Wo befindet sich die gleichwertige Seite für eine andere Sprache oder Locale?“ Das sind unterschiedliche Fragen.

Wenn der Hauptinhalt tatsächlich übersetzt wurde, betrachtet Google die lokalisierten Seiten nicht allein deshalb als Duplikate, weil sie dasselbe Thema in verschiedenen Sprachen ausdrücken. Ein praktisches Muster besteht deshalb darin, dass jede Übersetzung ihre eigene kanonische URL verwendet, während der hreflang-Cluster das Set verbindet:

<!-- On the Indonesian page -->
<link rel="canonical"
      href="https://example.com/id/web-yang-tenang/">

Alle Canonical-Links auf die englische Quelle zu richten, kann die Aussage untergraben, dass die lokalisierten URLs eigenständige gültige Seiten sind. Übersetzte Standardtexte um einen unveränderten Hauptinhalt sind jedoch ein anderer Fall. Seiten sollten nicht als gleichwertig gekennzeichnet werden, nur weil ihre Navigation übersetzt wurde.

Leser dürfen eine Vermutung korrigieren

Browsereinstellungen können als Hinweis nützlich sein, sind aber keine Zustimmung. Bei einem gemeinsam genutzten Gerät, auf Reisen, beim Sprachenlernen oder nach dem Öffnen eines bestimmten Links kann eine andere Version als die Browser-Voreinstellung gewünscht sein. Googles Richtlinien für mehrsprachige Websites raten von automatischen Weiterleitungen zwischen Sprachversionen ab und empfehlen Links, mit denen Nutzer selbst wählen können.

Der Sprachumschalter sollte gewöhnliche crawlbare Links verwenden und die Sprachen eindeutig benennen:

<nav aria-label="Language">
  <a href="https://example.com/quiet-web/" lang="en">English</a>
  <a href="https://example.com/id/web-yang-tenang/" lang="id">Indonesia</a>
  <a href="https://example.com/de/das-ruhige-web/" lang="de">Deutsch</a>
</nav>

Wenn jeder Sprachname in der jeweiligen Sprache geschrieben wird, bleibt er erkennbar. Das lang an jeder Bezeichnung beschreibt den Inline-Text, während die umgebende Seite ihre eigene Standardsprache behält. JavaScript kann das Steuerelement verbessern, doch die Navigation sollte nicht verschwinden, wenn Skripte ausfallen.

Fehlende und unvollständige Übersetzungen ehrlich behandeln

Das schwierigste Problem ist häufig redaktionell und nicht technisch. Ein CMS kann überall englische, indonesische und deutsche Schaltflächen anzeigen, obwohl ein Artikel nur auf Englisch verfügbar ist. Die fehlende deutsche Auswahl auf eine englische Seite zu verlinken und diese als Deutsch auszuzeichnen, erzeugt eine falsche Beziehung.

Eine alternative Anmerkung sollte nur veröffentlicht werden, wenn das Ziel existiert, öffentlich ist und den entsprechenden Inhalt enthält. Befindet sich eine Übersetzung noch im Entwurfsstadium, gehört sie weder in den öffentlichen Cluster noch in den Sprachumschalter. Wenn nur die Benutzeroberfläche übersetzt wurde, während der Artikel englisch bleibt, muss sich die Dokumentangabe am tatsächlichen Hauptinhalt orientieren. Die Einschränkung kann Lesern zusätzlich erklärt werden, wenn dies hilfreich ist.

Übersetzungen können auch veralten, nachdem sich die Quelle geändert hat. Ein zuverlässiger Veröffentlichungsablauf sollte den Übersetzungsstatus erfassen und das Set nach einer wesentlichen Überarbeitung erneut prüfen. Vollkommene Gleichzeitigkeit ist nicht immer möglich, doch Metadaten müssen die Seiten beschreiben, die jetzt existieren, nicht die Versionen, die ein Redakteur später fertigstellen möchte.

Das gesamte Set statt nur einer Seite validieren

Eine einzelne Seite kann korrekt aussehen, obwohl der Beziehungsgraph beschädigt ist. Für jede veröffentlichte Inhaltsgruppe sollte Folgendes geprüft werden:

Jede URL liefert eine erfolgreiche öffentliche Antwort in der erwarteten Sprache.
Das Wurzelelement html besitzt den richtigen lang-Wert.
Canonical-URLs sind erreichbar und identifizieren die aktuelle lokalisierte Seite.
Jede Version gibt dasselbe vollständige Set gegenseitiger hreflang-Links aus.
Der sichtbare Sprachumschalter führt zum entsprechenden Artikel und nicht nur zur Startseite einer Locale.
Im Cluster befinden sich keine Entwürfe, Weiterleitungen, Fehlerseiten oder unübersetzten Platzhalter.

Geprüft werden sollte das gerenderte HTML und nicht nur die Datenbank oder das Template. Metadaten können falsch maskiert, außerhalb von head eingefügt oder nach einer Übersetzungsänderung im Cache gehalten werden. Ein kleiner automatisierter Test kann jede Geschwisterseite abrufen, die Links parsen und die Gegenseitigkeit bestätigen. Ob die Seiten inhaltlich wirklich gleichwertig sind, muss dennoch manuell beurteilt werden.

Eine wahrheitsgemäße Karte zwischen Sprachen

Mehrsprachiges Veröffentlichen ist nicht abgeschlossen, wenn drei Flaggen in einer Kopfzeile stehen. Es ist das Versprechen, dass jede Adresse die behauptete Sprache enthält, jede gleichwertige Seite auf ihre Geschwister zurückverweist und Leser frei wählen können.

Am Anfang steht das kleinste wahrheitsgemäße System: stabile URLs, korrekte lang-Werte, eine pflegbare hreflang-Methode, in sich stimmige Canonical-Links und eine sichtbare Navigation. Regionen oder x-default kommen erst hinzu, wenn das Inhaltsmodell sie tatsächlich braucht. Das Ergebnis wirkt vielleicht nicht spektakulär, doch gute Metadaten sind meistens leise. Sie beseitigen Unklarheit, ohne vorzugeben, die Wünsche eines Lesers bestimmen zu können.