Mehrsprachige Website: technische Checkliste

Eine mehrsprachige Website ist mehr als ein Übersetzungs-Button. Sie ist ein Versprechen an Suchmaschinen und Nutzer, dass jede Sprache ein gleichwertiges, korrekt verdrahtetes Erlebnis ist. Wer hreflang falsch setzt, kann seine Rankings in allen Sprachen gleichzeitig versenken. Wer die URL-Struktur falsch wählt, baut Duplicate-Content per Bauplan. Dieser Leitfaden ist die technische Checkliste, die wir vor jedem Internationalisierungs-Projekt abarbeiten.

URL-Struktur: die erste Entscheidung

Es gibt drei seriöse Wege, Sprachen abzubilden: Subdomain (de.site.com), Subordner (site.com/de) oder Country-Code-TLD (site.de). Wir empfehlen meist den Subordner, weil Autorität der Hauptdomain geteilt wird und das Setup schlank bleibt. Subdomains brauchen eigenes Linkbuilding, TLDs eigene Infrastruktur und rechtliche Impressen. Entscheiden Sie einmal — ein später Wechsel kostet mehr, als er bringt.

• Subordner /de, /en, /fr — einfach, teilt Domain-Autorität.
• Subdomain de.site.com — eigene Signalwelt, mehr Aufwand.
• ccTLD site.de — stärkstes Geo-Signal, höchste Betriebslast.

hreflang richtig setzen

Das hreflang-Attribut sagt Google, welche Seite die entsprechende Sprache ist. Jede Sprachversion muss auf alle anderen und auf sich selbst verweisen — ein geschlossener Kreis. Fehlt ein Rückverweis, ignoriert Google die gesamte Gruppe. Das Format ist „sprache-land“, also de-de, en-us, fr-fr. Eine x-default-Angabe fängt Nutzer ohne passende Sprache ab.

Häufigster Fehler: hreflang zeigt auf die Startseite statt auf die exakte Übersetzung. Das verwässert die Relevanz jeder Variante. Wir pflegen hreflang automatisch aus dem Content-Modell, damit keine Version vergisst, ihre Schwestern zu benennen.

Canonical, Duplicate und die Suchmaschine

Jede Sprache braucht ein eigenes, eindeutiges Canonical auf sich selbst — nicht auf die Quellsprache. Sonst erklären Sie der Suchmaschine, die Übersetzung sei Kopie der Original. Kombiniert mit hreflang ergibt sich ein klares Bild: „das hier ist die deutsche Variante, jenes die englische, beide gleichwertig“.

Internationalisierung scheitert selten am Übersetzen, sondern fast immer am Verdrahten. Die Suchmaschine liest Beziehungen, kein Deutsch.

Content: übersetzen reicht nicht

• Lokalisieren statt übersetzen: Maße, Währung, Recht, Tonfall pro Markt.
• Eigene Bilder mit passender Sprache und Symbolik, nicht nur Texttausch.
• Lokale Suchbegriffe recherchieren — die deutsche Anfrage ist nicht die russische.
• Datum, Uhrzeit, Steuer und Versandbedingungen pro Region korrekt.

Eine wörtliche Übersetzung rankt schlecht, weil niemand so sucht. Wir recherchieren pro Markt den semantischen Kern neu und schreiben die Zielseiten auf die dortige Intention. Das kostet mehr als Copy-Paste, trägt aber Traffic, den Maschinenübersetzung nie holt.

Technik unter der Haube

In Next.js lösen wir Sprachen über das i18n-Routing mit dynamischen Segmenten und Server-Komponenten, die die passende Locale laden. Inhalte liegen als strukturierte Daten, nicht als monsterhafte JSON-Blobs. Wir setzen auf Server-side Rendering, damit jede Sprache schnell lädt — auch eine langsame Übersetzung verkauft nichts.

Wichtig: Sprachwechsler dürfen die Nutzer nicht in die Startseite zurückschicken, sondern auf die exakt gleiche Seite in der anderen Sprache. Nichts bricht Vertrauen schneller als „ich war beim Produkt, und lande beim Impressum“.

Stolpersteine, die wir immer wieder sehen

• hreflang-Kreis offen: eine Version vergisst den Rückverweis.
• Canonical auf Quellsprache statt auf sich selbst gesetzt.
• Auto-Wechsler nach IP, der Nutzer gegen ihren Willen umleitet.
• Nur Startseite übersetzt, Rest als 404 in der Fremdsprache.
• Fehlende x-default, sodass Google raten muss, wohin unbekannte Märkte gehören.

Jeder dieser Fehler kostet Sichtbarkeit, und keiner fällt im Browser auf. Deshalb testen wir die Sprachmatrix automatisiert: für jede Seite prüfen wir, ob alle Schwester-Links existieren und kanonisch sauber sind. Erst wenn die Matrix grün ist, geht die Seite live.

Performance und Recht im Ausland

Mehr Sprachen heißt mehr Seiten und mehr Gewicht. Wir halten dennoch 90+ Lighthouse, indem wir Sprachinhalte lazily laden und Bilder pro Locale optimieren. Rechtlich kommt pro Markt Eigenes dazu: Impressum, Datenschutz, Widerruf, AGB. Eine einzige, für Russland geschriebene Datenschutzerklärung genügt der DSGVO nicht — sie muss pro Zielmarkt formuliert sein.

Suchmaschinen-Aufnahme und Sitemaps

Damit Google jede Sprache findet, braucht es eine saubere XML-Sitemap, die pro URL die alternativen Sprachversionen aufführt. Die Suchkonsole (Search Console) sollte jede Locale als eigenen Datensatz sehen. Fehlt die Sitemap, entdeckt Google Übersetzungen nur über interne Links — langsam und unvollständig. Wir pflegen Sitemap und hreflang aus derselben Quelle, damit beide niemals auseinanderlaufen. Ein automatischer Test meldet, wenn eine Sprachversion ohne Rückverweis ins Leben geht.

