Wer einen Magento-2-Shop migriert, exportiert Produkte, Kunden und Bestellungen mit Bordmitteln. Bewertungen bleiben liegen. Adobe Commerce und Magento Open Source kennen keinen nativen Import- oder Export-Mechanismus für Product Reviews — ein Leck, das beim Plattformwechsel oder Staging-Sync richtig teuer werden kann.
Dabei sind Reviews keine Dekoration. Sie sind Conversion-Instrument, SEO-Asset und Vertrauenssignal in einem. Spiegeleffekte zeigen die Erfahrung vieler deutscher Händler: Produkte mit zehn oder mehr Bewertungen konvertieren messbar besser als identische Produkte ohne. Lässt man diese Historie bei einer Migration verfallen, kauft man sich faktisch einen kalten Neu-Start — mitten im Betrieb.
Warum sammelt Magento 2 Reviews zwar ein, gibt sie aber nicht wieder her?
Die Antwort ist unbequem: Reviews waren im Magento-Universum schon immer ein Bürger zweiter Klasse. Das native Import/Export-Framework — ob über das Admin-Panel oder die erweiterten bin/magento import:run-CLI-Routinen — deckt Produkte, Kunden, Preise und Stock ab. Die Review-Tabellen (review, review_detail, rating_option_vote) sind in keinem dieser Pfade vorgesehen.
Das ist kein Versehen im Sinne eines Bugs, sondern eine Produktentscheidung: Adobe setzt offenkundig darauf, dass Reviews aus Drittsystemen kommen — Yotpo, Trustpilot, Bazaarvoice. Wer sich in das Adobe-Ökosystem einkauft, nutzt ohnehin ein Review-Tool mit eigener API. Wer aber jahrelang die nativen Reviews gesammelt hat — was gerade im deutschen Mittelstand die Regel ist —, steht bei jeder Migration vor demselben Problem.
Konkret relevant wird das in vier Szenarien: Wechsel von Magento 1 oder einem Fremdsystem auf Magento 2, Umzug von Open Source auf Adobe Commerce, Synchronisation zwischen Staging- und Live-Instanz, und das Konsolidieren mehrerer Shops nach einer Übernahme. Gerade Letzteres häuft sich im DACH-Markt, wo Handelshäuser regelmäßig Shops zusammenlegen.
Warum sind Product Reviews ein SEO- und Conversion-Asset, das man nicht opfern sollte?
Rechnen wir es nüchtern durch. Native Reviews liefern drei Dinge, die sich nur schwer ersetzen lassen:
Erstens: Unique Content. Jede Bewertung ist nutzergenerierter Text auf der Produktdetailseite — mit genau den Formulierungen, nach denen Kunden suchen. Ein Duschvorleger, den Käufer als „rutschfest auch bei Seifenwasser“ beschreiben, rankt für Longtail-Queries, die kein SEO-Redakteur je auf dem Schirm hatte.
Zweitens: Rich Snippets. Korrekt ausgezeichnete Aggregate-Ratings erzeugen Sterne in den Suchergebnissen. Die Klickrate-Unterschiede zwischen Snippets mit und ohne Sterne liegen nach den meisten Messungen im zweistelligen Prozentbereich. Wer Reviews verliert, verliert die Sterne — und mit ihnen CTR, bevor der erste Besucher überhaupt auf der Seite war.
Drittens: Vertrauen bei Neukunden. Gerade im deutschen Markt, wo Misstrauen gegenüber unbekannten Shops traditionell hoch ist, entscheiden Bewertungszahlen über den ersten Kauf. Ein Produkt mit 87 Bewertungen und 4,3 Sternen wirkt anders als eines mit null — auch wenn das Produkt identisch ist.
Welche Wege gibt es für den Review-Import in Adobe Commerce?
Drei realistische Optionen stehen zur Wahl — mit sehr unterschiedlichen Trade-offs.
1. Dedizierte Import/Export-Extensions. Das Marktsegment wird von FireBear Studio mit dem Improved Import & Export-Modul dominiert, daneben existieren Lösungen von Amasty, Mageplaza und BSS Commerce. Diese Extensions verstehen die Review-Datenstruktur, mappen Quell-Felder auf Magento-Felder und kümmern sich um die Zuordnung zu Produkten und Kundenkonten. Typischer Workflow: CSV oder XML aus dem Altsystem exportieren, Mapping definieren, Dry-Run auf Staging, Import auf Live. Kosten liegen je nach Edition und Anbieter im dreistelligen bis niedrigen vierstelligen Euro-Bereich — fair gemessen an dem, was man vermeidet.
2. Eigenentwicklung via Skript oder SQL. Für Agenturen mit Magento-Erfahrung ist der direkte Weg über die Datenbank machbar. Die Tabellenstruktur ist dokumentiert, die Zuordnung zu entity_pk_value und store_id überschaubar. Der Teufel steckt im Detail: Review-Status, Ratings als Multi-Select-Werte, Gast-Reviews ohne Kundenkonto, die Trennung zwischen review und review_detail. Wer das zum ersten Mal macht, vergisst mindestens eine Kante. Wer es sauber macht, baut sich ein wiederverwendbares Migrations-Tool.
3. Review-Dienstleister als neues Zuhause. Die strategisch radikalste Option: Statt die alten nativen Reviews zu retten, nutzt man die Migration zum Umstieg auf ein externes System wie Trustpilot, Trusted Shops (im DACH-Raum relevant) oder Yotpo. Einige dieser Anbieter übernehmen Alt-Daten über Import-Schnittstellen. Das löst zwei Probleme gleichzeitig: künftige Review-Infrastruktur und rechtliche Fragen — die DSGVO-Konformität nativer Magento-Reviews ist bei Gast-Reviewern nämlich ein eigenes Thema.
Wie funktioniert der Review-Export aus Magento 2 — und warum ist er einfacher als der Import?
Der Export ist der unproblematischere Teil. Daten rauszuholen ist leichter als sie korrekt wieder reinzuschreiben. Drei praktikable Wege:
- Direkte SQL-Queries über die Review-Tabellen, exportiert als CSV. Schnell, dreckig, für One-Shots ausreichend.
- Export-Funktionen der genannten Extensions (FireBear, Amasty). Sauber, dokumentiert, mit Filteroptionen nach Store-View und Zeitraum.
- REST-API von Magento 2: Der Endpunkt
/V1/reviewsliefert Reviews paginiert. Für automatisierte Syncs zwischen Systemen der sauberste Weg — Rate Limits beachten.
Was viele unterschätzen: Der Export ist häufig kein einmaliger Akt, sondern ein laufender Prozess. Wer Staging und Live synchron hält, braucht wiederkehrende Review-Syncs — sonst testet man auf Staging mit veralteten Daten, was insbesondere bei A/B-Tests auf Produktdetailseiten die Ergebnisse verfälscht.
Was übersehen Händler beim Review-Import regelmäßig?
Vier Stolpersteine tauchen in Projekten immer wieder auf — und werden selten vorab diskutiert.
Produkt-Mapping. Reviews hängen an Produkt-IDs. Beim Plattformwechsel ändern sich diese IDs fast immer. Ohne sauberes Mapping (SKU → neue entity_id) hängen Bewertungen am falschen Produkt — oder nirgendwo. Das Mapping gehört vor jedem Import validiert, idealerweise mit Stichproben auf Staging.
Store-Views und Sprachen. Magento-Shops im DACH-Raum laufen fast immer multilingual: Deutsch, Englisch, oft Französisch. Reviews sind Store-View-spezifisch. Wer beim Import die store_id-Zuordnung falsch setzt, zeigt deutsche Reviews plötzlich im englischen Store-View — ein peinlicher Live-Fehler.
Timestamps. Eine Bewertung von 2019, die beim Import auf heute datiert wird, sieht für Kunden komisch aus und für Suchmaschinen verdächtig. Saubere Importe übernehmen Original-Datum und -Uhrzeit.
Moderationsstatus. Alte Reviews, die im Altsystem „approved“ waren, sollten nicht plötzlich im Moderations-Queue hängen. Der Status gehört mit importiert.
Wie vermeidet man typische Fehler beim Review-Mapping?
Die ehrliche Antwort: durch einen kontrollierten Testlauf, nicht durch Hoffnung. Wer einen Review-Import plant, sollte drei Dinge ernst nehmen.
Ein vollständiger Dry-Run auf Staging. Nicht mit 50 Beispieldatensätzen, sondern mit dem kompletten Export. Erst dann zeigen sich Kantenfälle: Reviews ohne Kundenkonto, Sonderzeichen in Texten, gelöschte Produkte, die noch Reviews tragen.
Stichproben-Validierung. Zwanzig zufällige Produkte manuell prüfen: Stimmt die Anzahl? Stimmt das Datum? Stimmt die Store-View-Zuordnung? Wer das überspringt, findet die Fehler im Live-Betrieb — von Kunden.
Rollback-Plan. Review-Tabellen vor dem Import sichern. Ein mysqldump von fünf Tabellen kostet zwei Minuten und rettet im Zweifel den Tag.
Unser Fazit an dieser Stelle als Arbeitsregel, nicht als Schlusswort: Behandelt Reviews bei jeder Migration als eigenes Workpackage — mit eigenem Datenmodell, eigenem Testlauf und eigenem Verantwortlichen. Wer sie als Anhängsel der Produktmigration abhakt, merkt erst Wochen später, dass die Sterne in der Suche verschwunden sind und die Conversion auf Top-Produkten eingebrochen ist. Dann ist der Schaden bereits sichtbar — im Dashboard und im Umsatz.