Produkt und Katalogdaten migrieren, ohne deine Rankings zu verlieren

Kurz gesagt

Niveau: Fortgeschritten

  • Der Katalog ist ein Datenmodell, keine Liste: Produkte, Varianten, Optionstypen, SKUs, Barcodes, Preise, Taxonomien und Bestand bilden sich sauber auf Solidus ab.
  • Standardfelder ziehen an einem Nachmittag um; unterschätzt wird eine Migration bei den Metafeldern und individuellen Attributen, also bilde sie Feld für Feld ab.
  • In dieser Größe exportierst du über die Admin API, nicht über eine CSV, weil individuelle Daten auf Variantenebene und tausende Bilder nicht in eine Tabelle passen.
  • Der größte Rankingverlust kommt von weggelassenen oder falschen Weiterleitungen, nicht vom Umzug, also bilde jede alte URL auf eine 301 zum endgültigen Ziel ab und behalte sie mindestens ein Jahr.
  • Nimm Titel und Canonicals mit, ergänze korrektes Produkt und BreadcrumbList Markup, reiche eine frische Sitemap ein und setze hreflang für Shops in mehreren Sprachen.
  • Ein Crawl vor und nach dem Umzug, gegen die Weiterleitungstabelle geprüft, beweist, dass nichts einen 404 zurückgibt.

Shops sorgen sich weniger um den Katalog als darum, was der Umzug mit ihren Rankings macht. In diesem Artikel behandle ich beides: wie Produkte, Varianten, Bilder, Bestand, Preise und die sperrigen individuellen Daten auf einen eigenen Solidus Store kommen, und dann die Disziplin, die Rankings bewahrt, die vollständige URL Tabelle, dauerhafte Weiterleitungen, Canonicals, strukturierte Daten und ein Crawl davor und danach. An einem erfundenen Wohnshop aus Leipzig mit 8.000 SKUs und vielen Metafeldern zeige ich, wo ein Katalogumzug schiefgeht und wie er für Google fast unsichtbar wird.

Die eigentliche Frage hinter einem Katalogumzug

Wenn ein Shop mich fragt, ob er auf einen eigenen Store wechseln kann, ist der Katalog selten das Problem. Produkte, Preise und Bilder wirken wie etwas, das sich kopieren lässt. Die eigentliche Frage, die Inhaberinnen und Inhaber nachts beschäftigt, ist die nächste: Kostet uns der Umzug unsere Rankings? Diese Sorge ist berechtigt. Ein Shop, der sich über Jahre seinen Platz in Google erarbeitet hat, kann ihn an einem einzigen Wochenende verlieren, wenn der Umzug nachlässig gemacht wird.

Deshalb beantworte ich beide Hälften ehrlich. Zunächst, wie der gesamte Katalog umzieht: Produkte, Varianten, Bilder, Kategorien, Lagerbestände, Preise und die sperrigen individuellen Daten, die fast immer vergessen werden. Dann der Teil, der deine Rankings tatsächlich 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, an welcher Stelle diese Disziplin gefragt ist. 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 greifbar bleibt, nutze ich durchgehend ein erfundenes Unternehmen. Lumenwerk (lumenwerk.example) ist ein Händler für Wohnen und Leuchten in Leipzig. Der Shop führt rund 8.000 SKUs: Lampen, Schirme, Möbel und Accessoires, die meisten in mehreren Größen, Farben und Oberflächen. Stefan leitet 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 mitführt, die kein Standardfeld abbildet. Niemand davon ist echt, und jede Zahl ist erfunden, damit ich jeden Schritt sauber durchgehen kann. Lumenwerk zieht auf einen maßgeschneiderten Store auf Solidus um, dem quelloffenen Rails Shopframework, auf dem ich baue, und den Stefan anschließend selbst besitzt.

Ein Katalog ist ein Datenmodell, keine Tabelle

Der erste Fehler besteht darin, sich den Katalog als eine große Produktliste vorzustellen. Er ist ein Geflecht zusammenhängender Dinge, und die Migration ist eine Abbildung zwischen zwei Datenmodellen. Es lohnt sich, jeden Teil zu benennen, bevor man irgendetwas verschiebt.

Ein Produkt ist das, was eine Kundin zu kaufen meint. Eine Variante ist die konkrete Ausführung, die sie wirklich 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 samt Maßen für den Versand. Produkte liegen in Kategorien, die meist einen Baum bilden: Beleuchtung, dann Tischlampen, dann Nachttischlampen. Hinzu 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 allem 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 darin liegt der Sinn eines eigenen Stores. Ein Produkt ist ein Spree::Product, und jedes Produkt hat eine Mastervariante sowie beliebig viele verkäufliche Varianten.1 Optionstypen und Optionswerte sind eigenständige Datensätze, einmal angelegt und an Produkte gehängt, und eine Variante wird durch je einen Wert pro Optionstyp definiert.2 Preise liegen in eigenen Datensätzen, einer pro Währung, sodass ein Katalog in mehreren Währungen nativ funktioniert statt angeflanscht zu sein.3 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.4 Der Bestand wird als Lagerposten gegen benannte Lagerorte geführt, zwei Lager sind also kein Plugin, sondern eine eingebaute Vorstellung.3 Freie Attribute werden zu Produkteigenschaften.1 Die folgende Tabelle zeigt die gesamte Abbildung auf einer Seite.

