Ein Feature, das sich als Bug-Report liest
Die WooCommerce-Entwickler haben die Pre-Release-Notes zu Version 11.2 veröffentlicht, und die prominenteste Neuerung klingt unspektakulär: Der Product-CSV-Importer matcht Zeilen jetzt nach globalen Identifikatoren — GTIN, UPC, EAN, ISBN — wenn weder ID noch SKU vorhanden sind. Match-Reihenfolge: ID, dann SKU, dann Global Unique ID. Steht so in den Notes von Shani Banerjee vom 21. September 2026. Klingt nach sauberer Ingenieursarbeit. Ist es auch. Aber es erzählt eine andere Geschichte.
Denn wenn ein Shopsystem zehn Jahre braucht, um beim Produktimport anzuerkennen, dass GTIN der eigentliche Identifikator im Handel ist und SKU nur ein hausgemachtes Provisorium, dann sagt das etwas über die Architektur-Annahmen. SKU ist ein internes Konstrukt. Der Händler denkt ihn sich aus. GTIN ist der Code, den der Hersteller vergibt, den Amazon, Google Shopping, Idealo und die halbe Lieferkette verstehen. Wer im Multi-Channel-Handel unterwegs ist, lebt von GTINs — und musste in WooCommerce bisher beim Import raten.
„With ‚Update existing products‘ enabled, the importer now matches rows by GTIN, UPC, EAN, or ISBN when no ID or SKU is present. Match order is ID, then SKU, then Global Unique ID.“
Der „Cleanup“-Fix ist die eigentliche Sensation
Interessanter als das GTIN-Feature ist der zweite Satz in den Release Notes, der in der Außendarstellung völlig untergeht: Import-Cleanup löscht keine site-weiten Orphans mehr. Keine Variationen, keine Post-Metas, keine Term-Relationships. Grund laut Notes: Diese Bereinigung fügte bei großen Katalogen über eine Minute pro Import hinzu — und konnte unzusammenhängende Daten entfernen.
Lest diesen Satz noch mal. Ein Kernprozess in WooCommerce, den jeder ernsthafte Händler täglich nutzt, hatte das Potenzial, beim CSV-Import einer einzigen Produktzeile fremde Daten aus dem Shop zu löschen. Bei einem Katalog mit zehntausend Artikeln. Auf einem Shared-Hosting-Setup. Während der B2B-Import läuft. Wer in den letzten Jahren WooCommerce-Produktimporte in Produktivumgebungen gefahren hat und sich über fehlende Bilder, kaputte Variationen oder verschwundene Kategoriezuordnungen gewundert hat — hier ist eine plausible Erklärung. Nicht die einzige, aber eine, die Woo jetzt selbst liefert.
Das ist kein Detail. Das ist ein Zuverlässigkeitsproblem, das die Commerce-Community nachhaltiger hätte beschäftigen müssen als jede Styling-Option. „Row matching and cleanup improvements“ nennt sich das. Es ist de facto ein Datenintegritäts-Fix, der im Mittelteil der Notes versteckt wird.
Was die Release Notes nämlich prominent bewerben, ist derweil die dritte Schlagzeile: mehr Styling. Produktbilder mit Border-Styles. Quantity-Selector mit Box-Shadow und Border-Radius. Chips mit Typografie-Optionen. Ich habe nichts gegen Design-Flexibilität im Block-Editor — aber die Gewichtung sagt etwas aus. WooCommerce verkauft sich gegenüber dem Shopbetreiber zunehmend als Baukasten. Gegenüber dem Entwickler mit breiten Integrations- und Datenanforderungen bleibt es beim Flickwerk.
Was das für DACH-Händler bedeutet
Für den deutschen Markt ist das GTIN-Matching aus zwei Gründen relevant. Erstens: Preisvergleichs- und Marktplatzanbindung. Wer aus einem PIM-System heraus Publish-Feeds bedient, muss seine Produkte konsistent über GTIN identifizieren. Wer den WooCommerce-Shop als zweite Instanz neben Amazon oder Kaufland betreibt, hat sich bisher eigene Matching-Logik gebaut. Die fällt jetzt — teilweise — weg. Zweitens: EU-Regulatorik. Die neue EU-Produktsicherheitsverordnung (GPSR, seit Dezember 2024 in Kraft) verschärft die Rückverfolgbarkeit. GTIN-basiertes Matching ist genau das, was Händler für Audit-Trails und Rückruf-Prozesse brauchen. Dass WooCommerce das erst 2026 als Feature verkauft, ist ein Beispiel dafür, wie träge Core-Roadmaps auf reale Compliance-Anforderungen reagieren.
Aber die eigentliche Lehre liegt woanders: Die Insertion Order des Datenmodells. WooCommerce priorisiert ID, dann SKU, dann GTIN. In einem Multi-Channel-Katalog wäre die richtige Reihenfolge umgekehrt — GTIN zuerst, weil das der einzige identifier ist, der zwischen Systemen stabil bleibt. SKU und Woo-ID sind Woo-spezifisch. Wer seinen Katalog auf Woo-Reihenfolgen aufbaut, baut sich Lock-in ins eigene System.
Händler in DACH sollten die neue Funktion deshalb nutzen — aber die Matching-Regeln im eigenen PIM gegenläufig konfigurieren: GTIN als primärer Schlüssel, SKU als Fallback, Woo-ID nur als technische Notlösung. Sonst zementiert die Woo-Logik genau die Datenhaltung, unter der der Multi-Channel-Handel leidet.
WooCommerce hat in 11.2 zwei echte Probleme gefixt. Es hat sie aber als Routine-Release verkauft, versteckt zwischen Box-Shadows und Date-Pickern im Checkout. Wer als Händler nicht zwischen den Zeilen liest, verpasst den relevanten Teil. Und wer bei jeder Beta aufs Styling-Detail schaut, übersieht, dass hier über Jahre hinweg Datenintegrität auf dem Spiel stand. Die Frage ist nicht, ob GTIN-Matching in 11.2 gut ist. Die Frage ist, warum es 11 Major-Versionen gebraucht hat — und wie viele Import-Probleme in der Zwischenzeit auf das Konto der „cleanup“-Logik gingen.