Merchant Center gesperrt: Die häufigsten Gründe für die Kontosperrung im Google Merchant Center

Warum wurde mein Merchant Center gesperrt?

Kontosperrungen resultieren meist aus automatisierten Risiko-Bewertungen, die kumulative, gravierende Richtlinienverstöße oder systemische Inkonsistenzen erkennen – nicht aus einem einzelnen, harmlosen Feedfehler. Google kombiniert Signale aus Feed-Diagnostics, Crawling-Ergebnissen, Konto-Historie und Domain-Checks; bei „critical severity“ folgt eine sofortige Suspendierung, bis die ursächlichen Probleme behoben und geprüft sind.

Vertiefung und Vorgehen: Google bewertet nicht nur einzelne Produktfehler, sondern aggregiert Verstöße konto- oder domainweit. Relevante Signale sind wiederholte Feed-Fehler, widersprüchliche Angaben auf mehreren Produktseiten, fehlende Geschäftsinformationen, fehlerhafte Landingpages oder ein negatives Compliance-History. Technisch fließen die Ergebnisse von automatisierten Crawls, Merchant-API-Antworten und internen Heuristiken in ein Risikomodell; bei Überschreiten einer internen Schwelle wird das Konto deaktiviert.

Wie du systematisch triagierst: Exportiere sofort die Diagnostics (inklusive Beispiel-URLs und Fehlermeldungen), gruppiere Befunde nach „critical“ und „warning“, prüfe Konto-Ebenen wie Business-Informationen, verknüpfte Domains, Multi-Client-Setup oder Subaccounts. Kontrolliere außerdem, ob Domain-Verifikation, Business-Verification und Steuer-/Vergütungsdaten vollständig sind – diese Metadaten beeinflussen die Entscheidung und den Einspruchserfolg.

Mehrere Produktgruppen mit denselben Feed-Fehlern, unterschiedliche Angaben zwischen Landingpages und dem Feed über verschiedene Länder/Subdomains, oder zeitweise erreichbare Seiten (Flapping). Entscheide zuerst nach Schwere: kritische Probleme müssen systemisch behoben werden; punktuelle Produktfehler pausierst du temporär, bis das System stabil läuft.

Welche Rolle spielen Preisabweichungen zwischen Feed und Landingpage?

Preisabweichungen sind ein Hauptauslöser für Ablehnungen, weil sie direkt die Kaufentscheidung des Nutzers beeinflussen. Google vergleicht Feed-Preise mit der sichtbaren Preisdarstellung auf der Produktseite und erkennt Unterschiede automatisiert.

Technik und Ursachen: Google liest Preise aus dem Feed und crawlt die Ziel-URLs, inklusive strukturierter Daten und gerendertem HTML. Probleme entstehen, wenn Feed-Aktualisierungen zeitverzögert sind, Sale-Logik serverseitig anders berechnet wird oder Preise per JavaScript nachgeladen werden. Weitere Fallen: unterschiedliche Währungen je nach Lokal, personenbezogene Preise (z. B. für eingeloggte Nutzer), Preise nur in Bildern, sowie Versandkosten, die erst im Checkout hinzukommen.

Wie du prüfst und reproduzierst: Führe einen Fetch der Produkt-URL mit einem Browser-Renderer durch (Headless-Browser) und einen einfachen HTTP-Request (z. B. curl -I), um Unterschiede zwischen serverseitigem HTML und client-gerendertem Inhalt zu erkennen. Nutze die URL-Inspektion in der Search Console oder einen User-Agent-String von Googlebot, um genau zu sehen, was Googles Crawler sieht. Überprüfe zudem Feed-Felder wie price, sale_price und gegebenenfalls sale_price_effective_date sowie die Zeitstempel der Feed-Generierung.

Wenn Preise dynamisch generiert werden, muss die gleiche Logik im Feed abgebildet werden oder Produkte müssen temporär deaktiviert werden. Sind Preise nur per JS sichtbar, weise einer serverseitigen Ausgabe oder strukturierten Daten den Vorzug zu. Wenn Versandkosten variabel sind, dokumentiere das klar auf der Produktseite oder übergebe shipping-Angaben im Feed.

