Warum werden meine Produkte im Google Merchant Center abgelehnt?

Wenn Google Merchant Center Produkte ablehnt, dürfen die betroffenen Angebote nicht auf den vorgesehenen Google-Flächen erscheinen. Die Ursache liegt gewöhnlich in einer von drei Ebenen: Die eingereichten Produktdaten entsprechen nicht der Spezifikation, die Angaben passen nicht zur Landingpage oder Google erkennt einen Verstoß gegen Shopping-Richtlinien beziehungsweise Anforderungen an die Website.

Die sichtbare Fehlermeldung ist dabei der Startpunkt, nicht immer die eigentliche Ursache. Ein Hinweis auf Preisabweichung kann durch einen veralteten Feed entstehen, aber auch durch strukturierte Daten, Währungslogik, Variantenwahl oder einen regional anderen Preis auf der Seite. Wer nur den einzelnen Artikel manuell korrigiert, lässt den fehlerhaften Datenweg bestehen.

Der Produktstatus beschreibt die Ausspielbarkeit

Merchant Center unterscheidet unter anderem zwischen in Prüfung, genehmigt, eingeschränkt und nicht genehmigt. Ein eingeschränktes Produkt kann noch erscheinen, aber nicht in allen vorgesehenen Fällen. Ein nicht genehmigtes Produkt wird für den betroffenen Zielbereich nicht ausgespielt, bis die Ursache behoben und die Änderung verarbeitet wurde.

Der Status kann außerdem nach Land, Marketingmethode oder Datenquelle variieren. Ein Angebot ist deshalb nicht pauschal „bei Google freigegeben“, nur weil es in einem Markt oder für kostenlose Einträge sichtbar ist. Diagnose und Test müssen den konkreten Zielmarkt und das geplante Programm einbeziehen.

Warnung, Ablehnung und Kontoproblem sind nicht dasselbe

Warnungen weisen auf eine Abweichung hin, ohne das Produkt sofort vollständig auszuschließen. Eine Produktablehnung betrifft einzelne Angebote. Probleme auf Kontoebene können dagegen einen großen Teil oder den gesamten Bestand beeinträchtigen. Diese Reichweite bestimmt die Priorität und die Art der Reparatur.

Beginne deshalb immer mit drei Fragen: Welche Ebene nennt Google, wie viele Angebote sind betroffen und seit wann besteht der Befund? Erst danach wird nach Attribut, Template, Feedquelle oder Richtlinie gesucht.

Eine Ablehnung ist kein Kampagnenproblem

Gebote, Ziel-ROAS oder Kampagnenstruktur können ein abgelehntes Produkt nicht wieder verfügbar machen. Solange Merchant Center das Angebot nicht genehmigt, fehlt Google Ads die ausspielbare Grundlage. Die Reparatur liegt in Produktdaten, Shoptechnik oder Richtlinienkonformität.

Das macht Ablehnungen besonders geschäftskritisch: Ein Kampagnenteam kann Budgets optimieren, aber einen blockierten Katalog nicht durch Steuerung kompensieren. Shop, Datenquelle und Werbung müssen denselben Befund gemeinsam bearbeiten.

Merchant Center bündelt viele Fehler im Bereich „Überprüfung erforderlich“. Für eine belastbare Diagnose werden sie nach Reichweite und Ursprung getrennt. Ein einzelner fehlender Wert verlangt eine andere Reaktion als eine systematische Preisabweichung oder eine Kontowarnung wegen der Website.

Produktprobleme betreffen konkrete Angebote

Auf Produktebene zeigt Google, welches Attribut, welche Landingpage oder welche Richtlinie beanstandet wird. Öffne mehrere betroffene Beispiele und vergleiche sie mit genehmigten Produkten derselben Quelle. So wird erkennbar, ob eine bestimmte Kategorie, Variante oder Regel die Ablehnung auslöst.

Ein einzelner Fehler kann tatsächlich im Datensatz liegen. Häufen sich identische Meldungen, ist ein gemeinsamer Generator wahrscheinlicher: Exportregel, Shop-App, Mapping oder Template. Dann wird zuerst die Quelle repariert und anschließend der Bestand neu synchronisiert.

Kontoprobleme haben größere Reichweite

Probleme auf Kontoebene können Websiteanforderungen, Richtlinien oder die grundlegende Geschäftsidentität betreffen. Sie werden nicht durch Änderungen an einem Produkt gelöst. Prüfe die genaue Meldung, betroffene Länder und die von Google genannten Anforderungen, bevor du eine Überprüfung anstößt.

