Mehrsprachige Website migrieren ohne SEO-Verluste

Traffic verschwindet in der Regel nicht, weil Google verwirrt war. Er verschwindet, weil eine mehrsprachige Migration wie ein einfaches Redesign behandelt wurde – und jemand vergessen hat, dass jede Sprachversion ihre eigenen URLs, Signale, Canonicals und internen Verlinkungspfade hat. Wer eine mehrsprachige Website migrieren möchte, ohne SEO-Verluste zu riskieren, braucht einen Plan, der Lokalisierung wie Architektur behandelt – nicht wie Dekoration.

In WordPress kann das schnell unübersichtlich werden. Ein Plugin speichert übersetzte URLs auf eine Art, ein anderes schreibt Slugs anders, und ein drittes fügt hreflang-Tags nach eigener Logik ein. Dann ändert jemand die Domain-Struktur, bringt die neue Website an einem Freitag live – und verbringt den nächsten Monat damit, sich zu fragen, warum französische Produktseiten in den Rankings abgestürzt sind. Das ist kein Rätsel. Es ist meistens nur vermeidbar.

Warum mehrsprachige Migrationen SEO so leicht zerstören

Eine einsprachige Migration ist bereits fragil. Kommen mehrere Sprachen hinzu, migriert man plötzlich Cluster gleichwertiger Seiten, alternative URLs, regionale Ausrichtungen, übersetzte Metadaten, interne Links – und oft viele Inhalte, die sich für Suchmaschinen nur dank der sie umgebenden Signale unterscheiden lassen.

Der größte Fehler ist die Annahme, Rankings hingen allein am Seiteninhalt. Das ist nicht so. Sie hängen am gesamten Setup: URL-Struktur, Indexierbarkeit, Canonicals, hreflang, Weiterleitungen, Konsistenz der Sitemap – und daran, ob Google noch versteht, welche englische Seite zu welcher spanischen oder deutschen Version gehört.

Bricht auch nur eines dieser Elemente im großen Maßstab, verbreitet sich der Schaden. Ein falsches Canonical kann einen ganzen Sprachordner auslöschen. Fehlende Weiterleitungen können alte, linkstarke URLs entwerten. Falsches hreflang kann die falsche Seite in den falschen Markt schicken. Und wenn übersetzte Slugs sich ohne saubere Weiterleitungsübersicht ändern, bittet man Google im Grunde, von vorne anzufangen.

Vorbereitung: Bevor Sie eine mehrsprachige Website migrieren

Beginnen Sie nicht mit dem Design. Beginnen Sie mit der Bestandsaufnahme.

Crawlen Sie die aktuelle Website und exportieren Sie jede indexierbare URL für jede Sprache. Erfassen Sie Titel, Meta-Beschreibungen, Canonicals, Status-Codes, hreflang-Verweise, XML-Sitemap-Einträge und – wenn Ihr Crawler das unterstützt – interne Links. Wenn Sie von einem gehosteten Übersetzungs-Layer oder einer SaaS-Übersetzungsplattform wechseln, dokumentieren Sie das genaue URL-Format, das derzeit verwendet wird. Das umfasst Unterverzeichnisse, Subdomains, Parameter, übersetzte Slugs und – falls lokalisiert – auch Medien-URLs.

Ordnen Sie anschließend jeder alten URL eine neue Ziel-URL zu. Nicht nur Templates – jede einzelne URL. Kategorieseiten, paginierte Archive, Produktseiten, Blog-Beiträge, Sprachhomepages, Account-Seiten und alle hochwertigen Landing Pages, die für bezahlte oder organische Suche erstellt wurden. Wenn eine Seite entfernt wird, entscheiden Sie jetzt: Weiterleitung zu einer inhaltlich ähnlichen Seite, 410-Status oder ganz weg. Wer das später dem Zufall überlässt, produziert Weiterleitungsketten und verlorenen Traffic.

Das ist auch der Moment, in dem Sie entscheiden, was sich nicht ändern soll. Wenn aktuelle mehrsprachige URLs bereits gut ranken, behalten Sie sie. Eine Migration ist nicht der richtige Zeitpunkt für clevere neue Slug-Strukturen oder eine neue Spracharchitektur – es sei denn, der Nutzen ist klar und konkret. Stabilität gewinnt.