Welche Produktdaten-Inkonsistenzen lösen Sperrungen aus?

Widersprüche bei Kernattributen wie title, availability, GTIN/MPN, Variantenzuordnung und Beschreibung können Ablehnungen oder Kontosperrungen verursachen, weil sie die Verlässlichkeit der Produktdaten untergraben.

Detaillierte Zusammenhänge: Google vergleicht Feed-Attribute gegen sichtbare Produktangaben und strukturierte Daten auf der Seite. Besonders sensibel sind eindeutige Identifikatoren (GTIN, MPN, brand) und die richtige Modellierung von Varianten über item_group_id. Fehler in der Variantenzuordnung (z. B. gleiche SKU für unterschiedliche Farben) führen zu Inkonsistenzen bei Verfügbarkeit und Preis.

Praktisches Vorgehen zur Fehleranalyse: Erstelle eine Stichprobe problematischer SKUs, lade die zugehörigen Seiten mit einem Renderer und extrahiere die relevanten Felder (title, availability, gtin, mpn, brand, Preis). Vergleiche diese automatisiert mit dem Feed-Export; nutze dabei PIM-Exports und prüfe, ob Template-Logik im PIM Titel oder Attribute nachträglich verändert.

Häufige Ursachen und Gegenmaßnahmen: – Automatisch generierte Titel im Feed, die nicht auf der Landingpage erscheinen: korrigiere die Template-Logik oder passe die Seiten an. – Falsches GTIN-Mapping: bereinige die Zuordnungen im PIM und dokumentiere die Quelle der GTINs. – Variantensichtbarkeit: sorge dafür, dass alle Varianten auch auf der Seite als auswählbare Optionen vorhanden sind oder entferne nicht verfügbare Varianten aus dem Feed.

Wie wirken fehlende oder falsche Kontakt- und Geschäftsangaben auf die Sperrung?

Welche weiteren Ursachen kommen häufig vor (Rückgabe, Versand, Erreichbarkeit, SSL)?

Unklare Rückgabe- oder Versandbedingungen, nicht erreichbare URLs, fehlendes oder fehlerhaftes HTTPS und Checkout-Probleme sind häufige Ursachen für Produkt- und Konto-Sperrungen.

Ausführliche Aspekte und Prüfungen: Google verlangt gut auffindbare Rückgabe- und Versandinformationen, idealerweise in strukturierter Form (z. B. über hasMerchantReturnPolicy und shippingDetails). Fehlende oder widersprüchliche Angaben zu Versandkosten und Lieferzeiten können als irreführend gewertet werden. Technisch problematisch sind zudem wiederkehrende Timeouts, Redirect-Chains, robots.txt-Einträge, die Google vom Crawlen abhalten, sowie TLS-Fehler.

Wie du prüfst: – Server-Logs prüfen: Filtere nach Googlebot-Requests und prüfe HTTP-Statuscodes sowie Redirects. – Synthetische Checks: setze Monitoring-Tools für URL-Response, prüfe Inhalt mit Headless-Browsern und vergleiche das, was Google sieht, mit dem Nutzer-View. – Security-Checks: prüfe, ob alle Produktseiten HTTPS liefern und keine Mixed-Content-Warnungen auftreten.

Problemfelder und Gegenmaßnahmen: Cloaking (unterschiedliche Inhalte an Googlebot vs. Nutzer) wird automatisiert erkannt, entferne jegliche conditional content delivery. Staging- oder Passwort-geschützte Bereiche, die versehentlich indexierbar sind, musst du entweder schützen oder klar kennzeichnen. Bei Checkout-Problemen teste vollständige Bestellabläufe und akzeptierte Zahlungsmittel ohne Testdatenreste oder A/B-Tests, die für Googlebot andere Inhalte liefern.

Wie hebe ich eine Merchant Center Sperrung auf und wie läuft der Einspruch ab?

