Wie lässt sich mit einer mehrsprachigen Website-SEO-Architektur eine unübersichtliche Indexierung vermeiden?

Wie vermeidet eine SEO-Architektur für mehrsprachige Websites Probleme bei der Indexierung?

Indexierungsprobleme bei mehrsprachigen Websites entstehen häufig nicht dadurch, dass die Inhalte unzureichend sind, sondern weil Suchmaschinen nicht zuverlässig erkennen können: Handelt es sich bei diesen Seiten um entsprechende Versionen für Nutzer verschiedener Sprachen oder um mehrere URLs mit doppelten Inhalten? Soll eine bestimmte Seite Nutzer in den USA, Kanada oder alle englischsprachigen Nutzer bedienen? Und gelangen Nutzer aus den Suchergebnissen auf Seiten, die ihrer Sprache und Region entsprechen? Ist die Architektur grob umgesetzt, treten häufig Sprachversionen an die Stelle anderer Versionen, wichtige Seiten werden nicht indexiert, falsche Seiten erscheinen in Suchergebnissen der Zielmärkte oder die Crawling-Ressourcen der gesamten Website werden durch eine große Anzahl ähnlicher Seiten verbraucht.

Für technische Prüfer ist die SEO-Architektur einer mehrsprachigen Website nicht einfach eine Frage des Hinzufügens eines Sprachumschalters. Sie umfasst URL-Regeln, Beziehungen zwischen Seitenentitäten, Content-Management-Prozesse, Serverantworten, Sitemaps sowie die Abstimmung mit späteren Anzeigen-Landingpages und Seiten zur Traffic-Generierung über soziale Medien. Eine tatsächlich wartbare Lösung sollte jeder indexierbaren Seite eine eindeutige Identität geben: Welche Sprache wird verwendet, welche Region wird bedient, welche Version ist die Hauptversion und mit welchen Seiten bildet sie alternative Versionen?

Zunächst klären: Sprachversionen und Regionalversionen sind nicht dasselbe

Die Sprache beantwortet die Frage „In welcher Sprache wird die Seite dargestellt?“, während die Region beantwortet: „Für welche Menschen ist die Seite hauptsächlich bestimmt?“ Eine englische Seite ist nicht zwangsläufig eine US-Seite, und Spanisch steht nicht nur für Spanien. Richtet sich ein Unternehmen an mehrere englischsprachige Märkte, während Produktspezifikationen, Währungen, Lieferbedingungen und Zertifizierungsinformationen im Wesentlichen gleich sind, kann in der Regel eine allgemeine englische Version beibehalten werden. Erst wenn sich lokale Inhalte und Geschäftsbedingungen tatsächlich unterscheiden, ist eine Aufteilung in regionale Versionen wie US-Englisch, britisches Englisch oder australisches Englisch erforderlich.

Eine übermäßige Aufteilung ist ein häufiges Risiko. Viele Websites ersetzen lediglich Flaggen, Währungen oder einige wenige Begriffe und erstellen dann mehrere regionale Verzeichnisse. Dadurch ähneln sich die Hauptinhalte der Seiten stark, die Wartungskosten steigen, und Suchmaschinen können ihren eigenständigen Wert schwerer erkennen. Umgekehrt erhöht es auch die Unsicherheit bei Crawling und Indexierung, wenn deutlich unterschiedliche Inhalte wie Deutsch, Französisch und Japanisch auf derselben Seite untergebracht und anschließend per Frontend-Skript umgeschaltet werden. Sprachversionen, die von Suchmaschinen zuverlässig erreichbar sein sollen, müssen über eigenständige, teilbare und über die Navigation erreichbare URLs verfügen.

Die URL-Strategie bestimmt die späteren Verwaltungskosten

Zu den gängigen Bereitstellungsformen mehrsprachiger Websites gehören länderspezifische Domains, Subdomains und Verzeichnisse. Beispielsweise werden Sprachen über /en/, /de/, /ja/ oder Sprache und Markt über /en-us/, /en-gb/ unterschieden. Keine der drei Methoden ist grundsätzlich überlegen, doch sobald eine gewählt wurde, sollten Produktseiten, Kategorieseiten, Inhaltsseiten, Hilfeseiten und Formularseiten derselben Regel folgen. Was technische Teams am dringendsten vermeiden müssen, ist eine Mischform: Einige Seiten befinden sich in Unterverzeichnissen, bei anderen wird die Sprache über Parameter gewechselt, und wieder andere leiten auf Subdomains weiter. Für solche Websites ist es schwierig, stabile interne Links und Versionszuordnungen aufzubauen.

