Google Shopping e Merchant Center 2026 su PrestaShop: feed prodotto, GTIN, Performance Max

Google Shopping nel 2026: il canale di acquisizione più mal sfruttato dai negozi PrestaShop

Sui negozi PrestaShop mid-market che auditiamo, Google Shopping rappresenta in media il 18% del fatturato acquisito. Quando il feed è fatto bene. Quando non lo è — ed è la situazione di default — è il 3% o meno, con un costo di acquisizione che vola e prodotti disapprovati da Merchant Center senza che ce ne si accorga.

Lo scarto si gioca su tre livelli: la qualità del feed (attributi richiesti, GTIN, identificativi unici), la strategia di campagna (Performance Max vs Standard Shopping) e la conformità di Merchant Center (politiche 2024-2026, Comparison Shopping Service, prezzo di riferimento). I tre sono temi distinti e tecnici. Questo articolo li copre nell’ordine in cui appaiono nella pipeline di un merchant che avvia o ristruttura il proprio canale Shopping nel 2026.

Cosa è cambiato in Merchant Center nel 2024-2026

Tre evoluzioni maggiori ridefiniscono il terreno di gioco:

Merchant Center Next sostituisce la vecchia interfaccia

Dal 2024, Google ha migrato tutti gli account verso Merchant Center Next — una riprogettazione che appiattisce la gerarchia, semplifica la creazione di feed e impone più rigorosamente le politiche. Conseguenza pratica: feed che passavano in silenzio 18 mesi fa sono oggi disapprovati in blocco, in particolare sull’assenza di shipping e di tax per i merchant non-UE.

La fine dell’allineamento sui Comparison Shopping Service lato UE

A seguito della decisione europea e dei suoi aggiustamenti 2023-2024, i merchant UE possono passare da Google direttamente o tramite un CSS partner con un rabato effettivo del 20% sul CPC. Su budget Shopping superiori ai 5.000 €/mese, il passaggio tramite un CSS partner (Adwise, KelKoo Group, Productsup, ecc.) è redditizio. È un’ottimizzazione che non costa niente da implementare ma che l’80% dei merchant PrestaShop non attiva.

Gli attributi di reso e spedizione sono diventati quasi obbligatori

Da fine 2024, Google esige shipping e return_policy espliciti sulla grande maggioranza delle schede Shopping. Senza questo, gli annunci girano ma con visibilità degradata e Quality Score in calo. È allineato con le proprietà Schema.org Product 2026 (hasMerchantReturnPolicy, shippingDetails) che Google ha già imposto sui rich result.

Anatomia di un feed prodotto conforme nel 2026

Il feed Google Shopping è un file (XML, CSV, o tramite Content API) che descrive ogni prodotto a Google. Venticinque attributi sono possibili, dieci sono obbligatori, e il loro trattamento corretto fa la differenza tra un account Merchant Center sano e un account sotto warning permanente.

I dieci attributi obbligatori — e le insidie su PrestaShop

Gli attributi “opzionali ma critici”

Quattro attributi non sono marcati come obbligatori ma la loro assenza degrada fortemente la performance:

• shipping: tabella di tariffe di consegna per paese/regione. Senza, Google applica regole di default spesso sbagliate. Da compilare con cura, soprattutto per i negozi multi-paese.
• tax: tassa applicabile. Obbligatoria per i merchant US. Per l’UE, il prezzo IVA inclusa è in price e l’IVA è implicita ma può essere dichiarata.
• google_product_category: categoria Google (3-5 livelli). Senza, Google indovina — spesso male. Da mappare dalla tassonomia ufficiale Google (5.600 categorie).
• product_type: la propria tassonomia, utile per la segmentazione delle campagne.

Varianti e combinazioni: la complessità PrestaShop

Su PrestaShop, una scheda prodotto con varianti (taglia × colore) è un prodotto con più id_product_attribute. Su Google Shopping, ogni variante deve essere una riga distinta del feed, con:

• id unico per variante (tipicamente {id_product}-{id_product_attribute}).
• item_group_id comune a tutte le varianti dello stesso prodotto parent (tipicamente id_product). È ciò che permette a Google di raggruppare le varianti nell’interfaccia acquirente.
• Attributi di variazione: color, size, material, pattern, gender, age_group — a seconda della categoria.
• GTIN per variante (spesso un EAN diverso per taglia o colore).
• Stock per variante.