Wie der alte Shop es nenntWas es istWo es in Solidus landet
ProduktDas verkäufliche KonzeptSpree::Product mit Mastervariante1
Variante (Größe, Farbe)Der konkret gekaufte ArtikelSpree::Variant mit je einem Wert pro Optionstyp2
Option oder AttributGröße, Farbe, OberflächeOptionstyp und Optionswert2
SKU und BarcodeLagercode und GTIN oder EANSKU und Barcode der Variante2
Preis, auch je WährungWas es kostetSpree::Price, eine Zeile pro Währung3
KategoriebaumNavigation und GruppierungTaxonomie und Taxons4
Marke oder LieferantWer es herstelltEine Taxonomie oder eine Produkteigenschaft4
Lagerbestand je StandortWas wo verfügbar istLagerposten und Lagerorte3
Material, Lieferzeit, HändlerpreisIndividuelle GeschäftsdatenProdukteigenschaften oder ein eigenes Modell1

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

Den Katalog aus der alten Plattform herausholen

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

Bei Shopify ist das erste Werkzeug die Produkt CSV. Sie enthält 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.5 Metafelder werden ebenfalls exportiert, als Spalten im Muster product.metafields.namespace.key, doch es gibt eine klare Grenze, die man zweimal lesen sollte: Metafelder auf Variantenebene werden in der Produkt CSV überhaupt nicht unterstützt.5 Für sie, und für große Kataloge generell, ist die Admin GraphQL API der eigentliche Weg. Ihre products Abfrage liefert Produkte, Varianten, Preise und Bestand, ist für große Kataloge paginiert und macht Metafelder zugänglich.6 Bei 8.000 SKUs mit individuellen Daten auf Variantenebene ist Lumenwerk ein API Fall und kein Tabellenfall. Das ist dieselbe API erste Realität, die ich für headless und API first Solidus beschreibe.

Bei Magento, beziehungsweise 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.7 Der ehrliche Haken ist dort 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.8 Er beherrscht den Kernkatalog und bildet individuelle Felder über eine Spalte mit dem Präfix meta: ab.8 Die Falle sitzt beim Export: standardmäßig werden keine zusätzlichen Metadaten exportiert, du musst also die Option für individuelle Metadaten aktivieren oder die Spalten im Code ergänzen, sonst lässt du still die wichtigsten Felder zurück.8

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 weiter auf die Domain des alten Shops zu zeigen, die du gleich abschaltest.

Für Lumenwerk 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 regelmäßig verloren geht, 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 führt ihn in einer eigenen Spalte, und die API macht ihn zugänglich, es gibt also keinen Grund, ihn zu verlieren.5 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, denn in ihnen steckt die Geschäftslogik, die den Shop zu deinem macht, und oft gibt es davon weit mehr, als sich jemand erinnert.

Lumenwerks 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 übersehen, sieht der neue Shop vollständig aus und verhält sich falsch. Die Arbeit ist hier also eine Abbildung Feld für Feld: jedes individuelle Feld des alten Shops in einer Spalte, seine Bedeutung im neuen in der zweiten, sein Typ in der dritten und sein Ziel im neuen Modell in der vierten. Manche werden zu Produkteigenschaften, manche zu echten Spalten auf einem eigenen Modell, manche erweisen sich als tot und werden bewusst verworfen. Diese Abbildung ist mühsam zu erstellen und zugleich das wertvollste Dokument im ganzen Projekt. Die Plattformen verstecken die Daten jeweils anders, Shopify in Metafeldern, Magento in individuellen Attributen, WooCommerce im Post Meta, doch die Disziplin ist dieselbe: 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 größte Rankingverlust bei einer Migration stammt nicht vom Umzug selbst. Er stammt von weggelassenen oder falschen Weiterleitungen. Machst du es richtig, wandern die Rankings mit; machst du es falsch, rettet kein noch so schönes neues Design sie.

Jedes Produkt, jede Kategorie, jede Inhaltsseite und jeder Artikel im alten Shop hat eine URL, und manche dieser URLs tragen über Jahre angesammelte Links und Rankingsignale. Googles eigene Anleitung für einen Umzug mit URL Änderungen ist konkret und Wort für Wort 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.9 Behältst du dieselbe Domain, brauchst du das Change of Address Werkzeug in der Search Console nicht, das nur für den Wechsel auf eine andere Domain oder Subdomain gedacht ist.9 Google lässt einen großen Shop auch abschnittsweise umziehen, um die Wirkung auf den Traffic zu prüfen, bevor der ganze Katalog festgelegt wird.9

