Il 18 agosto Google ha dismesso l'interfaccia che per dieci anni ha alimentato i cataloghi prodotto. Dal 1° settembre le vecchie chiamate iniziano a fallire, in silenzio e a intermittenza. Ecco chi deve intervenire davvero e come scoprirlo in venti minuti.
Di Luca Giovannetti · 10 settembre 2026 · News dal Futuro · 13 min di lettura
Il 18 agosto 2026 Google ha spento la Content API for Shopping, l'interfaccia che per oltre dieci anni ha spinto i cataloghi prodotto dentro Merchant Center. Dal 1° settembre le chiamate che ancora la usano non vengono più semplicemente tollerate: iniziano a restituire errori progressivi, cioè a fallire sempre più spesso. Non è un annuncio, non è una deprecazione con anni davanti: è una scadenza già passata mentre molte aziende italiane erano chiuse per ferie.
Il problema è che nessuno riceve una telefonata quando succede. Un e-commerce con un'integrazione custom non vede un messaggio di errore in home page: vede i prodotti che smettono di aggiornarsi, i prezzi che restano fermi a quelli di due settimane fa, le disponibilità che raccontano bugie e le campagne Shopping che perdono spinta senza una causa evidente. Il danno arriva prima della diagnosi. In questo articolo spieghiamo chi deve intervenire davvero, chi può stare tranquillo, e come capire in mezz'ora da che parte stai.
In breve
Google ha separato due momenti che spesso vengono confusi. Il 18 agosto 2026 è la data di sunset formale: la Content API for Shopping non è più un prodotto supportato, non riceve sviluppo, non ha assistenza dedicata. Il 1° settembre 2026 è la data in cui la dismissione diventa percepibile, perché da lì le richieste cominciano a incontrare errori progressivi.
La parola chiave è "progressivi". Non è un interruttore che va a zero: è una degradazione. Una quota crescente di chiamate fallisce, in modo non uniforme e non annunciato. Questo è esattamente lo scenario peggiore dal punto di vista diagnostico, perché un sistema che fallisce sempre lo noti in un'ora, mentre un sistema che fallisce a intermittenza lo noti quando il danno è già distribuito su settimane di catalogo disallineato.
Tradotto in pratica: se il tuo negozio online aggiorna i prezzi tre volte al giorno e una parte di quegli aggiornamenti non arriva, Merchant Center continua a mostrare prodotti attivi con dati vecchi. Google non sa che hai cambiato prezzo. Il cliente clicca su un annuncio da 49 euro e trova 59 euro sul sito. A quel punto non hai solo un problema tecnico: hai un problema di disapprovazione prodotto per mismatch di prezzo, che è una delle cause di sospensione più frequenti in assoluto.
Perché il feed prodotto non è un dettaglio tecnico: è l'infrastruttura su cui poggia tutta la presenza commerciale di un e-commerce su Google. Shopping a pagamento, schede gratuite, annunci di inventario locale per chi ha anche un negozio fisico, e sempre più spesso le risposte generate dai motori conversazionali: tutto legge dallo stesso catalogo. Se quel catalogo si disallinea, si disallinea contemporaneamente su ogni superficie.
C'è poi una ragione meno ovvia e più strategica. Google ha detto in modo esplicito che le funzioni future arriveranno solo sulla Merchant API. Le recensioni prodotto e venditore caricabili via API, le notifiche push sui cambi di stato dell'account e dei prodotti, la gestione delle politiche di reso online, il collegamento con la scheda Google Business per i dati dei punti vendita: sono tutte cose che esistono di là e non esisteranno mai di qua. Restare sulla vecchia interfaccia non significa solo rischiare errori, significa scegliere di non poter usare metà degli strumenti disponibili.
Per un'azienda con 300 referenze e 4.000 euro al mese di budget Shopping, un feed che si degrada per tre settimane non è un fastidio: è un trimestre compromesso, perché il recupero della fase di apprendimento delle campagne dopo un blocco prodotti richiede tempo che non torna indietro.
Questa è la domanda che ci fanno per prima e la risposta è più rassicurante di quanto sembri. La maggior parte dei negozi online italiani non deve toccare una riga di codice. Il punto è capire in quale gruppo sei.
Google lo ha messo nero su bianco nella documentazione: se sincronizzi i dati prodotto tramite un partner tecnologico di terze parti — l'app Google & YouTube su Shopify è l'esempio che citano — non devi fare niente. La migrazione all'API nuova la gestisce il provider per conto tuo. Vale lo stesso principio per le piattaforme SaaS che mantengono l'integrazione al posto tuo.
Con una precisazione che facciamo sempre ai clienti: "il provider se ne occupa" vale se il provider è aggiornato. Un plugin WooCommerce fermo a una versione di due anni fa non è un partner tecnologico che ti protegge, è codice vecchio che parla un dialetto che Google ha smesso di ascoltare. Controlla la data dell'ultimo aggiornamento del modulo, non il fatto che esista.
Il gruppo a rischio è composto quasi sempre da queste quattro situazioni: un e-commerce con feed generato da uno script sviluppato internamente o da un'agenzia anni fa; un gestionale o un ERP che scrive direttamente su Merchant Center; un middleware costruito per gestire cataloghi multi-marketplace; un plugin abbandonato dal suo autore. Se ti riconosci in una di queste, il tuo è un cantiere aperto anche se oggi sembra che tutto funzioni.
Attenzione a un caso che vediamo spesso e che è il più insidioso: il "funziona ancora quindi va bene". Con errori progressivi, funzionare ancora non è un test valido. Una parte delle chiamate passa, e quella parte ti convince che il sistema è sano.