L’errore più frequente: inviare una sola riga per prodotto parent con un prezzo medio e uno stock aggregato. Google blocca immediatamente. Il modulo Google Shopping PrestaShop gestisce nativamente questa esplosione per variante, con mapping degli attributi PrestaShop verso gli attributi Google.

GTIN: l’attrito n°1 e la soluzione

Il GTIN (Global Trade Item Number) è l’identificativo universale di un prodotto. EAN-13 in Europa, UPC-A negli US, ISBN per i libri. Google chiede il GTIN per tutti i prodotti che ne hanno uno nativamente (brand noti, prodotti manufatti). Per i prodotti senza GTIN (creazione artigianale, marchio proprio esclusivo, servizi), bisogna esplicitamente marcare identifier_exists: false.

Due insidie frequenti:

1. Gli EAN-13 non validi

La tredicesima cifra è un check digit, calcolato sui primi dodici secondo l’algoritmo Modulo 10. Molti negozi importano referenze produttore con EAN troncati o inventati. Google le rigetta in massa. La validazione dovrebbe essere fatta al momento dell’import, non scoperta tre settimane dopo quando Merchant Center disapprova 800 schede.

2. Il GTIN condiviso tra varianti

Errore classico su PrestaShop: l’EAN è memorizzato sul prodotto parent (ps_product.ean13) invece che sulla variante (ps_product_attribute.ean13). Risultato: tutte le varianti hanno lo stesso GTIN, Google rileva la duplicazione e disapprova.

Il buon pattern: memorizzare l’EAN a livello di variante quando ha la propria referenza (caso tipico: taglie diverse dello stesso modello), e a livello di prodotto parent solo per le schede mono-variante.

Performance Max vs Standard Shopping nel 2026

Dal 2022, Google spinge Performance Max (PMax) come campagna di default. È una campagna automatizzata che combina Shopping, Display, YouTube, Discover e Search in un’unica logica di ottimizzazione. L’algoritmo decide dove piazzare gli annunci e a chi. L’inserzionista fornisce gli asset group (testi, immagini, segnali di audience) e il budget.

Quando PMax è redditizio

• Catalogo largo (1.000+ referenze) con una copertura categoriale variata.
• Dati di conversione solidi (50+ conversioni / 30 giorni per campagna, idealmente 100+).
• Margini che sostengono un CPA ottimizzato dall’algoritmo (tra +15 e +30% di CPA vs Standard, ma volume × 2 a × 5).
• Capacità di analizzare i segmenti tramite i report di asset group e di segnali di audience (report limitati ma in miglioramento dal 2024).

Quando Standard Shopping resta preferibile

• Catalogo specializzato (meno di 200 referenze) dove il controllo granulare per gruppo di prodotti è critico.
• Margini stretti che esigono un CPA stretto e un ROAS stabile.
• Categorie regolamentate (CBD, vape, certi integratori) dove PMax può allargare il targeting in modo non conforme.
• Fase di apprendimento: meglio strutturare in Standard Shopping per 3 mesi per misurare la performance per segmento, prima di passare a PMax con questi apprendimenti.

Lo stack ibrido 2026

Il pattern che funziona oggi: Standard Shopping sul top 20% del catalogo che fa l’80% del fatturato, PMax sulla long-tail. Questo combina il controllo (top prodotti strategici) e l’automazione su scala (long-tail dove il costo di ottimizzazione manuale non è redditizio).

L’export del feed PrestaShop: tre architetture

Architettura 1 — Feed statico XML/CSV rigenerato

Un cron PHP (ogni ora, o ogni notte secondo il ritmo del catalogo) rigenera un file XML o CSV esposto a un URL fisso. Merchant Center fa pull di questo file a frequenza configurata. Semplice, robusto, ma latenza di diverse ore tra un cambiamento e il suo riflesso in Shopping.

Architettura 2 — Content API push

Il modulo pusha i cambiamenti in tempo reale tramite la Google Content API. Ideale per i negozi dove i prezzi si muovono frequentemente (flash sale, dynamic pricing) o per gli inventari limitati. Più complesso da implementare, esige una quota Content API e una gestione fine degli errori.

