SEO Migration Shopware 6: Organische Sichtbarkeit beim Wechsel zu Odoo erhalten
Ein ERP-Wechsel kostet keine Rankings, solange sich an der sichtbaren Frontend-Ebene nichts ändert. Odoo spielt in dieser Architektur keine öffentlichen URLs aus. Google crawlt weiterhin ausschließlich Shopware.
Eine Stelle bleibt trotzdem heikel: SEO-URLs werden aus Artikelbezeichnungen generiert. Sobald Odoo die Hoheit über diese Bezeichnungen übernimmt und im Zuge der Migration Produktnamen bereinigt werden, ändern sich die daraus abgeleiteten Slugs. Genau dort entstehen Verluste, nicht am ERP-Wechsel selbst.
Dieser Beitrag richtet sich an SEO-Verantwortliche, die eine anstehende Migration einschätzen müssen, und an technische Projektleiter, die wissen wollen, welche Prüfpunkte in den Migrationsplan gehören.
SEO-Risiko richtig einordnen
In der zugrunde liegenden Zielarchitektur agiert Odoo 19 ausschließlich im Hintergrund und spielt keine öffentlichen URLs aus. Weder URLs noch Metadaten, Canonical-Tags oder XML-Sitemaps werden durch die ERP-Migration verändert, solange Shopware 6 das alleinige öffentliche Frontend bleibt. Suchmaschinen crawlen weiterhin ausschließlich die Shopware-Ebene – dadurch entsteht kein Duplicate Content, und das Crawl-Budget bleibt unverändert effizient genutzt.
Das SEO-Risiko einer solchen Migration ist also kein Automatismus, sondern eine Funktion davon, was sich an der sichtbaren Frontend-Ebene tatsächlich verändert. Auch strukturierte Daten (JSON-LD), interne Verlinkungen, Breadcrumbs und Kundenbewertungen werden in dieser Architektur weiterhin vollständig von Shopware generiert und verwaltet – sie sind von der ERP-Migration technisch nicht betroffen, solange die Datenquelle für die zugrunde liegenden Artikel- und Kategorieinformationen korrekt migriert wurde.
Der unterschätzte Fallstrick: seo_url-Erhalt ist eine Aufgabe, kein Automatismus
Hier liegt der eigentlich kritische Punkt, der in vielen Migrationsprojekten übersehen wird: Sobald Odoo die Hoheit über Artikelbezeichnungen und Kategoriestrukturen übernimmt, generiert Shopware seine SEO-URLs aus genau diesen Daten. Jede im Rahmen der Migration vorgenommene Normalisierung, Vereinheitlichung oder Bereinigung von Produktnamen – fachlich oft sinnvoll und deshalb besonders tückisch – verändert dadurch die abgeleiteten URL-Slugs.
Der Erhalt der Sichtbarkeit ist deshalb keine automatische Folge der Architektur, sondern das Ergebnis einer bewussten Migrationsentscheidung: Die bestehenden Einträge der SEO-URL-Struktur werden als eigenständiger, zu migrierender Datenbestand behandelt. Vor dem Cutover wird der vollständige Bestand kanonischer URLs exportiert, nach dem Import gegen die neu generierten Slugs abgeglichen, und jede Abweichung wird entweder durch Fixierung der ursprünglichen URL oder durch eine 301-Weiterleitung aufgelöst. Erst dieser Abgleich rechtfertigt die Aussage, dass eine Migration ohne Sichtbarkeitsverlust verläuft.
Ein zusätzlicher, technischer Aspekt betrifft die Suchinfrastruktur selbst: Bei Migrationen mit umfangreichen Katalogen werden ressourcenintensive Suchindizes auf Shopware-Seite (Elasticsearch beziehungsweise OpenSearch) während des eigentlichen Massenimports häufig bewusst pausiert und erst kurz vor dem finalen Go-Live neu aufgebaut. Das beschleunigt den Importprozess erheblich, sollte aber in der Zeitplanung berücksichtigt werden: Der Suchindex muss vor der Wiederfreigabe des Shops vollständig neu aufgebaut sein, da sonst Produktsuche und Filternavigation im Frontend unvollständige Ergebnisse liefern.
URL- und Redirect-Mapping
Wo Änderungen an URLs unumgänglich sind – etwa weil sich Artikelbezeichnungen im Rahmen einer Datenbereinigung ändern –, muss ein lückenloses Redirect-Mapping vorliegen, bevor der Cutover erfolgt:
- vollständige URL-Matrix alter zu neuer URLs
- ausschließlich direkte 301-Weiterleitungen, keine Redirect-Ketten
- Vollständigkeitsprüfung vor dem Go-Live, nicht danach
Redirect-Ketten (eine Weiterleitung, die auf eine weitere Weiterleitung zeigt) verlangsamen nicht nur die Nutzererfahrung, sondern verwässern auch die Signalweitergabe an Suchmaschinen. Jede Weiterleitung sollte deshalb möglichst direkt auf die finale Ziel-URL zeigen.
Eine praktikable Vorgehensweise für die Vollständigkeitsprüfung: Die vollständige Liste bestehender, indexierter URLs wird vor der Migration aus der Google Search Console sowie aus dem bestehenden Sitemap-Export gezogen. Nach dem Dry Run wird jede dieser URLs automatisiert gegen das neue System geprüft – entweder liefert sie denselben Inhalt wie zuvor, oder es liegt eine korrekte 301-Weiterleitung vor. Jede URL, die stattdessen mit einem 404 antwortet, muss vor dem produktiven Go-Live geklärt sein.
Canonicals
Canonical-Strukturen bestehen bei einer sauber umgesetzten Migration unverändert fort, da sie technisch von Shopware verwaltet werden und nicht vom ERP-Wechsel betroffen sind. Trotzdem gilt: Jede Änderung an Produktdaten, die sich indirekt auf generierte URLs auswirkt, sollte vor dem Go-Live gegen die bestehenden Canonical-Einträge geprüft werden – eine pauschale Aussage „Canonicals bleiben automatisch korrekt“ ist ohne diese Prüfung nicht seriös.
Metadaten und strukturierte Daten schützen
Auch strukturierte Daten (JSON-LD), interne Verlinkungen, Breadcrumbs und Kundenbewertungen werden in dieser Architektur weiterhin vollständig von Shopware generiert und verwaltet. Title, Description, Canonical-Tags und JSON-LD-Markup dürfen durch die Migration nicht unkontrolliert überschrieben werden – insbesondere dann nicht, wenn im Rahmen der Datenbereinigung Produktbezeichnungen oder Kategorienamen angepasst werden, aus denen diese Metadaten teilweise automatisch generiert werden.
SEO und ERP-Architektur gemeinsam planen
Der wirksamste Schutz gegen SEO-Verluste ist organisatorisch, nicht rein technisch: SEO-Verantwortliche und das Team, das die ERP-/Shopware-Architektur verantwortet, sollten den Migrationsplan gemeinsam abstimmen – inklusive einer gemeinsamen QA-Phase vor dem Cutover, in der URL-Mapping, Canonicals und strukturierte Daten stichprobenartig geprüft werden. Wie diese Prüfung in den größeren Cut-over-Prozess eingebettet wird, zeigt ERP-Migration ohne Downtime.
Eine sinnvolle Aufgabenteilung in dieser gemeinsamen QA-Phase: Das SEO-Team definiert vor dem Cutover eine Liste geschäftskritischer URLs (Top-Kategorien, umsatzstärkste Produkte, wichtige Landingpages), die nach dem Go-Live stichprobenartig manuell geprüft werden. Das technische Team stellt sicher, dass automatisierte Redirect- und Canonical-Prüfungen bereits vor der eigentlichen Umschaltung als Teil des Dry Runs durchlaufen wurden. Diese Kombination aus automatisierter Breitenprüfung und manueller Tiefenprüfung geschäftskritischer Seiten deckt die meisten praxisrelevanten Fehlerfälle ab.
Der SEO-Erhalt ist ein Prüfpunkt unter mehreren. Den vollständigen Migrationsablauf mit allen Phasen beschreibt unser Überblick zur Migration von PlentyONE zu Odoo.
Häufig gestellte Fragen zum SEO-Erhalt bei der ERP-Migration
Müssen wir mit einem temporären Ranking-Einbruch während der Migration rechnen?
Bei einer sauber geplanten Migration, die Shopware als alleiniges Frontend unverändert lässt, ist ein Ranking-Einbruch nicht die zu erwartende Folge. Risiken entstehen gezielt dort, wo sich URLs oder Metadaten durch Datenbereinigungen im Rahmen der Migration verändern – genau diese Stellen werden im beschriebenen Abgleichsprozess vorab identifiziert.
Wie lange vor dem Go-Live sollte der URL-Abgleich beginnen?
Idealerweise parallel zum Dry Run, also Wochen vor dem eigentlichen Cutover – nicht erst in den letzten Tagen davor. Nur so bleibt genug Zeit, um bei Abweichungen zwischen alten und neu generierten URLs sauber zu reagieren, statt unter Zeitdruck Kompromisse einzugehen.
Betrifft dieses Risiko auch Unternehmen, die keine Produktnamen bereinigen wollen?
Das Risiko ist deutlich kleiner, wenn keine Bereinigung stattfindet, aber nicht automatisch null: Auch technische Migrationsschritte wie eine veränderte Zeichenkodierung oder eine andere Behandlung von Sonderzeichen können URL-Slugs unbeabsichtigt beeinflussen. Ein Abgleich vor dem Go-Live bleibt deshalb in jedem Fall empfehlenswert.
Quellen
Die Aussagen zu permanenten Redirects, Canonicals und deren Rolle bei der Verarbeitung durch Google Search basieren auf der offiziellen Dokumentation von Google Search Central: Redirects and Google Search und How to Specify a Canonical with rel=“canonical“ and Other Methods.
SEO-abgesicherte Systemmigration anfragen
Ob und wo Ihre bestehende SEO-Struktur bei einer ERP-Migration tatsächlich gefährdet ist, hängt von Ihrer konkreten Produktdatenpflege und geplanten Bereinigungsschritten ab. Ziel ist, SEO-Risiken durch einen kontrollierten Abgleich von URLs, Redirects, Canonicals und Metadaten frühzeitig zu erkennen und zu begrenzen. Genau das prüfen wir im Rahmen unseres kostenlosen, unverbindlichen E-Commerce Audits.
Lassen Sie den SEO-Erhalt Ihrer Migration technisch prüfen – kostenfrei und unverbindlich.
Jetzt SEO-Migrationsprüfung anfordern
„Wir haben jahrelang in unsere Rankings investiert und wollen dieses Risiko nicht eingehen.“ Deshalb ist der Erhalt Ihrer SEO-URLs bei uns eine eigene Migrationsaufgabe mit eigenem Abgleich vor dem Go-Live. Jede URL, die nach dem Import nicht mehr identisch ist, wird entweder fixiert oder per 301 aufgelöst – bevor umgeschaltet wird, nicht danach.
✔ kostenlos ✔ unverbindlich ✔ dedizierter URL-/Metadaten-Abgleich ✔ Antwort innerhalb von 24 Stunden
Lukas Ehrenberg
Lukas Ehrenberg ist die operative Speerspitze der HQ GmbH, wenn es um komplexe und großvolumige E-Commerce-Infrastrukturen geht. In zahlreichen Projekten verantwortet er die technische Umsetzung von tiefgreifenden ERP-Migrationen – insbesondere den Wechsel von Legacy-Systemen wie PlentyONE hin zu modularen Plattformen wie Odoo. Gepaart mit seiner tiefen Shopware-Expertise baut er skalierbare Enterprise-Infrastrukturen auf. Seine enorme praktische Erfahrung macht ihn zum primären Ansprechpartner für Marken, die ein risikofreies, datensicheres und ausfallfreies Replatforming anstreben.
Als technischer Betreuer eines hochverfügbaren Enterprise-Shopware-Clusters mit über 14 Servern beherrscht er Lastverteilung und Systemstabilität im Hochfrequenzbereich. Seine besondere technische Expertise liegt in der architektonischen Neuausrichtung von E-Commerce-Ökosystemen: Er kombiniert fundiertes Wissen über die sichere Datenextraktion aus restriktiven Systemen (wie der PlentyONE REST-API unter strikter Optimierung von Rate-Limits) mit der performanten, asynchronen Anbindung an moderne ERP-Lösungen wie Odoo. Damit garantiert er nahtlose Systemübergänge selbst bei höchsten Transaktionsvolumina.
