18. August: Google kappt die alte Shopping-Schnittstelle

Ein Webshop zeigt im eigenen Backend 1.800 verfügbare Produkte. Im Google Merchant Center kommen nach einer technischen Änderung aber nur 1.240 davon an. Einige Preise sind alt, Varianten fehlen und mehrere Shopping-Anzeigen laufen weiter auf nicht mehr verfügbare Artikel. Genau dieses Szenario soll eine kontrollierte API-Migration verhindern.

Google stellt die Content API for Shopping am 18. August 2026 ein. Danach ist die Merchant API die primäre Schnittstelle für den programmatischen Zugriff auf Konten, Produktdaten, Inventar und Berichte im Merchant Center. Für österreichische Händler bleiben damit nur wenige Wochen, um eigene Integrationen, Plugins und Dienstleister zu prüfen.

Die Merchant API Umstellung ist kein reiner Austausch einer Internetadresse. Google hat Ressourcen, Bezeichner, Datentypen, Batch-Verarbeitung und Kontoverknüpfung neu strukturiert. Wer den Wechsel wie ein gewöhnliches Plugin-Update behandelt, kann Fehler erst bemerken, wenn Produkte aus kostenlosen Einträgen oder Shopping-Kampagnen verschwinden. Dieser Beitrag zeigt einen belastbaren Migrationsplan für Webshops, Agenturen und technische Dienstleister.

Zuerst klären: Ist der eigene Shop überhaupt direkt betroffen?

Nicht jeder Händler ruft die Content API selbst auf. Viele Shops übertragen Produktdaten über eine Plattform, ein Feed-Plugin, ein Warenwirtschaftssystem, eine PIM-Lösung oder einen spezialisierten Technologiepartner. Google weist ausdrücklich darauf hin, dass Händler mit einem betreuten Drittanbieter-Connector die Migration normalerweise nicht selbst programmieren müssen. Der Anbieter soll den API-Wechsel durchführen.

„Der Anbieter kümmert sich“ ist allerdings noch kein belastbarer Status. Shopbetreiber sollten bis zum Stichtag schriftlich klären:

• Welches System sendet Produkte, Preise und Bestände an das Merchant Center?
• Verwendet dieses System noch die Content API for Shopping oder bereits die Merchant API?
• Welche Plugin-, App- oder Connector-Version ist für die Umstellung erforderlich?
• Wer überwacht Produktfehler während und nach der Migration?
• Wie wird nachgewiesen, dass Anzahl, Preise, Verfügbarkeit und Zielmärkte übereinstimmen?

Wer WooCommerce, Shopify oder ein anderes Shopsystem einsetzt, sollte deshalb nicht nur im Merchant Center nachsehen. Die eigentliche Integration kann in einem WordPress-Plugin, einer Cloud-App, einem serverseitigen Cronjob oder einer Agenturplattform liegen. Auch alte Skripte, die nur Berichte abrufen oder Bestände korrigieren, gehören auf die Liste.

Was sich mit der Merchant API technisch ändert

Googles aktueller Migrationsleitfaden zur Merchant API beschreibt mehrere strukturelle Unterschiede. Die neue API ist modular aufgebaut. Konten, Produkte, Inventar, Datenquellen, Berichte und weitere Funktionen liegen in eigenen Sub-APIs mit separaten Versionen.

Ein zentraler Unterschied betrifft Ressourcenbezeichner. Die Content API arbeitete häufig mit einzelnen IDs wie merchantId und productId. Die Merchant API gibt vollständige Ressourcennamen zurück, etwa nach dem Muster accounts/{account}/products/{product}. Google empfiehlt, den zurückgegebenen Wert aus dem Feld name weiterzuverwenden und Ressourcennamen nicht selbst zusammenzubauen.

Auch Produktkennungen ändern sich. Wo in der Content API Bestandteile mit Doppelpunkten verbunden waren, verwendet die Merchant API Tilden. Der Kanal ist nicht mehr Teil derselben Kennung. Wer Produkt-IDs in einer lokalen Datenbank, in Logs oder in Fehlerlisten speichert, muss diese Zuordnung bewusst migrieren.

Weitere Beispiele sind neue Preisstrukturen mit Betrag in Mikros und separatem Währungscode sowie der Wegfall von customBatch. Mehrere Anfragen werden stattdessen parallel oder asynchron verarbeitet. Eine bloße Suche-und-Ersetzen-Aktion im Quellcode reicht deshalb selten aus.

