So überprüfen Sie vor dem Go-live einer mehrsprachigen Unternehmenswebsite die Sprachumschaltung

Vor dem Go-live einer mehrsprachigen Unternehmenswebsite darf beim Sprachwechsel nicht nur geprüft werden, ob „die Seite übersetzt werden kann“. Es muss auch sichergestellt werden, dass Nutzer, Suchmaschinen und Backend-Mitarbeiter jeweils dieselbe korrekte Sprachversion aufrufen. Sobald Einstiegspunkt, Weiterleitungsregeln, Seiteninhalte, URL-Struktur oder SEO-Kennzeichnungen nicht korrekt aufeinander abgestimmt sind, können beispielsweise chinesische Nutzer auf einer englischen Anfrageformularseite landen, Suchergebnisse die falsche Version indexieren oder die aktuelle Seite nach einem Sprachwechsel verloren gehen.

Entscheidend für die Wirkung internationaler Besuche und Marketingmaßnahmen ist häufig nicht die Anzahl der Sprachen, sondern ob die Zuordnung zwischen den Sprachversionen vollständig ist. Die Abnahme vor dem Go-live sollte den Sprachwechsel als vernetzten Test über Frontend, Inhalte, Routing, Formulare und Suchmaschinenoptimierung hinweg behandeln – nicht lediglich als Prüfung einer Schaltfläche im Rahmen der visuellen Abnahme.

Zunächst klären: Wechselt die Website die „Oberflächensprache“ oder eine „vollständige Marktversion“?

In vielen Projekten werden diese beiden Konzepte bereits in der Anforderungsphase verwechselt. Ein Wechsel der Oberflächensprache ändert in der Regel nur Systemfelder wie Navigation, Schaltflächen, Formularhinweise und Footer; eine vollständige Sprachversion sollte hingegen Seitentexte, Produktparameter, Referenzen, Download-Materialien, Anfrageformulare, Datenschutzerklärungen, Cookie-Hinweise, Fehlerseiten und E-Mail-Benachrichtigungen abdecken.

Wenn ein Unternehmen in verschiedenen Ländern oder Regionen tätig ist, muss zudem zwischen „Sprache“ und „Markt“ unterschieden werden. Beispielsweise genügt für englische Seiten nicht zwangsläufig nur eine Version: Für Märkte in den USA, im Vereinigten Königreich oder im Nahen Osten können Maßeinheiten, Telefonformate, Währungsdarstellung, Lieferhinweise, Zertifizierungsangaben und sogar Compliance-Texte unterschiedlich sein. Wird der Projektumfang lediglich als mehrsprachige Übersetzung definiert, aber kurz vor dem Go-live um Regionalisierungsanforderungen ergänzt, führt dies leicht zu wiederholten Änderungen an URLs, Content-Management und Weiterleitungslogik.

Vor der Abnahme sollte der Seitenumfang für jede Sprache eindeutig festgelegt werden, um Situationen zu vermeiden, in denen Startseite und Produktseiten bereits übersetzt sind, die Lösungsseiten jedoch noch in der Ausgangssprache vorliegen oder im Frontend die lokale Sprache angezeigt wird, heruntergeladene PDFs und automatische Antwort-E-Mails jedoch weiterhin auf Englisch sind. Ein korrekter Sprachwechsel bedeutet nicht, dass die gesamte Besucherkette bereits lokalisiert ist.

Die Prüfung des Einstiegspunkts beschränkt sich nicht auf die Frage, ob es eine Sprachschaltfläche gibt

