37.000 Produktbewertungen, gesammelt über acht Jahre, mit einem durchschnittlichen Rating von 4,6 Sternen — und kein einziger offizieller Weg, sie aus dem alten Shop herauszubekommen. Genau vor diesem Problem stand ein mittelständischer deutscher Werkzeughändler, als er im Frühjahr seinen Magento-1-Shop auf Adobe Commerce migrieren wollte. Die Produktdatenbank war in einem Nachmittag übertragen. Die Kundenbewertungen, sein wertvollstes Conversion-Asset, hingen fest.
Der Magento 2 Product Reviews Import ist eines jener Themen, über die Adobe ungern laut spricht. Die Plattform erlaubt Kunden seit jeher, Bewertungen nativ abzugeben — mit Sternen, Titel, Text, Nickname. Was sie nicht erlaubt: diese Daten gebündelt zu importieren oder zu exportieren. Während Artikel, Kunden und Bestellungen über das Standard-Import-Modul unter System → Data Transfer → Import laufen, fehlt die Entität „Review“ schlicht in der Auswahl. Für Händler, die einen Shop migrieren, eine Staging-Umgebung mit realen Daten füttern oder Reviews aus einem externen Tool wie Trusted Shops synchronisieren wollen, ist das mehr als ein Schönheitsfehler.
Warum sind Produktbewertungen in Magento 2 so schwer zu exportieren?
Die Antwort liegt im Datenmodell. Eine Magento-Review ist keine flache Tabelle, sondern verteilt sich über mehrere: review für die Metadaten, review_detail für Titel und Text, review_store für die Store-View-Zuordnung und rating_option_vote für die eigentlichen Sternebewertungen. Dazu kommen Verknüpfungen zum Produkt über die Entity-ID und zum Kunden — sofern eingeloggt bewertet wurde.
Genau diese Verknüpfungen machen den Transfer heikel. Ein Produkt, das im alten System die Entity-ID 4821 hatte, trägt im neuen Shop möglicherweise die ID 7312. Wer Reviews per CSV einspielt, ohne das Mapping der Produkt-IDs vorher sauber aufzulösen, erzeugt verwaiste Datensätze. Magento quittiert das nicht mit einer Fehlermeldung, sondern mit Bewertungen, die schlicht nirgends erscheinen. In der Praxis bedeutet das: stundenlanges Debugging in der Datenbank, obwohl der Import „erfolgreich“ durchgelaufen ist.
Adobe hat daran über Jahre nichts geändert — weder in der Open-Source-Version noch in der kostenpflichtigen Commerce-Edition. Das ist kein Versehen, sondern Produktlogik: Bewertungen gelten als nutzergenerierter Inhalt, nicht als Stammdaten. Nur dass Händler diese Unterscheidung nicht interessiert, wenn 4,6-Sterne-Durchschnitte und tausende Verifizierungs-Häkchen auf dem Spiel stehen.
Drei Wege, Reviews trotzdem zu übertragen
Wer vor der Aufgabe steht, hat realistisch drei Optionen — mit deutlich unterschiedlichem Aufwand und Risiko.
Der Extension-Weg ist für die meisten Händler die pragmatischste Lösung. Module wie „Import Export Product Reviews“ von MageComp, BSS Commerce oder Meetanshi — Preisrahmen 69 bis 149 US-Dollar — fügen dem Backend genau die fehlende Entität hinzu: Reviews als CSV exportieren, anpassen, wieder importieren. Die besseren Vertreter übernehmen dabei auch das Remapping der Produkt-SKUs, prüfen Duplikate und erhalten das ursprüngliche Erstellungsdatum. Letzteres ist wichtiger, als es klingt: Eine Bewertung von 2019 wirkt anders als 3.000 Reviews mit Identdatum vom Migrationstag. Preisvergleichsplattformen und Google Shopping ziehen Zeitstempel ohnehin mit; wer sie verliert, verliert auch ein Stück Glaubwürdigkeit.
Der Datenbank-Weg — direkter Export und Reimport der genannten Tabellen via SQL — funktioniert ebenfalls, ist aber Handarbeit für Leute, die wissen, was sie tun. Beim Sprung von Magento 1 zu Magento 2 scheidet er ohnehin weitgehend aus, weil sich die Tabellenstruktur zwischen den Versionen verändert hat. Hier führt praktisch kein Weg an einem Mapping-Skript vorbei, das alte Produkt- und Kunden-IDs auf die neuen Ziel-IDs auflöst. Agenturen mit eigener Magento-Praxis haben dafür meist hausinterne Tools; wer auf eigene Faust migriert, sollte diesen Weg nur mit Staging-Umgebung und Backup gehen.
Der API-Weg schließlich nutzt die REST-Schnittstelle von Adobe Commerce: Reviews lassen sich per POST /V1/reviews programmatisch anlegen. Das ist der sauberste Ansatz für automatisierte Szenarien — etwa wenn ein externes Bewertungstool regelmäßig neue Reviews in den Shop spiegeln soll. Er setzt allerdings Entwicklungskapazität voraus und skaliert bei großen Beständen zäh, weil jede Review einen eigenen Request bedeutet. Für 50.000 Bewertungen plant man besser einen Wartungsfenster-Nachtlauf ein.
Wie gelingt der Import ohne Datenverlust?
Unabhängig vom gewählten Weg entscheiden vier Details über Erfolg oder Scheitern, und sie werden in den Verkaufsseiten der Extension-Anbieter erstaunlich selten erwähnt.
Das wichtigste zuerst: SKU statt Entity-ID als Matching-Schlüssel. Interne IDs ändern sich bei jeder Migration; die Artikelnummer bleibt stabil. Jede ernsthafte Import-Lösung sollte Reviews über die SKU dem Zielprodukt zuordnen können — tut sie das nicht, ist sie für Migrationsprojekte unbrauchbar.
Zweitens die Store-View-Zuordnung. Wer einen mehrsprachigen Shop betreibt — im DACH-Raum der Normalfall: deutsch, österreichisch, oft noch englisch — muss entscheiden, ob Bewertungen pro Store View getrennt bleiben oder global gelten. Magento kennt beides, und die falsche Einstellung nach dem Import führt dazu, dass im deutschen Frontend plötzlich keine oder alle Reviews sichtbar sind.
Drittens der Moderationsstatus. Exportierte Reviews tragen einen Status — Approved, Pending, Not Approved. Beim Reimport landen sie je nach Tool pauschal auf „Approved“ oder „Pending“. Wer 3.000 Bewertungen händisch freischalten muss, weil der Import den Status nicht mitgenommen hat, lernt den Massenaktions-Button in Marketing → Reviews sehr schnell zu schätzen.
Viertens: Nickname und Gast-Bewertungen. Reviews von nicht eingeloggten Kunden haben keine Customer-Entity. Manche Import-Skripte verlangen zwingend eine Kunden-ID und verwerfen Gast-Reviews stillschweigend. Vor dem produktiven Import lohnt ein Testlauf mit einer Stichprobe von 50 Datensätzen — gemischt aus Gast- und Kundenbewertungen, verschiedenen Ratings und Datumsbereichen.
Eine Bewertung aus dem Jahr 2019 verkauft besser als zehn Bewertungen vom Migrationstag. Zeitstempel sind kein Metadatum, sie sind Vertrauenswährung.
Was deutsche Händler zusätzlich beachten müssen
Im DACH-Markt kommen zwei Besonderheiten hinzu, die der US-geprägte Magento-Kosmos kaum adressiert.
Da ist zum einen die DSGVO. Bewertungen enthalten personenbezogene Daten — mindestens den Nicknamen, oft die Kundenverknüpfung. Wer Reviews in ein neues System überträgt oder an ein externes Tool spiegelt, verarbeitet diese Daten weiter. Das ist im Bestand meist unproblematisch, solange Zweck und Rechtsgrundlage bestehen bleiben; bei der Migration zu einem Drittanbieter-System oder gar in eine US-Cloud lohnt der Blick in die Auftragsverarbeitung. Deutsche Datenschutzbeauftragte fragen sowas, amerikanische Tutorials nicht.
Zum anderen dominiert hierzulande Trusted Shops das Bewertungsgeschäft — ein Ökosystem, das parallel zur nativen Magento-Review läuft. Viele Händler sammeln über Jahre dort Käufer- und Produktbewertungen, die nie im eigenen Shop auftauchen. Wer diese Reviews per API oder Widget integriert, sollte bedenken: Die Daten leben auf Trusted-Shops-Servern. Wer kündigt oder wechselt, verliert die Darstellung. Eine Strategie, die zumindest Produktbewertungen zusätzlich nativ in Magento spiegelt, kostet etwas Pflegeaufwand — und zahlt genau dann, wenn es weh tut.
Reviews als SEO-Asset: Was beim Import mitwandern muss
Produktbewertungen sind nicht nur Sozialbeweis auf der Produktdetailseite. Über strukturierte Daten — das AggregateRating-Markup nach schema.org — fließen Sterne in die Google-Suchergebnisse ein. Magento 2 liefert dieses Markup nativ aus, aber nur für Reviews, die auch nativ im System liegen. Bewertungen, die per Widget von einem externen Anbieter eingebunden werden, erzeugen häufig kein validierbares Markup; Googles Richtlinien für Review-Snippets verlangen zudem, dass die Bewertungen auf der Seite selbst sichtbar sind.
Bis zu 17 Prozent höhere Klickraten nennen Analysen von Suchergebnissen mit Sterne-Snippets gegenüber identischen Positionen ohne. Für einen Shop mit tausenden Produktdetailseiten ist das kein Randphänomen, sondern ein Traffic-Hebel, der bei einer schlampig durchgeführten Review-Migration still und leise verloren geht. Wer nach dem Import prüft, ob das Rich-Results-Test-Tool die Aggregate-Ratings noch erkennt, hat das Thema im Griff. Wer es nicht tut, merkt den Schaden erst Wochen später in der Search Console.
Die Extension-Landschaft: Worauf es wirklich ankommt
Der Markt für Import-Export-Module ist überschaubar, aber uneinheitlich. Die einschlägigen Anbieter decken die Basis ab; die Unterschiede sitzen im Detail. Kaufentscheidend sind vier Fragen: Unterstützt das Modul SKU-basiertes Matching? Erhält es Erstellungsdatum und Moderationsstatus? Läuft es unter der aktuellen Adobe-Commerce-Version — viele Module hinken bei den halbjährlichen Releases hinterher? Und: Gibt es eine CLI-Variante, damit der Import sich in Deploy-Prozesse und Cronjobs einbetten lässt?
Wer die Antworten vor dem Kauf einholt, spart sich die zweite Runde. Die Alternative — einmalig ein Skript von einer Agentur schreiben lassen — kostet in Deutschland je nach Datenlage zwischen 800 und 3.000 Euro und lohnt sich vor allem dann, wenn Alt-Systeme mit exotischen Strukturen im Spiel sind: ein alter osCommerce-Shop, ein selbstgestricktes Bewertungstool, Daten aus einer abgelösten ERP-Landschaft.
Die unbequeme Wahrheit zum Schluss: Adobe wird die fehlende Funktion voraussichtlich nicht nachliefern. Die Roadmap der Plattform dreht sich um Composable Commerce, KI-Features und die Edge-Integration — nicht um Daten-Transfer-Komfort für Bestandskunden. Händler, die Review-Daten als das behandeln, was sie sind — ein migrierbares, messbares Geschäftsasset —, fahren mit einer dokumentierten Import-Routine und regelmäßigen Export-Sicherungen besser als mit der Hoffnung auf den Hersteller. Wer heute keine Strategie für den Fall hat, dass der nächste Systemwechsel kommt, steht in fünf Jahren wieder vor denselben 37.000 festgeklemmten Bewertungen.