Das Ergebnis ist schmucklos 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 Lumenwerks 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, sobald 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 gehören zum Katalog, 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 nahezu 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.10 Die XML Sitemap ist der Weg, über den Google die neuen URLs rasch 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.11 Mit 8.000 Produkten plus Kategorien und Inhalten passt Lumenwerk 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.12 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.13 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.14 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.15 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 in mehreren Währungen ist also nativ, und die Migration bringt die Preise jeder Währung schlicht in ihre eigenen Zeilen.3

Der praktische Weg, Schritt für Schritt

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

Zum Vergrößern antippen: Vollbild, frei verschiebbar

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

Stefans Katalog kommt über die Admin API heraus, weil die Händlerpreise und Lieferzeiten auf Variantenebene nicht in die CSV passen.56 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 erweisen.

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.9 Lumenwerk behält seine Domain, es gibt also keinen Change of Address Schritt.9 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. Stefan entscheidet Fall für Fall: Die meisten leiten auf die Elternkategorie, einige 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.11 In den folgenden zwei Wochen beobachtet Stefan 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 ebenfalls um, sobald du anerkennst, 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 und nicht umgekehrt. Wenn du die gesamte 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 zugleich der Teil, der am stärksten 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.

Sorgst du dich, dass ein Umzug deine Rankings kostet? Bring deinen Shop in einen kostenlosen Workshop mit, dann bauen wir gemeinsam die Weiterleitungstabelle und die Katalogabbildung, und ich zeige dir den Crawl davor und danach, der beweist, dass nichts kaputtgeht. Die ersten zwei Wochen Arbeit gehen auf meine Rechnung.

Quellen

  1. 1.

    Solidus, core/app/models/spree/product.rb (Produkt, Mastervariante, Produkteigenschaften), solidusio/solidus auf GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/product.rb

  2. 2.

    Solidus, core/app/models/spree/variant.rb und option_type.rb (Varianten, Optionstypen und Werte, SKU, Barcode), solidusio/solidus auf GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/variant.rb

  3. 3.

    Solidus, core/app/models/spree/price.rb und stock_location.rb (Preise je Währung, Lagerposten und Lagerorte), solidusio/solidus auf GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/price.rb

  4. 4.

    Solidus, core/app/models/spree/taxonomy.rb und taxon.rb (Taxonomien und Taxons, Klassifikation), solidusio/solidus auf GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/taxonomy.rb

  5. 5.

    Shopify, Using a CSV file to import and export products (Spalten, Barcodes, Alt Text, Metafeldspalten, Metafelder auf Variantenebene nicht unterstützt), Shopify Help Centre, 2026, https://help.shopify.com/en/manual/products/import-export/using-csv

  6. 6.

    Shopify, products query, Admin GraphQL API reference (Pagination, Varianten, Preise, Bestand, Metafelder), Shopify.dev, 2026, https://shopify.dev/docs/api/admin-graphql/latest/queries/products

  7. 7.

    Adobe Commerce, Import data (System, Datenübertragung, Import; Hinzufügen und Aktualisieren ändert alle Felder außer SKU; Kategorien und SKUs werden automatisch angelegt), Adobe Experience League, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/import/data-import

  8. 8.

    WooCommerce, Product CSV Importer and Exporter (eingebaut seit 3.1.0, meta: Spalten, standardmäßig keine zusätzlichen Metadaten exportiert), woocommerce/woocommerce wiki auf GitHub, 2026, https://github.com/woocommerce/woocommerce/wiki/Product-CSV-Importer-&-Exporter

  9. 9.

    Google Search Central, Site moves with URL changes, Google, 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

  10. 10.

    Google Search Central, How to specify a canonical URL with rel="canonical" and other methods, Google, 2026, https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

  11. 11.

    Google Search Central, Build and submit a sitemap (Grenzen 50.000 URLs und 50 MB, Sitemapindex), Google, 2026, https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

  12. 12.

    Google Search Central, Intro to how structured data markup works und Product structured data, Google, 2026, https://developers.google.com/search/docs/appearance/structured-data/product

  13. 13.

    Google Search Central, Merchant listing (Product) structured data, erforderliche und empfohlene Eigenschaften, Google, 2026, https://developers.google.com/search/docs/appearance/structured-data/merchant-listing

  14. 14.

    Google Search Central, Breadcrumb (BreadcrumbList) structured data, Google, 2026, https://developers.google.com/search/docs/appearance/structured-data/breadcrumb

  15. 15.

    Google Search Central, Tell Google about localized versions of your page (hreflang), Google, 2026, https://developers.google.com/search/docs/specialty/international/localized-versions