Der wichtigste Grundsatz: Nicht am Live-Katalog experimentieren

Eine Produktfeed-Migration sollte mit einer klar begrenzten Teilmenge beginnen. Wählen Sie beispielsweise 20 bis 50 Artikel, die verschiedene Fälle abdecken: einfache Produkte, Varianten, reduzierte Angebote, nicht verfügbare Artikel, Produkte mit mehreren Bildern, unterschiedliche Versandklassen und ein lokales Sortiment.

Für diese Auswahl werden die Ergebnisse beider Wege verglichen. Solange die Content API noch erreichbar ist, kann der alte Ablauf als Referenz dienen. Die neue Merchant API schreibt oder liest dieselben fachlichen Informationen, ohne dass sofort der gesamte Katalog umgestellt wird. Wo echte parallele Schreibvorgänge zu Konflikten führen würden, eignet sich zumindest ein paralleler Readback und ein Vergleich der resultierenden Produktansicht.

Vor jedem Test braucht es einen Export des aktuellen Zustands: Produktanzahl, Datenquellen, Zielländer, Sprache, Währung, Feed-Labels, Versandkonfiguration, aktive Kampagnen und bekannte Warnungen. Ohne diesen Ausgangspunkt lässt sich später nicht unterscheiden, ob ein Fehler neu ist oder schon vorher bestand.

Phase 1: Alle Datenwege inventarisieren

Beginnen Sie nicht im Code, sondern mit einem Datenfluss. Links stehen die führenden Systeme: Warenwirtschaft, PIM, Shop und Filialbestand. In der Mitte stehen Exporte, Plugins, geplante Jobs und API-Integrationen. Rechts stehen Merchant Center, kostenlose Produkteinträge, Shopping-Anzeigen und lokale Inventaranzeigen.

Zu jedem Pfeil gehören Eigentümer, Zeitplan und Fehlerweg. Wer aktualisiert Preise? Wie oft werden Bestände gesendet? Welches System liefert Bilder und Beschreibungen? Was passiert, wenn ein Job abbricht? Der ältere AdSimple-Beitrag Was ist PIM und wie hilft es Ihrem Online-Marketing? erklärt, warum zentral gepflegte Produktinformationen für mehrere Vertriebskanäle entscheidend sind.

Diese Inventur zeigt auch Schattenintegrationen. Vielleicht übermittelt der Shop seine Produkte über ein Plugin, während ein separates Skript regionale Bestände setzt und eine Agentur Berichte ausliest. Alle drei Verbindungen können die alte API verwenden. Nur den Hauptfeed zu migrieren wäre dann unvollständig.

Phase 2: Konten, Berechtigungen und Registrierung vorbereiten

Für die Merchant API muss das Merchant-Center-Konto mit dem verwendeten Google-Cloud-Projekt über die Developer Registration verknüpft werden. Prüfen Sie, welches Projekt tatsächlich zur Produktion gehört und welche Person Zugriff auf Cloud-Konsole, OAuth-Konfiguration und Merchant Center besitzt.

Vermeiden Sie private Konten einzelner Mitarbeitender als dauerhafte Betriebsgrundlage. Dokumentieren Sie, welche Anwendung welche Berechtigungen benötigt, wo Zugangsdaten sicher verwaltet werden und wer sie rotieren kann. Test- und Produktionszugänge sollten getrennt sein. Geheimnisse gehören weder in ein Plugin-Repository noch in Support-Screenshots oder Tickets.

Ein Berechtigungsfehler muss sichtbar scheitern. Ein Job, der ohne erfolgreiche Authentifizierung einfach mit dem letzten bekannten Produktstand weiterläuft, erzeugt trügerische Sicherheit. Monitoring sollte deshalb zwischen „keine Änderungen“ und „keine Verbindung“ unterscheiden.

Phase 3: Felder und Ressourcen systematisch zuordnen

Erstellen Sie keine unübersichtliche Liste aller API-Felder. Ordnen Sie nach Geschäftsprozessen:

• Produktkern: ID, Titel, Beschreibung, Marke, GTIN, Zustand und Produktkategorie.
• Angebot: Preis, Aktionspreis, Verfügbarkeit, Gültigkeit und Zielseite.
• Medien: Hauptbild, zusätzliche Bilder und seit 2026 optional Produktvideos.
• Logistik: Versandkosten, Lieferzeit, Annahmeschluss und Mindestbestellwert.
• Kanäle: Zielland, Sprache, Feed-Label, kostenlose Einträge und Anzeigen.
• Lokal: Filialbestand, lokale Preise, Abholung und verknüpfte Unternehmensprofile.
• Auswertung: Produktprobleme, Klickpotenzial, Benachrichtigungen und eigene Reports.

Die Google-Produktspezifikation wurde 2026 ebenfalls erweitert. Dazu zählen etwa der optionale Videolink sowie zusätzliche Versandattribute. Eine API-Migration ist ein guter Zeitpunkt, die eigene Datenqualität zu verbessern. Sie sollte aber nicht gleichzeitig jede fachliche Baustelle lösen. Trennen Sie erforderliche Migrationsänderungen von späteren Optimierungen, damit Fehlerursachen nachvollziehbar bleiben.

Phase 4: Eine Testmatrix statt Stichprobengefühl

Ein paar korrekt aussehende Produkte im Merchant Center reichen nicht. Legen Sie Sollwerte fest und vergleichen Sie automatisiert oder zumindest strukturiert:

Prüfen Sie nicht nur erfolgreiche Artikel. Ein absichtlich ungültiges Produkt zeigt, ob Fehlerberichte, Alerts und Supportprozesse funktionieren. Ebenso wichtig sind Löschung, Reaktivierung und Preisänderung: Die Migration muss den gesamten Lebenszyklus abbilden, nicht nur den ersten Import.

Der Parallelbetrieb für die letzten Wochen

Ein pragmatischer Zeitplan teilt die verbleibende Zeit in vier Abschnitte:

1. Inventur und Zuständigkeit: Betroffene Systeme, Anbieter und Konten innerhalb weniger Tage erfassen.
2. Technischer Pilot: Registrierung, Authentifizierung und eine repräsentative Produktgruppe über die Merchant API testen.
3. Vergleichslauf: Mindestens mehrere vollständige Aktualisierungszyklen vergleichen, einschließlich Preis- und Bestandsänderungen.
4. Geplanter Cutover: Produktion bewusst umstellen, alten Schreibweg deaktivieren und engmaschig überwachen.

Warten Sie nicht bis zum 18. August. Nach der Abschaltung fehlt der alte Weg als kurzfristige Rückfalloption. Der produktive Wechsel sollte daher mit ausreichend Puffer erfolgen. Planen Sie außerdem keine große Sortimentsaktion, Plugin-Migration oder Shop-Neugestaltung für dasselbe Wartungsfenster.

Was österreichische Webshops zusätzlich prüfen sollten

Für Händler in Österreich sind Sprache, Euro-Preise, Versandgebiete und die Abgrenzung zu Deutschland oder anderen Zielmärkten besonders wichtig. Eine deutschsprachige Datenquelle kann mehrere Länder bedienen, aber Zielländer, Versandkonfiguration und Google-Ads-Targeting müssen zueinander passen. Wer in mehrere Märkte liefert, prüft jedes Land separat.

Lokale Händler sollten außerdem Filialdaten und lokale Inventare testen. Produktseite, Abholoption, Öffnungszeiten und tatsächlicher Bestand müssen zusammenpassen. Google verlangt für lokale kostenlose Einträge und lokale Inventaranzeigen in Österreich zudem eine hinterlegte Impressums-URL. Ein technischer Feedwechsel darf solche Kontoangaben nicht unbeachtet lassen.

Auch Bilder verdienen einen eigenen Vergleich. Der Beitrag Produktbilder brauchen eine klare Kategorie zeigt, wie Bildtypen und Verwendungszwecke geordnet werden können. Für Merchant Center zählt zusätzlich, dass Bild-URLs erreichbar bleiben und die richtige Variante dem richtigen Produkt zugeordnet wird.

Monitoring nach der Umschaltung

Der Cutover ist nicht das Ende der Migration. Beobachten Sie mindestens sieben bis vierzehn Tage lang:

• Anzahl aktiver, abgelehnter und ausstehender Produkte,
• Alter der zuletzt erfolgreichen Produkt- und Bestandsaktualisierung,
• neue Warnungen nach Zielland und Ausspielungsart,
• Abweichungen bei Preis und Verfügbarkeit,
• Shopping-Impressionen, Klicks und Kampagnenkosten,
• kostenlose Produkteinträge und lokale Sichtbarkeit,
• Fehlerquoten, Laufzeiten und API-Limits der neuen Jobs.