Der Spracheinstieg muss für Besucher zunächst zuverlässig auffindbar sein. Übliche Positionen sind die Hauptnavigation im Kopfbereich der Website, der Footer, mobile Menüs sowie vereinfachte Navigationen auf bestimmten Landingpages. Die Darstellung des Einstiegspunkts kann je nach Endgerät variieren, die Bedeutung von Sprachbezeichnung, Abkürzung und Flagge muss jedoch einheitlich sein. Die alleinige Verwendung von Flaggen als Sprachkennzeichnung kann irreführend sein: Flaggen stehen für Länder oder Regionen und sind nicht automatisch mit einer Sprache gleichzusetzen. Bei regionsübergreifenden Sprachen wie Englisch, Spanisch oder Arabisch empfiehlt es sich eher, die eindeutige Sprachbezeichnung oder standardisierte Sprachcodes anzuzeigen.

Die Prüfung des Einstiegspunkts sollte Desktop-, Mobil- und Tablet-Ansichten sowie Zustände nach dem Scrollen, dem Öffnen von Menüs und dem Überlagern durch Pop-ups abdecken. Besonders auf Mobilgeräten ist das Sprachmenü häufig im Hamburger-Menü verborgen. Sind Klickbereiche zu klein, wird die Dropdown-Ebene vom Seitenkopf verdeckt oder lässt sich das Menü nach dem Wechsel nicht automatisch schließen, beeinträchtigt dies die tatsächliche Nutzererfahrung deutlich.

Es sollte außerdem überprüft werden, ob der aktuelle Sprachstatus klar erkennbar ist. Wenn ein Nutzer die deutsche Version aufruft, muss der Sprachwähler korrekt Deutsch markieren, statt dauerhaft das standardmäßige Englisch anzuzeigen. Auch bei der Browser-Zurück-Funktion, beim Aktualisieren der Seite sowie nach dem Schließen und erneuten Öffnen der Website sollte das System die Sprachpräferenz nach den festgelegten Regeln behandeln.

Nach dem Wechsel muss die „Semantik derselben Seite“ erhalten bleiben

Das wichtigste Kriterium beim Sprachwechsel ist, ob Nutzer nach dem Wechsel von einer bestimmten Seite weiterhin auf der entsprechenden Inhaltsseite bleiben, statt pauschal zur Startseite weitergeleitet zu werden. Wenn nach dem Aufruf einer englischen Produktdetailseite auf Französisch gewechselt wird, sollte idealerweise die französische Detailseite dieses Produkts geöffnet werden. Wird nach dem Aufruf eines englischen Fachartikels auf Spanisch gewechselt, sollte vorrangig der entsprechende Artikel zugeordnet werden, statt zur spanischen Blog-Startseite zu springen.

Dafür muss die Website auf Inhaltsebene stabile mehrsprachige Verknüpfungen aufbauen, anstatt lediglich Sprachverzeichnisse anhand von URL-Zeichenfolgen zu ersetzen. Besonders geprüft werden sollten Produktdetailseiten, Kategorieseiten, Lösungsseiten, Nachrichtenartikel, Download-Center, Kontaktseiten und Event-Landingpages. Bei Websites mit umfangreichen Inhalten ist kein manueller Seitenaufruf jeder einzelnen Seite erforderlich, jedoch sollte mindestens nach Seitentemplates, wichtigen Produktlinien und bereits beworbenen Seiten geschichtet stichprobenartig geprüft werden.

Wenn für die Zielsprache noch keine entsprechende Seite eingerichtet wurde, müssen die Regeln einheitlich sein. Es kann auf der Seite in der aktuellen Sprache geblieben und auf das fehlende Pendant hingewiesen werden, oder eine Weiterleitung zur übergeordneten Kategorie der Zielsprache erfolgen. Am wenigsten sinnvoll ist es, wenn bei derselben Seitenart teilweise zur Startseite zurückgekehrt wird, teilweise ein 404-Fehler erscheint und teilweise weiterhin Inhalte der Ausgangssprache geladen werden. Bei Landingpages für Werbekampagnen kann das Fehlen einer entsprechenden Sprachversion außerdem dazu führen, dass Werbetext, Seitensprache und Anfrageformular nicht übereinstimmen, was die Beurteilung durch Besucher beeinträchtigt.

Die automatische Spracherkennung sollte zurückhaltend eingesetzt werden und dem Nutzer nicht die Kontrolle nehmen

