Jeder, der schon einmal einen größeren Shop aufgebaut oder migriert hat, kennt das Bild: ein Ordner mit hunderten Hersteller-PDFs, dazu Excel-Listen mit Artikelnummern und das diffuse Gefühl, dass die nächsten zwei Wochen verloren sind. Produktnamen abtippen, Beschreibungen umformulieren, Kategorien zuordnen, Alt-Texte erfinden – alles wichtig, alles wiederholend.
Mit unserer Plattform Axon bauen wir diesen Schritt anders. Statt Datenblätter manuell zu erfassen, übergeben wir sie an einen KI-Pipeline-Job, der über Nacht durchläuft. Das Ergebnis am Morgen: vollständig befüllte Produkte mit Beschreibungen, SEO-Daten, Tags und Alt-Texten, eingecheckt im Magento- oder Hyvä-Shop. Dieser Beitrag beschreibt, wie das technisch funktioniert, wo es seine Stärken hat – und wo wir bewusst auf den Menschen setzen.
Der Schmerzpunkt: Kataloge wachsen, Teams nicht
Eine typische Migration von Magento 1 oder einem Altsystem auf Hyvä bringt zwei Probleme zusammen: die Daten sind schlecht (kurze, kopierte Beschreibungen ohne SEO-Wert), und es gibt viele davon (mehrere tausend SKUs). Wer die Migration als reine Datenübernahme behandelt, landet im neuen Shop mit dem alten Qualitätsproblem.
Die übliche Lösung – Texter beauftragen, Excel exportieren, manuell überarbeiten – kostet je nach Größe sechs- bis siebenstellig und dauert Monate. In dieser Zeit verkauft niemand mit besseren Texten.
Wie Axon das Problem zerlegt
Die Pipeline besteht aus vier Stufen, die jeweils auf ihrer eigenen Datenbasis arbeiten:
- Extraktion. Aus dem PDF werden strukturierte Felder geholt – Artikelnummer, Maße, Material, Gewicht, technische Eigenschaften. Dafür reicht heute kein klassisches PDF-Parsing mehr; wir nutzen Vision-Modelle, die auch Tabellen, schlecht gesetzte Spalten und Mischlayouts verstehen.
- Normalisierung. Die rohen Felder werden auf das Magento-Attribut-Set des Shops gemappt. Hier passieren die meisten Fehler: ein Hersteller schreibt „Farbe: kirschrot", der Shop kennt aber nur „rot". Die Mapping-Regeln pflegen wir pro Kunde einmal und sie wachsen mit jedem Datenblatt mit.
- Generierung. Auf Basis der extrahierten Fakten erzeugt das LLM eine Produktbeschreibung in der Markentonalität, dazu SEO-Title, Meta-Description, Tags und Alt-Texte. Wichtig: die Generierung sieht nur die normalisierten Fakten, nicht das PDF. Damit halluziniert das Modell keine Eigenschaften.
- Validierung. Markenrechts-Check (Wortlisten), Plausibilitäts-Check (passt die Beschreibung zur Kategorie?), Konsistenz-Check (Tonalität, Längen). Was durchfällt, landet in einer Review-Queue für den Menschen.
Die Reihenfolge ist entscheidend. Wer einem Sprachmodell ein PDF vor die Nase wirft und „mach mir eine Produktbeschreibung" sagt, bekommt poetische Texte mit erfundenen Features. Das ist nicht das, was wir wollen.
Ein konkretes Projekt
Im Frühjahr haben wir für einen Kunden im Tierfutter- und Reitsportbereich ca. 2 100 Produkte aus Hersteller-PDFs in einen frisch migrierten Hyvä-Shop überführt. Eingangsmaterial:
- 180 PDFs mit insgesamt rund 2 100 Produkten (manche PDFs sind Sammelblätter mit 20+ Varianten)
- Eine Excel-Liste mit SKUs, Preisen und Beständen
- Ein paar Beispiel-Beschreibungen aus dem alten Shop, die der Kunde mochte, als Tonalitäts-Referenz
Die Pipeline lief in einer Nacht durch. Am nächsten Morgen lagen im Shop:
- Vollständige Produktstammdaten inklusive Attribute (Maß, Material, Größe, Farbe)
- Eine Produktbeschreibung pro SKU, im Schnitt 80–120 Wörter
- SEO-Title und Meta-Description, individuell pro Produkt
- Drei bis sieben Tags pro Produkt für Filter und interne Verlinkung
- Alt-Texte für Produkthauptbilder
Wichtig zu wissen
Rund 8 % der Produkte fielen in die Review-Queue – meistens, weil das Datenblatt eine Eigenschaft enthielt, die wir markenrechtlich nicht ohne Prüfung beschreiben wollten („antibakteriell"). Die manuelle Sichtung dieser 8 % dauerte etwa zwei Arbeitstage. Manuell hätten dieselben 2 100 Produkte rund zwei Monate gekostet.
Was wir gelernt haben
1. Die Markentonalität ist die wichtigste Stellschraube
Drei bis fünf gut gewählte Beispiel-Beschreibungen reichen, damit das Modell den Ton trifft. Mehr Beispiele helfen wenig; das Modell überfittet eher. Wichtig ist, dass die Beispiele nicht die generische „Made by KI"-Mittellage haben, sondern erkennbar die Markenstimme.
2. Validierungs-Regeln sind keine Kür
Die größten Fehler in den ersten Durchläufen waren nicht erfundene Fakten – das Modell hält sich erstaunlich gut an die normalisierten Felder –, sondern subtilere Probleme: doppelte Phrasen über mehrere Produkte hinweg, übertriebene Adjektive in Nischen, in denen sachlich besser verkauft. Solche Muster fängt eine zweite, kritische LLM-Pass mit klaren Kriterien zuverlässig ab.
3. Menschen lesen am Ende trotzdem
Wir empfehlen, nach jeder Pipeline einen Stichproben-Review zu machen (5–10 % der Produkte). Nicht weil die KI typischerweise scheitert, sondern um Vertrauen ins System aufzubauen und Mapping-Regeln nachzuschärfen.
Wann das Sinn macht
Die Pipeline rechnet sich, sobald mehr als ein paar hundert Produkte mit gleichem Schema in den Shop sollen – sei es bei einer Migration, einer Markenerweiterung oder einer neuen Kategorie. Bei 20 Produkten lohnt sich der Aufwand nicht; bei 2 000 schon deutlich.
Wer überlegt, ob das für den eigenen Katalog funktioniert: schicken Sie uns ein typisches Datenblatt und ein paar Wunsch-Beispieltexte. Wir spielen das einmal durch und zeigen Ihnen das Ergebnis – das sagt mehr als jede Beschreibung der Methode.
