Google Merchant Center reparieren
Abgelehnte Produkte zurück in Shopping bringen.
Diagnose von Ablehnungen und Kontoproblemen, Korrekturen an den Quelldaten statt im Feed-Export, und eine erneute Einreichung mit den Belegen, die Google verlangt. Wir haben eine Monitoring-App genau auf diesem Problem gebaut.
Festpreis
Ab 850 €
Darin enthalten sind die Diagnose und die Datenkorrekturen an einem Konto. Eine Sperrung, mehrere Feeds oder eine kaputte Synchronisation gehen bis 3.750 €. Die Zahl steht vor Arbeitsbeginn fest und wird nicht nach Stunden abgerechnet.
Schicken Sie die Beschreibung, Sie bekommen eine Zahl zurück.
Projekt beschreibenDie Produkte werden nicht mehr ausgespielt, und die Begründung ist ein Code
Die Impressionen in Shopping fallen, im Konto steht ein rotes Banner, und die Erklärung ist ein Begriff wie Falschdarstellung oder ungültiger Wert, ohne Hinweis darauf, welcher Teil Ihres Shops ihn ausgelöst hat. Gleichzeitig geben die Kampagnen weiter Geld für das aus, was übrig geblieben ist, der Verlust ist also teilweise und wird leicht als schwache Woche gelesen. Der Reflex ist, den Feed zu öffnen und Attribute zu korrigieren, und genau dort versickert die meiste Arbeit: Ein großer Teil dieser Ablehnungen steckt gar nicht im Feed, sondern in dem Shop, den Google danach besucht hat.
Was die Arbeit umfasst
Eine Diagnose, keine Liste von Fehlercodes
Probleme auf Produkt- und auf Kontoebene werden über die Merchant API gezogen, nach Ursache statt nach Produkt gruppiert und in die zwei Arten getrennt, die sich unterschiedlich verhalten: Datenprobleme, die sich nach der Korrektur beim nächsten Crawl von selbst erledigen, und Richtlinienprobleme, die eine erneute Prüfung brauchen. Welche Sorte vorliegt, entscheidet über alles Weitere.
An der Quelle behoben, nicht im Export
Korrekturen gehen in die Produktdaten Ihres Shops, in die Versand- und Steuerkonfiguration oder auf die Seite selbst. Werte im Feed-Export zu flicken bringt Feed und Zielseite auseinander, und genau diese Abweichung ist ein eigener Ablehnungsgrund. Die schnelle Lösung erzeugt also das nächste Ticket.
Ein Prüfantrag, richtig aufgebaut
Bei Richtlinien- und Kontofällen lautet die Reihenfolge: beheben, belegen, dann ein einziger Antrag. Versuche und Wartezeiten sind begrenzt, und ein Antrag vor der tatsächlichen Behebung verbrennt einen davon. Der Antrag sagt, was falsch war, was geändert wurde und wo es nachprüfbar ist.
Warum es so gemacht wird
Falschdarstellung wird auf Ihrer Website beurteilt
Google liest nicht nur den Feed. Es besucht den Shop und prüft, ob Sie wie ein Unternehmen wirken, zu dem es Käufer schicken kann: erreichbare Kontaktdaten, eine auffindbare Rückgabe- und Erstattungsregelung, Preise und Verfügbarkeit, die zum Feed passen, und Aussagen, die es überprüfen kann. Seriöse Shops fallen ständig darüber, und sie suchen die Ursache weiter im Feed, wo sie nicht liegt.
Die Engine ist unsere, die Diagnose also kein Raten
Feed Guard, unsere eigene App, läuft auf der Merchant API und ist genau für dieses Problem gebaut: Konto- und Produktprobleme auslesen, sie in verständlicher Sprache erklären und auf das nächste achten. Von derselben Auswertung startet hier die Diagnose. Was niemand anbieten kann, ist ein Versprechen: Freigabe und Entsperrung entscheidet Google, ein Ergebnis wird also nicht garantiert, und wer es garantiert, verkauft etwas anderes.
Wie es abläuft
Lesezugriff auf Merchant Center und Shop, oder ein Export, wenn Zugriff nicht möglich ist. Sie bekommen die Problemliste nach Ursache gruppiert, mit der Zahl der betroffenen Produkte je Ursache.
Eine schriftliche Diagnose: was Datenproblem ist und sich beim Crawl erledigt, was Richtlinienfall ist und eine Prüfung braucht, was strukturell ist und echte Arbeit kostet, und was sich gar nicht beheben lässt.
Die Korrekturen landen in den Produktdaten, in der Versand- und Steuereinrichtung oder auf der Seite selbst, und warten dann auf den Crawl, der sie bestätigt, statt für erledigt erklärt zu werden.
Bei Richtlinien- und Kontofällen geht der Prüfantrag einmal raus, nachdem die Ursache nachweislich behoben ist, mit den Belegen dabei.
Eine Kontrolle nach dem erneuten Crawl, dazu eine kurze Liste dessen, was monatlich zu beobachten ist, damit dieselbe Fehlerklasse nicht unbemerkt zurückkommt.
Hintergrund
Wie Merchant-Center-Probleme wirklich funktionieren
Ablehnung, Abwertung und Sperrung sind drei verschiedene Probleme
Eine Ablehnung verbirgt einzelne Produkte, während der Rest des Katalogs weiter verkauft. Eine Abwertung ist leiser: Das Angebot erscheint weiterhin, rankt aber hinter dem Wettbewerb, weil ein Attribut fehlt oder schwach ist, und nichts im Konto nennt das einen Fehler. Eine Sperrung wirkt auf Kontoebene und verbirgt alles, meist nach einer Warnung. Alle drei werden als eine Sache namens Feed-Problem behandelt, und deshalb korrigieren Händler eine Woche lang Attribute, während die eigentliche Ursache im Shop sitzt. Die erste nützliche Frage lautet nicht, was am Feed falsch ist, sondern welcher der drei Fälle vorliegt.
Warum die Lösung meist nicht im Feed liegt
Der Feed ist eine Behauptung über Ihre Produkte. Google prüft diese Behauptung gegen die verlinkte Seite. Deshalb kommen genau die Fehler immer wieder, bei denen beide auseinandergehen: ein Preis, der sich ändert, sobald eine Rabatt-App rendert, Verfügbarkeit auf Lager bei einer ausverkauften Variante, eine Zielseite, die weiterleitet, eine Währung, die zwischen Feed und Zielmarkt wechselt. Den Export so zu bearbeiten, dass der Validator zufrieden ist, vergrößert die Abweichung, statt sie zu schließen. Dauerhaft hilft nur die Produktdatenbasis, aus der alles andere erzeugt wird.
Den ersten Prüfantrag richtig einsetzen
Prüfanträge sind nicht unbegrenzt, und jeder startet eine Wartezeit. Der übliche Fehler ist, sofort einen zu senden, weil das Banner Druck macht und der Knopf direkt daneben liegt, bevor die Ursache wirklich behoben ist. Dann wird der Antrag abgelehnt, die Wartezeit beginnt, und der zweite Versuch geht unter Zeitdruck raus. Probleme auf Datenebene brauchen gar keinen Antrag: beheben, und der nächste Crawl räumt sie ab. Heben Sie den Antrag für das auf, was wirklich einen Menschen braucht, und schicken Sie ihn mit einer bereits nachprüfbaren Korrektur.
Woher dieses Wissen kommt
Feed Guard, unsere eigene Shopify-App, ist auf der Merchant API gebaut und liest genau diese Konto- und Produktprobleme. Deshalb liegen im Blog hier zehn Artikel, die diese Fehler einzeln durchgehen: Sperrungen, Falschdarstellung, abgelehnte Bilder, fehlende GTIN und Marke, Abweichungen bei Preis und Verfügbarkeit, redaktionelle Anforderungen, Prüfanträge und die Umstellung auf die Merchant API. Die Leistung ist dieselbe Auswertung, angewandt auf Ihr Konto, mit ausgeführten statt beschriebenen Korrekturen.
Verwandte Leistungen
Projekt beschreiben
Sagen Sie, was vorhanden ist und was sich ändern soll. Innerhalb von zwei Werktagen bekommen Sie eine schriftliche Kalkulation: den Umfang nach Teilen aufgeschlüsselt mit einem Preis je Teil, oder die Fragen, die dafür noch fehlen. Kein Kennenlerngespräch dazwischen.
Fragen
Ärger im Merchant Center, gefragt und beantwortet
Datenprobleme klären sich meist innerhalb von Tagen nach der Korrektur, beim nächsten Crawl, ganz ohne Antrag. Richtlinien- und Kontofälle dauern länger und hängen an einer Prüfung, die Sie nicht steuern. Wer Ihnen ein Datum für eine Entsperrung nennt, nennt ein Datum, das Google ihm nicht gegeben hat.
Nein. Die Entscheidung liegt bei Google, und daran ändert diese Arbeit nichts. In unserer Hand liegt, dass die Ursache richtig erkannt, tatsächlich behoben und mit Belegen dargestellt wird, und genau das macht einen Antrag überhaupt sinnvoll. Wenn die ehrliche Einschätzung ist, dass das Konto nicht zurückkommt, hören Sie das, statt Versuche bezahlt zu bekommen.
Das ist die häufigste Variante dieses Falls. Falschdarstellung ist selten ein Betrugsvorwurf. Meist heißt es, dass Google etwas nicht bestätigen konnte, das es erwartet: Kontaktdaten, eine klare Rückgaberegelung, Preise, die zur Zielseite passen, oder eine überprüfbare Unternehmensidentität. Die Arbeit besteht darin, das nachprüfbar zu machen, statt über Absichten zu streiten.
Selten. Feed-Apps unterscheiden sich darin, wie sie Attribute abbilden, und eine schlechte Zuordnung verursacht durchaus Ablehnungen. Die Fälle auf Kontoebene und die meisten wiederkehrenden Produktfälle kommen aber aus den Produktdaten und dem Shop darunter. Die App zu wechseln, während die Quelldaten gleich bleiben, reproduziert dieselben Probleme unter neuen Bezeichnungen.
Nur wenn etwas Eigenes Ihre Produkte synchronisiert: ein selbstgebautes Skript, eine ältere Integration oder eine App, die nicht migriert wurde. Die Standardwege bei Shopify und WooCommerce haben die Anbieter selbst umgestellt. Hängt ein eigener Job in der Kette, liefert er nach dem Stichtag keine Daten mehr, und das prüft man besser vorher als hinterher.