Produkt und Katalogdaten migrieren, ohne deine Rankings zu verlieren

Die eigentliche Frage hinter einem Katalogumzug

Wenn ein Shop mich fragt, ob er auf einen eigenen Store umziehen kann, ist der Katalog selten die Sorge. Produkte, Preise und Bilder fühlen sich an wie etwas, das man kopieren kann. Die eigentliche Frage, die Inhaberinnen und Inhaber nachts wachhält, ist die nächste: Kostet uns der Umzug unsere Rankings? Die Angst ist berechtigt. Ein Shop, der sich über Jahre seinen Platz in Google erarbeitet hat, kann diesen Platz an einem Wochenende verlieren, wenn der Umzug schlampig gemacht wird.

Also beantworte ich beide Hälften ehrlich. Zuerst, wie der ganze Katalog umzieht: Produkte, Varianten, Bilder, Kategorien, Lagerbestände, Preise und die sperrigen individuellen Daten, die fast jeder vergisst. Dann der Teil, der deine Rankings wirklich schützt: die URLs, die Weiterleitungen, die Canonicals und die strukturierten Daten. Der Katalog kommt fast immer mit. Rankings bewahrst du durch Disziplin, nicht durch Glück, und ich zeige dir genau, wo diese Disziplin hingehört. Dieser Artikel ist ein Baustein der größeren Übersicht dazu, was sich übertragen lässt und was nicht, und er gehört eng zur Migration deiner Bestell und Kaufhistorie.

Ein Shop, der den ganzen Artikel begleitet

Damit es konkret bleibt, verwende ich durchgehend ein erfundenes Unternehmen. Lampenhof (lampenhof.example) ist ein Wohn und Leuchtenhändler in Linz. Der Shop hat rund 8.000 SKUs: Lampen, Schirme, Möbel und Accessoires, die meisten in mehreren Größen, Farben und Oberflächen. Marlene führt ihn. Heute läuft der Shop auf Shopify Advanced und hat über vier Jahre stark auf Metafelder gesetzt, sodass jedes Produkt ein Material, eine Montagezeit, eine Lieferklasse, eine Lieferzeit und einen Händlerpreis trägt, die keines der Standardfelder abbildet. Niemand davon ist echt, und jede Zahl ist erfunden, damit ich jeden Schritt durchgehen kann. Lampenhof zieht auf einen maßgeschneiderten Store auf Solidus um, dem quelloffenen Rails Shopframework, auf dem ich baue, und den Marlene danach selbst besitzt.

Ein Katalog ist ein Datenmodell, keine Tabelle

Der erste Fehler ist, sich den Katalog als eine große Liste von Produkten vorzustellen. Er ist eine Menge zusammenhängender Dinge, und die Migration ist eine Abbildung zwischen zwei Datenmodellen. Es hilft, jeden Teil zu benennen, bevor man irgendetwas verschiebt.

Ein Produkt ist das, was eine Kundin zu kaufen glaubt. Eine Variante ist die konkrete Ausführung, die sie tatsächlich kauft: diese Lampe, in Messing, in der großen Größe. Die Merkmale, aus denen Varianten entstehen, sind Optionstypen (Größe, Farbe, Oberfläche) mit Optionswerten (groß, Messing, matt). Jede verkäufliche Variante trägt ihre eigene SKU, ihren eigenen Barcode (eine GTIN oder EAN), ihren eigenen Preis und oft ihr eigenes Gewicht und ihre Maße für den Versand. Produkte liegen in Kategorien, die meist ein Baum sind: Beleuchtung, dann Tischlampen, dann Nachttischlampen. Dazu kommen eine Marke oder ein Lieferant, eine Steuerkategorie, Lagerbestände an einem oder mehreren Standorten und Beziehungen zu anderen Produkten: Ähnliches, Cross Sells, Bundles. Über all dem liegen die Metafelder oder individuellen Attribute, die plattformspezifischen Zusatzfelder, in denen die eigentliche Geschäftslogik steckt.

