Shopping-Feeds trotz API-Wechsel stabil halten: Was PPC-Teams jetzt prüfen sollten

Bei Shopping- und Performance-Max-Kampagnen kann die Werbeauslieferung unauffällig weiterlaufen, obwohl die dahinterliegende Produktdaten-Schnittstelle bereits Fehler produziert. Seit September 2026 ist genau das bei Integrationen möglich, die noch Googles Content API for Shopping verwenden. Für PPC-Verantwortliche ist deshalb nicht allein die Frage entscheidend, ob die technische Migration geplant wurde. Entscheidend ist, ob Preise, Bestände und Produktfreigaben nachweislich weiterhin korrekt im Merchant Center ankommen.

Was sich geändert hat – und warum ein grüner Kampagnenstatus nicht genügt

Google hat die Content API for Shopping am 18. August 2026 offiziell in den Sunset-Status versetzt. Seit dem 1. September werden Anfragen ohne genehmigte Verlängerung schrittweise mit HTTP 410 Gone abgewiesen. Die vollständige Abschaltung aller Endpunkte ist für Anfang 2027 vorgesehen; Google weist darauf hin, dass sich dieser Zeitpunkt noch ändern kann. Die Nachfolgeschnittstelle heisst Merchant API.

Die Fehler treten zunächst nur bei einem Teil der Anfragen auf. Ein erneuter Versuch kann vorübergehend erfolgreich sein. Genau deshalb reicht ein einzelner erfolgreicher Feed-Lauf nicht als Nachweis. Wer nur Google-Ads-Kennzahlen kontrolliert, sieht die technische Ursache womöglich erst, wenn Produktinformationen veralten oder Artikel nicht mehr für Anzeigen verfügbar sind. Ob und wann das im konkreten Konto passiert, hängt von der Datenquelle und der Verarbeitung ab.

Zuerst klären: Wer überträgt die Produktdaten tatsächlich?

Nicht jeder Shop ist direkt betroffen. Wer seine Produkte über eine Datei, einen geplanten Dateiabruf oder eine andere nicht auf der Content API basierende Datenquelle einspielt, muss wegen dieses API-Sunsets nicht automatisch eine Schnittstelle migrieren. Wer Merchant Center über eine E-Commerce-Plattform anbindet, für den übernimmt laut Google der jeweilige Plattformpartner die Migration. Das entbindet das PPC-Team nicht von einer Funktionskontrolle, verlangt aber normalerweise keinen eigenen API-Umbau.

Kritisch sind selbst entwickelte Feed-Prozesse, Agentur-Skripte und ältere Middleware, die direkt Anfragen an die Content API for Shopping senden. Auch bei Drittanbietern wie Feed-Tools sollte die verwendete Schnittstelle konkret erfragt werden, statt aus dem Produktnamen auf den technischen Stand zu schliessen.

Ein Audit in fünf Schritten

1. Datenwege inventarisieren. Für jedes Merchant-Center-Konto dokumentieren, welche Datenquelle Produktstammdaten, Preise und Verfügbarkeiten liefert, wer sie betreibt und wann der letzte erfolgreiche vollständige Import erfolgte. Bei API-basierten Quellen den Anbieter beziehungsweise das verantwortliche Entwicklerteam nach dem verwendeten Endpunkt und dem Migrationsstatus fragen. Bei mehreren Märkten DE, AT und CH getrennt prüfen.
2. Fehlermeldungen im richtigen System suchen. In Anwendungs- und Integrationslogs nach HTTP 410 sowie dem von Google dokumentierten Fehlergrund content_api_sunset suchen. Die Fehlermeldung kann die betroffene Google-Cloud-Projekt-ID enthalten. Eine bewilligte Verlängerung schützt laut Google nur bis zum genehmigten Ende; sie ist kein Ersatz für die Migration. Reine Retry-Erfolgsquoten reichen nicht, weil sie die schrittweise Degradierung verdecken können.
3. Einen kontrollierten Produktdaten-Test durchführen. Eine kleine Auswahl aktiver Produkte mit bekannten SKUs festlegen: darunter verfügbare und nicht verfügbare Artikel, Produkte mit Preisänderung sowie Artikel für unterschiedliche Zielländer. Nach einem regulären Update prüfen, ob die neuen Werte im Merchant Center tatsächlich verarbeitet wurden. Ein erfolgreicher API-Aufruf ist dabei nicht mit einem erfolgreich verarbeiteten Produkt gleichzusetzen.
4. Die Auslieferungsfähigkeit statt nur die Produktanzahl kontrollieren. Vor und nach der Umstellung die Anzahl verarbeiteter Produkte, die Länderfreigaben und die Artikelprobleme vergleichen. In der Merchant API liefern products.list beziehungsweise products.get den verarbeiteten Produktzustand einschliesslich productStatus; destinationStatuses und itemLevelIssues helfen bei der Ursachenanalyse. Für einen aggregierten Überblick sind die entsprechenden Status- und Reporting-Funktionen vorgesehen. Zusätzlich im Google-Ads-Konto prüfen, ob Shopping- und Performance-Max-Kampagnen weiterhin die erwarteten Produkte adressieren.
5. Monitoring nach dem Wechsel fortsetzen. Für die ersten Tage nach der Umstellung mindestens einen täglichen Abgleich von Datenquellen-Status, Produktanzahl, Freigaben, Preis-/Bestandsstichproben und API-Fehlern vorsehen. Bei grossen Katalogen oder häufig wechselnden Beständen sollte die Kontrolle zum Aktualisierungsrhythmus passen. Ein Rückgang der Shopping-Impressionen kann ein Signal sein, beweist für sich allein aber keinen Feed-Fehler.