Die richtige URL-Strategie wählen und konsequent umsetzen

Für mehrsprachiges SEO gibt es nur wenige sinnvolle Optionen: Unterverzeichnisse, Subdomains oder länderspezifische Domains. In WordPress sind Unterverzeichnisse oft am einfachsten zu verwalten und erhalten Authority gut – aber das macht sie nicht automatisch zur richtigen Wahl für jedes Setup.

Entscheidend während der Migration ist Konsistenz. Wenn die alte Website /es/ und /de/ verwendet, wechselt man nicht einfach zu es.example.com, nur weil das für jemanden professioneller wirkt. Das schafft ein zweites Migrationsproblem auf dem ersten. Gleicher Inhalt, neue Struktur, neue Signale, mehr Fehlerquellen.

Es gibt Fälle, in denen eine URL-Änderung sinnvoll ist. Vielleicht hat die alte Plattform hässliche Query-Strings verwendet, oder übersetzte Seiten wurden über einen Proxy ausgeliefert, bei dem man nie wirklich Eigentümer war. In Ordnung. Aber seien Sie ehrlich über die Kosten. Je größer die strukturelle Veränderung, desto sorgfältiger müssen Weiterleitungs-Mapping und QA nach dem Launch sein.

Weiterleitungen sind keine Nacharbeitsaufgabe

Weiterleitungen sind die Migration.

Wenn auch nur ein mehrsprachiges URL-Muster sich ändert, erstellen Sie eine Weiterleitungstabelle, die jede alte URL einer finalen Ziel-URL zuordnet. Verwenden Sie 301-Weiterleitungen. Vermeiden Sie Weiterleitungsketten. Vermeiden Sie Sprach-Mismatches, sofern es keine Alternative gibt. Eine alte spanische Produktseite sollte Nutzer nicht auf die englische Homepage umleiten, nur weil dem Migrationsteam die Zeit ausgegangen ist.

Das ist wichtig für Nutzer und Crawler – aber auch für den Umsatz. WooCommerce-Shops mit mehrsprachigen Produktseiten haben oft Backlinks, die auf lokalisierte SKUs, Kategorieseiten und Blog-Inhalte zeigen. Verliert man diese Pfade, verliert man nicht nur Rankings. Man verschwendet Linkstärke, die durch Inhalte, PR und Zeit aufgebaut wurde.

Wenn Sie von einer Abo-basierten Übersetzungsplattform wechseln, stellen Sie sicher, dass Sie die genauen SEO-relevanten URLs erhalten können, die Nutzer bereits besuchen. Dort entscheidet sich die Frage der Eigentümerschaft. Einige Migrationslösungen – darunter auch Setups, die auf TrueLang basieren – sind gezielt darauf ausgelegt, mehrsprachige URLs zu übertragen und die SEO-Struktur intakt zu halten, anstatt einen Neustart zu erzwingen.

Hreflang, Canonicals und Indexierbarkeit: Ein gründliches Audit ist Pflicht

Hier scheitern viele Migrationen still und leise.

Hreflang muss auf echte, indexierbare Äquivalente in anderen Sprachen verweisen. Jede Seite im Cluster sollte korrekt auf die anderen verlinken – einschließlich sich selbst. Sprach- und Regionscodes müssen gültig sein. Wenn x-default verwendet wird, dann bewusst – nicht weil ein Plugin es standardmäßig eingefügt hat.

Canonicals erfordern noch mehr Aufmerksamkeit. Das Canonical einer übersetzten Seite sollte in der Regel auf sich selbst zeigen – nicht auf die Originalsprachversion. Wenn die spanische Seite auf das englische Original kanonisiert, sagt man Google, dass die spanische Seite eine Kopie ist, die ignoriert werden soll. Dieser Fehler ist verbreitet, schädlich und vollständig vermeidbar.

Prüfen Sie außerdem die Indexierbarkeit auf Template-Ebene. Noindex-Tags, blockierte Ordner, vergessene Staging-Reste, versehentliche Passwortabfragen und JavaScript-Rendering-Probleme können eine einzelne Sprachsektion treffen, ohne die anderen zu berühren. Man kann nicht davon ausgehen, dass die englische Version crawlbar ist und die italienische deshalb auch in Ordnung ist.

Inhaltliche Gleichwertigkeit wird unterschätzt