Solidus bildet jedes einzelne davon sauber ab, und genau das ist der Sinn eines eigenen Stores. Ein Produkt ist ein Spree::Product, und jedes Produkt hat eine Mastervariante plus beliebig viele verkäufliche Varianten.¹ Optionstypen und Optionswerte sind eigene Datensätze, einmal angelegt und an Produkte gehängt, und eine Variante wird durch je einen Wert pro Optionstyp bestimmt.² Preise liegen in eigenen Datensätzen, einer pro Währung, sodass ein Katalog mit mehreren Währungen nativ ist statt angeflanscht.³ Kategorien sind Taxonomien und Taxons: eine Taxonomie ist der Baum, ein Taxon ein Ast, und ein Produkt kann über einen Klassifikationsdatensatz unter beliebig vielen Taxons hängen.⁴ Lagerbestand wird als Lagerposten gegen benannte Lagerorte geführt, zwei Lager sind also kein Plugin, sondern eine eingebaute Idee.³ Freie Attribute werden zu Produkteigenschaften.¹ Die Tabelle unten zeigt die ganze Abbildung auf einer Seite.

Wie der alte Shop es nennt	Was es ist	Wo es in Solidus landet
Produkt	Das verkäufliche Konzept	`Spree::Product` mit Mastervariante¹
Variante (Größe, Farbe)	Der konkret gekaufte Artikel	`Spree::Variant` mit je einem Wert pro Optionstyp²
Option oder Attribut	Größe, Farbe, Oberfläche	Optionstyp und Optionswert²
SKU und Barcode	Lagercode und GTIN oder EAN	SKU und Barcode der Variante²
Preis, auch je Währung	Was es kostet	`Spree::Price`, eine Zeile pro Währung³
Kategoriebaum	Navigation und Gruppierung	Taxonomie und Taxons⁴
Marke oder Lieferant	Wer es herstellt	Eine Taxonomie oder eine Produkteigenschaft⁴
Lagerbestand je Standort	Was wo verfügbar ist	Lagerposten und Lagerorte³
Material, Lieferzeit, Händlerpreis	Individuelle Geschäftsdaten	Produkteigenschaften oder ein eigenes Modell¹

Der Wert der Migration liegt darin, dass du die Form hier zurechtrückst. Auf einer gemieteten Plattform ist dein Katalog das, was Theme und Apps erlaubt haben. Auf deinem eigenen Store ist das Modell genau das, was das Geschäft braucht, was Teil der größeren Frage ist, wem deine Geschäftsdaten eigentlich gehören.

Den Katalog aus der alten Plattform herausholen

Jede gängige Plattform lässt dich den Katalog exportieren, über eine Massendatei, eine API oder beides. Jede hat einen ehrlichen Sonderfall, und ihn vorher zu kennen erspart später eine schlechte Woche.

Bei Shopify ist das erste Werkzeug die Produkt CSV. Sie trägt den Handle, den Titel, die Beschreibung, den Lieferanten, die Produktkategorie, den Typ, die Tags, die drei Optionsnamen und Werte, die SKU der Variante, das Gewicht, den Preis, die Lagermenge, die Barcodespalte, die Bild URL und, wichtig, den Alt Text des Bildes sowie den SEO Titel und die SEO Beschreibung.⁵ Metafelder werden ebenfalls exportiert, als Spalten im Muster product.metafields.namespace.key, aber es gibt eine scharfe Grenze, die man zweimal lesen sollte: Metafelder auf Variantenebene werden in der Produkt CSV gar nicht unterstützt.⁵ Für die, und für große Kataloge überhaupt, ist die Admin GraphQL API der eigentliche Weg. Ihre products Abfrage liefert Produkte, Varianten, Preise und Bestand, ist zur Bewältigung großer Kataloge paginiert und macht Metafelder zugänglich.⁶ Bei 8.000 SKUs mit individuellen Daten auf Variantenebene ist Lampenhof ein API Fall, kein Tabellenfall. Das ist dieselbe API erste Realität, die ich für headless und API first Solidus beschreibe.

Bei Magento, oder Adobe Commerce, zieht der Katalog über System, Datenübertragung, Import und Export als CSV um. Das Verhalten Hinzufügen und Aktualisieren ändert jedes Feld außer der SKU, die der stabile Schlüssel ist, und neue Kategorien und neue SKUs aus der Datei werden automatisch angelegt.⁷ Der ehrliche Haken dort ist das individuelle Attributset: Magento ist ein EAV Modell, ein Produkt kann also Dutzende Attribute tragen, und jedes braucht seine Spalte in der Datei und seine Entsprechung im neuen Store.

Bei WooCommerce gibt es den eingebauten Produkt CSV Import und Export seit Version 3.1.0.⁸ Er beherrscht den Kernkatalog und bildet individuelle Felder über eine Spalte mit dem Präfix meta: ab.⁸ Die Falle liegt beim Export: standardmäßig werden keine zusätzlichen Metadaten exportiert, du musst also die Option für individuelle Metadaten setzen oder die Spalten im Code ergänzen, sonst lässt du still die wichtigsten Felder zurück.⁸

