Google Shopping und Merchant Center 2026 auf PrestaShop: Produktfeed, GTIN, Performance Max

Google Shopping 2026: die am schlechtesten genutzte Acquisition-Schicht in PrestaShop-Shops

Bei den Mid-Market-PrestaShop-Shops, die wir auditieren, macht Google Shopping im Durchschnitt 18 % des erworbenen Umsatzes aus. Wenn der Feed gut gemacht ist. Wenn nicht – und das ist der Standardzustand – sind es 3 % oder weniger, mit explodierenden Akquisitionskosten und Produkten, die vom Merchant Center abgelehnt werden, ohne dass man es bemerkt.

Der Unterschied entscheidet sich auf drei Ebenen: Qualität des Feeds (erforderliche Attribute, GTIN, eindeutige Identifikatoren), Kampagnenstrategie (Performance Max vs. Standard Shopping) und Merchant-Center-Konformität (Richtlinien 2024-2026, Comparison Shopping Services, Referenzpreise). Die drei sind voneinander getrennte und technische Themen. Dieser Artikel behandelt sie in der Reihenfolge, in der sie in der Pipeline eines Händlers auftauchen, der seinen Shopping-Kanal 2026 startet oder neu aufsetzt.

Was sich beim Merchant Center 2024-2026 geändert hat

Drei wesentliche Entwicklungen prägen das Spielfeld neu:

Merchant Center Next ersetzt die alte Oberfläche

Seit 2024 hat Google alle Konten auf Merchant Center Next migriert – eine Neuauflage, die die Hierarchie verflacht, die Feed-Erstellung vereinfacht und Richtlinien strenger durchsetzt. Praktische Folge: Feeds, die vor 18 Monaten lautlos durchgingen, werden heute pauschal abgelehnt, vor allem wegen fehlendem shipping und tax bei Nicht-EU-Händlern.

Das Ende der EU-CSS-Diskriminierung

Nach der europäischen Entscheidung und ihren Anpassungen 2023-2024 können EU-Händler entweder direkt über Google oder über einen Partner-CSS mit einem effektiven Rabatt von 20 % auf den CPC laufen. Bei Shopping-Budgets über 5.000 €/Monat lohnt sich der Weg über einen Partner-CSS (Adwise, KelKoo Group, Productsup, etc.). Es ist eine Optimierung, die nichts in der Einrichtung kostet, die aber 80 % der PrestaShop-Händler nicht aktivieren.

Rückgabe- und Versandattribute sind quasi-obligatorisch geworden

Seit Ende 2024 verlangt Google explizit shipping und return_policy bei der überwiegenden Mehrheit der Shopping-Anzeigen. Ohne das laufen die Anzeigen zwar, aber mit verschlechterter Sichtbarkeit und sinkendem Quality Score. Das passt zu den Schema.org-Product-2026-Eigenschaften (hasMerchantReturnPolicy, shippingDetails), die Google bereits für die Rich Results vorgeschrieben hat.

Anatomie eines konformen Produktfeeds 2026

Der Google-Shopping-Feed ist eine Datei (XML, CSV oder über die Content API), die jedes Produkt für Google beschreibt. Fünfundzwanzig Attribute sind möglich, zehn sind verpflichtend, und ihre korrekte Behandlung macht den Unterschied zwischen einem gesunden Merchant-Center-Konto und einem unter permanentem Warning.

Die zehn verpflichtenden Attribute – und die Fallstricke bei PrestaShop

Die „optional, aber kritischen“ Attribute

Vier Attribute sind nicht als verpflichtend markiert, aber ihr Fehlen verschlechtert die Performance stark:

• shipping: Tabelle mit Versandtarifen pro Land/Region. Ohne diese wendet Google Standardregeln an, die oft falsch sind. Fein zu pflegen, vor allem bei Multi-Country-Shops.
• tax: anwendbare Steuer. Verpflichtend für US-Händler. Für die EU steht der Bruttopreis in price und die Mehrwertsteuer ist implizit, kann aber deklariert werden.
• google_product_category: Google-Kategorie (3 bis 5 Ebenen). Ohne sie rät Google – oft schlecht. Aus der offiziellen Google-Taxonomie zu mappen (5.600 Kategorien).
• product_type: Ihre eigene Taxonomie, nützlich für die Kampagnensegmentierung.