Eine Kontosperrung sollte nicht mit wiederholten, unvorbereiteten Einsprüchen beantwortet werden. Google begrenzt bei bestimmten Problemen die Zahl möglicher Überprüfungen. Die technische und inhaltliche Korrektur muss deshalb abgeschlossen und belegbar sein.

Datenquellen können widersprüchliche Werte liefern

Produkte gelangen über Datei, automatischen Abruf, API, Shop-Integration oder zusätzliche Datenquelle ins Merchant Center. Ergänzende Quellen können Attribute überschreiben. Automatische Website-Updates können Preis oder Verfügbarkeit korrigieren, sind aber kein Ersatz für einen stabilen Hauptfeed.

Dokumentiere für ein Beispielprodukt, welcher endgültige Wert im Merchant Center steht und aus welcher Quelle er stammt. Ein korrekter Wert im Shopsystem beweist nicht, dass dieselbe Fassung übertragen oder nach einer Zusatzregel erhalten wurde.

Die Reichweite zeigt den wahrscheinlichsten Hebel

Ein Fehler bei nahezu allen Produkten deutet auf Konto, Feedstruktur oder globales Template. Ein Fehler in einer Marke kann am Identifier-Mapping liegen. Abweichungen bei reduzierten Artikeln sprechen eher für Preis- oder Aktionslogik. Dieses Muster ersetzt keine Prüfung, priorisiert sie aber sinnvoll.

Erstelle eine kleine Stichprobe aus betroffenen und genehmigten Produkten. Vergleiche Quelle, Kategorie, Variante, Markt und Fehlertyp. So entsteht aus einer langen Fehlerliste eine überschaubare Zahl technischer Ursachen.

Ein Zeitvergleich trennt Bestand von neuer Regression

Prüfe, ob die Meldungen seit der ersten Einreichung bestehen oder nach einer konkreten Änderung begonnen haben. Ein neuer Export, eine Shop-App, ein Theme-Release oder eine Marktaktivierung kann eine ganze Fehlerklasse gleichzeitig erzeugen. Der Veröffentlichungszeitpunkt liefert dann einen stärkeren Hinweis als die Betrachtung einzelner Produkte.

Vergleiche dafür einen betroffenen Datensatz vor und nach der Änderung, sofern ein Export oder eine Versionshistorie vorhanden ist. Relevant sind nicht nur sichtbare Werte, sondern auch URL, Varianten-ID, Sprache und Quelle. Eine scheinbar harmlose Änderung der Feed-ID kann aus einem bestehenden Angebot einen neuen, ungeprüften Datensatz machen.

Google vergleicht eingereichte Produktdaten mit den Informationen auf der Zielseite. Stimmen Preis oder Verfügbarkeit nicht überein, kann das Angebot vorbeugend abgelehnt werden. Der Vergleich betrifft nicht nur sichtbaren Text, sondern auch strukturierte Daten und die vom Crawler tatsächlich erreichbare Variante.

Der richtige Preis hängt von Variante und Markt ab

Ein Feed kann auf eine konkrete Größe oder Farbe verweisen, während die Landingpage zunächst eine günstigere Standardvariante zeigt. Auch Währung, Steuerdarstellung, Kundengruppe und Standort können den sichtbaren Betrag verändern. Google muss auf der Ziel-URL den Preis des eingereichten Angebots eindeutig nachvollziehen können.

Prüfe deshalb nicht nur den Betrag im Backend. Öffne die exakte Feed-URL ohne eingeloggte Sitzung, im vorgesehenen Zielland und mit derselben Variante. Vergleiche sichtbaren Preis, strukturierte Daten und den im Merchant Center gespeicherten Wert.

Aktionspreise brauchen Anfang, Ende und Rückfalllogik

Rabatte werden häufig im Shop aktiviert, bevor der Feed aktualisiert ist, oder laufen aus, während eine alte Exportdatei weiter den reduzierten Preis liefert. Eine saubere Aktionslogik synchronisiert regulären Preis, Angebotspreis und Gültigkeit. Nach Ende der Aktion muss der normale Wert in allen Systemen wieder konsistent erscheinen.

Vermeide Zeitfenster, in denen Website und Datenquelle unterschiedliche Veröffentlichungsstände haben. Bei häufigen Preisänderungen sind Aktualisierungsrhythmus und API-Verarbeitung Teil der Kampagnenfähigkeit.

Bestand braucht eine gemeinsame Wahrheit

Das Attribut availability muss zum tatsächlich bestellbaren Zustand passen. Ein Artikel kann im Warenwirtschaftssystem Bestand haben, im Shop aber wegen fehlender Variante, Marktfreigabe oder Lieferregel nicht kaufbar sein. Umgekehrt darf ein Feed kein out_of_stock melden, wenn die Zielseite das Produkt regulär in den Warenkorb legt.

