Home We Academy Business Fammi il Sito Da Lead a Cash Automazioni Aziendali News Contatti
Sito & E-commerce

Google ha spento la Content API for Shopping: cosa deve fare ora il tuo e-commerce

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

  • La Content API for Shopping è stata dismessa il 18 agosto 2026. Dal 1° settembre 2026 le richieste ricevono errori progressivi.
  • La sostituisce la Merchant API, modulare, divisa in sub-API e con funzioni che sulla vecchia interfaccia non esisteranno mai.
  • Chi usa un partner tecnologico ufficiale (per esempio l'app Google & YouTube su Shopify) non deve fare nulla: la migrazione la gestisce il provider.
  • Chi ha un'integrazione su misura, un gestionale collegato o un plugin non aggiornato deve intervenire ora, o rischia feed fermi e campagne che si svuotano.
  • Chi non fa in tempo può richiedere una proroga di accesso esteso alla vecchia API, ma è una toppa, non una soluzione.

Le due date che contano (e perché sono diverse tra loro)

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é è importante per aziende e professionisti?

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.

Chi deve agire e chi può stare tranquillo

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.

Puoi stare tranquillo se usi un partner tecnologico ufficiale

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.

Devi intervenire se hai un'integrazione su misura

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.

Pannello di controllo che monitora lo stato di un feed prodotto e l'avanzamento della migrazione verso la Merchant API
Il primo passo non è migrare: è misurare. Senza una fotografia dello stato attuale del feed non sai né cosa stai rompendo né cosa hai già rotto.

Come capire in venti minuti se il tuo feed è a rischio

Non serve un tecnico per la diagnosi iniziale. Servono venti minuti e l'accesso a Merchant Center.

  1. Apri la diagnostica prodotti e guarda la data dell'ultimo aggiornamento riuscito della sorgente dati. Se è più vecchia di quanto dovrebbe essere secondo la tua frequenza di sincronizzazione, hai già una risposta.
  2. Confronta tre prezzi a campione tra il tuo sito e la scheda in Merchant Center. Scegli prodotti che hai modificato di recente, non i best seller stabili.
  3. Controlla la sezione problemi account cercando errori di mismatch prezzo o disponibilità comparsi dopo la fine di agosto. La finestra temporale è l'indizio.
  4. Verifica come entrano i dati: feed programmato via URL, upload manuale, o chiamata API. Solo il terzo caso è esposto a questa scadenza.
  5. Chiedi a chi ha costruito l'integrazione una risposta secca: stiamo usando 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.

Cosa cambia tecnicamente tra Content API e Merchant API

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.

Identificatori, prezzi e batch

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.

Le funzioni che esistono solo di là

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.

Cosa dovrebbe fare ora un'azienda?

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.

  1. Stabilisci come entrano i dati in Merchant Center. API, feed URL o manuale. Serve una risposta certa, non un'ipotesi.
  2. Se è API, identifica l'endpoint in uso. Il dominio nella chiamata dice tutto: shoppingcontent è la vecchia, merchantapi è la nuova.
  3. Fotografa lo stato attuale. Numero di prodotti attivi, disapprovati, in attesa, e data dell'ultimo aggiornamento riuscito. Questa è la baseline con cui misurerai la migrazione.
  4. Registra il progetto Google Cloud con la Developer Registration verso il tuo account Merchant Center. È il prerequisito senza il quale la nuova API non risponde.
  5. Migra per sub-API, non tutto insieme. Prima i prodotti, poi gli inventari, poi i report, poi il resto. Le due interfacce possono convivere durante la transizione.
  6. Testa su un account di prova prima di toccare il catalogo vero. Merchant API permette di creare account di test proprio per questo.
  7. Se non arrivi in tempo, chiedi la proroga. Google prevede una richiesta di accesso esteso alla Content API. Considerala una cintura di sicurezza, non una scusa per rimandare.
  8. Metti un presidio permanente. Un controllo settimanale sullo stato del feed e un alert automatico quando i prodotti attivi calano oltre una soglia. Questo è il punto che quasi nessuno fa e che avrebbe evitato il problema a monte.

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.

Gli errori comuni che vediamo in queste migrazioni

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.

Quanto costa non fare niente

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.

Il punto di vista di Exclusiwe

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.

Domande frequenti

Come faccio a sapere se il mio e-commerce usa ancora la Content API for Shopping?

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.

Uso Shopify con l'app ufficiale Google: devo fare qualcosa?

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.

Cosa succede esattamente se non migro?

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.

Posso chiedere più tempo a Google?

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.

Quanto dura una migrazione di questo tipo?

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 prossima scadenza arriva comunque

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

Vuoi campagne che portano clienti veri?

Parliamone in una call.

Le campagne fanno parte del metodo Da Lead a Cash. In una call gratuita capiamo se è adatto alla tua azienda.

Fatto