Varianten und Ausführungen: die PrestaShop-Komplexität

In PrestaShop ist eine Produktseite mit Varianten (Größe × Farbe) ein Produkt mit mehreren id_product_attribute. In Google Shopping muss jede Variante eine eigene Zeile im Feed sein, mit:

• id eindeutig pro Variante (typischerweise {id_product}-{id_product_attribute}).
• item_group_id gemeinsam für alle Varianten desselben Elternprodukts (typischerweise id_product). Damit kann Google die Varianten in der Käuferoberfläche gruppieren.
• Variantenattribute: color, size, material, pattern, gender, age_group – je nach Kategorie.
• GTIN pro Variante (oft eine andere EAN je Größe oder Farbe).
• Bestand pro Variante.

Der häufigste Fehler: nur eine Zeile pro Elternprodukt mit Durchschnittspreis und aggregiertem Bestand senden. Google blockiert sofort. Das Google-Shopping-PrestaShop-Modul erledigt dieses Aufspalten nach Variante nativ, mit Mapping der PrestaShop-Attribute auf die Google-Attribute.

GTIN: die Friktion Nr. 1 und ihre Lösung

Die GTIN (Global Trade Item Number) ist der universelle Produktidentifikator. EAN-13 in Europa, UPC-A in den USA, ISBN für Bücher. Google verlangt die GTIN für alle Produkte, die nativ eine haben (bekannte Marken, hergestellte Produkte). Für Produkte ohne GTIN (Handwerksherstellung, exklusive Eigenmarke, Dienstleistungen) muss explizit identifier_exists: false gesetzt werden.

Zwei häufige Fallstricke:

1. Ungültige EAN-13

Die dreizehnte Ziffer ist eine Prüfziffer, die auf den ersten zwölf nach dem Modulo-10-Algorithmus berechnet wird. Viele Shops importieren Herstellerreferenzen mit gekürzten oder erfundenen EANs. Google lehnt sie massenweise ab. Die Validierung sollte zum Zeitpunkt des Imports erfolgen, nicht drei Wochen später entdeckt werden, wenn das Merchant Center 800 Seiten ablehnt.

2. GTIN, die zwischen Varianten geteilt wird

Klassischer Fehler in PrestaShop: Die EAN wird im Elternprodukt (ps_product.ean13) gespeichert statt in der Variante (ps_product_attribute.ean13). Ergebnis: Alle Varianten haben dieselbe GTIN, Google erkennt die Duplikation und lehnt ab.

Das gute Muster: EAN auf Variantenebene speichern, wenn diese eine eigene Referenz hat (typischer Fall: verschiedene Größen desselben Modells), und auf Elternproduktebene nur für Produkte ohne Varianten.

Performance Max vs. Standard Shopping 2026

Seit 2022 drängt Google Performance Max (PMax) als Standardkampagne. Es ist eine automatisierte Kampagne, die Shopping, Display, YouTube, Discover und Search in einer einzigen Optimierungslogik kombiniert. Der Algorithmus entscheidet, wo die Anzeigen platziert werden und für wen. Der Werbetreibende liefert die Asset Groups (Texte, Bilder, Zielgruppensignale) und das Budget.

Wann PMax rentabel ist

• Großer Katalog (1.000+ Referenzen) mit vielfältiger Kategorieabdeckung.
• Solide Konversionsdaten (50+ Konversionen / 30 Tage pro Kampagne, idealerweise 100+).
• Margen, die einen vom Algorithmus optimierten CPA tragen (zwischen +15 und +30 % CPA vs. Standard, aber Volumen × 2 bis × 5).
• Fähigkeit, die Segmente über die Berichte zu Asset Groups und Zielgruppensignalen zu analysieren (Berichte sind begrenzt, aber seit 2024 in Verbesserung).

