Wer in Shopware 6 auf „Export“ klickt, bekommt eine CSV-Datei. Das dauert drei Sekunden und fühlt sich nach Kontrolle an. Bis der Händler 40.000 Produkte exportieren will, der Prozess nach 30 Sekunden mit einem Timeout abbricht und die Datei mit 12.000 Zeilen endet. Genau hier beginnt das eigentliche Problem des Standard-Exports — nicht bei der Funktion, sondern bei der Skalierung.
Der built-in Export in Shopware 6 ist ein Werkzeug für Administratoren, die gelegentlich Produktdaten sichern oder eine Kundenliste für eine Newsletter-Kampagne ziehen. Für den laufenden Betrieb eines mittelgroßen Shops mit mehreren Verkaufskanälen, Marktplatz-Anbindung und PIM-Sync ist er strukturell zu schwach. Das ist 2026 keine Meinung, sondern dokumentiertes Verhalten: Die Export-Queue arbeitet synchron über PHP-Prozesse, das Memory-Limit greift bei großen Datenmengen, und die verfügbaren Felder decken das tatsächliche Datenmodell nur teilweise ab.
Was der Standard-Export in Shopware 6 tatsächlich leistet
Shopware 6 exportiert CSV über den Admin-Bereich unter Einstellungen → Import/Export. Der Prozess läuft über sogenannte Profile: Der Händler wählt ein Datenobjekt — Produkte, Bestellungen, Kunden, Kategorien, Medien — und legt fest, welche Felder exportiert werden. Diese Profile lassen sich speichern und wiederverwenden, was für wiederkehrende Aufgaben wie monatliche Bestellreports praktisch ist.
Der entscheidende Vorteil: Der Export greift direkt auf die Datenbank zu, ohne Umweg über die Store-API. Das macht ihn schnell bei kleinen Datenmengen und unabhängig von API-Rate-Limits. Für einen Testshop mit 500 Artikeln ist das die sauberste Lösung, die Shopware bietet.
Die Grenzen zeigen sich erst im Detail. Der Export kennt keine inkrementelle Logik — es gibt keinen „nur geänderte Datensätze seit letztem Export“-Modus. Wer täglich 80.000 Produkte an einen Marktplatz überträgt, exportiert jedes Mal den vollständigen Katalog. Bei Variantenprodukten mit mehreren hundert Varianten pro Hauptartikel potenziert sich das. Ein Hersteller von technischem Zubehör mit 2.000 Hauptartikeln und durchschnittlich 60 Varianten landet schnell bei 120.000 Zeilen pro Export.
Warum brechen große Exporte in Shopware 6 ab?
Die häufigste Fehlerquelle ist das PHP-Memory-Limit. Shopware verarbeitet den Export im Arbeitsspeicher, bevor die CSV geschrieben wird. Bei 50.000 Produkten mit allen Feldern — inklusive Custom Fields, Übersetzungen und Variantenrelationen — sind 256 MB schnell erreicht. Der Prozess stirbt mit einem 500er-Fehler, die Datei bleibt unvollständig.
Der zweite Engpass ist die Ausführungszeit. Viele Hosting-Setups — gerade Shared Hosting oder schlecht konfigurierte Managed-Server — limitieren PHP-Skripte auf 30 oder 60 Sekunden. Das reicht für 10.000 bis 20.000 Datensätze. Alles darüber erfordert serverseitige Anpassungen: max_execution_time und memory_limit müssen erhöht werden, was auf Plesk- und cPanel-Umgebungen oft nur über den Hoster läuft.
Der dritte Punkt ist weniger technisch, aber gravierender: Der Standard-Export kennt keine Verknüpfung zwischen Datenobjekten in einer Datei. Wer Produkte mit ihren Kategoriepfaden, Herstellern und Eigenschaftswerten in einem einzigen Export braucht, muss mehrere Exporte fahren und sie extern zusammenführen — in Excel, in einem Skript, in einem ETL-Tool. Für einen Shop, der zehnmal pro Woche verschiedene Datenziele bedient, ist das ein latenter Fehlerherd.
- Bestellungen lassen sich nur als Rohdaten exportieren — Positionen, Adressen und Zahlungsstatus landen in getrennten Profilen, nicht in einem konsistenten Datensatz.
- Übersetzungen für mehrere Verkaufskanäle werden nicht automatisch mitgeführt; mehrsprachige Shops brauchen separate Exporte pro Sprache.
- Ein zeitgesteuerter Export ist nativ nicht vorgesehen. Shopware führt Import/Export-Profile nur manuell oder über einen eigenen Cron-Wrapper aus.
Wie lösen Händler das Problem 2026 in der Praxis?
Drei Wege dominieren. Der erste: serverseitiges Tuning. Hoster mit Shopware-spezifischem Setup — etwa die auf Shopware spezialisierten Managed-Hosting-Anbieter im DACH-Raum — erlauben Memory-Limits von 1 GB und Ausführungszeiten von mehreren Minuten. Damit laufen auch 100.000-Zeilen-Exporte stabil durch. Die Kosten liegen im höheren Tarif, nicht in zusätzlicher Software.
Der zweite Weg führt über Plugins aus dem Shopware Store. Anbieter wie Shopware selbst, Pickware oder Drittanbieter wie Datatrics bieten Export-Erweiterungen, die asynchron arbeiten: Der Export läuft als Background-Job in der Message Queue, das Ergebnis landet als Download bereit. Das umgeht Timeouts strukturell. Manche Plugins bieten zusätzlich inkrementelle Exporte über Zeitstempel-Filter und vorgefertigte Profile für Marktplätze wie Amazon, eBay oder OTTO.
Der dritte Weg ist der professionelle: eine echte Middleware. Tools wie n8n, Make oder etablierte PIM- und ETL-Systeme wie Akeneo oder Celigo greifen nicht auf den Admin-Export zu, sondern auf die Shopware Store-API oder Admin-API. Über die API lassen sich gefilterte, paginierte und inkrementelle Abfragen fahren — der Export wird zum programmatischen Datenstrom. Das ist der einzige Ansatz, der bei mehreren Zielsystemen mit unterschiedlichen Datenanforderungen skaliert.
Wer Produktdaten in Shopware 6 als CSV exportiert, um sie an einen Marktplatz zu übergeben, baut 2026 eine Lösung, die beim ersten Katalogwachstum bricht. Die API ist nicht die kompliziertere Wahl — sie ist die einzige, die hält.
Welche Daten sollte ein Shopware-Export überhaupt abdecken?
Die Frage klingt banal, ist aber der Punkt, an dem die meisten Export-Setups scheitern. Ein Export ist nur so gut wie das Datenmodell, das er abbildet. Für Produkte bedeutet das: Stammdaten, Varianten, Preise pro Verkaufskanal, Lagerbestände, Eigenschaften, Kategorien, Hersteller, Medien-URLs, Custom Fields und SEO-Metadaten. Fehlt eines dieser Felder im Export, bricht die Weiterverarbeitung — meist erst im Zielsystem, wo der Fehler schwer zu finden ist.
Für Bestellungen gilt Ähnliches. Ein brauchbarer Bestellexport enthält Kopf- und Positionsdaten, Kundenreferenz, Rechnungs- und Lieferadresse, Zahlungsart, Versandart, Steueraufschlüsselung und Status-Historie. Der Standard-Export in Shopware 6 liefert diese Daten, aber fragmentiert über mehrere Profile und ohne Verknüpfung. Wer daraus einen konsistenten Report bauen will, exportiert viermal und joint manuell.
Ein pragmatischer Mittelweg für kleinere Shops: Der Standard-Export bleibt für Backups und Ad-hoc-Abfragen. Für alles, was regelmäßig und automatisiert läuft — Marktplatz-Sync, ERP-Anbindung, Reporting — wird ein einziges Export-Profil pro Zielsystem definiert, das über die API oder ein Plugin bedient wird. Diese Trennung verhindert, dass das Backup-Werkzeug zum Integrations-Werkzeug umfunktioniert wird.
Ein letzter Punkt, der oft übersehen wird: Der Export ist nur die halbe Miete. Wer Produktdaten aus Shopware 6 exportiert, muss auch das Zielsystem kennen — Feldnamen, Pflichtfelder, Encoding, Trennzeichen, Datumsformate. Die häufigste Ursache für fehlgeschlagene Marktplatz-Importe ist nicht der Shopware-Export, sondern die Formatinkompatibilität beim Empfänger. Ein Testlauf mit 100 Datensätzen vor jedem Voll-Export spart Stunden.
Der Standard-Export in Shopware 6 wird 2026 nicht verschwinden — und das ist gut so. Er ist ein solides Werkzeug für seinen Zweck. Die Frage ist nur, ob der eigene Shop noch zu diesem Zweck passt. Wer beim nächsten Export wieder 40 Minuten wartet und danach 12.000 Zeilen manuell nachbearbeitet, hat die Antwort bereits.