Adobe hat Magento 2 über Jahre zur Enterprise-Plattform aufgerüstet, B2B-Funktionen, Live Search, GraphQL-APIs. Doch wer Kundenbewertungen in einem Rutsch exportieren will, starrt in einen leeren Admin-Bereich. Es gibt keinen Button. Keinen Cronjob. Keinen nativen Weg, um tausende Product Reviews aus einem alten Shop in einen neuen zu heben oder ein Staging-System mit echtem Bewertungsmaterial zu befüllen.
Das ist kein Randproblem. Reviews sind nach Einschätzung von Baymard Institute und zahlreichen Conversion-Studien einer der stärksten Kaufsignale überhaupt, Spiegel Research Center bezifferte den Umsatzanstieg durch angezeigte Bewertungen einst auf bis zu 270 Prozent bei höherpreisigen Produkten. Wer bei einer Migration oder einem Plattformwechsel dieses Material verliert, verliert nicht Kommentare. Er verliert Umsatz.
Warum Product Reviews mehr sind als Sterne unter dem Produktbild?
Bewertungen erfüllen im E-Commerce drei Funktionen gleichzeitig. Sie sind ein Vertrauenssignal für Erstkunden, die den Shop nicht kennen. Sie sind ein SEO-Asset, weil Review-Texte Long-Tail-Keywords enthalten, die keine Redaktion je schreiben würde. Und sie sind ein Conversion-Booster, der die Unsicherheit vor dem Klick auf „In den Warenkorb“ abbaut.
Gerade im DACH-Markt spielt das eine besondere Rolle. Deutsche Online-Käufer gelten als vergleichsweise skeptisch, Trusted Shops hat hierzulande nicht ohne Grund eine marktbeherrschende Stellung. Ein Produkt mit 47 echten Bewertungen konvertiert spürbar besser als eines mit null, selbst wenn die durchschnittliche Sternezahl bei 4,2 statt 5,0 liegt. Perfekte Bewertungen wirken auf deutsche Kunden eher verdächtig als überzeugend.
Wer also seinen Magento-Shop neu aufsetzt, von Magento 1 migriert (immer noch Realität in manchen Mittelstands-Projekten) oder ein Shopware- oder Shopify-Relaunch-Projekt hinter sich hat, steht vor derselben Frage: Wie bekomme ich die alten Bewertungen in das neue System, ohne sie manuell einzutippen?
Wie funktioniert der Review-Import in Magento 2 technisch?
Die kurze Antwort: nicht nativ, aber über drei bewährte Wege. Bewertungen in Magento 2 sind keine einfachen Kommentare, sondern verknüpfte Entitäten. Jede Review hängt an einem Produkt (über die Entity-ID), optional an einem Kundenkonto, an einem Store View und an bis zu drei Rating-Dimensionen. Wer importiert, muss diese Verknüpfungen korrekt auflösen, sonst landen Bewertungen am falschen Produkt oder im falschen Store.
Der erste Weg führt über Extensions. Am weitesten verbreitet sind Import/Export-Module wie das Improved Import & Export von Firebear Studio oder spezialisierte Review-Import-Tools von Anbietern wie Mageplaza oder BSS Commerce. Diese Extensions lesen CSV- oder XML-Dateien und mappen die Felder auf die Magento-Tabellen review, review_detail und rating_option_vote. Preislich liegen die brauchbaren Lösungen zwischen 100 und 400 Euro, bei einer Migration mit mehreren tausend Reviews ein Klacks gegenüber der manuellen Alternative.
Der zweite Weg ist der direkte Datenbank-Import per SQL. Er funktioniert, ist aber fehleranfällig: Die Tabellen-Struktur von Magento 2 erfordert konsistente Einträge in mindestens vier Tabellen gleichzeitig, und die entity_pk_value muss auf die korrekte Produkt-Entity zeigen. Ein falscher Join, und 3.000 Bewertungen zeigen auf das falsche Sortiment. Für Agenturen mit starkem Backend-Team machbar, für Inhouse-Teams ohne Magento-Spezialisten ein Risiko.
Der dritte Weg nutzt die REST-API. Magento 2 stellt Endpunkte für Reviews bereit (/V1/reviews), über die sich Bewertungen programmatisch anlegen lassen. Das ist der sauberste Weg für wiederkehrende Synchronisationen, etwa wenn ein externes Bewertungstool wie Trustpilot, Trusted Shops oder eKomi Reviews liefern soll. Die API ist allerdings nicht für Bulk-Operationen optimiert: Bei 20.000 Reviews dauert ein API-basierter Import deutlich länger als ein direkter CSV-Import über eine Extension.
CSV-Struktur und Mapping: Wo die meisten Importe scheitern
Die Praxis zeigt: Der Import selbst ist selten das Problem. Das Problem ist die Datenqualität vorher. Eine typische CSV-Datei für den Review-Import braucht mindestens diese Felder: Produkt-SKU oder Entity-ID, Review-Titel, Review-Text, Nickname, Sternebewertung (1-5), Erstellungsdatum, Store-View-ID und Status (Approved, Pending, Not Approved).
- SKU vs. Entity-ID: Extensions erwarten meist die SKU, die intern auf die Entity-ID gemappt wird. Fehlt die SKU oder existiert sie nicht mehr im Katalog, schlägt der Import für diese Zeile fehl, oder schlimmer: er importiert mit einer falschen Zuordnung.
- Encoding-Fallen: Deutsche Umlaute und Sonderzeichen in UTF-8 sind Pflicht. Latin1-encodierte CSVs erzeugen zerstörte Umlaute, die im Frontend wie Datenmüll aussehen.
- Datumskonsistenz: Magento speichert
created_atals UTC-Timestamp. Wer lokale Zeiten importiert, verschiebt alle Bewertungsdaten um ein bis zwei Stunden, bei Sortierungen nach „Neueste zuerst“ spürbar.
Ein weiterer Klassiker: Store Views. Magento-Instanzen mit mehreren Sprachen, typisch für DACH-Händler mit deutsch-, englisch- und französischsprachigen Shops, ordnen Bewertungen pro Store View zu. Eine deutsche Bewertung sollte im englischen Store View nicht erscheinen, es sei denn, der Händler will das explizit. Beim Import muss die store_id korrekt gesetzt werden, sonst tauchen deutschsprachige Reviews im internationalen Shop auf oder umgekehrt.
Warum Staging-Syncs ohne Review-Export sinnlos sind?
Ein unterschätztes Szenario: Die Staging-Umgebung. Entwicklerteams spiegeln Produktdaten, Kundendaten und Bestellungen regelmäßig vom Live-System auf Staging, aber Bewertungen bleiben oft außen vor, weil kein nativer Export existiert. Das Ergebnis: Auf Staging sieht jedes Produkt aus wie ein Ladenhüter ohne ein einziges Review.
Wer auf Staging neue Produktdetailseiten, Review-Widgets oder strukturierte Daten (Schema.org AggregateRating) testen will, braucht realistische Bewertungsdaten. Ohne sie testet man gegen eine leere Kulisse und entdeckt Layout-Brüche oder Snippet-Fehler erst nach dem Livegang. Der Export aus dem Live-System, per Extension oder direktem SQL-Dump der Review-Tabellen, gehört deshalb in jedes ernsthafte Deployment-Skript.
Beim Export per SQL ist die Query überschaubar: Ein Join über review, review_detail, review_store und rating_option_vote liefert alle Felder, die für einen Re-Import nötig sind. In Kombination mit catalog_product_entity.sku entsteht eine saubere Exportdatei, die SKU-basiert wieder importierbar ist. Das Ganze lässt sich als Cronjob automatisieren, etwa wöchentlich, damit Staging nie mehr als sieben Tage hinter dem Live-Stand hinkt.
DSGVO, Trusted Shops und die DACH-Besonderheiten
Der deutsche Markt bringt zwei Eigenheiten mit, die der englischsprachige Originalkontext ausblendet. Erstens: die DSGVO. Kundenbewertungen enthalten personenbezogene Daten, mindestens den Nicknamen, oft auch die Kunden-E-Mail, wenn Reviews an Kundenkonten geknüpft sind. Wer Bewertungen zwischen Systemen transferiert, verarbeitet personenbezogene Daten. Das ist legitim, solange die ursprüngliche Einwilligung die Verarbeitung deckt. Problematisch wird es, wenn Nicknamen Klarnamen enthalten oder Kunden ihre Bewertungen zwischenzeitlich gelöscht haben wollten, der Export muss solche Löschanfragen respektieren.
Zweitens: die Trusted-Shops-Frage. Viele deutsche Magento-Händler sammeln Bewertungen parallel über Trusted Shops. Diese Bewertungen liegen nicht in der Magento-Datenbank, sondern im Trusted-Shops-System. Wer sie auf den Produktdetailseiten anzeigen will, braucht eine Integration, entweder über das offizielle Trusted-Shops-Plugin für Magento 2 oder über die API. Ein Import in die Magento-eigenen Review-Tabellen ist zwar technisch möglich, wirft aber Lizenz- und Darstellungsfragen auf, die man vorher mit Trusted Shops klären sollte.
Die schlechteste Review-Strategie ist die, die bei der ersten Migration verloren geht. Bewertungen sind ein Asset, behandeln Sie sie wie eins.
Review-Daten als SEO-Hebel: AggregateRating richtig ausspielen
Importierte Bewertungen entfalten ihren vollen Wert erst, wenn Google sie lesen kann. Das Stichwort: strukturierte Daten. Magento 2 gibt standardmäßig AggregateRating-Markup aus, allerdings nur, wenn Bewertungen in den eigenen Tabellen vorhanden sind. Externe Review-Systeme, die per JavaScript-Widget eingebunden werden, erzeugen häufig kein crawlbar schema.org-Markup. Die Sterne erscheinen dann im Shop, aber nicht in den Suchergebnissen.
Das ist verschenkte Sichtbarkeit. Produkte mit sichtbaren Sternen in den SERPs erreichen nach Studien von CXL und anderen Anbietern Klickraten-Steigerungen von 15 bis 35 Prozent gegenüber identischen Listings ohne Sterne. Wer seine Reviews sauber in Magento importiert und das Markup kontrolliert, hat diesen Vorteil. Wer auf Widgets setzt, hat ihn oft nicht.
Praktisch heißt das: Nach dem Import das Markup mit dem Rich Results Test von Google prüfen. Steht aggregateRating mit ratingValue und reviewCount im HTML-Quelltext, nicht erst nach JavaScript-Rendering, ist alles korrekt. Fehlt es, liegt das Problem meist am Theme oder an einer Überschreibung im Custom-Modul.
Was bleibt: Magento 2 gibt Händlern ein starkes Framework für Bewertungen an die Hand, lässt sie aber beim Datentransport allein. Wer diesen Transport professionalisiert, mit den richtigen Tools, sauberem Mapping und einem Blick auf DSGVO und Store-View-Logik, verwandelt eine technische Lücke in einen Wettbewerbsvorteil. Die Konkurrenz, die bei ihrem letzten Relaunch 4.000 Bewertungen verloren hat, holt das nicht mehr auf.