Ein sinnvoller Alarm reagiert nicht erst auf einen kompletten Ausfall. Ein Rückgang der aktiven Produkte um zehn Prozent, ein ungewöhnlich alter Feed oder eine plötzliche Häufung von Preisabweichungen kann früher auf ein Problem hinweisen. Definieren Sie Schwellenwerte passend zum Sortiment und zu den Aktualisierungszyklen.

Die häufigsten Migrationsfehler

• Nur die Hauptintegration wird geprüft: Reporting, lokale Bestände oder ergänzende Datenquellen bleiben auf der alten API.
• Ressourcennamen werden selbst konstruiert: Alte ID-Logik wird auf das neue Namensmodell übertragen.
• Batch-Verhalten wird kopiert: Der weggefallene customBatch-Ablauf wird nicht für parallele oder asynchrone Anfragen neu entworfen.
• Nur Create wird getestet: Preisänderung, Löschung, Reaktivierung und Fehlerbehandlung fehlen.
• Drittanbieterstatus bleibt mündlich: Es gibt keinen Versionsnachweis und keinen Termin für die produktive Umstellung.
• Marketing sieht den Fehler zu spät: Technik überwacht HTTP-Antworten, aber niemand beobachtet Produktfreigaben und Kampagnenwirkung.
• Zu viele Änderungen gleichzeitig: Feedmigration, Relaunch und Sortimentsumbau lassen sich später nicht mehr sauber auseinanderhalten.

Online Marketing und Technik brauchen einen gemeinsamen Cutover

Produktfeeds verbinden technische Systeme direkt mit Sichtbarkeit und Werbebudget. Deshalb braucht die Umstellung eine gemeinsame Freigabe durch Shopbetrieb, Entwicklung und Marketing. Die technische Seite bestätigt erfolgreiche Jobs und korrekte Daten. Das Marketing prüft Produktfreigaben, Zielländer, Kampagnen und tatsächliche Reichweite.

Die Online-Marketing-Leistungen von AdSimple verbinden Website-Analyse, Strategieplanung und konkrete Umsetzung im Suchmaschinenmarketing. Für einen Merchant-API-Cutover ist diese Verbindung relevant: Ein technisch erfolgreicher Feed ist erst dann vollständig geprüft, wenn Produkte in den vorgesehenen organischen und bezahlten Kanälen korrekt erscheinen.

Bei Webshops mit mehreren Dienstleistern sollte eine Person die Freigabe koordinieren. Sie sammelt Bestätigungen von Plugin-Anbieter, Entwicklung und Kampagnenbetreuung, dokumentiert offene Abweichungen und entscheidet, ob der Cutover stattfinden kann.

Fazit: Der Feedwechsel ist ein kontrollierter Release

Die Abschaltung der Content API for Shopping am 18. August 2026 setzt eine klare Frist. Händler mit betreuten Standard-Connectors müssen wahrscheinlich nicht selbst programmieren, sollten den Migrationsstatus und die Ergebnisprüfung aber trotzdem einfordern. Eigene Integrationen brauchen jetzt einen priorisierten Paralleltest.

Der belastbare Weg besteht aus Inventur, Rollenklärung, technischer Zuordnung, repräsentativer Testgruppe, Vergleichsläufen und Monitoring nach dem Cutover. Entscheidend ist nicht, ob eine API-Anfrage erfolgreich antwortet. Entscheidend ist, ob Preis, Bestand, Bilder, Versand und Zielmarkt für Kunden weiterhin richtig ausgespielt werden.

Wer Shoptechnik und Kampagnensteuerung gemeinsam absichern möchte, kann die AdSimple Online-Marketing-Beratung für Analyse, Strategie und Umsetzung einbinden. Beginnen Sie mit einer einfachen Frage an Entwicklung oder Connector-Anbieter: „Welcher produktive Datenweg verwendet am 19. August die Merchant API – und wie weisen wir nach, dass der vollständige Katalog angekommen ist?“

Quellen

• Google Merchant Center-Hilfe: Einführung der Merchant API und Abschaltung der Content API
• Google for Developers: Migration von der Content API for Shopping zur Merchant API
• Google Merchant Center-Hilfe: Aktualisierung der Produktdatenspezifikation 2026
• Google Merchant Center: Ankündigungen und Änderungen