Shop-Migration ohne Ranking-Verlust: 43.943 Bestellungen, null Abweichungen
Die häufigste Sorge von Betreibern eines laufenden Shops: „Wir ziehen um und verlieren den Google-Traffic.“ Diese Sorge ist berechtigt — aber nicht, weil Migrationen den Rankings von Natur aus schaden. Schaden richtet das an, woran niemand denkt.
Was tatsächlich umzieht
Wenn ein Kunde sagt „lassen Sie uns den Shop umziehen“, meint er meist Produkte und Bestellungen. Das ist vielleicht ein Drittel der Arbeit. Ein Shop, der seit Jahren läuft, hat um sich herum eine Schicht von Dingen aufgebaut, die nicht wie Daten aussehen — und die darüber entscheiden, ob der Traffic den Umzug übersteht.
Bei der letzten großen Migration, die wir begleitet haben — ein Brennstoffhändler mit drei Märkten — haben wir aus der Produktion in die neue Architektur ein vollständiges Paket übernommen:
Bestellungen und Kunden sind das Offensichtliche. Interessant sind die beiden anderen Zeilen, denn sie entscheiden über Ihre Position in der Suche und über das Vertrauen, mit dem jemand auf einer Produktseite ankommt.
Weiterleitungen: 738 Adressen, an die sich niemand erinnert
Jede Adresse, unter der einmal etwas lag, hat bei Google eine Geschichte. Manche tragen Links von anderen Seiten, manche stehen in den Lesezeichen von Kunden, manche leben in alten Newslettern weiter. Antwortet diese Adresse nach der Migration mit „nicht gefunden“, ist diese Geschichte weg — nicht allmählich, sondern über Nacht.
In diesem Shop waren es 738. Keine Adressen aktueller Produkte — die wandern mit dem Katalog. Es waren Überbleibsel früherer Umbauten: alte Kategorien, ausgelistete Produkte, Adressen aus einer Zeit, in der der Shop anders strukturiert war. Irgendwann hat jemand Weiterleitungen dafür eingerichtet und sie vergessen, weil sie jahrelang leise funktioniert haben.
Ein einfacher Test vor jeder Migration: Exportieren Sie die Liste der Weiterleitungen, die Ihr Shop heute hat. Kommt als Antwort „haben wir welche?“, dann haben Sie welche — und niemand hat sie gezählt.
Diese Weiterleitungen mitzunehmen ist keine kreative Arbeit, sondern ein Haken auf einer Liste. Steht sie nicht auf der Liste, macht es niemand, weil nichts zu fehlen scheint. Der Shop sieht nach dem Umzug gut aus, der Traffic sinkt drei Monate lang, und alle fragen sich, warum.
Bewertungen: 375 Rezensionen, die leicht verloren gehen
Produktbewertungen liegen meist in einer anderen Tabelle als die Produkte und migrieren getrennt. Sehr oft migrieren sie gar nicht, weil jemand unter Termindruck entscheidet: „Bewertungen machen wir später, die Kunden schreiben neue.“ Werden sie nicht.
Wir haben 375 Rezensionen samt 1.825 Einzelbewertungen übernommen, denn jede Rezension in diesem Shop bewertete fünf Dimensionen getrennt. Die technische Falle saß dort, wo sie niemand vermutet: Die Bewertungen brauchten einen Eintrag, der sie mit dem Store mit der Kennung null verknüpft. Ohne diesen Eintrag lagen die Daten in der Datenbank, das Admin-Panel zeigte aber eine leere Liste — was exakt wie Datenverlust aussieht, obwohl nichts verloren war.
Ich erwähne es, weil es die typische Form von Migrationsproblemen ist: Nichts explodiert, alles sieht erledigt aus, und in einer Hilfstabelle fehlt eine Zeile.
Drei Länder, drei Währungen, eine Engine
Dieser Shop verkauft in Polen, Österreich und Deutschland — in drei Währungen, mit drei Steuersätzen und Preisen inklusive Steuer, weil dort Privatkunden kaufen. Dazu kommt eine Preisgestaltung, die vom Hersteller und von der Lieferform abhängt: Palette, Komplettzug, Big Bag.
Bei dieser Struktur besteht Migration nicht darin, Preise zu kopieren. Sie besteht darin, dass nach dem Umzug dieselbe Person, die aus demselben Land kommt, denselben Preis sieht wie vorher. Das klingt trivial, bis man zählt, wie viele Stellen im Code eines Shops diesen Preis verändern können.
Wir haben die alten Preisfelder in der Datenbank belassen, obwohl der neue Mechanismus sie nicht nutzt. Der Grund ist unspektakulär: Im Moment der Migration kann jemand einen Warenkorb mitten im Bestellvorgang haben. Das Löschen der alten Daten würde genau die Bestellungen zerstören, die unterwegs sind — also die, deren Verlust am meisten wehtut.
Wie Sie prüfen, ob die Migration gelungen ist
Der schlechteste Zeitpunkt, einen Fehler zu entdecken, ist drei Wochen nach der Umstellung, wenn der Traffic sinkt und niemand weiß, welche von fünfzig Änderungen es war. Deshalb kann Prüfung nicht heißen, sich durch den Shop zu klicken.
Die vollständige Adressliste vergleichen
Vor der Umstellung wird eine Liste aller Adressen erstellt, unter denen der alte Shop geantwortet hat — aus der Sitemap, aus dem Panel, aus den Google-Berichten. Nach der Umstellung wird jede maschinell abgefragt und die Antwort verglichen. Nicht „öffnet die Seite“, sondern: Antwortet sie so wie vorher, und wenn sie weiterleitet, an dieselbe Stelle?
Bei 738 Weiterleitungen sind das ein paar Minuten Maschinenzeit und die einzige Möglichkeit, sicher zu sein. Zehn zufällige Adressen anzuklicken erzeugt die Illusion von Kontrolle — sind fünf Prozent kaputt, erwischt vermutlich keine dieser zehn den Fehler.
Summen abgleichen, nicht nur das Vorhandensein von Daten
Nach der Migration vergleicht man Summen: Zahl der Bestellungen, Gesamtwert, Zahl der Kunden, Zahl der Bewertungen. Nicht um zu prüfen, ob die Daten da sind — das sind sie fast immer. Sondern um den Fall zu erwischen, dass 43.900 von 43.943 Bestellungen angekommen sind, weil dreiundvierzig etwas Ungewöhnliches in ihrer Struktur hatten und still herausgefallen sind.
Dieser Unterschied ist in keinem Panel sichtbar. Er zeigt sich nur, wenn jemand zwei Zahlen aus zwei Systemen vergleicht. Steht im Migrationsplan keine Zeile „Kontrollsummen vergleichen“, wird es niemand tun.
Die Nummerierung, nach der die Buchhaltung fragt
Bestellungen und Rechnungen tragen eine fortlaufende Nummerierung, und nach einer Migration muss sie nicht nur erhalten bleiben, sondern auch an der richtigen Stelle weiterlaufen. Der klassische Fehler: Die historischen Daten wandern korrekt, der Zähler für neue Dokumente startet bei eins, und die erste Bestellung nach der Umstellung bekommt eine Nummer, die in der Buchhaltung bereits existiert.
Das Problem, das nichts mit Daten zu tun hat
Eine eigene Klasse von Migrationsproblemen betrifft nicht die Daten, sondern die Umgebung, in der der Shop läuft. Zwei Beispiele aus diesem Projekt, beide teuer in der Diagnose und trivial in der Behebung:
Ein Server in einem anderen Zustand als das Repository. Jemand hat ein Modul direkt auf dem Server aktiviert, eine Konfigurationsdatei änderte sich außerhalb der Versionsverwaltung, und beim nächsten Deployment war die Änderung weg. Seither beginnt jedes Deployment mit der Prüfung, ob der Server nichts enthält, was das Repository nicht hat.
Änderungen, die nicht greifen, obwohl sie hochgeladen wurden. Der Shop hält kompilierten Code vor, und ein normaler Neustart leert das nicht. Das Symptom führt in die Irre: Sie laden eine Korrektur hoch, prüfen, nichts ändert sich, also laden Sie erneut hoch. Die Lösung ist, den generierten Code zu löschen und neu zu kompilieren — ein Schritt, der dauerhaft in der Deployment-Prozedur stehen muss, sonst verliert alle paar Monate jemand einen halben Tag damit.
Das ist das Argument dafür, die Migration von jemandem durchführen zu lassen, der die konkrete Plattform aus der Produktion kennt und nicht nur aus der Dokumentation. Die Daten bewegt jeder; der Unterschied liegt darin, wie lange die Diagnose solcher Situationen dauert.
Wann umgestellt wird
Die Umstellung des Traffics auf die neue Version ist der einzige Moment dieses Projekts, der sich nicht schmerzfrei rückgängig machen lässt. Drei Dinge, die vorher geklärt sein sollten:
- Was mit laufenden Bestellungen passiert. Jemand hat gerade jetzt einen Warenkorb offen oder ist mitten in der Zahlung. Der Plan muss zulassen, dass diese zu Ende gehen — deshalb blieben in dieser Migration die alten Preisfelder bestehen.
- Wer die alte Version noch erreicht. In den ersten Tagen sollte die alte Installation für Ihr Team erreichbar bleiben, damit sich etwas vergleichen lässt, wenn ein Kunde wegen einer Bestellung von vor der Migration anruft.
- Wann genau. Nicht Freitagnachmittag. Nicht in der Hochsaison. In diesem Shop beginnt die Heizsaison im Spätsommer — eine Umstellung im August wäre unabhängig von der Vorbereitung eine teure Entscheidung gewesen.
Die Liste, die vor dem Gespräch mit dem Dienstleister hilft
- Wie viele Weiterleitungen haben Sie? Nicht „ob“, sondern „wie viele“. Die Zahl ist in Minuten exportiert.
- Wo liegen die Bewertungen und in wie vielen Tabellen? Bewerten Sie mehrere Dimensionen, sind es weit mehr Daten, als die Produktseite vermuten lässt.
- Was passiert mit laufenden Bestellungen? Also: Sieht der Plan vor, dass jemand einen Warenkorb offen hat?
- Bleibt die Nummerierung von Bestellungen und Rechnungen erhalten? Das ist eine Frage Ihrer Buchhaltung, gestellt werden muss sie aber dem Dienstleister, und zwar vor dem Start.
- Wer prüft, ob alte Adressen weiterhin antworten? Maschinell und über die ganze Liste, nicht durch Anklicken von dreien.
Beantwortet ein Dienstleister diese fünf konkret, hat er das wahrscheinlich schon gemacht. Lautet die Antwort „das übernimmt die Plattform“, fragen Sie nach, welcher Teil genau — und was passiert, wenn sie es nicht übernimmt.