Wann Standard Shopping vorzuziehen bleibt

• Spezialisierter Katalog (weniger als 200 Referenzen), bei dem die granulare Kontrolle pro Produktgruppe kritisch ist.
• Enge Margen, die einen strikten CPA und einen stabilen ROAS verlangen.
• Regulierte Kategorien (CBD, Vape, bestimmte Nahrungsergänzungsmittel), bei denen PMax die Zielausrichtung auf nicht konforme Weise erweitern kann.
• Lernphase: Es ist besser, 3 Monate lang in Standard Shopping zu strukturieren, um die Performance pro Segment zu messen, bevor man mit diesen Erkenntnissen auf PMax umstellt.

Der hybride Stack 2026

Das heute funktionierende Muster: Standard Shopping auf den Top 20 % des Katalogs, der 80 % des Umsatzes macht, PMax auf den Long Tail. So kombiniert man Kontrolle (strategische Top-Produkte) und Automatisierung im Maßstab (Long Tail, bei dem manuelle Optimierung nicht rentabel ist).

Der Export des PrestaShop-Feeds: drei Architekturen

Architektur 1 – Statischer, regenerierter XML/CSV-Feed

Ein PHP-Cron (stündlich oder nachts, je nach Katalogrhythmus) generiert eine XML- oder CSV-Datei neu, die unter einer festen URL bereitgestellt wird. Das Merchant Center zieht diese Datei in einer konfigurierten Frequenz ab. Einfach, robust, aber mit mehrstündiger Latenz zwischen einer Änderung und ihrer Sichtbarkeit in Shopping.

Architektur 2 – Content-API-Push

Das Modul sendet Änderungen in Echtzeit über die Google Content API. Ideal für Shops, bei denen die Preise häufig schwanken (Flash-Sales, Dynamic Pricing), oder für begrenzte Bestände. Komplexer in der Umsetzung, erfordert ein Content-API-Kontingent und eine sorgfältige Fehlerbehandlung.

Architektur 3 – Echtzeit-Feed über Merchant Center Next

Seit 2024 unterstützt Merchant Center Next Real-Time Inventory Updates für kritische Attribute (Preis, Lagerbestand, Verfügbarkeit). Es ist ein dedizierter Endpunkt, unabhängig vom Hauptfeed. Das 2026 empfohlene Muster ist die Kombination: ein statischer Feed für stabile Daten (Titel, Bild, Beschreibung) und ein Echtzeit-Push für Preis und Bestand.

Das DataFirefly-Modul implementiert die statische Architektur mit einer Option für Preis-/Bestand-Push – und deckt damit 95 % der Händler-Fälle ohne API-Gateway-Komplexität ab.

Merchant-Center-Konformität: die 2024-2026-Richtlinien, die ablehnen

Vier Richtlinien stehen 2026 hinter 80 % der Ablehnungen:

1. Referenzpreis – Omnibus-Richtlinie und damit ausgerichtete Google-Policy

Wenn Sie einen durchgestrichenen Preis anzeigen („99 € statt 149 €“), muss der Referenzpreis der Omnibus-Richtlinie entsprechen: der niedrigste in den letzten 30 Tagen praktizierte Preis. Google hat seine Policy daran ausgerichtet: ein nicht konformer Referenzpreis = Ablehnung, und das wird über das gesamte Konto verfolgt.

2. Eingeschränkte und verbotene Produkte

Tabak, Waffen, Inhalte für Erwachsene, verschreibungspflichtige Medikamente: verboten. Nahrungsergänzungsmittel, Vape (ohne Nikotin), CBD: eingeschränkt, mit länderspezifischen Regeln. Die Ablehnung eines einzigen eingeschränkten Produkts kann bei Wiederholung zu einer Kontosperre führen – im PrestaShop-Feed immer filtern, um diese Kategorien aus dem Export auszuschließen.

3. Inkohärente Verfügbarkeit