Bilder und Alt Texte sind ebenfalls Katalogdaten

Tausende Produktbilder unterschätzt man leicht, weil sie wie ein Ordner voller Dateien aussehen. Das sind sie nicht. Jedes Bild gehört zu einem Produkt oder einer bestimmten Variante, jedes sollte einen Alt Text tragen, und die Dateien selbst müssen heruntergeladen und auf dem neuen Store neu gehostet werden, statt auf die Domain des alten Shops zu zeigen, die du gleich abschaltest.

Für Lampenhof sind das rund 30.000 Bilddateien über 8.000 Produkte. Sie zu holen ist eine skriptgesteuerte Aufgabe gegen den Export oder die API: für jedes Produkt und jede Variante das Bild abrufen, speichern und festhalten, zu welchem Produkt und welcher Variante es in welcher Reihenfolge gehört. Das Einzige, was Leute fallen lassen, ist der Alt Text. Alt Text ist keine Dekoration. Er ist das, was ein Screenreader vorliest und was Google liest, um das Bild zu verstehen, also zugleich ein Gut für Barrierefreiheit und für die Auffindbarkeit. Die Shopify CSV trägt ihn in einer eigenen Spalte, und die API macht ihn zugänglich, es gibt also keine Entschuldigung, ihn zu verlieren.⁵ Herunterladbare Produktdateien, die Anleitungen und digitalen Güter, ziehen genauso um: abrufen, neu hosten, neu anhängen.

Metafelder sind der still unterschätzte Teil einer Migration

Wenn eine Migration das Budget sprengt, ist meist das der Grund. Die Standardfelder sind an einem Nachmittag abgebildet. Die individuellen Daten nicht, weil in ihnen die Geschäftslogik steckt, die den Shop zu deinem macht, und oft gibt es davon weit mehr, als sich jemand erinnert.

Lampenhofs Metafelder sind ein gutes Beispiel. Das Material steuert einen Pflegehinweis. Die Lieferklasse entscheidet die Versandregel. Die Lieferzeit setzt das Versandversprechen auf der Produktseite. Der Händlerpreis speist eine getrennte Großhandelsansicht. Nichts davon steckt in einem Standardfeld, und wird es vergessen, sieht der neue Shop vollständig aus und verhält sich falsch. Die Arbeit hier ist also eine Abbildung Feld für Feld: jedes individuelle Feld des alten Shops in einer Spalte, was es im neuen bedeutet in der zweiten, sein Typ in der dritten und wo es im neuen Modell landet in der vierten. Manche werden zu Produkteigenschaften, manche zu echten Spalten auf einem eigenen Modell, manche stellen sich als tot heraus und werden bewusst verworfen. Diese Abbildung ist langweilig zu erstellen und sie ist das wertvollste Dokument im ganzen Projekt. Die Plattformen verstecken die Daten jeweils anders, Shopify in Metafeldern, Magento in individuellen Attributen, WooCommerce im Post Meta, aber die Disziplin ist identisch: auflisten, verstehen, abbilden, prüfen.

Der Teil, der die Rankings wirklich schützt: URLs und Weiterleitungen

Jetzt die Hälfte, nach der Inhaber wirklich fragen. Die ehrliche Schlagzeile lautet: Der meiste Rankingverlust bei einer Migration kommt nicht vom Umzug selbst. Er kommt von weggelassenen oder falschen Weiterleitungen. Mach das richtig, und die Rankings wandern mit; mach es falsch, und kein noch so schönes neues Design rettet sie.

Jedes Produkt, jede Kategorie, jede Inhaltsseite und jeder Artikel im alten Shop hat eine URL, und manche dieser URLs tragen jahrelang angesammelte Links und Rankingsignale. Googles eigene Anleitung für einen Umzug, der URLs ändert, ist konkret und wörtlich wert, befolgt zu werden: Bilde jede alte URL auf ihre neue ab, nutze serverseitige dauerhafte Weiterleitungen wie 301 oder 308, richte jede Weiterleitung direkt auf ihr endgültiges Ziel statt über eine Kette von Sprüngen, und behalte die Weiterleitungen so lange wie möglich, in der Regel mindestens ein Jahr.⁹ Behältst du dieselbe Domain, brauchst du das Change of Address Werkzeug in der Search Console nicht, das nur für den Umzug auf eine andere Domain oder Subdomain gedacht ist.⁹ Google lässt einen großen Shop auch in Abschnitten umziehen, um die Wirkung auf den Traffic zu testen, bevor der ganze Katalog festgezurrt wird.⁹