Reservierungen, Vorbestellungen und Nachbestellungen benötigen eine eindeutige fachliche Zuordnung. Die Bezeichnung im Shop allein genügt nicht; der übertragene Merchant-Center-Wert muss zur realen Bestellmöglichkeit passen.

Automatische Updates sind ein Sicherheitsnetz

Merchant Center kann bestimmte Abweichungen über erkannte Websiteinformationen automatisch aktualisieren. Das verringert kurzfristig Fehler, löst aber keine falsche Feedquelle. Wenn Google laufend korrigieren muss, bleiben Reporting, andere Kanäle und spätere Crawls instabil.

Nutze automatische Updates als Absicherung und überwache dennoch die Ursache. Ziel ist eine Datenkette, in der Shop, strukturierte Daten und Feed denselben aktuellen Zustand ausgeben.

Cache und Aktualisierungstakt gehören zur Ursache

Zwischen Warenwirtschaft, Shop, CDN, strukturierten Daten und Feed können mehrere Zwischenspeicher liegen. Eine Preisänderung erscheint dann im Backend sofort, auf der Produktseite später und im Feed erst beim nächsten Export. Google sieht währenddessen widersprüchliche Fassungen, obwohl jede einzelne Komponente für sich planmäßig arbeitet.

Zeichne für kritische Attribute den erwarteten Aktualisierungsweg auf: Wo entsteht der Wert, welcher Prozess überträgt ihn, welcher Cache hält ihn zurück und wann wird die Zielseite neu aufgebaut? Danach lässt sich entscheiden, ob Exporte häufiger laufen, Caches gezielt invalidiert oder Preisänderungen koordiniert veröffentlicht werden müssen. Ein manuelles Nachladen einzelner Produkte ist keine dauerhafte Synchronisationsstrategie.

Ein korrekter Feed hilft nicht, wenn Google die angegebene Landingpage nicht zuverlässig abrufen kann. Serverfehler, blockierte Ressourcen, langsame Antworten, Weiterleitungen oder eine allgemeine Kategorieseite verhindern den Abgleich. Die URL ist deshalb ein Datenattribut und zugleich ein technischer Vertrag.

Die Ziel-URL muss genau zum Angebot führen

Jeder Link sollte das eingereichte Produkt und bei Bedarf die passende Variante öffnen. Eine Weiterleitung zur Startseite, Suche oder Oberkategorie ist kein gleichwertiges Ziel. Wenn ein Produkt dauerhaft entfernt wurde, braucht es auch im Feed eine saubere Entfernung statt einer kosmetischen Umleitung.

Trackingparameter dürfen die Seite nicht verändern oder einen anderen Markt wählen. Teste die vollständige Feed-URL, nicht nur ihre bereinigte Basis. Auch Parameterreihenfolge und Kodierung können bei Varianten oder Sprachversionen relevant sein.

Googlebot braucht Zugriff auf Seite und Bilder

robots.txt, Firewall, Bot-Schutz und Login dürfen die erforderlichen Crawler nicht blockieren. Google nennt blockierte Seiten oder Bilder ausdrücklich als mögliche Ursache für Probleme. Ein Browseraufruf aus dem Firmennetz beweist nicht, dass Googles Systeme dieselbe Antwort erhalten.

Prüfe Serverstatus, Weiterleitungskette und ausgelieferte Inhalte mit passenden User-Agents und in den Zielregionen. Ein Schutzsystem sollte bösartige Zugriffe begrenzen, ohne legitime Produkt-Crawls pauschal abzuweisen.

Die Seite braucht vollständige kaufrelevante Angaben

Produktname, Preis, Verfügbarkeit und Kaufmöglichkeit müssen klar erkennbar sein. Fehlende oder inkonsistente Informationen erschweren nicht nur den automatischen Abgleich, sondern können auch Websiteanforderungen berühren. Platzhaltertexte und leere Templates sind keine veröffentlichungsfähigen Produktseiten.

Bei clientseitig geladenen Daten wird geprüft, ob Google die endgültigen Werte zuverlässig rendern kann. Server- oder statisch ausgegebene Kerndaten reduzieren Abhängigkeiten, während interaktive Auswahl weiterhin im Browser funktionieren darf.

Strukturierte Daten und sichtbarer Inhalt müssen zusammenpassen

Google kann strukturierte Produktdaten als zusätzliche Quelle heranziehen. Wenn Markup einen alten Preis, eine andere Währung oder falsche Verfügbarkeit enthält, widerspricht es dem sichtbaren Angebot. Häufig entsteht das durch getrennte Templates oder Cache-Schichten.