Der Feed sagt in_stock, die Seite zeigt „Nicht auf Lager“ oder eine deaktivierte Schaltfläche. Google vergleicht und lehnt ab. Die Lösung: den Feed mit dem realen Bestand pro Variante synchronisieren, mit einem Schwellenwert (z. B. availability = out_of_stock, wenn quantity ≤ 0 und allow_oosp = false).

4. Nicht deklarierte Rückgabe- und Versandrichtlinie

Seit 2025 verlangt Google explizit die Rückgabe- und Versandrichtlinien. Entweder über die Merchant-Center-Kontoeinstellungen (globale Richtlinien pro Land) oder über die Attribute shipping und return_policy im Feed. Ohne dies: permanentes Warning und Verschlechterung des Quality Score.

Performance messen – über den Merchant-Center-ROAS hinaus

Der von Google Ads angezeigte ROAS ist die Oberflächenmetrik. Um richtig zu steuern, drei weitere Lesarten:

• Netto-ROAS = (Brutto-Umsatz × Margenrate) / Werbekosten. Der Google-ROAS berücksichtigt nicht die Produktmarge. Ein ROAS von 8 bei Produkten mit 15 % Marge ist weniger rentabel als ein ROAS von 4 bei Produkten mit 45 % Marge.
• Inkrementalität: Wie viele dieser Verkäufe hätten ohne Shopping stattgefunden (über organisches SEO, Markenrückkehrer, anderen Kanal)? Test: PMax 14 Tage auf einem Segment pausieren und den Umsatz-Delta messen. Sauber schwer durchzuführen, aber kritisch für Budgets über 20 K€/Monat.
• Akquisitionskosten new vs. returning. Shopping konvertiert massiv bei New (Akquisition). Um den LTV zu messen, mit dem CRM/Backoffice von PrestaShop über 6 bis 12 Monate kreuzen.

Die Implementierung von server-side GA4 Tracking ist 2026 unverzichtbar geworden, um diese Messungen zu zuverlässigem Datum zu machen, angesichts der Erosion der Third-Party-Cookies und dem Consent Mode v2.

Vernetzung mit den anderen SEO/AEO-Signalen

Google Shopping lebt nicht isoliert. Die KI-Agenten – Google AI Overviews, ChatGPT Shopping, Perplexity – lesen sowohl den Shopping-Feed (über die Merchant Center API) als auch die strukturierten Schema.org-Daten der Seite und den semantischen Inhalt der Website. Drei sich gegenseitig verstärkende Optimierungen:

• Die llms.txt-Datei, die als Index für die LLMs dient.
• Vollständiges Schema.org Product (mit hasMerchantReturnPolicy, shippingDetails, aggregateRating) für das organische Matching.
• Konformer Shopping-Feed mit reichen Attributen (GTIN, brand, gender, material, age_group).

Bei Shops, die in alle drei investieren, beobachten wir eine starke Korrelation zwischen der Qualität des Shopping-Feeds und den KI-Zitierungen in den KI-Shopping-Agenten.

Realistisches Budget für den Start 2026

Für einen Mid-Market-PrestaShop-Shop, der Google Shopping startet:

• Feed-Modul: 149 € unbefristete Lizenz, oder 30 bis 80 €/Monat für SaaS-Alternativen.
• Initial-Setup: 1 bis 3 Arbeitstage (Mapping der Google-Taxonomie, GTIN-Validierung, Versand-/Steuereinrichtung). Das DataFirefly-Modul automatisiert 80 % dieses Setups.
• Ads-Budget: bei 30-50 €/Tag starten, bei stabilisiertem ROAS auf 200-500 €/Tag steigen. Der Lern-Sweetspot von PMax liegt bei etwa 50 Konversionen / 30 Tage.
• Partner-CSS: −20 % effektive CPC, kostenlos zu aktivieren nach Kontoeröffnung. Ab 5.000 €/Monat Budget rentabel.

Mit diesem Setup liegt der ROAS-Ziel-12-Monate bei 4 bis 8 bei Margen von 30-40 %, mit einem Payback der Einrichtung in den ersten beiden Monaten.

FAQ

Braucht man ein Google-Ads-Konto, um das Merchant Center zu nutzen?