Das Ergebnis ist unglamourös und entscheidend: eine Tabelle mit einer benannten verantwortlichen Person. Eine Zeile für jede alte URL, die in den letzten zwölf Monaten einen Besuch oder einen Link bekommen hat, gezogen aus Search Console und Analytics. Spalte eins, die alte URL. Spalte zwei, die neue. Spalte drei, der Weiterleitungstyp, in fast jedem Fall 301. Spalte vier, getestet, ja oder nein. In Lampenhofs Größe sind das ein paar tausend Zeilen und zwei bis drei Tage sorgfältige Arbeit, und jede fehlende Zeile ist eine Seite, die nach dem Umzug einen 404 zurückgibt. Auf den Stores, die ich baue, liegen diese Weiterleitungen in einer Datenbanktabelle im Store mit einer Admin Oberfläche, nicht in einem Proxy oder einem DNS Dienst, den ein späteres Deployment vergessen kann, sie überleben also jede Änderung, und das eigene Team kann eine ergänzen, wenn es in der Search Console eine Streunerin entdeckt.

Titel, Canonicals, Sitemaps und strukturierte Daten

Weiterleitungen sind der große Hebel. Vier kleinere runden die Arbeit ab.

Seitentitel und Meta Beschreibungen sind Teil des Katalogs, nimm sie also mit den Produkten mit, statt sie neu zu erzeugen, denn viele wurden über Jahre von Hand abgestimmt. Canonical Tags sagen Google, welche URL die echte ist, wenn mehrere fast gleiche Inhalte zeigen, was in dem Moment passiert, in dem ein Produkt unter zwei Kategorien liegt oder ein Filter einen Parameter anhängt. Gib jeder Seite ein Canonical, das auf ihre eigene saubere URL zeigt, und richte Varianten oder gefilterte URLs auf diese Version, damit sich die Signale auf einer Seite bündeln.¹⁰ Die XML Sitemap ist der Weg, über den Google die neuen URLs schnell entdeckt: erzeuge eine frische aus dem neuen Katalog, reiche sie ein, und denk an die Grenzen, 50.000 URLs und 50 MB unkomprimiert je Datei, mit einem Sitemapindex, der auf mehrere Dateien zeigt, sobald du sie überschreitest.¹¹ Mit 8.000 Produkten plus Kategorien und Inhalten passt Lampenhof bequem in eine Datei.

Strukturierte Daten sind der vierte Hebel, und hier zahlt sich der eigene Store aus, weil du das Markup kontrollierst. Produkt Markup beschreibt Google das Produkt mit Name, Bild und Angebot, und auszuzeichnen, welche Artikel Varianten eines Elternprodukts sind, hilft Google, ein Sortiment zu verstehen statt eines Haufens Fastdubletten.¹² Innerhalb des Angebots sind der Preis und der dreibuchstabige Währungscode für ein Händlerlisting Pflicht, und die GTIN, die SKU und die Verfügbarkeit sind empfohlen und wert, angegeben zu werden, weil jede ein reicheres Ergebnis freischaltet.¹³ BreadcrumbList Markup, das die Liste, jedes Listenelement, seine Position und seinen Namen braucht, sagt Google, wo die Seite in deinem Kategoriebaum sitzt, und zeigt diese Spur im Ergebnis.¹⁴ Nichts davon ist ein Plugin, das du mietest. Auf deinem eigenen Store ist es Teil des Templates.

Kataloge in mehreren Sprachen und Währungen

Verkauft der Shop in mehr als einer Sprache oder Währung, müssen zwei weitere Dinge mit.

Lokalisierte Produktinhalte, die übersetzten Titel, Beschreibungen und Metadaten, ziehen als Teil des Katalogs um, ein Satz pro Sprache. Danach sagst du Google mit hreflang Anmerkungen, wie die Versionen zusammenhängen. Die Regeln sind streng und leicht falsch zu machen: Jede Version muss jede Version auflisten, sich selbst eingeschlossen, die Menge muss auf jeder Seite identisch sein, die Anmerkungen müssen wechselseitig sein, sonst werden sie ignoriert, und ein x-default Eintrag benennt die Rückfallseite für Sprachen, die du nicht abdeckst.¹⁵ Ist hreflang falsch, zeigt Google womöglich die deutsche Seite einer britischen Kundin, was wie ein schlechteres Ergebnis wirkt, obwohl der Katalog einwandfrei ist.

