Der Katalog wächst, die Saisonpreise stehen an, und der Produktmanager arbeitet am liebsten in Excel. Ein bekanntes Bild in deutschen Onlineshops, und ein strukturelles Problem für Magento-2-Betreiber: Adobe Commerce bzw. die Open-Source-Variante spricht nativ nur CSV. Wer Produktdaten als XLSX-Datei exportieren, komfortabel bearbeiten und wieder importieren will, stößt an die Grenzen des Systems. 2026 ist Excel im operativen Katalogmanagement weiterhin Standard, gerade bei Händlern ab einer Million Euro Jahresumsatz, deren Warenwirtschafts-Teams mit Tabellen denken.
Das Problem ist technisch trivial, operativ aber heikel. Excel formatiert EAN-Codes als Gleitkommazahlen, verwandelt Datumsangaben eigenmächtig und kodiert Umlaute je nach Speicherweg unterschiedlich. Ein CSV-Import nach Excel-Bearbeitung scheitert im Magento-Backend regelmäßig an genau diesen Stellen, mit Fehlermeldungen, die auf den ersten Blick nichts mit der Ursache zu tun haben.
Warum nativer CSV-Import in Magento 2 so oft scheitert
Der Import über System → Import → Products verlangt eine strikte Spaltenstruktur: sku als Pflichtfeld, Attribute als Spaltenköpfe, Kategoriepfade in einem eigenen Format. Magento akzeptiert ausschließlich CSV mit UTF-8-Kodierung und Komma als Trennzeichen. Excel speichert unter Windows aber gern mit Semikolon (deutsches Gebietsschema) und in der Legacy-Codepage, der Import bricht dann nach wenigen Zeilen ab oder legt korrupte Sonderzeichen in Produktnamen an.
Dazu kommt das Mengenproblem: Ab etwa 10.000 SKUs läuft der native Import über die Browser-Oberfläche in Timeouts. Wer saisonale Preisänderungen für einen fünfstelligen Artikelstamm einspielen will, wartet entweder geduldig, oder bricht den Lauf ab und hat danach einen halb aktualisierten Katalog.
Wie bekommen Händler Produkte sauber nach Excel, und zurück?
Die pragmatische Route 2026 sieht so aus: Export über die Magento-Oberfläche (System → Export) oder direkt aus der Datenbank als CSV, Öffnen der Datei in Excel über den Daten-Import-Assistenten mit expliziter UTF-8-Auswahl, nie per Doppelklick. Damit bleiben EANs, Preise und deutsche Umlaute intakt. Nach der Bearbeitung wird nicht als.xlsx, sondern als „CSV UTF-8 (durch Trennzeichen getrennt)“ gespeichert, dann per Backslash-Check auf Semikolons geprüft.
Wer diesen Weg häufig geht, spart sich die Handarbeit mit einer Extension. Etabliert sind etwa die Import/Export-Module von Firebear Studio und Amasty: Sie sprechen nativ XLSX und Google Sheets, erlauben Feld-Mapping auf Attribute und Cronjob-gesteuerte Läufe. Für Händler mit wiederkehrenden Lieferantendaten, etwa Preislisten von Herstellern im XLS-Format, ist das die sauberere Lösung als jede Excel-Vorlage mit hinterlegten Formatierungsregeln.
Große Kataloge: CLI statt Browser
Ab fünfstelligen Artikelmengen gehört der Import auf die Kommandozeile: bin/magento import:products oder, in der Open-Source-Community seit Jahren Standard, das kostenlose Tool Magerun2 für Katalogoperationen. CLI-Imports umgehen PHP-Limits und lassen sich in Deployment-Prozesse einhängen. Händler mit Staging-Umgebung importieren dort zuerst, prüfen Indizes und fahren den Katalog dann live.
Die Alternative für datengetriebene Teams: ein PIM vor Magento, Akeneo oder Pimcore, in dem Excel-Dateien ohnehin nur noch Lieferanten-Input sind. Wer 2026 mehrmals pro Quartal große Katalogänderungen per Tabelle einspielt, sollte genau diese Infrastrukturfrage stellen, statt zum dritten Mal dieselbe CSV-Formatierung zu reparieren.
Kurzfristig hilft eine interne Dokumentationsseite mit dem exakten Speicherpfad aus Excel und den drei häufigsten Fehlermeldungen aus dem Import-Report. Langfristig entscheidet sich: Bleibt Excel das Katalogwerkzeug, oder nur noch das Analysewerkzeug? Die zweite Antwort ist die richtige.