Für bezahlte Shopping-Anzeigen ja. Aber das Merchant Center allein ermöglicht auch die Free Listings (kostenlose Anzeigen im Shopping-Tab und in der Search). Diese Listings konvertieren nicht so gut wie die bezahlten, aber es ist kostenloser Traffic, den kein Shop liegen lassen sollte.

Lassen sich Shopping-Anzeigen im B2B schalten?

Offiziell ist Shopping für B2C bestimmt. Aber B2B-Shops in PrestaShop stellen ihren öffentlichen Katalog in Shopping aus, um Leads zu generieren – das funktioniert, solange die Seite den Direktkauf ermöglicht. Die Preise müssen brutto angezeigt werden (oder mit dem Hinweis „zzgl. MwSt.“); Shops, die ausschließlich netto sind und eine Pro-Validierung erfordern, sind nicht zugelassen.

Was verursacht die Sperrung eines Merchant-Center-Kontos?

Drei Hauptursachen: Häufung von Ablehnungen ohne Korrektur (Google geht davon aus, dass Sie die Richtlinie nicht einhalten), wiederholtes Anlegen von Konten, um eine vorherige Sperrung zu umgehen (die Sperre wird über Domain, IBAN, Steuer-Identität verfolgt), oder das Vorhandensein eines verbotenen Produkts (Waffen, verschreibungspflichtige Medikamente). Bei einer Sperrung verlangt die Berufungsprozedur eine dokumentierte Korrektur, keine Entschuldigung.

Wie verwaltet man Aktionen und Sales über Shopping?

Google Merchant Promotions ermöglichen es, Promo-Codes an die Anzeigen anzuhängen. Der Code muss gültig sein, auf den Mindestwarenkorb anwendbar und konform mit der Omnibus-Richtlinie für den durchgestrichenen Preis. Für kalenderbasierte Sales (Black Friday, Sommerschlussverkauf) bereitet man die Anzeigen 7 bis 14 Tage im Voraus über den Feed vor und plant die PMax-Kampagne mit einem Budget × 2 oder × 3 für den Zeitraum. Siehe auch unsere Black-Friday-Checkliste.

Muss der Feed zweisprachig/mehrsprachig sein?

Ja, aber mit einem eigenen Feed pro Zielland/-sprache. Ein und dasselbe Produkt für Deutschland und Österreich wird über zwei Einträge im Merchant Center deklariert: einen mit language=de, feed_country=DE, Preis in EUR, Versand DE; einen mit language=de, feed_country=AT, Preis in EUR (oder anders, wenn die Strategie es rechtfertigt), Versand AT. Niemals ein Produkt mit demselben Feed in mehreren Ländern deklarieren: Das bricht das Matching und führt zur Ablehnung.

Zusammenfassend

Google Shopping 2026 ist kein Kanal, den man in 30 Minuten aktiviert. Es ist eine Produkt-Daten-Infrastruktur, die Strenge bei den GTINs, Sauberkeit beim Taxonomie-Mapping, regulatorische Konformität (Omnibus, Rückgabe, Versand) und Ausrichtung mit den SEO/AEO-Signalen des restlichen Sites erfordert. Für PrestaShop-Shops, die diese Investition tätigen, sind das typischerweise 15 bis 25 % des erworbenen Umsatzes mit einem ROAS von 4 bis 8 und einem Payback der Einrichtung in 60 Tagen.

Das Google-Shopping-PrestaShop-Modul von DataFirefly automatisiert die zeitaufwendigsten Elemente: Aufspaltung pro Variante, GTIN-Validierung, Mapping der Google-Taxonomie, XML/CSV-Export, Content-API-Integration. Für Shops, die weiter gehen möchten, identifiziert das vollständige Audit des Shopping-Kanals Konformitätslecks und schnelle Gewinne.

Nicht parallel zu vergessen: die Google-Search-Console-Integration, um die organische Performance parallel zum bezahlten zu verfolgen, und die semantische interne Verlinkung, um die thematische Autorität des Katalogs unabhängig vom Ads-Budget zu stärken.