Zwei Dinge machen 2026 zu keinem gewöhnlichen Jahr für jeden, der Produktdaten an Google liefert: Seit Dezember 2024 verlangt die EU-Produktsicherheitsverordnung (GPSR) zusätzliche Pflichtangaben im Feed – und am 18. August 2026 schaltet Google die Content API for Shopping endgültig ab. Wer seinen Feed programmatisch befüllt, ohne migriert zu haben, verliert an diesem Tag ohne Vorwarnung seine Sichtbarkeit bei Google Shopping.
Die meisten Anleitungen zum Merchant Center Feed behandeln beide Themen nicht. Sie erklären Titel-Optimierung, Bilder, GTINs – wichtig, aber taktisch. Dieser Leitfaden geht einen Schritt weiter: von den Pflichtattributen über systematische Fehlerbehebung bis zu den zwei strukturellen Themen, die über Sichtbarkeit in den nächsten zwölf Monaten entscheiden.
Was ist ein Google Merchant Center Feed?
Ein Google Merchant Center Feed ist die strukturierte Datenquelle, über die ein Online-Shop seine Produktinformationen an Google übermittelt – als Grundlage für Google Shopping-Anzeigen, kostenlose Produkteinträge und zunehmend auch für Googles KI-gestützte Shopping-Funktionen. Der Feed besteht aus einzelnen Produkteinträgen mit standardisierten Attributen (ID, Titel, Preis, Verfügbarkeit, Bild, GTIN u. a.), die Google gegen seine Produktdatenspezifikation prüft, bevor ein Produkt ausgespielt wird.
Technisch lässt sich ein Feed auf drei Wegen einspielen: als Datei-Upload (CSV, TSV, XML, XLS/XLSX), über eine per URL geplante automatische Abholung, oder programmatisch über eine API. Alle drei Wege landen im selben Datenqualitäts-Check, der bis zu 72 Stunden dauern kann – ein Grund, warum frisch hochgeladene Produkte nicht sofort erscheinen.
Pflichtattribute & Datenqualität
Acht Attribute bilden die Mindestanforderung, unter der Google ein Produkt gar nicht erst prüft: ID, Titel, Beschreibung, Link, Bild, Verfügbarkeit, Preis und Marke. Für den deutschen und europäischen Markt kommen zwei Attribute hinzu, die in vielen Anleitungen fehlen, aber rechtlich bindend sind, sobald ein Produkt nach Gewicht, Volumen, Länge oder Fläche verkauft wird.
| Attribut | Feld-Name | Status | Praxishinweis |
|---|---|---|---|
| ID | id | Pflicht | Eindeutig und dauerhaft — nach Vergabe nie ändern oder wiederverwenden |
| Titel | title | Pflicht | Produktattribute (Marke, Variante, Menge) statt Marketing-Sprache voranstellen |
| Beschreibung | description | Pflicht | Fließtext ohne Werbeversprechen, HTML wird ignoriert |
| Link | link | Pflicht | Muss auf eine kaufbare, indexierbare Landingpage zeigen, nicht durch robots.txt blockiert |
| Bild | image_link | Pflicht | Mind. 100 x 100 px, kein Wasserzeichen, kein Platzhalterbild |
| Verfügbarkeit | availability | Pflicht | Muss in Echtzeit mit dem tatsächlichen Lagerbestand übereinstimmen |
| Preis | price | Pflicht | Muss exakt dem Preis auf der Landingpage entsprechen, inkl. MwSt. |
| Marke | brand | Pflicht (bei den meisten Kategorien) | Herstellermarke, nicht der Shopname |
| GTIN | gtin | Empfohlen, faktisch Pflicht | Produkte mit korrekter GTIN performen laut Google 20–40 % besser in Auktionen |
| Grundpreis-Mengeneinheit | unit_pricing_measure | Pflicht bei Gewicht/Volumen/Länge/Fläche | Gesetzlich vorgeschrieben in DE/EU — ohne Angabe droht Ablehnung und Abmahnrisiko |
Die GTIN-Zeile verdient besondere Aufmerksamkeit: Produkte mit korrekter GTIN erzielen im Schnitt 20 bis 40 Prozent bessere Ergebnisse in Shopping-Auktionen als identische Produkte ohne Identifikator – ein Attribut, das offiziell “empfohlen” heißt, sich in der Praxis aber wie eine Pflichtangabe verhält.
Vollständigkeit schlägt Menge: Ein Feed mit den acht Pflichtattributen plus GTIN und korrekten Grundpreisangaben performt zuverlässiger als ein Feed mit 40 halb ausgefüllten Zusatzfeldern. Google gewichtet konsistente, verifizierbare Daten stärker als Datenmenge.
Feed-Fehler systematisch beheben
Die Diagnose-Seite im Merchant Center (Menüpunkt „Produkte” → „Diagnose”, in der neuen Oberfläche „Needs attention”) listet jedes Problem mit Ursache und betroffenen Produkten. Die meisten Ablehnungen fallen in vier wiederkehrende Kategorien:
- Preisabweichung — Der Feed-Preis stimmt nicht mit dem Preis auf der Landingpage überein, meist durch verzögerte Synchronisation bei Rabattaktionen.
- Verfügbarkeits-Mismatch — Ein Produkt wird als „auf Lager” gemeldet, obwohl der Shop es als ausverkauft führt.
- Blockierter oder fehlerhafter Link — Die robots.txt blockiert den Crawler, die URL leitet auf eine andere Seite weiter, oder die Landingpage liefert einen Fehlerstatus.
- Unzureichende Produktdatenqualität — Fehlende Pflichtattribute, generische Bilder, oder Titel, die keine Kategorie erkennen lassen.
Bei Datei-Uploads gilt zusätzlich eine harte Grenze von 4 GB pro Datei; bei Fehlermeldungen ohne erkennbare Ursache hilft häufig, einige Stunden zu warten und erneut hochzuladen, da Google-seitige Verarbeitungsfehler nicht immer sofort auftreten.
GPSR-Pflichtangaben im Feed
Seit dem 13. Dezember 2024 gilt die EU-Verordnung über die allgemeine Produktsicherheit (General Product Safety Regulation, GPSR) für die meisten Non-Food-Konsumgüter. Für Google Merchant Center bedeutet das: Zusätzlich zu den klassischen Produktattributen müssen Angaben zum Hersteller und, falls dieser nicht in der EU niedergelassen ist, zur „verantwortlichen Person” vorliegen.
Die verantwortliche Person kann der Hersteller selbst sein, ein EU-Importeur, ein von ihm bevollmächtigter Vertreter, oder — falls keiner davon in der EU ansässig ist — ein Fulfillment-Dienstleister. Erforderlich sind Name, Postanschrift und E-Mail-Adresse dieser Person, dazu produktspezifische Warnhinweise und Sicherheitsinformationen, sofern relevant.
Praktisch heißt das: Wer GPSR-Daten bereits für Amazon oder den eigenen Shop gepflegt hat, sollte dieselben Angaben strukturiert in den Google-Feed übernehmen, statt sie ein zweites Mal separat zu erfassen. Genau hier zeigt sich der Wert einer zentralen Datenquelle statt gepflegter Insellösungen pro Kanal — dazu mehr im Abschnitt zur Feed-Architektur.
Content API → Merchant API: Die Migration bis August 2026
Das ist der am meisten unterschätzte Termin für alle, die Produktdaten nicht manuell, sondern programmatisch einspielen — über eine eigene Systemanbindung, eine individuelle Shop-Integration oder ein PIM-System.
| Datum | Ereignis | Konsequenz |
|---|---|---|
| Bereits abgeschlossen | Umstellung der Merchant-Center-Oberfläche auf „Merchant Center Next" | Neue Begriffe wie „Data Sources" statt „Feeds" und „Needs attention" statt „Diagnose" — reine UI-Umstellung ohne technische Auswirkung |
| 28. Februar 2026 | Deadline für Beta-Nutzer der Merchant API (v1beta) | Wer die Beta-Version nutzt, muss auf die stabile v1 wechseln |
| 18. August 2026 | Content API for Shopping wird abgeschaltet | Programmatische Anbindungen ohne Migration verlieren ab diesem Datum ihren Feed-Zugang |
| Ab 1. September 2026 | Anfragen an die Content API schlagen zunehmend fehl | Kein Soft-Cutoff — der Ausfall kommt ohne weitere Vorwarnung |
Betroffen sind ausschließlich programmatische Anbindungen. Wer Produkte ausschließlich per manuellem Datei-Upload oder über Google Sheets pflegt, ist von der API-Migration nicht direkt betroffen — diese Wege bleiben unverändert bestehen. Für Shops auf Standardplattformen wie Shopify, Shopware oder WooCommerce übernehmen die jeweiligen Google-Shopping-Plugins die Migration in der Regel automatisch; die relevante Frage an den Plugin-Anbieter lautet, bis wann das Update ausgeliefert wird.
Kritisch wird es bei individuellen Anbindungen: eigenentwickelte Middleware, ein selbst gebautes PIM-Interface, oder ältere Agentur-Integrationen, die seit Jahren unverändert laufen. Hier braucht es einen konkreten Migrationsplan, keine Hoffnung auf automatische Kompatibilität. Die Merchant API selbst ist modular aufgebaut — Produkte, Inventar, Konten, Datenquellen und Reporting sind getrennte Teil-APIs, die einzeln angebunden werden können, was mittelfristig weniger Overhead bedeutet als die monolithische Content API, aber kurzfristig eine bewusste Migrationsentscheidung erfordert.
Feed-Architektur bei wachsenden Katalogen
Alle bisherigen Empfehlungen setzen voraus, dass Produktdaten manuell im Feed gepflegt oder über einfache Regeln transformiert werden. Das funktioniert bis zu einigen Hundert SKUs zuverlässig. Ab mehreren Tausend Produkten, mehreren Lieferanten oder mehreren Vertriebskanälen (Google, Amazon, Preisvergleichsportale, eigener Shop) wird die Frage strategisch: Wo liegt die Datenhoheit, und wie viele Systeme pflegen dieselbe Information parallel?
Drei Architekturen stehen typischerweise zur Wahl:
Manuelle Pflege direkt im Feed — praktikabel bis knapp unter tausend Produkten mit stabilem Sortiment. Jede Änderung an Titel, Kategorie oder GPSR-Angaben muss von Hand nachgezogen werden; das Fehlerrisiko wächst linear mit der Katalogbreite.
Attributregeln im Merchant Center — deckt wiederkehrende Transformationen ab (Titel-Templates, Kategorie-Zuordnung, Markenergänzung), löst aber nicht das Grundproblem, wenn Produktdaten in der Quelle (Shop-System, ERP) selbst unvollständig oder inkonsistent sind. Regeln transformieren, sie reparieren keine fehlenden Rohdaten.
Ein zentrales PIM-System als Datenquelle, aus dem Feeds für alle Kanäle automatisch generiert werden — Google, Amazon, der eigene Shop und Preisvergleichsportale ziehen aus derselben, kanalspezifisch aufbereiteten Datenbasis. Das lohnt sich, sobald Produktdaten von mehreren Personen oder Systemen gepflegt werden und Inkonsistenzen zwischen Kanälen bereits spürbar sind — nicht vorher. Ein PIM-System für einen Katalog mit zweihundert stabilen Produkten ist Overengineering.
Wer mehrere Vertriebskanäle parallel bespielt, sollte die Entscheidung nicht am Feed allein, sondern an der gesamten Systemlandschaft festmachen — ein Thema, das im Vergleich der gängigen Shopsysteme vertieft wird.
Automatisierung & Attributregeln richtig einsetzen
Attributregeln erlauben es, Bedingungen zu definieren — etwa „nur Produkte der Kategorie X” oder „nur wenn der Titel einen bestimmten Begriff enthält” — und darauf basierend Attribute automatisch zu setzen oder zu korrigieren. Vor der produktiven Anwendung lässt sich jede Regel im Vorschau-Modus oder an einer separaten Feed-Kopie testen, ohne das Live-Sortiment zu gefährden.
Sinnvolle erste Automatisierungen sind meist: fehlende Markenangaben pro Herstellerkategorie ergänzen, Titel nach einem festen Schema normalisieren (Marke + Produktart + Kernattribut + Menge), und GTINs aus einer separaten Stammdatentabelle nachtragen, wenn sie im Ursprungssystem fehlen. Größere Transformationen — etwa vollständige GPSR-Daten oder kanalspezifische Preislogik — gehören eher in die vorgelagerte Datenquelle als in eine Feed-Regel, weil sie sonst nur im Google-Feed korrekt sind, während Amazon und der eigene Shop weiterhin veraltete Daten zeigen.
Checkliste: Feed-Gesundheits-Check in 15 Minuten
FAQ
Wie lange dauert es, bis ein neu hochgeladenes Produkt im Merchant Center sichtbar ist?
Die Datenqualitätsprüfung kann bis zu 72 Stunden dauern. Erscheint ein Produkt danach nicht, liegt in der Regel ein Fehler vor, der auf der Diagnose-Seite aufgelistet wird — kein reines Zeitproblem mehr.
Muss ich meinen Feed umstellen, wenn ich Shopify, Shopware oder WooCommerce nutze?
In den meisten Fällen nicht direkt. Die Migration von Content API zu Merchant API betrifft programmatische Anbindungen; Standardplattformen liefern die Umstellung über ihre Google-Shopping-Plugins aus. Prüfen Sie beim Plugin-Anbieter, bis wann das Update verfügbar ist.
Was passiert, wenn ich die GPSR-Angaben nicht im Feed hinterlege?
Betroffene Produkte werden nicht zwingend sofort gesperrt, aber zunehmend als „needs attention” markiert und in der Sichtbarkeit eingeschränkt. Zusätzlich drohen unabhängig von Google wettbewerbsrechtliche Risiken, wenn Pflichtangaben auf der Landingpage selbst fehlen.
Lohnt sich ein PIM-System nur für den Google-Feed?
Nein. Ein PIM-System rechnet sich, wenn Produktdaten für mehrere Kanäle (Google, Amazon, eigener Shop, Preisvergleichsportale) parallel gepflegt werden und Inkonsistenzen zwischen diesen Kanälen bereits spürbar sind. Für einen Google-Feed allein reichen Attributregeln in der Regel aus.
Ist die Umbenennung zu 'Merchant Center Next' dasselbe wie die API-Migration?
Nein, das sind zwei getrennte Vorgänge. Die Umstellung auf „Merchant Center Next” betraf nur die Benutzeroberfläche und Terminologie und ist bereits abgeschlossen. Die Migration von der Content API zur Merchant API ist eine technische Umstellung mit Deadline 18. August 2026, die nur programmatische Anbindungen betrifft.
Wie finde ich heraus, ob meine Anbindung von der Migration betroffen ist?
Fragen Sie, wer den Datenimport ursprünglich gebaut hat: Läuft er über eine Standardplattform mit Plugin, ein PIM-System, oder eine Individualentwicklung? Nur bei einer Individualentwicklung ohne bestätigtes Update besteht akuter Handlungsbedarf.
Fazit
Ein Google Merchant Center Feed ist 2026 kein reines Marketing-Thema mehr, sondern eine technische und rechtliche Systemfrage. Wer Pflichtattribute und Grundpreisangaben sauber pflegt, GPSR-Angaben nicht vergisst und rechtzeitig klärt, ob eine Individualanbindung vor dem 18. August 2026 migriert werden muss, sichert sich Sichtbarkeit, während ein guter Teil des Wettbewerbs diese drei Punkte erst bemerkt, wenn Produkte plötzlich aus dem Sortiment verschwinden.
Die strategische Frage dahinter lautet nicht „Wie optimiere ich meinen Feed?”, sondern „Wo liegt meine Produktdatenhoheit, und wie viele Systeme pflegen dieselbe Information redundant?” Bei wachsenden Katalogen entscheidet diese Antwort mehr über langfristige Sichtbarkeit als jede einzelne Attribut-Optimierung.
Quellenverzeichnis
- Produktdatenspezifikation - Google Merchant Center-Hilfe
- Mengeneinheit für Grundpreis [unit_pricing_measure] - Google Merchant Center-Hilfe
- Attributregeln einrichten - Google Merchant Center-Hilfe
- Merchant API - Google Merchant Center-Hilfe
- Migrate from Content API for Shopping to Merchant API - Google for Developers
- Merchant-Center-Ablehnungen wegen Produktdatenqualität beheben - Google Merchant Center-Hilfe
- Verordnung über die allgemeine Produktsicherheit (GPSR) - IT-Recht Kanzlei
- Grundpreise bei Google Shopping: Wie und wo? - IT-Recht Kanzlei
