Wenn du die Content API for Shopping in irgendeiner Form nutzt, solltest du den 18. August 2026 nicht als lockere Empfehlung verstehen. Das ist der Stichtag, an dem Google die bisherige Content API for Shopping durch die Merchant API ersetzt. Und ja, solche Termine wirken in großen technischen Migrationsprojekten oft weiter weg, als sie tatsächlich sind. Aus meiner Erfahrung ist genau das der Punkt, an dem es später teuer wird: Man denkt, „das schaffen wir schon“, und plötzlich hängen Produktfeeds, Preisupdates, Verfügbarkeiten oder Kampagnenlogik an einer Schnittstelle, die nicht mehr zuverlässig läuft.
Google bietet nun ein Formular an, mit dem du verlängerten Zugriff auf die Content API for Shopping beantragen kannst. Das ist keine automatische Schonfrist und auch kein Freifahrtschein, die Migration monatelang aufzuschieben. Es ist eher eine Art Sicherheitsnetz für Unternehmen, Agenturen, Integratoren oder Händler, die realistisch absehen können, dass sie bis zum offiziellen Abschaltdatum nicht vollständig auf die Merchant API umgestellt haben werden.
Wichtig ist dabei: Du solltest dieses Formular nur dann ausfüllen, wenn du wirklich zusätzliche Zeit brauchst. Wenn deine Migration rechtzeitig fertig wird, brauchst du keinen Antrag. Wenn sie aber wackelt, mehrere Teams beteiligt sind oder du Abhängigkeiten von Drittanbietern hast, würde ich das Thema sehr ernst nehmen. Denn Google macht ziemlich klar, dass es ohne genehmigte Verlängerung zu Serviceeinschränkungen kommen kann. Und das betrifft nicht nur irgendeine technische Randfunktion, sondern deine API-Integration selbst – mit möglichen Auswirkungen auf bezahlte Werbung und organische Shopping-Erlebnisse.
Was sich konkret ändert
Die Content API for Shopping wird am 18. August 2026 abgelöst. An ihre Stelle tritt die Merchant API. Damit verschiebt Google die technische Grundlage, über die Händler und Plattformen Produktdaten, Merchant-Center-Informationen und weitere Shopping-relevante Prozesse verwalten.
Für dich bedeutet das: Wenn du heute Systeme betreibst, die über die Content API for Shopping mit Google kommunizieren, musst du prüfen, ob diese Systeme bereits mit der Merchant API arbeiten können. Das betrifft zum Beispiel Feed-Management-Tools, eigene Middleware, Shop-System-Erweiterungen, interne Datenpipelines, Agenturtools oder Automatisierungen, die Produktdaten regelmäßig aktualisieren.
Manchmal wird so eine API-Migration unterschätzt, weil sie auf dem Papier einfach klingt: alte Schnittstelle raus, neue Schnittstelle rein. In der Praxis ist es selten so sauber. Feldnamen ändern sich, Authentifizierungen müssen geprüft werden, Fehlermeldungen verhalten sich anders, Limits oder Antwortstrukturen können abweichen. Und dann hängt irgendwo noch ein Cronjob, den seit zwei Jahren niemand angefasst hat, der aber jeden Morgen um 4:15 Uhr Produktbestände aktualisiert. Genau solche Kleinigkeiten sind es, die bei API-Umstellungen gern für unangenehme Überraschungen sorgen.
Google weist in den eigenen Hinweisen ausdrücklich darauf hin, dass die Content API for Shopping am genannten Datum eingestellt wird. Falls du mehr Zeit brauchst, kannst du verlängerten Zugriff beantragen. Das klingt zunächst beruhigend, ist aber mit Vorsicht zu lesen: Beantragen heißt nicht automatisch bekommen. Und selbst wenn die Verlängerung bewilligt wird, gilt sie nur bis zu einem ausgewählten neuen Enddatum.
Die Verlängerung: Was du beantragen kannst
Das Formular für den verlängerten Zugriff fragt mehrere Informationen ab. Du musst unter anderem deine E-Mail-Adresse, den Namen deines Partners oder Unternehmens, deine Website, die relevanten Google-Cloud-Projekt-IDs und eine geschäftliche Begründung angeben. Außerdem sollst du erklären, warum du die zusätzliche Zeit benötigst.
Interessant ist, dass Google zwei mögliche Verlängerungsfristen anbietet: 15. Oktober 2026 oder 31. Dezember 2026. Damit bekommst du, falls dein Antrag genehmigt wird, entweder knapp zwei weitere Monate oder etwas mehr als vier Monate Zeit. Das ist nicht nichts, aber auch kein ganzer zusätzlicher Projektzyklus. Wer glaubt, man könne mit einer Verlängerung die Migration auf irgendwann später schieben, wird sich wahrscheinlich selbst ein Bein stellen.
Aus meiner Sicht ist die Wahl des Verlängerungsdatums ein ziemlich wichtiger Punkt. Wenn dein Team bereits mitten in der Umstellung steckt und nur noch Tests, Freigaben oder einzelne Partner-Integrationen offen sind, kann der 15. Oktober 2026 ausreichend sein. Wenn du allerdings ein größeres System betreibst, viele Kundenkonten verwaltest oder noch gar nicht tief in der technischen Analyse bist, könnte der 31. Dezember 2026 realistischer sein. Trotzdem würde ich auch dann nicht bis Dezember planen. Eine Verlängerung ist ein Puffer, kein Projektplan.
Google verlangt außerdem eine geschäftliche Rechtfertigung. Das ist kein unwichtiger Formalismus. Du solltest hier nicht einfach schreiben, dass dein Team noch keine Zeit hatte. Besser ist eine klare, nachvollziehbare Erklärung: Welche Systeme sind betroffen? Wie viele Merchant-Konten hängen daran? Welche Funktionen sind kritisch? Gibt es externe Abhängigkeiten? Welche Risiken entstehen bei einer Unterbrechung? Und, ganz wichtig, wie sieht dein Migrationsplan aus?
Wenn ich so einen Antrag vorbereiten müsste, würde ich ihn intern fast wie eine kleine technische Risikoanalyse behandeln. Nicht übermäßig dramatisch, aber konkret. Google möchte vermutlich sehen, dass du nicht einfach aufschiebst, sondern aktiv migrierst und nur aus nachvollziehbaren Gründen mehr Zeit brauchst.
Welche Angaben besonders sorgfältig sein sollten
Die Google-Cloud-Projekt-IDs sind besonders wichtig, weil Google darüber deine API-Nutzung und die betroffenen Integrationen zuordnen kann. Wenn du hier etwas vergisst oder falsche IDs einträgst, kann das später ziemlich nervig werden. Gerade bei größeren Setups gibt es oft mehrere Projekte: eines für Produktion, eines für Staging, vielleicht noch alte Projekte aus früheren Tests oder getrennte Projekte für verschiedene Kundenbereiche.
Ich würde hier nicht aus dem Bauch heraus antworten. Lass jemanden aus dem technischen Team prüfen, welche Projekte tatsächlich Requests an die Content API for Shopping senden. Wenn du mit externen Dienstleistern arbeitest, solltest du sie ebenfalls einbeziehen. Manchmal liegt die eigentliche API-Kommunikation nicht dort, wo man sie vermutet.
Auch die angegebene E-Mail-Adresse ist nicht bloß Kontaktkosmetik. Google schreibt, dass Support-Teams diese E-Mail-Adresse verwenden, falls Rückfragen zur Prüfung des Verlängerungsantrags nötig sind. Wenn dort eine allgemeine Adresse landet, die niemand regelmäßig prüft, kann aus einem kleinen Rückfrageprozess schnell ein Problem werden. Nimm also eine Adresse, die zuverlässig überwacht wird, idealerweise mit Zugriff für mehrere Verantwortliche.
Warum die Migration mehr als nur Technik ist
Auf den ersten Blick klingt das alles sehr technisch. Eine API wird ersetzt, Entwickler passen Code an, fertig. Aber im Shopping-Kontext hat so eine Änderung fast immer geschäftliche Folgen. Produktdaten sind nicht einfach Daten. Sie steuern, welche Artikel sichtbar sind, welche Preise ausgespielt werden, ob Verfügbarkeiten stimmen, ob Kampagnen sauber laufen und ob Nutzer überhaupt das sehen, was sie kaufen können.
Wenn deine API-Integration schlechter funktioniert oder teilweise ausfällt, kann das direkte Auswirkungen auf deine Performance haben. Google warnt ausdrücklich vor Service Degradation, also einer Verschlechterung oder Einschränkung des Dienstes, wenn du keine Verlängerung beantragst, sie nicht genehmigt wird oder du das genehmigte Enddatum überschreitest. Das ist ein recht deutliches Signal.
Besonders heikel ist die Formulierung, dass dies deine API-Integration direkt betreffen und sich auf Werbeerlebnisse sowie organische Erlebnisse auswirken kann. Für Händler kann das bedeuten, dass Produktdaten nicht wie gewohnt aktualisiert werden. Preise könnten veraltet sein. Produkte könnten nicht korrekt erscheinen. Bestände könnten abweichen. Kampagnen könnten schlechter performen, weil Datenqualität und Aktualität leiden.
Natürlich heißt das nicht automatisch, dass am Morgen des 19. August 2026 alles brennt. Aber verlassen würde ich mich darauf nicht. Google bereitet solche Übergänge meist mit Ankündigungen vor, und wenn dann ausdrücklich von möglichen Einschränkungen gesprochen wird, solltest du das als ernst gemeinte Warnung behandeln.
Ein Beispiel aus der Praxis: Stell dir einen Händler mit mehreren tausend Produkten vor, der Preise und Verfügbarkeiten mehrmals täglich automatisiert aktualisiert. Wenn diese Aktualisierung plötzlich ausfällt oder verzögert wird, sieht der Nutzer eventuell ein Produkt, das gar nicht mehr verfügbar ist. Oder ein Preis stimmt nicht. Das wirkt klein, aber es kann Conversion-Raten, Freigaben, Anzeigenqualität und letztlich Umsatz berühren. Bei saisonalen Produkten oder stark schwankenden Sortimenten wird das noch empfindlicher.
Wer besonders aufmerksam sein sollte
Besonders aufmerksam solltest du sein, wenn du nicht nur ein einzelnes Merchant Center betreust, sondern viele Konten oder Kunden. Agenturen, SaaS-Plattformen, Feed-Management-Anbieter und größere E-Commerce-Teams haben oft mehrere Schichten zwischen Shop-System und Google. Da gibt es Exportlogik, Normalisierung, Mapping, Fehlerbehandlung, Monitoring und manchmal noch kundenindividuelle Sonderregeln. Eine API-Migration muss durch all diese Schichten durch.
Auch wenn du eine Standardsoftware nutzt, bist du nicht automatisch aus dem Schneider. Vielleicht liefert dein Anbieter rechtzeitig ein Update. Vielleicht auch nicht. Vielleicht musst du es aktiv installieren, konfigurieren oder neu autorisieren. Ich habe schon öfter erlebt, dass Unternehmen dachten, ein Anbieter würde „das schon machen“, und dann stellte sich heraus, dass ein bestimmtes Modul, ein alter Connector oder eine individuelle Anpassung eben nicht automatisch migriert wurde.
Wenn du intern eher auf Marketingseite sitzt, solltest du trotzdem nachfragen. Nicht technisch bis ins letzte Detail, aber klar genug: Nutzen wir die Content API for Shopping? Wer ist verantwortlich? Gibt es einen Plan für die Merchant API? Sind Tests geplant? Brauchen wir eine Verlängerung? Das sind keine übertriebenen Fragen, sondern schlicht gutes Risikomanagement.
Wie du jetzt sinnvoll vorgehst
Der wichtigste Schritt ist eine ehrliche Bestandsaufnahme. Du musst wissen, ob und wo die Content API for Shopping bei dir im Einsatz ist. Das klingt banal, ist es aber in gewachsenen Systemlandschaften selten. Fang nicht mit dem Formular an, sondern mit der Frage: Welche Prozesse hängen aktuell an dieser API?
Prüfe, ob Produktuploads, Preisänderungen, Bestandsupdates, Kontoverwaltung, Fehlerabfragen oder Reporting-Prozesse betroffen sind. Danach solltest du klären, welche dieser Funktionen bereits über die Merchant API abgebildet werden können und wo noch Anpassungen nötig sind. Wenn du Entwickler im Team hast, sollten sie frühzeitig testen, nicht erst kurz vor dem Stichtag.
Ich würde außerdem Monitoring und Fehlermeldungen nicht vergessen. Eine Migration gilt erst dann als stabil, wenn du nicht nur erfolgreiche Standardfälle getestet hast, sondern auch Fehlerfälle verstehst. Was passiert bei ungültigen Produktdaten? Wie sehen Fehlermeldungen aus? Werden Alerts ausgelöst? Kann dein Support-Team sie interpretieren? Solche Dinge wirken trocken, retten dir aber im Betrieb den Tag.
Wenn du merkst, dass die vollständige Migration bis zum 18. August 2026 unsicher ist, solltest du den Antrag auf verlängerten Zugriff nicht auf die lange Bank schieben. Gerade wenn Google Rückfragen hat, brauchst du Zeit. Und falls dein Antrag abgelehnt wird, musst du ebenfalls reagieren können. Ein Antrag zwei Tage vor der Deadline ist, freundlich gesagt, mutig.
Was in eine gute Begründung gehört
Eine gute Begründung sollte knapp, aber belastbar sein. Du kannst erklären, welche geschäftskritischen Prozesse betroffen sind, warum die Migration noch nicht abgeschlossen werden kann und welchen konkreten Plan du für die Umstellung hast. Wenn du technische Abhängigkeiten hast, nenn sie. Wenn du mehrere Google-Cloud-Projekte oder viele Merchant-Konten betreibst, mach das deutlich.
Es hilft, wenn du nicht nur Probleme beschreibst, sondern auch Fortschritt. Zum Beispiel, dass Entwicklung und Tests bereits laufen, dass bestimmte Module schon umgestellt sind oder dass du einen Rollout in Phasen planst. Das zeigt, dass du die Verlängerung nutzt, um sauber abzuschließen, nicht um das Thema zu ignorieren.
Mein persönlicher Rat wäre: Lass die Begründung von Technik und Business gemeinsam formulieren. Entwickler wissen, was realistisch ist. Das Business weiß, welche Auswirkungen ein Ausfall hätte. Zusammen entsteht meist ein Antrag, der weder zu technisch noch zu vage ist.
Die eigentliche Botschaft hinter der Frist
Die auffälligste Botschaft ist nicht nur, dass ein Formular verfügbar ist. Die eigentliche Botschaft lautet: Google meint die Ablösung der Content API for Shopping ernst. Die Merchant API ist der neue Weg, und wer weiterhin auf der alten Schnittstelle bleibt, bewegt sich in Richtung Risiko.
Eine Verlängerung bis Oktober oder Dezember 2026 kann dir Luft verschaffen. Aber sie ändert nichts daran, dass du migrieren musst. Ich würde sie daher wie eine Versicherung betrachten. Gut, wenn du sie hast. Schlecht, wenn du dich darauf ausruhst.
Gerade im E-Commerce ist Datenstabilität oft unsichtbar, solange alles funktioniert. Niemand jubelt, wenn Bestände korrekt aktualisiert werden. Aber sobald etwas schiefläuft, merken es alle: Marketing, Support, Produktteam, Umsatzverantwortliche und manchmal auch Kunden. Deshalb ist diese API-Umstellung ein klassisches Thema, das früh langweilig wirkt und spät plötzlich dringend wird.
Wenn du betroffen bist, hast du im Grunde drei Aufgaben. Erstens: herausfinden, ob deine Systeme die Content API for Shopping nutzen. Zweitens: die Migration zur Merchant API planen und testen. Drittens: falls nötig, rechtzeitig und sauber verlängerten Zugriff beantragen. Mehr Magie steckt nicht dahinter. Aber genau diese einfachen Dinge müssen eben gemacht werden.
Der 18. August 2026 ist der harte Orientierungspunkt. Wenn du bis dahin nicht vollständig auf die Merchant API umgestellt bist, solltest du eine Verlängerung beantragen und dabei sorgfältig erklären, warum du sie brauchst. Nach Ablauf deiner genehmigten Frist, ob am 15. Oktober oder am 31. Dezember 2026, solltest du nicht mehr auf die alte API angewiesen sein. Alles andere wäre unnötig riskant.
Unterm Strich ist das eine gute Gelegenheit, deine Shopping-Integration einmal sauber anzusehen. Nicht hektisch, nicht panisch, aber gründlich. Denn solche Migrationsfenster sind manchmal lästig, ja. Gleichzeitig zwingen sie dich, alte Abhängigkeiten aufzuräumen, Verantwortlichkeiten zu klären und technische Prozesse robuster zu machen. Und wenn du am Ende ohne Unterbrechung auf der Merchant API läufst, wirst du froh sein, das Thema nicht erst in der letzten Woche angefasst zu haben.