Validiere Markup und sichtbare Ausgabe gemeinsam. Der Wert muss aus derselben fachlichen Quelle stammen, damit eine Preisänderung nicht nur an einer Stelle ankommt.

Mobil und Desktop dürfen keinen anderen Kaufzustand zeigen

Responsive Oberflächen können Informationen anders anordnen, sollten aber denselben Preis, dieselbe Verfügbarkeit und dasselbe Produkt ausgeben. Problematisch sind getrennte mobile Templates, nachgeladene Sticky-Kaufboxen oder Variantenwähler, die auf einem Gerät einen anderen Standard setzen. Google und Nutzer müssen aus beiden Darstellungen denselben fachlichen Zustand ableiten können.

Teste repräsentative URLs daher mit verschiedenen Viewports und ohne vorhandene Shop-Cookies. Achte darauf, ob Standortabfragen, App-Banner oder Pop-ups den Produktinhalt verdecken oder einen Crawl in eine Sackgasse führen. Die Lösung liegt im robusten Template, nicht in einer Sonderseite nur für den Crawler.

Die Merchant-Center-Produktspezifikation definiert, welche Attribute je Produkt, Land und Angebotsart erforderlich sind und in welchem Format sie übertragen werden. Ein Feed kann technisch importiert werden und dennoch Produkte verlieren, wenn einzelne Werte fehlen, ungültig sind oder nicht zur Produktart passen.

Identität beginnt mit einer stabilen ID

Das Attribut id identifiziert ein Angebot innerhalb des Kontos. Es sollte stabil bleiben, solange dasselbe Produkt verkauft wird. Wechselnde IDs trennen Historie, Status und Kampagnenzuordnung. Sie sind kein geeignetes Mittel, um eine Ablehnung zu umgehen oder ein Produkt künstlich neu erscheinen zu lassen.

Bei Varianten muss das Modell konsistent sein: eigene Angebots-ID je Variante, gemeinsame item_group_id für die Gruppe und passende Variantenattribute. Wenn alle Varianten dieselbe ID teilen, überschreiben sie sich oder werden uneindeutig.

Titel und Beschreibung müssen das Produkt beschreiben

Titel und Beschreibung sollen das tatsächliche Angebot wiedergeben. Werbeslogans, Großschreibung oder nicht vorhandene Eigenschaften erzeugen keine bessere Datenqualität. Wichtig sind unterscheidende Merkmale wie Produkttyp, Marke, Modell, Größe oder Material, soweit sie für die Auswahl relevant und tatsächlich vorhanden sind.

Die Landingpage muss diese Angaben tragen. Ein Feed darf kein anderes Produktversprechen aufbauen als der Shop. Bei automatischer Texterzeugung werden Stichproben auf abgeschnittene, vermischte oder erfundene Merkmale geprüft.

Kategorie und Produkttyp erfüllen unterschiedliche Aufgaben

google_product_category ordnet das Angebot einer von Google definierten Taxonomie zu. product_type bildet die eigene Shopstruktur ab. Beide können ähnlich wirken, folgen aber unterschiedlichen Vokabularen. Ein eigener Kategoriename gehört nicht automatisch in das Google-Attribut.

Die Zuordnung sollte regelbasiert und überprüfbar sein. Pauschale Standardwerte für den ganzen Katalog können Verarbeitung und Kampagnenstruktur verschlechtern, selbst wenn sie nicht jede Position sofort ablehnen.

Landesspezifische Angaben gehören in den Export

Versand, Steuern, Sprache, Währung und Verfügbarkeit müssen zum Zielmarkt passen. Merchant Center kann Anforderungen je Land unterschiedlich bewerten. Ein globaler Feed ohne klare Marktlogik produziert deshalb leicht Fehler, die nur einen Teil der Ausrichtung betreffen.

Prüfe pro Zielmarkt ein vollständiges Beispielprodukt vom Quellsystem bis zur Landingpage. Erst wenn diese vertikale Kette stimmt, wird der gesamte Bestand erneut übertragen.

Zusatzquellen brauchen eine definierte Priorität

Ergänzende Datenquellen können ausgewählte Attribute anreichern oder überschreiben. Das ist nützlich, wenn ein Hauptfeed bestimmte Kampagnenlabels nicht kennt, wird aber riskant, sobald dieselbe fachliche Information aus mehreren Quellen kommt. Ein alter Zusatzfeed kann einen gerade korrigierten Preis oder Titel erneut verändern.

