Was in der Woche nach einer Migration zu PrestaShop kaputtgeht
Der Tag des Livegangs verläuft fast immer gut. Das ist ein falsches Signal
Eine Migration, die „funktioniert“, im strengen Sinn, dass der neue Shop läuft und Bestellungen annimmt, ist relativ leicht hinzubekommen: Produkte, Preise, Lagerbestand und Bestellhistorie sind strukturierte Daten, die Importtools verschieben sie recht gut, und am ersten Tag scheint alles in Ordnung. Die echten Probleme zeigen sich nicht am Tag des Livegangs, sondern sieben bis zehn Tage später, wenn Besucher mit einer alten, in ihren Lesezeichen gespeicherten URL ankommen, wenn Google sein Crawling mit der Adresskarte wieder aufnimmt, die es kannte, und wenn jemand bemerkt, dass eine Funktion, „die es früher gab“, verschwunden ist, nicht weil jemand sie absichtlich entfernt hätte, sondern weil kein Importtool sie je berücksichtigt hat. Dieser Artikel handelt nicht davon, wie man migriert (dafür gibt es spezialisierte Dienstleister, das ist nicht unser Geschäft): Er handelt davon, was Sie in der Woche danach prüfen sollten, wenn der Shop online ist und die Liste der Probleme von selbst zu wachsen beginnt.
Tote URLs, nicht Dutzende, sondern Hunderte
Das am stärksten unterschätzte Problem ist der Umfang. Wer migriert, rechnet damit, „ein paar URLs“ zu korrigieren, nicht die ganze Adressstruktur. In der Praxis teilen fast keine zwei Plattformen dasselbe URL-Schema: Ein Katalog, der bei WooCommerce unter /product/produkt-name/, bei Magento unter /kategorie-name/produkt-name.html oder bei Shopify unter /products/produkt-name lag, kommt bei PrestaShop mit wieder einem anderen Schema an, das oft die numerische ID des Produkts in der Adresse enthält. Jede URL, die eine Suchmaschine indexiert hatte, jeder Link, den eine andere Website oder ein Kunde gespeichert hatte, zeigt nun auf einen Pfad, den es im neuen Shop schlicht nicht gibt. Bei einem Katalog von einigen tausend Produkten kommt man mit Kategorien, indexierten Filterseiten und redaktionellen Inhalten leicht auf einige hundert umzuleitende URLs, selbst bei einem mittelgroßen Shop: Das ist kein Grenzfall, der großen Katalogen vorbehalten wäre.
Die bewährte Vorgehensweise, die fast nie rechtzeitig angewandt wird, besteht darin, vor der Umstellung die vollständige Liste der URLs zu exportieren, die die alte Plattform hatte indexieren lassen (aus der Google Search Console, nicht aus der Sitemap der alten Website, die oft schon unvollständig ist), und den Weiterleitungsplan als Teil des Migrationsprojekts aufzubauen, nicht als Korrektur nach den ersten Meldungen über verlorenen Traffic.
Das Cookie-Banner, das die Länder nicht mehr unterscheidet
Eine mehrsprachige Migration, die in Eile durchgeführt wird, übernimmt fast immer Texte und Einstellungen, die für die Hauptsprache gedacht waren, und die Konfiguration der Cookie-Einwilligung ist eine der ersten Stellen, an denen man das sieht: Ein Banner, das das Publikum korrekt nach Sprache oder Land unterschied, fällt nach der Migration manchmal auf einen einzigen Standardwert zurück oder zeigt, schlimmer noch, für die Nebensprachen einen unübersetzten Text (einen Fehler genau dieser Art haben wir im September 2026 in unserem eigenen Modul für die Cookie-Einwilligung gefunden und behoben, nicht wegen einer Migration, sondern aus demselben Grund: Texte, die nur zwei von fünf Sprachen abdeckten). Es lohnt sich, die Einwilligungskonfiguration gleich nach der Umstellung in jeder aktiven Sprache erneut zu prüfen und nicht nur in der Hauptsprache, in der die Tests tatsächlich gemacht wurden.
Compliance-Daten, die das Importtool gar nicht suchen konnte
Importtools verschieben gut alles, was als Begriff auf der Ausgangsplattform schon existierte: Preis, Beschreibung, Bilder, Kategorien. Ein Feld wie „GPSR-Hersteller“, „Sicherheitshinweis für genau dieses Produkt“ oder „Bevollmächtigter in der EU“ gab es auf der alten Plattform oft gar nicht als strukturierte Angabe, und kein Importtool konnte es daher übertragen, ganz einfach weil es kein Quellfeld zum Kopieren gab. Das eigentliche Risiko ist ein migrierter Shop, der annimmt „wenn es vorher in Ordnung war, ist es jetzt in Ordnung“, obwohl die Compliance-Lücke, falls es sie gab, schon vorher da war und die Migration sie nur sichtbarer macht, indem sie dazu zwingt, die Produktdaten von Grund auf neu zu durchdenken.
Die interne Suche, die bei null anfängt
Hatte der frühere Shop eine Suchmaschine, die im Lauf der Zeit abgestimmt wurde, mit von Hand ergänzten Synonymen, nachdem Kunden einen Begriff gesucht und nichts gefunden hatten, mit auf die Sprache des Katalogs abgestimmten Stoppwörtern, mit einer Relevanzreihenfolge, die nach Monaten der Beobachtung korrigiert wurde, was die Kunden tatsächlich anklickten, dann reist nichts von dieser Abstimmung mit einem Produktimport mit. Es ist Arbeit am Verhalten der Suche, nicht an den Katalogdaten, und kein Migrationstool kann sie verschieben, weil sie nicht einmal eine „Angabe“ im üblichen Sinn ist: Es ist angesammelte Konfiguration. Das typische Symptom ist ein Rückgang der Conversions aus der internen Suche in den ersten Wochen, nicht weil die neue Suchmaschine an sich schlechter wäre, sondern weil sie mit einer generischen Einstellung startet statt mit den Korrekturen von Monaten.
Produktfeeds, die noch auf das alte Schema zeigen
Ein Google-Shopping- oder Marktplatz-Feed baut auf den URLs und Kennungen der Ausgangsplattform auf. Wird der Feed nach der Migration nicht vollständig auf das neue Adressschema umgebaut, zeigt jede Anzeige weiter auf eine URL, die eine Weiterleitung oder, schlimmer, einen 404 liefert: Ab einem gewissen Anteil defekter Links beginnt das Google Merchant Center den Feed zu melden und kann die Ausspielung der Anzeigen aussetzen, was ein direkter und unmittelbarer wirtschaftlicher Schaden ist, nicht nur ein Problem der organischen Suche.
Eine Checkliste für die erste Woche
- Vergleichen Sie die Liste der vor der Migration indexierten URLs (aus der Search Console) mit dem, was heute einen 200 liefert: Jede fehlende URL braucht entweder eine permanente Weiterleitung auf den gleichwertigen Inhalt oder eine bewusste Stilllegung, wenn der Inhalt wirklich nicht mehr existiert.
- Prüfen Sie das Cookie-Banner in jeder aktiven Sprache und jedem aktiven Land, nicht nur in der Hauptsprache.
- Prüfen Sie die Compliance-Daten der Produkte (GPSR eingeschlossen) erneut mit der Annahme, dass der Import sie nicht übertragen hat, denn das ist mit ziemlicher Sicherheit der Fall.
- Verfolgen Sie die Conversions aus der internen Suche in den ersten zwei Wochen getrennt: Das ist das schnellste Signal dafür, ob die Suchkonfiguration neu gemacht werden muss.
- Bauen Sie den Produktfeed auf dem neuen URL-Schema neu auf, bevor Sie die Kampagnen wieder starten, nicht erst, nachdem Sie den Rückgang bemerkt haben.
Kurz gesagt
Die Woche nach einer Migration ist keine ruhige Einlaufzeit: Es ist der Moment, in dem die Probleme auftauchen, die der Tag des Livegangs nicht zeigen konnte. URLs, die niemand weitergeleitet hat, Einstellungen ohne Quellfeld zum Kopieren, Monate an Abstimmung (Suche, Einwilligung, Feeds), die nie als „Daten“ zum Migrieren existiert haben. Ein Weiterleitungsmanager mit 404-Überwachung wie cll_seoredirect hilft, diese Lücken zu erkennen, wenn sie entstehen, statt erst, nachdem die Besucher sie schon bemerkt haben, doch die obige Checkliste gilt unabhängig vom verwendeten Werkzeug.