Non serve un tecnico per la diagnosi iniziale. Servono venti minuti e l'accesso a Merchant Center.
shoppingcontent.googleapis.com o merchantapi.googleapis.com? È l'unica domanda che conta e ha una risposta di una riga.Se il quinto punto ottiene silenzio o un "verifichiamo", quello è il tuo segnale. Nella nostra esperienza sui progetti di realizzazione e gestione di siti ed e-commerce, il tempo tra la domanda e la risposta è un indicatore di rischio più affidabile della risposta stessa.
Se hai uno sviluppatore che deve mettere le mani nel codice, queste sono le differenze che gli faranno perdere più tempo se non le conosce in anticipo.
Il cambiamento più profondo è concettuale: la Content API identificava le risorse con degli ID (merchantId, productId), la Merchant API usa un campo name che contiene il percorso completo della risorsa, per esempio accounts/4321/products/it~IT~1234. Google raccomanda esplicitamente di leggere il valore restituito dal campo name e riutilizzarlo, invece di costruirlo a mano concatenando gli ID. Il separatore nell'identificatore prodotto passa dai due punti alla tilde, e la parte channel sparisce.
Il secondo scoglio sono i prezzi. Non sono più una stringa decimale: l'importo diventa amountMicros, un intero in milionesimi, e la valuta passa da currency a currencyCode. Un milione di micro equivale a un'unità della valuta. È una modifica banale da capire e micidiale da sbagliare, perché un errore di tre zeri non genera un errore di sistema: genera un catalogo con prezzi sbagliati che Google accetta senza discutere.
Il terzo è il customBatch, che semplicemente non esiste più. Al suo posto si usano chiamate parallele asincrone. Non è una traduzione riga per riga: è una riscrittura della logica di invio, e va messa a budget come tale. In compenso la paginazione dei report passa da 250 a 1.000 righe per chiamata, il che riduce drasticamente il numero di richieste necessarie per estrarre dati.
La Merchant API è organizzata in sub-API versionate in modo indipendente, sul modello dell'API di Google Ads. Questo significa che puoi migrare un pezzo alla volta invece di fare un salto in blocco, e che le migrazioni future saranno meno traumatiche. Le novità che valgono davvero per un'azienda: gestione delle recensioni prodotto e venditore, notifiche push sui cambi di stato, gestione delle politiche di reso, impostazioni omnicanale per chi vende anche in negozio, collegamento diretto con la scheda Google Business, e supporto gRPC oltre a REST.
Chi ha un punto vendita fisico dovrebbe guardare con attenzione le impostazioni omnicanale e gli inventari locali: è il ponte tra il catalogo online e le ricerche di prossimità, e si incastra direttamente con il lavoro che descriviamo nella nostra guida alle categorie della scheda Google.
Otto passi, in ordine, da far eseguire a chi gestisce la parte tecnica. Se il punto 1 dà esito negativo, i successivi non ti riguardano.
shoppingcontent è la vecchia, merchantapi è la nuova.L'ottavo passo è quello che trasforma un'emergenza in un processo. È esattamente il tipo di controllo che si automatizza una volta e non si tocca più, e che raccontiamo nel dettaglio nella pagina dedicata alle automazioni aziendali.
Sono sempre gli stessi cinque, e nessuno è tecnico in senso stretto.
Confondere "il sito funziona" con "il feed funziona". Sono due sistemi indipendenti. L'e-commerce può vendere benissimo mentre il catalogo su Google si fossilizza. Il primo segnale non arriva dal sito, arriva dal calo di impression su Shopping.
Fidarsi del silenzio. Nessuno ti avvisa. Merchant Center segnala problemi sui prodotti, non ti manda una mail che dice "la tua integrazione sta morendo". L'assenza di allarmi non è una diagnosi.
Migrare tutto in un weekend. La riscrittura del batching e il cambio di formato dei prezzi sono i due punti dove si sbaglia, e si sbaglia in silenzio. Un prezzo in micro sbagliato non blocca nulla: pubblica cifre assurde.
Non conservare la baseline. Senza il conteggio dei prodotti attivi prima della migrazione, dopo non sai dire se hai perso 12 referenze o 120. È il singolo dato che rende verificabile tutto il lavoro.
Trattarla come una scadenza burocratica. Chi ha migrato a marzo non ha solo evitato un problema: ha acceso notifiche, recensioni via API e report più profondi mentre i concorrenti rincorrevano. La differenza tra i due gruppi non è il codice, è il momento in cui hanno deciso di guardarci.
Facciamo un conto realistico su un e-commerce medio italiano: 250 referenze, 3.500 euro al mese di spesa Shopping, margine lordo medio del 35%, ordine medio 78 euro.
Se il feed si degrada e il 30% dei prodotti finisce disapprovato per dati non aggiornati, la spesa non si ferma: si concentra sui prodotti rimasti, spesso quelli meno profittevoli, con un CPC che sale perché l'asta si stringe. In tre settimane la perdita non è teorica: è la somma tra il fatturato mancato sui prodotti spenti e l'inefficienza sul budget che continua a girare. Su questi numeri parliamo di un ordine di grandezza tra i 4.000 e gli 8.000 euro, prima ancora di contare il tempo necessario a far ripartire le campagne dopo il ripristino.
Il confronto è con qualche giornata di lavoro tecnico programmato. Non è una scelta difficile: è una scelta che va solo fatta prima, invece che dopo. Se vuoi capire se i tuoi numeri reggono questo tipo di stress, il ragionamento è lo stesso che facciamo quando analizziamo se un sito sta effettivamente funzionando.
Questa storia ci interessa meno per l'API e più per quello che rivela. Ogni azienda che oggi si trova con il feed rotto aveva la stessa informazione un anno fa: Google annunciò la sostituzione nell'agosto 2025, con dodici mesi di preavviso e documentazione pubblica. Non è mancata l'informazione. È mancato qualcuno il cui compito fosse leggerla.
È il vero divario che vediamo nei nostri clienti tra San Cesareo, Roma e i Castelli Romani: non tra chi ha strumenti più costosi e chi no, ma tra chi ha un presidio sulle piattaforme che usa e chi le tratta come elettrodomestici che funzionano da soli. Merchant Center, la scheda Google, il pixel, il CRM: nessuno di questi si mantiene da solo, e tutti smettono di funzionare in silenzio.
La nostra posizione è netta: se un canale porta fatturato, quel canale ha bisogno di un responsabile e di un controllo periodico calendarizzato. Non di un intervento quando qualcosa si rompe. Chi lavora con noi su acquisizione e conversione dei contatti lo sa: la manutenzione noiosa è ciò che rende possibile la crescita interessante. E se non hai in azienda le competenze per farla, la risposta è formarle o affidarle — non sperare che la scadenza successiva sia meno cattiva di questa. È il motivo per cui abbiamo costruito i percorsi di formazione per imprenditori e team.
La verifica più rapida è chiedere a chi gestisce l'integrazione quale dominio viene chiamato: se le richieste vanno verso shoppingcontent.googleapis.com stai usando l'API dismessa, se vanno verso merchantapi.googleapis.com sei già migrato. In parallelo, in Merchant Center controlla la data dell'ultimo aggiornamento riuscito della sorgente dati: se è più vecchia della tua frequenza di sincronizzazione abituale, qualcosa si è già fermato.
No. Google ha specificato che chi sincronizza i dati prodotto tramite un partner tecnologico di terze parti, e cita esplicitamente l'app Google & YouTube su Shopify, non deve intervenire: è il provider a gestire la migrazione. Vale lo stesso per le altre piattaforme che mantengono l'integrazione ufficiale, a patto che il modulo sia aggiornato all'ultima versione.
Dal 1° settembre 2026 le chiamate alla vecchia API incontrano errori progressivi: una quota crescente di richieste fallisce. In pratica prezzi, disponibilità e nuovi prodotti smettono di aggiornarsi in modo intermittente. Le conseguenze tipiche sono disapprovazioni per disallineamento tra il prezzo dell'annuncio e quello del sito, prodotti che escono dalle campagne e un calo di impression che sembra senza causa.
Sì. Google prevede una procedura per richiedere l'accesso esteso alla Content API for Shopping a chi ha bisogno di tempo aggiuntivo per completare la migrazione. È una misura ponte pensata per non lasciare fermi i cataloghi durante i lavori, non un modo per rimandare indefinitamente: le funzioni nuove restano comunque disponibili solo sulla Merchant API.
Dipende dalla complessità dell'integrazione. Un e-commerce con un catalogo lineare e uno script di feed ben scritto si sposta in pochi giorni di lavoro. Le tempistiche si allungano quando ci sono batching custom da riscrivere con chiamate asincrone, gestionali collegati o logiche multi-marketplace. Il consiglio pratico è migrare una sub-API alla volta e testare su un account di prova prima di toccare il catalogo in produzione.
La Content API for Shopping è finita, ma il meccanismo che l'ha fatta finire è ancora in funzione: le piattaforme su cui costruiamo il nostro fatturato cambiano, e cambiano senza chiedere il permesso. La differenza tra un'azienda che assorbe questi cambiamenti e una che li subisce non è la dimensione, è l'abitudine a controllare.
Se hai un e-commerce e non sai con certezza da che parte stai, il modo più veloce per scoprirlo è farlo guardare da qualcuno che sa dove cercare. Facciamo questo tipo di verifica sui cataloghi dei nostri clienti come parte del presidio ordinario. Scrivici e ne parliamo: mezz'ora è sufficiente per capire se hai un problema, e se non ce l'hai te lo diciamo.
Fonte: Google for Developers — Migrate from Content API for Shopping to Merchant API (pagina aggiornata il 1° settembre 2026). Annuncio originale della sostituzione: Search Engine Land, 19 agosto 2025.
Continua a leggere: cosa cambia con le AI Overviews dentro AI Mode · quando conviene davvero aprire un e-commerce · tutte le News dal Futuro
Le campagne fanno parte del metodo Da Lead a Cash. In una call gratuita capiamo se è adatto alla tua azienda.