Sperrungen werden aufgehoben, wenn du die beanstandeten Probleme systemisch behoben und dies im Einspruch nachvollziehbar dokumentiert hast; Google prüft dann erneut und entscheidet über die Wiederaufnahme.

Schritt-für-Schritt-Vorgehen für einen erfolgreichen Einspruch: 1) Sammle alle Diagnostics-Exporte und gruppiere die Fehler nach Relevanz; 2) Behebe die Ursachen nachhaltig (nicht nur punktuelle Korrekturen); 3) Dokumentiere jede Änderung mit konkreten Belegen: aktualisierte Feed-Dateien, Screenshots der Produktseiten, Server-Log-Ausschnitte oder Zeitstempel von Deployments; 4) Reiche den Einspruch über das Merchant-Center ein und lege die Dokumentation bei.

Worauf Google besonders achtet: Der Reviewer will sehen, dass nicht nur Symptome, sondern auch die Ursachen entfernt wurden. Häufige Gründe für erneute Ablehnungen sind unvollständige Nachweise, fehlende Änderungen an allen betroffenen URLs oder temporäre Fixes, die nicht reproduzierbar sind. Wenn du systemische Fehler (z. B. fehlerhafte PIM-Templates oder automatische Preis-Aktualisierungen) behoben hast, beschreibe die Deployment- und Monitoring-Maßnahmen im Einspruch.

Nach dem Einspruch: Google führt eine erneute Prüfung durch, die einige Tage dauern kann; bei wiederholten Verstößen ist die Toleranz geringer. Empfehlenswert ist, vor dem Einspruch ein kurzes internes Review durchzuführen, um mögliche Lücken in der Dokumentation zu schließen.

Welche Punkte enthält die praktische Checkliste zum Abhaken?

Arbeite die Checkliste systematisch ab und dokumentiere jede Änderung mit Zeitstempeln und Belegen, bevor du einen Einspruch einreichst.

1. Feed vs. Landingpage: Automatisiere den Vergleich von Preis, Verfügbarkeit und Währung mit Scripts oder Tools, die gerendertes HTML auslesen. Nutze Feed-Zeitstempel und notiere die Ausspielungszeit.
2. Streichpreise und Sale-Logik: Melde Sale-Preise im Feed über sale_price (ggf. mit sale_price_effective_date) und stelle sicher, dass die Seite dieselbe Darstellung ohne Login oder Geofilter zeigt.
3. Produktattribute: Lege eine Stichprobe an und vergleiche title, description, gtin, mpn, brand und item_group_id zwischen Feed und Seite. Prüfe PIM-Templates auf ungewollte Änderungen.
4. Kontaktinformationen: Vergleiche Merchant-Center-Angaben mit Impressum, Footer und Kontaktseiten auf allen Domains/Subdomains; dokumentiere Abweichungen und Korrekturen.
5. Rückgabe- & Versandinfos: Stelle sicher, dass Widerrufsinformationen, Versandkosten und Lieferzeiten prominent und in strukturierten Daten vorhanden sind (z. B. hasMerchantReturnPolicy, shippingDetails).
6. Erreichbarkeit: Prüfe HTTP-Statuscodes (200-Responses), HTTPS-Konfiguration, Redirect-Chains und serverseitige Timeouts; exportiere relevante Server-Logs für Beanstandungen.
7. Cloaking & Weiterleitungen: Führe Vergleichsfetches mit unterschiedlichen User-Agents und Standorten durch, um conditional content oder geobasierte Weiterleitungen zu entdecken.
8. Checkout & Zahlungsarten: Teste vollständige Checkout-Flows auf Fehler, prüfe, ob akzeptierte Zahlungsmittel sichtbar sind und ob der Checkout für externe Nutzer erreichbar ist.
9. Business-Informationen: Stelle Übereinstimmung von Geschäftsadresse und Telefonnummer zwischen Website, Merchant Center und Rechnungsangaben sicher; dokumentiere Quellen.
10. Diagnostics & Logs: Exportiere Merchant-Center-Diagnostics, API-Fehler und Server-Logs; archiviere Feed-Versionen und Deployment-Timestamps für den Einspruch.