Führe deshalb ein Quellenregister: Welche Quelle liefert welche Attribute, für welche Produkte gilt sie und wann wird sie aktualisiert? Entferne überholte Regeln vollständig. In den Produktdetails lässt sich anschließend prüfen, welcher endgültige Wert verwendet wird. So bleibt nachvollziehbar, ob die Reparatur im Shop, im Export oder in einer ergänzenden Regel erfolgen muss.

Globale Produktkennzeichnungen helfen Google, ein Angebot dem richtigen Produkt zuzuordnen. Dazu gehören je nach Produkt Marke, GTIN oder MPN. Fehler entstehen, wenn Händler fremde Nummern erfinden, Varianten dieselbe Kennzeichnung erhalten oder das Fehlen einer Kennzeichnung falsch deklarieren.

Vorhandene Kennzeichnungen werden vollständig übertragen

Bei handelsüblichen Markenprodukten sollten die vom Hersteller vergebenen Kennzeichnungen verwendet werden. Die Nummer muss zur konkreten Variante gehören, nicht nur zur Produktfamilie. Eine GTIN einer anderen Größe oder Packung macht den Datensatz nicht vollständiger, sondern falsch.

Die Quelle dafür sollte im Produktstamm liegen. Manuelle Ergänzungen direkt im Feed gehen bei der nächsten Synchronisation verloren und lassen sich schlecht pflegen. Wenn Daten fehlen, wird zuerst geklärt, ob der Hersteller sie bereitstellt.

identifier_exists ist keine Abkürzung

Das Attribut identifier_exists teilt mit, ob für ein Produkt eindeutige Kennzeichnungen existieren. Es wird nicht auf false gesetzt, nur weil sie im eigenen System gerade fehlen. Für kundenspezifische oder tatsächlich nicht gekennzeichnete Produkte kann der Wert passend sein; für reguläre Markenware wäre er eine falsche Aussage.

Lege für Produkttypen klare Regeln fest und prüfe Ausnahmen. So verhindert der Export, dass eine pauschale Einstellung den gesamten Katalog verfälscht.

Varianten müssen in Daten und Zielseite zusammenpassen

Farbe, Größe, Material oder Muster unterscheiden Varianten. Feed, Bild und Link sollten dieselbe Ausprägung zeigen. Wenn der Link eine schwarze Jacke öffnet, das Bild eine rote Variante zeigt und die GTIN zur blauen gehört, kann Google das Angebot nicht eindeutig bewerten.

Die Variantenauswahl auf der Landingpage sollte über die URL oder einen stabilen Zustand reproduzierbar sein. Eine zufällige Standardvariante macht den automatischen Abgleich unzuverlässig.

Produktbilder brauchen Zugriff und sachlichen Inhalt

Das Hauptbild muss das Produkt klar darstellen und für Google abrufbar sein. Platzhalter, fehlerhafte URLs oder blockierte Bild-CDNs verhindern die Nutzung. Zusätzliche Bilder können Perspektiven zeigen, dürfen aber die Zuordnung nicht verwirren.

Prüfe Bildantworten, Weiterleitungen und Aktualisierung. Wenn ein Bild unter derselben URL ausgetauscht wurde, können Cache und erneuter Crawl zeitversetzt reagieren. Eine neue Einreichung ersetzt keine funktionierende Bildquelle.

Nicht jede Ablehnung ist ein Formatfehler. Google prüft auch, ob Produkte und Website die Shopping-Richtlinien erfüllen. Bestimmte Inhalte sind untersagt oder eingeschränkt; außerdem muss die Website einen nachvollziehbaren Kaufprozess und konsistente Unternehmensinformationen bieten. Solche Befunde verlangen mehr als eine Feedkorrektur.

Die genaue Richtlinie bestimmt die Reaktion

Öffne die Problemdetails und lies die genannte Richtlinie für das betroffene Land. Ähnliche Meldungen können unterschiedliche Ursachen haben. Ein eingeschränktes Produkt benötigt möglicherweise andere Angaben oder Zielgruppenlogik, während ein unzulässiges Angebot aus der Datenquelle entfernt werden muss.

Versuche nicht, eine beanstandete Eigenschaft durch andere Schreibweise zu verstecken. Richtlinien gelten für Produkt, Seite und Geschäftsmodell, nicht nur für einzelne Feedbegriffe.

Website und Unternehmen müssen zusammenpassen

Kunden sollen erkennen können, wer verkauft, wie sie bestellen und welche Bedingungen gelten. Fehlende oder widersprüchliche Kontakt-, Zahlungs- oder Rückgabeinformationen können das Vertrauen in die Website beeinträchtigen. Diese Angaben müssen zum realen Angebot und Zielmarkt passen.

