Analyse Shop-Management

Magento 2 Reviews importieren und exportieren: Der Workflow-Guide für Adobe Commerce & Open Source

30 Prozent mehr Conversion durch sichtbare Produktbewertungen — diese Zahl kursiert seit Jahren in E-Commerce-Reports, und sie stimmt in etwa. Was die Reports nicht erwähnen: Magento 2 bietet von Haus aus keinerlei Möglichkeit, Reviews im Bulk zu importieren oder zu exportieren. Wer einen Shop migriert, eine Staging-Umgebung synchronisieren will oder schlicht ein Backup seiner Bewertungen braucht, steht vor einem leeren Admin-Panel. Für ein System, das im Enterprise-Segment mit Adobe Commerce vierstellige Lizenzkosten pro Monat aufruft, ist das eine bemerkenswerte Lücke.

Diese Lücke kostet deutsche Händler bares Geld. Bewertungen sind im DACH-Markt ohnehin ein sensibles Gut — die Käufer hier gelten als skeptischer als US-Konsumenten, ein frisch migrierter Shop mit null Reviews wirkt wie ein Laden ohne Kundschaft. Gleichzeitig schärft die EU-Kommission mit der Omnibus-Richtlinie die Regeln für Bewertungsauthentizität. Wer Reviews bewegt, muss sie sauber bewegen: mit Timestamp, Verifizierungsstatus und korrekter Kundenzuordnung. Dieser Guide zeigt, wie der Workflow tatsächlich funktioniert — und wo er bricht.

Warum kann Magento 2 Reviews nicht nativ importieren?

Die Antwort liegt im Datenmodell. Produkte, Kategorien und Kunden sind in Magento 2 als flache Entities über das Import-Framework abbildbar. Reviews sind es nicht. Eine Bewertung hängt an mindestens vier Tabellen: review, review_detail, review_store und review_entity_summary. Dazu kommen Verknüpfungen zum Kundenkonto, zum Produkt und zur Store-View. Ein einfacher CSV-Import, wie ihn der Admin für Produkte bietet, würde diese Beziehungen nicht auflösen können — Adobe hat das Feature deshalb schlicht nie gebaut.

Exportiert werden können Reviews ebenfalls nicht. Die Daten sitzen in der Datenbank, und ohne Zusatztool kommt man nur über direkte SQL-Abfragen an sie heran. Für Agenturen, die Kundenprojekte zwischen Staging und Live synchronisieren, heißt das: Jedes Deployment ohne Review-Strategie ist ein Risiko. Bewertungen, die Kunden auf der Live-Instanz abgeben, während auf Staging weitergearbeitet wird, gehen beim nächsten Datenbank-Sync verloren — es sei denn, man hat einen Export-Pfad.

Kernsatz: Magento 2 speichert Reviews über vier verknüpfte Tabellen verteilt — genau deshalb gibt es keinen nativen Bulk-Import, und genau deshalb scheitern naive SQL-Skripte regelmäßig.

Welche Wege gibt es für den Bulk-Import?

Praktisch bewährt haben sich drei Ansätze, die sich in Aufwand, Risiko und Skalierbarkeit deutlich unterscheiden.

Der erste Weg führt über Erweiterungen aus dem Adobe Commerce Marketplace. Module wie die Import/Export-Extensions etablierter Anbieter — etwa von Mageplaza, BSS Commerce oder Amasty — bilden die Review-Tabellen auf ein CSV- oder XML-Schema ab. Der Händler füllt Spalten für Produkt-SKU, Kunden-E-Mail, Titel, Detailtext, Rating und Datum, das Modul übernimmt die Entity-Verknüpfung. Kostenpunkt: je nach Anbieter zwischen 100 und 300 Euro, für Adobe-Commerce-Editionen oft mehr. Für die meisten DACH-Händler mit Shops im Mittelstand ist das der pragmatischste Weg, weil er ohne Entwicklungszeit auskommt und Updates von Magento-Versionen meist abgefedert werden.

Wer es individueller braucht, baut auf die REST-API. Magento 2 stellt Endpunkte zum Anlegen von Reviews bereit — mit einem Skript lassen sich tausende Bewertungen aus einem Altsystem oder einer Mitbewerber-Plattform einspielen. Der Vorteil: volle Kontrolle über Mapping und Validierung, keine Abhängigkeit von Drittanbieter-Modulen. Der Nachteil: Die API ist langsam. Bei fünfstelligen Review-Mengen dauert ein Durchlauf Stunden, und Rate-Limits in produktiven Adobe-Commerce-Cloud-Umgebungen erzwingen Batch-Logik mit Wiederanlauf. Für eine einmalige Migration akzeptabel, als wiederkehrender Sync ungeeignet.