Währung, Steuer und Versand pro Markt

Mehrsprachig heißt nicht automatisch multinational. Wer nur übersetzt, lässt den Kunden in Euro zahlen, wo er Rubel gewohnt ist. Wir verknüpfen Sprache mit Markt: Preise, Mehrwertsteuer, Lieferfristen und Zahlarten richten sich nach Region, nicht nach Übersetzung. Eine deutsche Seite zeigt brutto in Euro inklusive MwSt., eine russische netto in Rubel. Wer das vergisst, baut Vertrauen ab, das die Übersetzung mühsam aufgebaut hat.

• Währung und Steuer aus Locale, nicht aus Übersetzung ableiten.
• Versandzeiten und -kosten pro Zielmarkt separat pflegen.
• Rechtliche Hinweise (Widerruf, AGB) pro Jurisdiktion eigenständig.
• Zahlarten an lokale Gewohnheiten anpassen — Karten, Rechnung, Wallets.

Team-Workflow für dauerhaft saubere Sprachen

Internationalisierung verrottet, sobald das Team inkonsistent arbeitet. Wir legen Inhalte nicht als Monster-JSON ab, sondern als strukturierte Collections, in denen jede Sprache ein gleichwertiges Feld ist. Übersetzer sehen Quelle und Ziel nebeneinander, Entwickler ändern eine Komponente, und alle Sprachen folgen. Ein fehlender Text wird im Build als Warnung markiert, nicht als leere Seite ausgeliefert. So bleibt die Matrix grün, auch wenn monatlich zehn neue Seiten dazukommen.

Entscheidend ist die Disziplin nach dem Launch: Jede neue Seite wird erst dann live geschaltet, wenn alle Sprachvarianten und ihre hreflang-Links stehen. Eine halbe Übersetzung schadet mehr als gar keine, weil sie Vertrauen und Ranking zugleich beschädigt. Wer das Prozess-Zeug hasst, sollte es trotzdem nicht weglassen — es ist der Unterschied zwischen „wir sind international“ und „wir tun so“.

Hreflang automatisiert statt von Hand

Sobald mehr als zehn Sprachen dazukommen, wird manuelles hreflang zur Fehlerquelle. Wir erzeugen die Attribute aus dem Content-Modell: Jede Seite kennt ihre Schwestern, und ein Build-Schritt schreibt die geschlossenen Kreise in den Kopf. Fällt eine Sprachversion weg, entfernt der Build ihren Link überall — und verhindert so die klassische „eine Version vergisst den Rückverweis“-Falle. Automatisierung ist hier keine Bequemlichkeit, sondern die einzige verlässliche Verteidigung gegen menschliches Vergessen bei wachsender Matrix.

Lokale Domains, rechtliche Impressen und Trust

In streng regulierten Märkten will die Suchmaschine lokale Signale: ein Impressum mit Ansprechpartner im Land, eine Telefonnummer mit Landesvorwahl, eine Datenschutzerklärung in der dortigen Sprache und nach dortigem Recht. Eine einzige, für Russland geschriebene Seite wirkt im EU-Markt schnell misstrauisch — und rankt schwächer. Wer ernsthaft international verkauft, pflegt pro Zielmarkt eigene rechtliche Texte und Kontaktdaten. Das kostet Pflege, zahlt aber zurück in Conversion und Sichtbarkeit, weil Vertrauen die härteste Währung im Auslandsvertrieb ist.

Performance pro Sprache halten

Mehr Sprachen bedeuten mehr ausgelieferte Seiten, und jede davon muss 90+ Lighthouse halten. Wir laden Sprachinhalte nicht alle auf einmal, sondern nur die aktive Locale, und optimieren Bilder pro Markt. Ein langsameres Französisch ist kein kleineres Problem als ein langsames Deutsch — beide kosten Kunden. Deshalb messen wir jede Sprachversion einzeln im Feld, nicht nur die Hauptsprache im Test. Internationalisierung, die am Ende langsam lädt, hat ihren eigenen Sieg kaputt gemacht, bevor der erste Besucher etwas davon hatte.

• Nur aktive Locale laden, Rest lazily nach Bedarf.
• Bilder und Fonts pro Sprache separat optimieren.
• Feld-Daten je Markt im Auge behalten, nicht nur Lab-Werte.
• Core Web Vitals pro Sprachversion als KPI im Bericht führen.

Migration bestehender Seiten in mehrere Sprachen

Wer eine bestehende, rankingstarke Seite mehrsprachig macht, muss vorsichtig umbrechen. Die Originalversion behält ihre Autorität, sobald hreflang sauber zeigt, wo die Übersetzungen liegen. Wir migrieren nie im großen Wurf, sondern Sprache für Sprache, mit Redirect-Prüfung und Rankings-Monitoring. Fällt eine Übersetzung schlechter aus, korrigieren wir Inhalt und Locale, bevor wir die nächste anfassen. So wächst das internationale Portfolio, ohne das erarbeitete Haus zu gefährden, auf dem es steht.

Fazit: planen Sie die Beziehungen, nicht nur die Worte

Eine mehrsprachige Website gelingt, wenn die Suchmaschine die Beziehungen versteht: saubere URL-Struktur, geschlossener hreflang-Kreis, eigenes Canonical, lokal recherchierter Content, funktionierender Sprachwechsler. Wer das vor dem ersten Commit klärt, spart Monate und Rankings. Wir bauen Internationalisierung so, dass jede Sprache ein erstklassiges Erlebnis ist — schnell, korrekt verdrahtet und rechtlich sauber.