Für die meisten B2B-Websites, die Markenressourcen, Produktunterlagen und Content-Ressourcen zentral verwalten müssen, erleichtert eine Verzeichnisstruktur in der Regel die einheitliche Verwaltung von Vorlagen, Log-Analysen, Berechtigungen und Sitemaps. Welche Struktur gewählt wird, muss jedoch weiterhin anhand der bestehenden Domain, der Zielmärkte, rechtlicher Anforderungen und der Lieferfähigkeit des Teams beurteilt werden. Unabhängig von der gewählten Variante sollten URLs langfristig stabil bleiben und nicht aufgrund von Übersetzungstools, Relaunches oder Aktionssystemen häufig geändert werden.

hreflang, canonical und Weiterleitungen: Drei Signale dürfen sich nicht widersprechen

hreflang dient dazu, verschiedene Sprach- oder Regionalversionen desselben Inhalts zu deklarieren. Es sollte gemeinsam von einer Gruppe entsprechender Seiten gepflegt werden: Jede Version muss nicht nur auf andere Sprachversionen verweisen, sondern auch eine Deklaration auf sich selbst enthalten. Sprach- und Regionscodes müssen allgemeinen Standards entsprechen, und die Links müssen auf normal erreichbare, indexierbare Seiten führen. Wurde eine französische Seite gelöscht, weitergeleitet, vom Crawling ausgeschlossen oder tatsächlich mit noindex gekennzeichnet, bleibt jedoch weiterhin in der wechselseitigen Linkgruppe, führt dies zum Ausfall des Signals.

canonical klärt hingegen, welche URL die bevorzugte Version des aktuellen Inhalts ist. Es sollte nicht verwendet werden, um alle deutschen und japanischen Seiten auf die englische Seite zu verweisen; damit würde Suchmaschinen signalisiert, dass diese Seiten lediglich doppelte Kopien sind, was den Sinn einer mehrsprachigen Bereitstellung direkt aufhebt. Normalerweise sollte jede Sprachseite mit eigenständig übersetzten Inhalten einen selbstreferenzierenden canonical erhalten. Nur Parameterseiten, Sortier- und Filterseiten, Druckseiten oder andere tatsächlich doppelte URLs sollten mit der entsprechenden kanonischen Seite zusammengeführt werden.

Auch die automatische, erzwungene Weiterleitung anhand der IP-Adresse oder Browsersprache ist ein häufiger Auslöser für Indexierungsprobleme. Für die Nutzererfahrung kann ein Sprachvorschlag angeboten werden, jedoch sollten nicht alle Besucher und Crawler bedingungslos auf eine andere Seite geleitet werden. Sicherer ist es, die aktuelle Seite zugänglich zu halten und oben auf die empfohlene, umschaltbare Version hinzuweisen. Falls tatsächlich eine regionale Ausrichtungslogik vorhanden ist, muss sichergestellt werden, dass Suchmaschinen alle Sprach-URLs crawlen können und Nutzer manuell zurückkehren und wechseln dürfen.

Nicht nur Titel übersetzen – die Seitenbeziehungen müssen vollständig sein

Die Sprachversion einer Produktdetailseite sollte zumindest die wesentlichen Seitenbeziehungen einheitlich halten: Breadcrumb-Navigation, Kategorieeinstieg, verwandte Produkte, Anfrageeinstieg, Footer-Navigation und interne Suchergebnisse sollten alle auf dieselbe Sprachumgebung verweisen. In der Praxis sieht man häufig, dass der Haupttext einer chinesischen Produktseite nach der Übersetzung ins Englische bereits englisch ist, die Produktempfehlungen jedoch weiterhin auf chinesische URLs führen und auch Formularbestätigungsseite sowie Datenschutzerklärung in einer anderen Sprache angezeigt werden. Dies unterbricht nicht nur den Nutzerpfad, sondern führt auch dazu, dass Crawler über verschiedene Einstiege wiederholt nicht passende Versionen aufrufen.

Versionen für unterschiedliche Märkte können verschiedene inhaltliche Schwerpunkte haben, sollten jedoch vergleichbare Seitenentitäten beibehalten. Beispielsweise sollten Modellnummer, wichtige Spezifikationen, Bildressourcen und strukturierte Felder desselben Modells in allen Sprachversionen nachvollziehbar zueinander passen. Lieferhinweise, Fallbeispiele oder Compliance-Hinweise, die einer lokalen Version hinzugefügt werden, sollten den jeweiligen Markt tatsächlich bedienen und nicht lediglich Ortsnamen stapelweise ersetzen. Für Fertigungsunternehmen müssen insbesondere technische Parameter, Einheiten, Download-Unterlagen und Anfragefelder in den Übersetzungs- und Veröffentlichungsprüfprozess einbezogen werden.