Der dritte Weg ist der direkte Datenbank-Import. Er ist der schnellste — und der gefährlichste. Wer die vier Review-Tabellen direkt befüllt, muss die Summary-Tabelle anschließend neu aggregieren, sonst zeigen Produktseiten veraltete Durchschnittsratings. Hinzu kommen Store-View-Zuordnungen: In Multi-Store-Setups, die im deutschsprachigen Raum wegen der DACH-Ausrichtung häufig sind — deutsch für Deutschland, deutsch für Österreich, deutsch für die Schweiz — muss jede Bewertung der richtigen Store-View zugeordnet werden, sonst tauchen Reviews im falschen Shop auf oder gar nicht. Dieser Weg gehört in die Hände von Entwicklern mit Magento-Erfahrung, nicht in ein Wochenendprojekt.

Wie funktioniert der Export — und wozu braucht man ihn überhaupt?

Der Export ist die unterschätzte Seite des Workflows. Drei Szenarien machen ihn Pflicht: Migrationen auf ein neues Shopsystem, die Synchronisation zwischen Staging und Live sowie die Analyse der Bewertungsdaten außerhalb von Magento.

Gerade das dritte Szenario gewinnt an Bedeutung. Review-Texte sind ein Rohstoff: Sie enthalten die Sprache der Kunden, ungefiltert. Händler, die ihre Review-Datenbank exportieren, können Sentiment-Analysen fahren, Produktmängel clusternd erkennen oder Textbausteine für Produktdetailseiten ableiten. Ein mittelständischer Möbelhändler aus Nordrhein-Westfalen hat genau das 2025 gemacht — aus 4.000 exportierten Bewertungen extrahierte das Team die zwanzig häufigsten Reklamationsgründe und baute sie als FAQ direkt in die Produkttemplates ein. Die Retourenquote der betroffenen Kategorien sank messbar.

Technisch läuft der Export über dieselben Erweiterungen wie der Import oder über einen maßgeschneiderten Datenbank-Dump. Wichtig ist das Format: CSV mit klar definierten Spalten für Entity-ID, SKU, Nickname, Titel, Detail, Rating, Status, Erstellungsdatum und Store-ID. Wer hier schludert und etwa das Datum im US-Format exportiert, zahlt beim Re-Import mit chronologisch kaputten Review-Listen — Kunden sortieren Bewertungen nach Datum, und ein Shop, dessen neueste Bewertung angeblich aus dem Jahr 2019 stammt, verliert Vertrauen auf der Stelle.

  • Migration: Vollständiger Export vor Systemwechsel, inklusive Review-Status (approved, pending, not approved).
  • Staging-Sync: Delta-Export der Live-Reviews vor jedem Deployment, damit keine Kundenstimmen verloren gehen.
  • Analyse: Regelmäßiger Export als Basis für Sentiment-Auswertung und Produkt-Feedback-Loops.

Was ist bei DSGVO und Omnibus-Richtlinie zu beachten?

Hier wird es für deutsche Händler juristisch relevant. Bewertungen enthalten personenbezogene Daten — mindestens den Nickname, häufig die Kunden-ID, manchmal im Text selbst volle Namen. Ein ungeschützter CSV-Export, der per E-Mail zwischen Agentur und Händler wandert, ist ein DSGVO-Problem. Der Export gehört verschlüsselt auf einen Server in der EU, mit Auftragsverarbeitungsvertrag, wenn ein Dienstleister ins Spiel kommt.

Die Omnibus-Richtlinie, seit 2022 auch im deutschen Wettbewerbsrecht verankert, verlangt zudem Transparenz darüber, ob und wie ein Shop prüft, dass Bewertungen von echten Käufern stammen. Wer Reviews aus einem Altsystem importiert, sollte den Verifizierungsstatus mitnehmen — Magento kennt dafür kein natives Feld, gute Import-Module mappen es über die Kunden-Verknüpfung oder ein Custom-Attribut. Importierte Massen-Bewertungen ohne Nachvollziehbarkeit sind nicht nur ein Vertrauensproblem, sie sind abmahnfähig. Die Wettbewerbszentrale verfolgt gefälschte und nicht verifizierbare Bewertungen aktiv, und Bußgelder auf EU-Ebene können bis zu vier Prozent des Jahresumsatzes betragen.