Architettura 3 — Feed real-time tramite Merchant Center Next

Dal 2024, Merchant Center Next supporta i real-time inventory update per gli attributi critici (prezzo, stock, disponibilità). È un endpoint dedicato, indipendente dal feed principale. Il pattern consigliato nel 2026 è di combinare: un feed statico per i dati stabili (titolo, immagine, descrizione) e un push real-time per prezzo e stock.

Il modulo DataFirefly implementa l’architettura statica con un’opzione di push prezzo/stock — copre il 95% dei casi merchant senza complessità di API gateway.

Conformità Merchant Center: le politiche 2024-2026 che disapprovano

Quattro politiche sono all’origine dell’80% delle disapprovazioni nel 2026:

1. Prezzo di riferimento — direttiva Omnibus e politica Google allineata

Se mostri un prezzo barrato (“99 € invece di 149 €”), il prezzo di riferimento deve essere conforme alla direttiva Omnibus: prezzo più basso praticato negli ultimi 30 giorni. Google ha allineato la sua politica: un prezzo di riferimento non conforme = disapprovazione, e viene tracciato sull’intero account.

2. Prodotti soggetti a restrizioni e vietati

Tabacco, armi, contenuti per adulti, farmaci da prescrizione: vietati. Integratori alimentari, vape (senza nicotina), CBD: soggetti a restrizioni, con regole per paese. La disapprovazione di un solo prodotto soggetto a restrizioni può comportare una sospensione dell’account se ripetuta — filtrare sempre lato feed PrestaShop per escludere queste categorie dall’export.

3. Disponibilità incoerente

Il feed dice in_stock, la scheda mostra “Esaurito” o un pulsante disabilitato. Google confronta e disapprova. La soluzione: sincronizzare il feed con lo stock reale per variante, con una soglia (ad esempio availability = out_of_stock se quantity ≤ 0 e allow_oosp = false).

4. Politica di reso e spedizione non dichiarata

Dal 2025, Google chiede esplicitamente le politiche di reso e di spedizione. O tramite i parametri account Merchant Center (politiche globali per paese), o tramite gli attributi shipping e return_policy nel feed. Senza: warning permanente e degrado del Quality Score.

Misurare la performance — oltre il ROAS di Merchant Center

Il ROAS mostrato da Google Ads è la metrica di superficie. Per pilotare correttamente, tre altre letture:

• ROAS netto = (fatturato lordo × tasso di margine) / costo pub. Il ROAS Google non tiene conto del margine prodotto. Un ROAS di 8 su prodotti al 15% di margine è meno redditizio di un ROAS di 4 su prodotti al 45% di margine.
• Incrementality: quante di queste vendite sarebbero avvenute senza Shopping (tramite SEO organica, ritorno del brand, altro canale)? Test: mettere in pausa PMax per 14 giorni su un segmento e misurare il delta fatturato. Difficile da fare correttamente, ma critico per i budget superiori ai 20 K€/mese.
• Costo di acquisizione new vs returning. Shopping converte massicciamente su new (acquisizione). Per misurare il LTV, incrociare con il CRM/back-office PrestaShop su 6-12 mesi.

L’implementazione del server-side tracking GA4 è diventata indispensabile nel 2026 per affidabilizzare queste misure, con l’erosione dei cookie di terze parti e il Consent Mode v2.

Maillage con gli altri segnali SEO/AEO

Google Shopping non vive isolato. Gli agenti AI — Google AI Overviews, ChatGPT Shopping, Perplexity — leggono allo stesso tempo il feed Shopping (tramite Merchant Center API), i dati strutturati Schema.org della scheda, e il contenuto semantico del sito. Tre ottimizzazioni che si rafforzano reciprocamente:

• Il file llms.txt che serve da indice per gli LLM.
• Schema.org Product completo (con hasMerchantReturnPolicy, shippingDetails, aggregateRating) per il matching organico.
• Feed Shopping conforme con attributi ricchi (GTIN, brand, gender, material, age_group).

Sui negozi che investono i tre, si osserva una forte correlazione tra la qualità del feed Shopping e le citazioni AI negli agenti di shopping AI.

Budget realistico per partire nel 2026