Eine technische Shopvorschau, Baustellenseite oder Domain mit Platzhalterinhalten ist keine belastbare Grundlage für eine Kontoüberprüfung. Schließe Website und Kaufprozess ab, bevor der vollständige Katalog beworben wird.

Der Checkout gehört zur Prüfung

Das Produkt muss zum beworbenen Preis tatsächlich kaufbar sein. Unerwartete Pflichtkosten, nicht verfügbare Lieferländer oder ein defekter Warenkorb widersprechen der Darstellung auf der Landingpage. Führe deshalb einen Testkauf bis vor den verbindlichen Abschluss durch und prüfe die Marktbedingungen.

Bei B2B-Angeboten, Mindestmengen oder individuellen Preisen muss klar sein, ob das Merchant-Center-Format zur tatsächlichen Verkaufssituation passt. Ein öffentlich genannter Standardpreis darf nicht nur unter versteckten Voraussetzungen gelten.

Kontoprobleme werden zentral behoben

Wenn ein Richtlinienbefund das Konto betrifft, werden Website, Datenquellen und alle relevanten Länder gemeinsam betrachtet. Einzelne Produkte neu einzureichen erzeugt keine stabile Lösung. Dokumentiere die Korrekturen und prüfe, dass alte Quellen die beanstandeten Daten nicht erneut hochladen.

Bei rechtlich oder fachlich strittigen Produkten gehört die Bewertung an die zuständige Stelle. Technische Teams können den Befund und Datenweg erklären, aber keine rechtliche Freigabe ersetzen.

Ein größerer Katalog kann gleichzeitig viele Warnungen und Ablehnungen enthalten. Wer jede Zeile nacheinander bearbeitet, verliert Zeit und übersieht gemeinsame Ursachen. Eine wirksame Priorisierung gruppiert Probleme nach Fehlerklasse, Quelle, Template und geschäftlicher Bedeutung.

Kontoweite Blocker kommen zuerst

Ein Problem auf Kontoebene oder eine fehlerhafte Hauptquelle kann alle nachgelagerten Produktkorrekturen überdecken. Bearbeite zuerst Befunde mit größter Reichweite. Danach folgen systematische Fehler in Preis, Verfügbarkeit, URL oder Kennzeichnung.

Warnungen werden nicht ignoriert, aber nach ihrem Risiko eingeordnet. Ein Hinweis, der künftig zur Ablehnung führen kann, gehört in den Plan; eine akute Sperre ausspielungsstarker Produkte hat dennoch Vorrang.

Produkte werden in repräsentative Gruppen geteilt

Erstelle Gruppen nach Quelle, Kategorie, Marke, Variante und Fehlermeldung. Wähle aus jeder Gruppe ein typisches Beispiel und einen Sonderfall. Wenn die Ursache dort behoben ist, teste die Regel auf einer kleinen Menge, bevor sie den ganzen Feed verändert.

So verhindert das Team, dass eine globale Korrektur andere Produktgruppen beschädigt. Besonders bei Mappingregeln und Variantenlogik ist ein kontrollierter Test sicherer als ein sofortiger Vollimport.

Kampagnendaten helfen bei der Reihenfolge

Ausspielungs- und Geschäftsdaten zeigen, welche genehmigungsfähigen Produkte besonders relevant sind. Sie dürfen Richtlinien nicht umgehen, helfen aber, Reparaturen sinnvoll zu staffeln. Saisonale Sortimente benötigen rechtzeitig stabile Daten, nicht erst am Starttag der Kampagne.

Wenn wir Shopping-Kampagnen samt Datenqualität laufend steuern, werden Merchant-Center-Befunde deshalb mit Sortiment und Kampagnenstruktur verbunden. Ein technischer Fehler erhält dadurch einen fachlichen Kontext, ohne dass Werbeoptimierung seine Ursache verdeckt.

Jede Fehlergruppe erhält einen Owner

Feed-Mapping, Shoptemplate, Produktpflege, Recht und Kampagnenkonto liegen oft bei verschiedenen Personen. Weise jeder Ursache eine verantwortliche Rolle und einen überprüfbaren Abschluss zu. „Marketing kümmert sich“ ist zu ungenau, wenn die Reparatur im ERP oder Theme erfolgen muss.

Ein kurzes Fehlerboard reicht: Meldung, Reichweite, Beispiel, vermutete Quelle, Owner, Korrektur und Prüfergebnis. So bleibt sichtbar, ob eine Meldung wirklich behoben oder nur kurzfristig verschwunden ist.