Wer Reviews migriert wie ein beliebiges Text-Asset, migriert auch deren rechtliches Risiko. Verifizierungsstatus und Herkunft gehören in jede Import-Datei — nicht als Nice-to-have, sondern als Pflichtspalte.

Wie wird aus importierten Reviews ein Conversion-Hebel?

Die eigentliche Frage ist nicht, wie Reviews ins System kommen, sondern was danach passiert. Magento 2 aggregiert Ratings in der review_entity_summary-Tabelle — diese Daten lassen sich als strukturierte Daten im Schema.org-Format ausspielen. Nur dann zeigt Google die Sterne direkt in den Suchergebnissen. Viele deutsche Magento-Shops verschenken genau das: Die Bewertungen existieren, aber das Markup fehlt oder ist fehlerhaft. Ein Check mit dem Rich-Results-Test dauert zwei Minuten und entscheidet über sichtbare Klickraten-Vorteile in der organischen Suche.

Zweiter Punkt: Review-Frische. Algorithmen und Kunden honorieren aktuelle Bewertungen stärker. Ein Shop mit 500 importierten Reviews aus 2021 und keiner einzigen aus 2026 signalisiert Stillstand. Der Import historischer Daten ist also nur der Sockel — darauf muss ein Prozess stehen, der neue Bewertungen generiert, etwa über automatisierte Post-Purchase-Mails sieben bis zehn Tage nach Lieferung. In Magento Open Source braucht es dafür ein Modul oder eine Anbindung an Tools wie Trusted Shops, die im DACH-Raum ohnehin der De-facto-Standard für verifizierte Bewertungen sind.

Kernsatz: Der Import ist Infrastruktur, kein Ergebnis. Wirkung entfalten Reviews erst durch Schema.org-Markup, laufende Neugenerierung und sichtbare Verifizierung.

Dritter Hebel: die Bewertungsdichte pro Produkt. Zehn Reviews auf ein Produkt konzentriert wirken stärker als hundert Reviews auf zehn Produkte verteilt. Beim Import aus Altsystemen lohnt deshalb eine Kuration — Reviews für eingestellte Artikel und Ladenhüter können wegfallen, die Top-Seller sollten die dichteste Bewertungslage bekommen. Das ist redaktionelle Arbeit, keine technische, und sie wird in kaum einem Migrationsprojekt eingeplant.

Die typischen Fehler — und wie man sie vermeidet

Über die Jahre sammeln sich bei Magento-Migrationen immer dieselben Bruchstellen. Der häufigste Fehler: fehlende Reindexierung nach dem Import. Magento cached die Review-Aggregation aggressiv; ohne bin/magento indexer:reindex und Cache-Flush zeigt der Shop die alten Durchschnittsratings oder gar keine. Der zweite Klassiker sind Encoding-Probleme. Deutsche Bewertungen enthalten Umlaute, und ein CSV, das nicht als UTF-8 ohne BOM abgespeichert wurde, produziert im Frontend Zeichensalat — aus „Qualität“ wird „Qualität“. Das passiert peinlicherweise auch in Enterprise-Projekten.

Weniger offensichtlich ist das Duplikat-Problem. Wer Importe mehrfach anstößt — etwa nach einem abgebrochenen Lauf — erzeugt doppelte Bewertungen, die im Frontend wie gekaufte Masse wirken. Saubere Import-Prozesse arbeiten deshalb mit einer externen ID aus dem Quellsystem und prüfen vor dem Anlegen, ob die Bewertung bereits existiert. Und schließlich: Die Zuordnung von Gast-Bewertungen. Reviews von Kunden ohne Konto hängen in Magento nicht an einer Customer-Entity. Wer das beim Import ignoriert, verliert entweder diese Bewertungen oder erzeugt verwaiste Datensätze.

Magento wird Reviews auch in absehbarer Zukunft nicht nativ importierbar machen — Adobe investiert seine Entwicklungsressourcen erkennbar in die Cloud- und SaaS-Schienen. Für Händler heißt das: Der Review-Workflow bleibt Eigenverantwortung. Wer ihn einmal sauber aufsetzt — Export-Routine, validiertes CSV-Schema, Verifizierungsstatus, Reindex-Automatismus —, hat eine Infrastruktur, die jede Migration, jedes Redesign und jeden Plattformwechsel übersteht. Wer ihn improvisiert, wird das bei der nächsten Migration spüren. Die Bewertungen sind das Gedächtnis des Shops; man sollte es nicht dem Zufall überlassen.