Was Entwickler bei der Merchant API nicht eins zu eins übernehmen können

Die Migration ist mehr als ein Austausch des Hostnamens. Laut Googles Migrationsleitfaden verwendet die Merchant API eigene Sub-APIs und versionierte Endpunkte. Ein Google-Cloud-Projekt muss mit dem Merchant-Center-Konto über die Developer Registration verbunden werden. Ressourcen werden über name- beziehungsweise parent-Bezeichner adressiert. Preisangaben verwenden amountMicros und currencyCode. Die aus der Content API bekannte Methode customBatch wird nicht unterstützt; Google beschreibt stattdessen asynchrone beziehungsweise parallele Aufrufe. Google garantiert keine vollständige Rückwärtskompatibilität bei Feldnamen und Methoden.

Für PPC-Teams sind diese Details vor allem Abnahmekriterien gegenüber Entwicklung und Dienstleistern: Wurde nur die Verbindung hergestellt, oder wurden auch Produktkennungen, Preisfelder, Batch-Verarbeitung und Fehlerbehandlung getestet? Besonders wichtig ist, bei Änderungen an Produktidentifikatoren und Feed-Labels die Zuordnung in Merchant Center und den produktbasierten Kampagnen zu prüfen. Daraus folgt nicht, dass Labels bei jeder Migration automatisch wechseln – die Zuordnung muss im konkreten Setup verifiziert werden.

DACH-Praxis: Länder, Währungen und Verfügbarkeit getrennt testen

Ein Händler, der denselben Katalog in Deutschland, Österreich und der Schweiz bewirbt, sollte den Test nicht mit einem einzigen deutschen Produkt abschliessen. Sinnvoll sind Stichproben je Land und Datenquelle: Währung, Zielmarkt, Verfügbarkeit, Versandangaben und die tatsächlich freigegebenen Produkte. Im Merchant Center kann ein Artikel technisch vorhanden sein, ohne für die gewünschte Shopping-Ausspielung im betreffenden Land freigegeben zu sein. Ein Abgleich mit dem Kampagneninventar verhindert, dass ein grüner Datenimport mit einer erfolgreichen Auslieferung verwechselt wird.

Was PPC-Verantwortliche jetzt entscheiden sollten

Wer einen vollständig gemanagten Shop-Connector nutzt, sollte eine dokumentierte Bestätigung des Anbieters und einen erfolgreichen Produktdaten-Test einholen. Wer eine eigene API-Integration betreibt, sollte den Merchant-API-Umstieg priorisieren und nicht auf die endgültige Abschaltung Anfang 2027 warten. Wer ausschliesslich Dateiimporte nutzt, braucht wegen dieses API-Wechsels keinen unnötigen technischen Umbau; die reguläre Qualitätskontrolle der Datenquelle bleibt trotzdem sinnvoll.

Das Muster ist auch auf anderen Plattformen relevant: Eine API-Migration ist erst dann abgeschlossen, wenn die Datenflüsse nach dem Wechsel überprüfbar funktionieren. Wie die parallele Umstellung bei Microsoft Advertising von SOAP auf REST aussieht, steht im Beitrag zur REST-Migration vor dem SOAP-Ende 2027.