Die „Liste indexierbarer Seiten“ mit Sitemap und Veröffentlichungsprozessen verwalten

Große mehrsprachige Websites können sich nicht allein auf die Erinnerung von Mitarbeitern zum Seitenstatus verlassen. Bei jeder neuen Sprachwebsite, Verzeichnismigration oder Produktdeaktivierung sollte eine Liste indexierbarer Seiten geprüft werden: Gibt die URL einen normalen Statuscode zurück, wird sie durch robots-Regeln blockiert, ist versehentlich noindex gesetzt, ist canonical konsistent, existiert das hreflang-Ziel und wurde die Seite in die entsprechende Sitemap aufgenommen? Eine Sitemap ist keine Garantie für die Indexierung, aber eine grundlegende Infrastruktur, um Suchmaschinen den Bereich wichtiger URLs zu übermitteln. Werden Testseiten, Filterparameterseiten, Login-Seiten und deaktivierte URLs darin vermischt, erhöht dies lediglich den Prüfaufwand.

Bei Inhaltsaktualisierungen wird die fehlende Synchronisierung zwischen Versionen am leichtesten übersehen. Die englische Seite hat einen Produktlink ersetzt, während die deutsche Seite noch die alte URL enthält; nach Einstellung des Verkaufs in einer Region wird die Seite gelöscht, aber andere Sprachseiten führen sie weiterhin als alternative Version auf. Es empfiehlt sich, „Quellseite – Übersetzungsaufgabe – Prüfung – Veröffentlichung – Indexierungsprüfung“ als geschlossenen Kreislauf einzurichten, anstatt die abgeschlossene Übersetzung als Projektende zu betrachten. Bei Shops und Content-Centern mit einer großen Seitenanzahl kann das System Versionsbeziehungen anhand von Seitenentitäten automatisch generieren, jedoch sollten weiterhin manuelle Stichproben und Warnmeldungen bei Ausnahmen vorgesehen werden.

Website-Erstellung und Lead-Generierung müssen dieselben Regeln teilen

Sobald die mehrsprachige Architektur in die Phase von Werbung, sozialen Medien und Content-Marketing eintritt, werden Probleme verstärkt. Wenn das Anzeigenteam Landingpages beliebig kopiert und mehrere Parameter-URLs für denselben Inhalt konfiguriert, kann das SEO-Team die kanonische Version nicht mehr eindeutig bestimmen. Wenn das Social-Media-Team Traffic verschiedener Sprachen dauerhaft auf die englische Startseite leitet, werden sowohl die interne Gewichtung der Sprachwebsite als auch die Conversion-Pfade unklar. Daher müssen Teams für Website-Erstellung, SEO, Werbung und Inhalte Sprachverzeichnisse, Benennungsregeln, Landingpage-Regeln und Standards für Tracking-Parameter gemeinsam nutzen.

Seit seiner Gründung im Jahr 2013 hat Yiyingbao Information Technology (Beijing) Co., Ltd. integrierte Dienstleistungskapazitäten rund um intelligente Website-Erstellung, SEO-Optimierung, Anzeigenplatzierung und Social-Media-Betrieb im Ausland aufgebaut. Für exportorientierte Fertigungsunternehmen, grenzüberschreitende Verkäufer und Teams für die internationale Markenexpansion liegt der Wert solcher Fähigkeiten nicht nur in der schnellen Erstellung mehrsprachiger Seiten, sondern auch darin, Seitenstrukturen im Cloud-System für intelligente Website-Erstellung, AI-gestützte Content-Produktion, SEO/GEO-Optimierung und Landingpages für Werbemaßnahmen einheitlich zu verwalten. Insbesondere bei einer parallelen Erschließung mehrerer Märkte wie Nordamerika, Europa, Südostasien, Nahost, Japan und Korea sowie Lateinamerika müssen zunächst Seitenidentitäten und Datenregeln klar definiert werden, damit die spätere Erweiterung um Sprachversionen nicht leicht außer Kontrolle gerät.

Bei der Bewertung einer SEO-Architektur für mehrsprachige Websites empfiehlt es sich, zunächst eine reale Produktseite zu testen: Sind nach dem Sprachwechsel URL, Seiteninhalt, Navigationslinks, canonical, hreflang, Sitemap und Formularziel konsistent? Können zugehörige Verweise nach der Deaktivierung einer Version gleichzeitig bereinigt werden? Kann das Team bei der Erschließung eines neuen Marktes eindeutig entscheiden, ob eine neue regionale Seite erstellt oder eine allgemeine Sprachseite weiterverwendet werden soll? Nur eine Architektur, die solchen konkreten Prüfungen standhält, bildet eher eine Grundlage für den langfristigen Betrieb einer globalen Website.