Nach einer Korrektur braucht Merchant Center aktuelle Produktdaten und eine erreichbare Website. Je nach Problem verarbeitet Google die Änderung automatisch oder bietet eine Überprüfung beziehungsweise einen Einspruch an. Diese Aktion sollte erst erfolgen, wenn der beanstandete Zustand wirklich behoben ist.

Die Reparatur beginnt im führenden System

Preis und Bestand werden im Shop oder Warenwirtschaftssystem korrigiert, Mappingfehler im Export und Templatefehler im Websitecode. Eine manuelle Änderung direkt im Merchant Center kann für einen Test nützlich sein, wird aber von der nächsten Synchronisation überschrieben, wenn die Quelle unverändert bleibt.

Notiere deshalb pro Fehler, welches System die fachliche Hoheit besitzt. Die Korrektur wird dort umgesetzt und anschließend entlang des gesamten Wegs geprüft.

Aktualisierung und Crawl werden kontrolliert

Stoße die passende Datenaktualisierung an und prüfe, ob der neue Wert im Merchant Center angekommen ist. Öffne die Zielseite in einer frischen Sitzung und kontrolliere sichtbare sowie strukturierte Daten. Bei URL- oder Bildproblemen wird zusätzlich die Serverantwort geprüft.

Eine gespeicherte Änderung ist nicht gleichbedeutend mit verarbeiteter Änderung. Warte auf den aktualisierten Produktstatus und vermeide hektische Folgeänderungen, die den Befund erneut verändern.

Überprüfung ist ein Gate, kein Reparaturknopf

Wenn Google eine Überprüfung anbietet, bestätigst du damit, dass du die genannte Anforderung geprüft und die Ursache beseitigt hast oder den Befund begründet für falsch hältst. Beantrage sie nicht probeweise. Bei manchen Verstößen sind Wiederholungen begrenzt, und eine unvollständige Korrektur erschwert den Prozess.

Halte Belege bereit: funktionierende URLs, konsistente Werte, aktualisierte Richtlinienseiten oder entfernte unzulässige Angebote. Ein Einspruch beschreibt konkret, warum der aktuelle Zustand die Anforderung erfüllt.

Nach Freigabe folgt ein End-to-End-Test

Genehmigung bedeutet, dass das Produkt wieder grundsätzlich ausspielbar ist. Prüfe anschließend, ob es im richtigen Land, Programm und Kampagnenbestand erscheint. Kontrolliere außerdem Varianten, Ziel-URL und Conversion-Messung, damit die Wiederaufnahme nicht an der nächsten Systemgrenze scheitert.

Überwache die zuvor betroffene Gruppe nach der nächsten regulären Synchronisation. Bleibt der Status stabil, ist die Quelle tatsächlich repariert. Kehrt der Fehler zurück, liegt noch ein konkurrierender Datenweg oder eine zeitabhängige Regel vor.

Teilfreigaben werden nicht mit vollständiger Lösung verwechselt

Ein Produkt kann für einen Zielbereich genehmigt und für einen anderen weiterhin eingeschränkt sein. Prüfe deshalb Land, Programm und Ausspielziel, statt nur den grünen Status einer Ansicht zu übernehmen. Besonders bei mehreren Märkten können Versandangaben, Sprache oder Richtlinienbewertung voneinander abweichen.

Dokumentiere nach der Reparatur, welche Teilmenge freigegeben wurde und welche Befunde offen bleiben. Kampagnen werden erst auf den tatsächlich verfügbaren Bestand ausgerichtet. So entstehen keine Erwartungen an Produkte, die in der vorgesehenen Region noch nicht ausspielbar sind.

Die Reparatur erhält einen Regressionstest

Aus jedem systematischen Fehler entsteht eine kleine Vorabprüfung. Nach einer Preisabweichung vergleicht sie künftig Feed, sichtbare Seite und Markup. Nach blockiertem Crawling prüft sie Serverstatus und Bot-Zugriff. Nach einer Variantenverwechslung kontrolliert sie ID, Link, Bild und Kennzeichnung derselben Ausprägung.

Dieser Test wird an der verursachenden Änderung verankert. Er verhindert, dass dieselbe Fehlerklasse beim nächsten Theme-, App- oder Export-Release zurückkehrt und erst wieder im Merchant Center auffällt.

Merchant-Center-Qualität ist kein einmaliges Aufräumprojekt. Preise, Bestände, Sortimente, Märkte und Shoptechnik ändern sich laufend. Ein stabiler Betrieb erkennt Abweichungen früh und prüft jede relevante Änderung entlang derselben Kette aus Quelle, Feed, Landingpage und Status.