Preise je Währung sind die andere Hälfte. Auf einer gemieteten Plattform ist das oft eine App mit eigenen Regeln. In Solidus ist ein Preis ein Datensatz pro Währung auf der Variante, ein Katalog mit mehreren Währungen ist also nativ, und die Migration bringt die Preise jeder Währung einfach in ihre eigenen Zeilen.³

Der praktische Weg, Schritt für Schritt

Zusammengesetzt folgt der Umzug einem disziplinierten Weg, und die Reihenfolge zählt.

Die zwei Crawls sind das Sicherheitsnetz. Ein Crawl des Live Shops ist deine Liste dessen, was weiter funktionieren muss. Ein Crawl des Staging Stores, mit angewandter Weiterleitungstabelle, beweist, dass jede dieser URLs auf eine echte Seite auflöst, bevor eine Kundin sie sieht. Dieselben zwei Crawls nach dem Umzug, plus der Abdeckungsbericht der Search Console, fangen alles ab, was der Plan übersehen hat, solange noch Zeit ist, eine Weiterleitung zu ergänzen.

Beispiel: achttausend SKUs und viele Metafelder

Marlenes Katalog kommt über die Admin API heraus, weil die Händlerpreise und Lieferzeiten auf Variantenebene nicht in die CSV passen.⁵⁶ Das Skript erfasst 8.000 Produkte, rund 26.000 Varianten, etwa 30.000 Bilder mit ihren Alt Texten und elf Metafelder pro Produkt. Die Abbildung Feld für Feld dauert den besseren Teil einer Woche und mustert drei Metafelder aus, die sich als aufgegebene Experimente herausstellen.

Die Weiterleitungstabelle ist die stille Heldin. Aus Search Console und Analytics hat der alte Shop rund 9.400 URLs, die im letzten Jahr einen Besuch oder einen Link bekommen haben: Produktseiten auf /products/, Kategorieseiten auf /collections/, Artikel und eine Handvoll Kampagnenlandeseiten. Jede bekommt eine Zeile und eine 301 auf ihre neue Adresse.⁹ Lampenhof behält seine Domain, es gibt also keinen Change of Address Schritt.⁹ Vor dem Umzug findet ein Crawl des Staging Stores mit angewandter Tabelle 140 URLs, die weiter einen 404 geben, fast alle eingestellte Produkte, die über die Jahre still entfernt wurden und nun ins Leere zeigen. Marlene entscheidet Fall für Fall: Die meisten leiten auf die Elternkategorie, ein paar auf einen nahen Ersatz. Nach der Korrektur ist der Staging Crawl sauber, jede der 9.400 löst auf.

Am Umzugsvormittag zeigt die Domain auf den neuen Store, eine frische Sitemap geht an die Search Console, und ein Crawl danach bestätigt null unerwartete 404.¹¹ In den folgenden zwei Wochen beobachtet Marlene den Abdeckungsbericht, ergänzt vier Weiterleitungen für seltsame Alt URLs, die erst auftauchten, als echte Crawler kamen, und sieht die Rankings halten. An diesem Ergebnis war nichts Glück. Es waren die Tabelle und die zwei Crawls.

Der ehrliche Schluss

Der Katalog zieht fast immer um. Produkte, Varianten, Preise, Bilder, Bestand und Kategorien sind eine Abbildung, anspruchsvoll, aber risikoarm, und die individuellen Daten ziehen auch um, sobald du respektierst, wie viel davon es gibt. Der Umzug ist zugleich deine Gelegenheit, ein Modell zu reparieren, das dir ein Theme oder eine App aufgezwungen hat, damit der neue Store zum Geschäft passt statt umgekehrt. Wenn du die ganze Wirtschaftlichkeit dahinter abwägst, stehen die Gesamtkosten über fünf Jahre und der Systemvergleich neben diesem Artikel.

Rankings sind der Teil, den man fürchtet, und der Teil, der am meisten in deiner Hand liegt. Sie werden geschützt durch eine vollständige URL Tabelle, dauerhafte Weiterleitungen auf das endgültige Ziel, mitgenommene Titel und Canonicals, korrekte strukturierte Daten, eine frische Sitemap und einen Crawl davor und danach, der beweist, dass nichts fallen gelassen wurde. Mach diese Arbeit, und der Umzug ist für Google fast unsichtbar. Lass sie aus, und du verlierst Monate an Rankings an ein paar hundert 404 Seiten, was die traurigste Art ist, eine Migration zu bereuen, weil sie vollständig vermeidbar war.