Browsersprache, IP-Adresse und bisherige Besuchsdaten können zur Sprachempfehlung verwendet werden, sollten jedoch nicht bei jedem Besuch eine erzwungene Weiterleitung auslösen. Die IP-Geolokalisierung entspricht nicht zwangsläufig der Präferenz des Besuchers: Teilnehmer von Auslandsmessen, internationale Einkaufsteams, VPN-Nutzer und Unternehmens-Proxy-Netzwerke können dazu führen, dass das Lokalisierungsergebnis von der tatsächlichen Lesesprache abweicht.

Ein verlässlicherer Ansatz besteht darin, die automatische Erkennung als Empfehlung beim ersten Besuch zu verwenden, dem Nutzer eine eindeutige Auswahl zu ermöglichen und seine Präferenz zu speichern. Bei automatischen Weiterleitungen müssen drei Grenzen geprüft werden: Werden Suchmaschinen beim Crawlen falsch umgeleitet? Wird eine vom Nutzer manuell gewählte Sprache vom System wiederholt zurückgesetzt? Werden Nutzer, die über Anzeigen-, E-Mail- oder Social-Media-Links eine Seite in einer bestimmten Sprache aufrufen, auf eine andere Version umgeleitet?

Externe Links mit Sprachpfad sollten vorrangig respektiert werden. Öffnet ein Besucher beispielsweise /de/product/..., darf das System die Seite nicht allein aufgrund der Browsereinstellungen auf eine englische Seite umstellen. Andernfalls verlieren die in Werbelinks, Vertriebs-E-Mails und internationalen Social-Media-Inhalten vorab festgelegten Landing-Sprachen ihre Wirkung.

Die Inhaltsprüfung muss entlang der Anfragekette erfolgen, nicht nur im Fließtext

Die Übersetzungsqualität ist selbstverständlich wichtig, vor dem Go-live müssen jedoch vor allem Probleme mit „Sprachmischungen“ untersucht werden. Sie treten häufig in Template-Feldern und Backend-Konfigurationen auf: Die Navigation ist bereits übersetzt, die Breadcrumb-Navigation jedoch noch in der Ausgangssprache; der Produkttext ist übersetzt, die Überschriften der Spezifikationstabelle nicht; Formularschaltflächen sind in der Zielsprache, während Pflichtfeldhinweise und Fehlermeldungen des Captchas weiterhin auf Chinesisch erscheinen; Cookie-Pop-ups, Links zur Datenschutzerklärung, 404-Seiten und interne Suchergebnisse wurden hingegen vollständig übersehen.

Für B2B-Unternehmenswebsites darf insbesondere die Anfragekette nicht unterbrochen werden. Der gesamte Prozess vom Aufruf der Kontaktseite über eine Seite in der Zielsprache, der Formularübermittlung, dem Empfang der Erfolgsbestätigung und der automatischen E-Mail-Antwort bis zur internen Benachrichtigung sollte vollständig getestet werden. Dabei ist zu prüfen, ob Feldbezeichnungen, Hinweise zur Datenschutz-Einwilligung, Hinweise zu Telefonvorwahlen, Beschränkungen für Dateiuploads und die Sprache der E-Mail-Vorlagen einheitlich sind. Muss das Vertriebsteam die Nachverfolgung per E-Mail fortsetzen, sollte die interne Benachrichtigung zumindest die Sprache der Anfragequelle und die besuchte Seite erkennen lassen, damit die spätere Antwortsprache nicht von den Erwartungen des Kunden abweicht.