Eine mehrsprachige Migration ist nicht nur technisches Handwerk. Suchmaschinen vergleichen Äquivalente. Hatte die alte deutsche Seite optimierte Title-Tags, Fließtext, FAQs und interne Links, ist die neue aber maschinell übersetzt mit eingekürzter Formatierung und fehlenden Metadaten – können Rankings sinken, selbst wenn die Weiterleitungen perfekt sind.

Das bedeutet nicht, dass jedes Wort mit der alten Version übereinstimmen muss. Manchmal hilft eine Überarbeitung. Aber Absicht, Struktur und On-Page-Ausrichtung sollten erhalten bleiben. Übersetzte SEO-Felder, die gut performen, sollten beibehalten werden. Relevante Bild-Alt-Texte ebenfalls. Strukturierte Daten, falls in der jeweiligen Sprache vorhanden, ebenfalls. Und interne Links in übersetzten Inhalten – vor allem, wenn sie auf lokalisierte Zielseiten verweisen.

Das ist einer der Gründe, warum viele Website-Betreiber aufgeblähte Plattformen überhaupt verlassen. Sie erkennen, dass sie kein sauberes, editierbares mehrsprachiges Setup besitzen. Sie haben es nur gemietet. Dann wird die Migration zur Archäologie.

Launch-Tag ist für Verifikation, nicht für Optimismus

Wenn die neue Website live geht, prüfen Sie live URLs sofort. Nicht morgen. Nicht nach dem Wochenende.

Testen Sie Ihre Weiterleitungsliste gegen echte Antworten. Crawlen Sie die neue Website nach Sprache. Prüfen Sie die hreflang-Ausgabe. Überprüfen Sie Canonicals. Validieren Sie XML-Sitemaps. Stellen Sie sicher, dass alte URLs korrekt weiterleiten und neue Seiten 200-Status-Codes zurückgeben. Prüfen Sie stichprobenartig interne Links in Menüs, Sprachumschaltern, Breadcrumbs, Produkten, Blog-Beiträgen und transaktionalen Abläufen wie Warenkorb und Checkout.

Öffnen Sie dann die Search Console und beobachten Sie Coverage-Änderungen, Crawling-Anomalien und hreflang-Fehler. Vergleichen Sie die Anzahl indexierter URLs in den verschiedenen Sprachbereichen. Wenn ein Markt überproportional einbricht, reagieren Sie schnell. Im mehrsprachigen SEO bleiben kleine Implementierungsfehler selten klein.

Erwarten Sie außerdem gewisse Schwankungen. Nicht jeder Rückgang bedeutet Misserfolg. Wenn Architektur, Inhalte, Hosting und Übersetzungs-Tooling gleichzeitig geändert wurden, braucht Google Zeit, die Signale neu zu verarbeiten. Es geht nicht um null Bewegung. Es geht um kontrollierte Bewegung mit einer klaren Erklärung.

Was man vermeiden sollte, wenn Rankings erhalten bleiben sollen

Migrieren, redesignen und jeden Inhalt gleichzeitig neu schreiben – nur wenn man Freude daran hat, drei Variablen auf einmal zu debuggen.

Keinem Plugin erlauben, übersetzte Slugs anders zu generieren als die bestehenden indexierten URLs – es sei denn, für jeden einzelnen existiert ein Weiterleitungsplan.

Alle entfernten lokalisierten Seiten nicht auf eine generische Sprach-Homepage umleiten. Das ist nachlässig, und Suchmaschinen erkennen es.

Nicht darauf vertrauen, dass hreflang korrekt ist, nur weil ein Plugin mehrsprachiges SEO unterstützt. Unterstützung ist nicht dasselbe wie korrekte Ausgabe auf der eigenen Website.

Und Eigentümerschaft nicht als Nebensache behandeln. Wenn übersetzte Seiten, Metadaten und URLs im Fremdsystem eines anderen liegen, steigt das Migrationsrisiko. Immer.

Die kluge Strategie ist unspektakulär: behalten, was funktioniert; jede URL dokumentieren; jede Weiterleitung mappen; jedes Signal prüfen; nach dem Launch nicht improvisieren. So migriert man ohne Dramen. Und so hört man auf, für die Abhängigkeit von anderen zu zahlen – und behält die Rankings, die man sich verdient hat.