Datenquellen werden regelmäßig überwacht

Kontrolliere Abruffehler, Verarbeitungsstatus, Aktualität und Zahl betroffener Produkte. Ein fehlgeschlagener Export kann zunächst nur alte Werte stehen lassen und später zu Ablehnungen führen. Alarme sollten deshalb nicht erst beim vollständigen Katalogausfall beginnen.

Für wichtige Attribute helfen Plausibilitätsregeln: keine leeren Links, gültige Währung, erlaubte Verfügbarkeiten, eindeutige IDs und vollständige Werte für relevante Produktarten. Solche Prüfungen laufen vor der Übertragung und halten fehlerhafte Releases zurück.

Shop-Releases enthalten Merchant-Center-Smokes

Änderungen an Produktseiten, Varianten, Preisen, strukturierten Daten, Routing, Bild-CDN oder Bot-Schutz können den Abgleich beeinflussen. Prüfe nach solchen Releases eine feste Auswahl repräsentativer Produkt-URLs. Vergleiche Feedwert, sichtbare Seite und Markup.

Ein Relaunch braucht zusätzlich URL- und Weiterleitungsprüfungen. Alte Feedlinks dürfen nicht unbemerkt auf allgemeine Seiten fallen. Der Feed wird gemeinsam mit dem neuen Shopstand veröffentlicht.

Änderungen erhalten eine nachvollziehbare Historie

Dokumentiere, wann Feedregeln, Apps, Datenquellen und Zielmärkte geändert wurden. Wenn Ablehnungen plötzlich steigen, lässt sich der Beginn mit einem konkreten Release verbinden. Ohne Historie bleibt nur der Vergleich einzelner Produkte.

Auch automatische Regeln werden versioniert. Eine kleine Änderung an Kategorien oder Preislogik kann tausende Datensätze betreffen und muss deshalb denselben Review erhalten wie Code.

Stichproben bilden die tatsächliche Sortimentslogik ab

Eine dauerhafte Prüfauswahl enthält nicht nur Bestseller. Sie umfasst reguläre und reduzierte Produkte, Varianten, Artikel ohne globale Kennzeichnung, unterschiedliche Verfügbarkeiten und jeden aktiven Zielmarkt. So decken wenige Fälle die wichtigsten Exportregeln ab. Wird eine neue Produktart eingeführt, erhält sie vor der vollständigen Übertragung einen eigenen Referenzfall.

Die Stichprobe wird nicht nur im Merchant Center angesehen. Ein Prüflauf liest den Quellwert, die endgültigen Feedattribute, die Landingpage und strukturierte Daten. Dadurch fällt eine Abweichung auf, bevor Google aus ihr eine Ablehnung macht. Gleichzeitig bleibt der Test klein genug, um ihn nach relevanten Releases wirklich auszuführen.

Wachsende Fehlerzahlen erhalten einen festen Eskalationsweg

Steigt die Zahl abgelehnter Produkte deutlich, stoppt das Team zunächst weitere riskante Änderungen am Feed und sichert den aktuellen Stand. Danach wird geprüft, ob ein gemeinsames Release, eine ausgefallene Quelle oder ein Richtlinienhinweis den Anstieg erklärt. Diese Reihenfolge verhindert, dass mehrere Personen gleichzeitig Einzelwerte ändern und damit den Ausgangsbefund verwischen.

Der Eskalationsweg nennt außerdem, wann Kampagnenverantwortliche informiert werden und wer eine Überprüfung beantragen darf. Bei großen Auswirkungen braucht es einen koordinierten Plan aus technischer Reparatur, Sortimentseinschätzung und anschließender Wiederaufnahme. Schnelle Kommunikation ist wichtig; ungeprüfte Massenänderungen sind es nicht.

Alle Beteiligten arbeiten dabei mit derselben priorisierten Fehlerliste und demselben dokumentierten Datenstand.

Verantwortung verbindet Shop und Kampagne

Lege fest, wer tägliche Befunde sichtet, wer Datenquellen ändern darf und wer Richtlinienfälle bewertet. Das Kampagnenteam meldet die geschäftliche Auswirkung, Shop und Datenverantwortliche beheben die Ursache. Niemand sollte darauf warten, dass eine andere Oberfläche denselben Fehler deutlicher meldet.

So wird Merchant Center zu einem überwachten Produktdatenkanal statt zu einer Blackbox zwischen Shop und Werbung. Genehmigte Produkte bleiben nicht durch Glück verfügbar, sondern weil Daten, Website und Richtlinienanforderungen dauerhaft gemeinsam gepflegt werden.