Besondere Aufmerksamkeit verdienen außerdem Zahlen, Daten, Einheiten und Eigennamen. Maschinelle Übersetzungen führen nicht unbedingt zu Seitenfehlern, können jedoch die Glaubwürdigkeit von Informationen unmittelbar beeinträchtigen. Beispielsweise sollten Millimeter und Zoll, Grad Celsius und Grad Fahrenheit, Angaben zu Arbeitstagen, Zertifizierungsbezeichnungen, Modellschreibweisen und Handelsbedingungen in einer Weise beibehalten werden, die den Geschäftsregeln entspricht. Wenn Produktparameter auf Seiten in verschiedenen Sprachen voneinander abweichen, sollte dies nicht einfach als Übersetzungsproblem eingestuft werden; vielmehr muss zur Produktdatenquelle zurückgekehrt werden, um die Verantwortung für das Versionsmanagement zu klären.

SEO-Einstellungen entscheiden darüber, ob Suchmaschinen die Seiten jeder Sprache erkennen können

Dass die Seiten einer mehrsprachigen Unternehmenswebsite erreichbar sind, bedeutet nicht, dass Suchmaschinen sie zwangsläufig korrekt indexieren und anzeigen. Jede indexierbare Sprachversion sollte über eine eigene, stabile und erreichbare URL verfügen. Übliche Strukturen umfassen Unterverzeichnisse, Subdomains oder länderspezifische Top-Level-Domains. Wichtiger ist im Projekt, dass die gesamte Website einheitlich bleibt und nicht ein Teil der Seiten /en/ verwendet, ein anderer Teil auf Parameter wie ?lang=en setzt und zusätzlich Standardseiten ohne Sprachpfad gemischt werden.

Die Seiten müssen über hreflang alternative Sprachbeziehungen herstellen und die korrekten Sprach- oder Sprach-Regions-Codes verwenden. Der Zweck besteht nicht darin, das Ranking zu verbessern, sondern Suchmaschinen dabei zu helfen, in Suchszenarien verschiedener Sprachen oder Regionen zu verstehen, welche Version angezeigt werden soll. Die Kennzeichnung muss wechselseitig oder als vollständige Gruppe verknüpft sein: Die englische Seite verweist auf die deutsche Seite, und die deutsche Seite muss wiederum auf die englische Seite zurückverweisen können; nicht vorhandene Seiten dürfen nicht in die Zuordnung aufgenommen werden.

Auch kanonische Links (canonical) müssen mit der Sprachstrategie übereinstimmen. Jede tatsächlich eigenständige Sprachseite sollte in der Regel auf sich selbst verweisen. Die Canonical-Angaben aller Sprachseiten dürfen nicht auf die englische Seite zeigen, da Suchmaschinen andere Sprachversionen sonst möglicherweise als Duplicate Content bewerten und ihre Indexierung abschwächen. Seitentitel, Beschreibungen, die Erklärung der Hauptsprache, das lang-Attribut, Sitemaps und interne Links müssen ebenfalls zur aktuellen Sprache passen.

Ob für die Standardsprachseite x-default eingerichtet werden soll, hängt von der Einstiegsstrategie ab. Es eignet sich als Auffangseite, wenn keine eindeutige Sprache oder Region übereinstimmt, sollte jedoch keine spezifischen Sprachseiten ersetzen. Ebenso wenig darf die Startseite als Ersatzversion für sämtliche fehlenden Inhalte verwendet werden.

„Pfade testen“ statt vereinzelt zu klicken

Die Effizienz der Prüfung vor dem Go-live hängt davon ab, ob die Testpfade als reale Besuchsvorgänge konzipiert werden. Die Vorschau einiger Seiten im Backend allein macht es schwierig, Konflikte zwischen Cache, Weiterleitungen, Formularen und Indexierungseinstellungen zu erkennen. Effektiver ist eine Prüfung über mehrere Einstiegspunkte hinweg:

• Die URLs der Startseiten in verschiedenen Sprachen direkt eingeben und prüfen, ob Serverstatus, Standardsprache und Seiteninhalte korrekt sind;
• Über Suchergebnisse, Anzeigenlinks, E-Mail-Links oder Social-Media-Links tiefere Seiten aufrufen und anschließend die Sprache wechseln;
• Auf Desktop- und Mobilgeräten jeweils Menüwechsel, Seitenaktualisierung, Browser-Zurück-Funktion und Formularübermittlung durchführen;
• Cookies löschen oder ein Inkognito-Fenster verwenden, um Erkennung und Weiterleitung beim ersten Besuch zu prüfen;
• Ausnahmesituationen simulieren, etwa wenn eine Seite keine Zielsprachversion besitzt, ein Produkt nicht mehr verfügbar ist oder ein Artikel nicht übersetzt wurde, und sicherstellen, dass keine toten Links oder fehlerhaften Weiterleitungen entstehen;
• Den Quellcode einsehen oder mit Crawling-Tools stichprobenartig hreflang, canonical, Sprachattribute und Indexierungsanweisungen prüfen.

Zwischen Testumgebung und Produktionsumgebung bestehen häufig Unterschiede bei Domainnamen, Caches, CDN-Regeln, robots-Einstellungen und Drittanbieter-Formulardiensten. Daher sollte nach einer erfolgreichen Abnahme in der Vorproduktionsumgebung auch nach der offiziellen Veröffentlichung eine Online-Nachprüfung erfolgen. Besonders nach einer Migration von Sprachverzeichnissen, einem Domainwechsel oder einer CMS-Überarbeitung müssen die Weiterleitungsregeln für bestehende externe Links und bereits indexierte URLs einzeln geprüft werden; es genügt nicht, nur zu kontrollieren, ob neue Seiten normal geöffnet werden.

Probleme nach ihrem Wirkungsbereich behandeln und wiederholte Nacharbeiten nach dem Go-live vermeiden

Nicht alle Mängel beim Sprachwechsel sollten mit derselben Priorität behandelt werden. Probleme, durch die Nutzer in die falsche Sprache gelangen, keine Anfrage übermitteln können, 404-Fehler entstehen, Werbe-Landingpages verloren gehen oder die Suchmaschinenindexierung unübersichtlich wird, müssen vor dem Go-live behoben werden. Einzelne Long-Tail-Artikel, deren Übersetzung noch nicht abgeschlossen ist, oder fehlende Alternativtexte bei einigen nicht zentralen Bildern können hingegen eindeutig in einen nachfolgenden Veröffentlichungsplan aufgenommen werden – vorausgesetzt, sie führen nicht zu falschen Zusagen oder unterbrochenen Links.

Bei der Projektübergabe sollten für die Sprachversionen außerdem klar abgrenzbare Verantwortlichkeiten für die Wartung bestehen: Wer erstellt neue Seiten und richtet Übersetzungszuordnungen ein? Wer pflegt Terminologie und Produktparameter? Wer aktualisiert SEO-Kennzeichnungen? Wer prüft nach der Veröffentlichung Sitemap und Indexierungsauffälligkeiten? Ohne diese Vereinbarung kann eine mehrsprachige Website selbst dann, wenn der erste Go-live korrekt erfolgt, bei später hinzugefügten Produkten oder Inhalten schrittweise in einen fragmentierten Zustand geraten: „Seite vorhanden, aber keine entsprechende Sprache“, „Übersetzung vorhanden, aber keine internen Links“ oder „Inhalt vorhanden, aber keine Indexierungsbeziehung“.

Der Abnahmestandard für den Sprachwechsel darf nicht bei einer anklickbaren Schaltfläche stehen bleiben, sondern muss ein vollständiges Ergebnis sicherstellen: Besucher können dauerhaft in ihrer gewählten Sprache navigieren und Kontaktaktionen ausführen; jede Sprachseite verfügt über eine eindeutige und stabile Adresse; Suchmaschinen bewerten verschiedene Versionen nicht fälschlich als doppelte oder fehlerhafte Seiten. Werden diese Beziehungen vor dem Go-live eindeutig geprüft, erhält die mehrsprachige Unternehmenswebsite erst die Grundlage für kontinuierliche Vermarktung und Inhaltserweiterung.