Per un negozio PrestaShop mid-market che lancia Google Shopping:

• Modulo di feed: 149 € licenza perpetua, o 30-80 €/mese per le alternative in SaaS.
• Setup iniziale: 1-3 giorni di lavoro (mapping tassonomia Google, validazione GTIN, configurazione shipping/tax). Il modulo DataFirefly automatizza l’80% di questo setup.
• Budget Ads: iniziare a 30-50 €/giorno, salire a 200-500 €/giorno mano a mano che il ROAS si stabilizza. Lo sweet spot di apprendimento PMax è intorno alle 50 conversioni / 30 giorni.
• CSS partner: −20% sul CPC effettivo, gratuito da attivare dopo l’apertura dell’account. Redditizio già da 5.000 €/mese di budget.

Con questo setup, il ROAS target a 12 mesi è di 4-8 su margini 30-40%, con un payback dell’implementazione sui primi due mesi.

FAQ

Serve un account Google Ads per usare Merchant Center?

Per fare annunci Shopping a pagamento, sì. Ma Merchant Center da solo permette anche i free listing (annunci gratuiti nella scheda Shopping e su Search). Questi listing non convertono quanto i pagati ma è traffico gratuito che nessun negozio dovrebbe lasciare sul tavolo.

Si possono fare annunci Shopping in B2B?

Ufficialmente, Shopping è destinato al B2C. Ma negozi B2B su PrestaShop espongono il loro catalogo pubblico in Shopping per generare lead — funziona finché la scheda permette l’acquisto diretto. I prezzi devono essere IVA inclusa mostrati (o con menzione “esclusa IVA”); i negozi 100% esclusa IVA con validazione pro non sono idonei.

Cosa causa la sospensione di un account Merchant Center?

Tre cause principali: moltiplicarsi delle disapprovazioni senza correzione (Google considera che non rispetti la politica), creazione ripetuta di account per aggirare una sospensione precedente (la sospensione è tracciata per dominio, IBAN, identità fiscale), o presenza di un prodotto vietato (armi, farmaci da prescrizione). In caso di sospensione, la procedura di appello richiede un correttivo documentato, non una scusa.

Come gestire promozioni e saldi tramite Shopping?

Google Merchant Promotions permette di allegare codici promo agli annunci. Il codice deve essere valido, applicabile al carrello minimo, e conforme alla direttiva Omnibus per il prezzo barrato. Per i saldi calendarizzati (Black Friday, saldi estivi), si preparano gli annunci 7-14 giorni in anticipo tramite il feed, e si pianifica la campagna PMax con un budget × 2 o × 3 nel periodo. Vedi anche la nostra checklist Black Friday.

Il feed deve essere bilingue/multi-paese?

Sì, ma con un feed distinto per paese/lingua target. Uno stesso prodotto in Italia e in Spagna si dichiara tramite due voci in Merchant Center: una con language=it, feed_country=IT, prezzo in EUR, spedizione IT; una con language=es, feed_country=ES, prezzo in EUR (o diverso se la strategia lo giustifica), spedizione ES. Mai dichiarare un prodotto in più paesi con uno stesso feed: rompe il matching e disapprova.

In sintesi

Google Shopping nel 2026 non è un canale che si attiva in 30 minuti. È un’infrastruttura prodotto-data che esige rigore sui GTIN, pulizia sul mapping di tassonomia, conformità normativa (Omnibus, reso, spedizione) e allineamento con i segnali SEO/AEO del resto del sito. Per i negozi PrestaShop che fanno questo investimento, è tipicamente il 15-25% del fatturato acquisito con un ROAS di 4-8 e un payback dell’implementazione su 60 giorni.

Il modulo Google Shopping PrestaShop di DataFirefly automatizza gli elementi più dispendiosi: estrazione per variante, validazione GTIN, mapping tassonomia Google, export XML/CSV, integrazione Content API. Per i negozi che desiderano andare oltre, l’audit completo del canale Shopping identifica le fughe di conformità e i guadagni rapidi.

Da non dimenticare in parallelo: l’integrazione Google Search Console per seguire le performance organiche in parallelo del pagato, e il maillage interno semantico per rafforzare l’autorità topica del catalogo indipendentemente dal budget Ads.