Feed prodotti per Google Merchant Center: la guida

Chi digita «feed prodotti google merchant» ha quasi sempre un e-commerce già attivo e si scontra con il fraintendimento più comune dello shopping search: il feed prodotti non è il sito. È un file strutturato — un elenco di articoli con attributi precisi, uno per riga — che invii a Google Merchant Center separatamente da qualunque cosa il motore di ricerca trovi facendo la scansione delle tue pagine. Merchant Center non legge il tuo catalogo online come farebbe Googlebot con un articolo di blog: legge esattamente ciò che il feed dichiara, lo valida attributo per attributo e decide se ogni prodotto può comparire nelle schede Shopping, nelle schede prodotto gratuite o negli annunci a pagamento.

Confondere le due superfici genera errori molto concreti. Si ottimizza il tag title della pagina prodotto pensando che influenzi anche il titolo mostrato in Shopping — non è così, sono due campi distinti con regole diverse. Si aggiorna il prezzo sul sito e si dà per scontato che il feed si allinei da solo, quando invece ha un proprio ciclo di generazione e caricamento. Si presume che i dati strutturati Product bastino da soli, quando in realtà dialogano con il feed ma non lo sostituiscono. Questo articolo tratta il feed come oggetto a sé: cosa deve contenere, quale attributo ha più leva di tutti gli altri, perché la maggior parte delle disapprovazioni si concentra su due soli campi, e cosa fare quando l'origine dei dati sul sito non si può correggere in tempi brevi.

Il feed non è una copia del sito: è un contratto di dati

Un feed prodotti è tecnicamente un file — XML, TSV o generato tramite la Merchant API — che elenca ogni variante di ogni prodotto come una riga a sé, con un set fisso di colonne che Google riconosce. Non è un crawl: se una pagina cambia ma il feed non viene rigenerato, Merchant Center continua a mostrare i vecchi dati finché non arriva un nuovo caricamento, che sia manuale, schedulato o via API.

Ogni riga passa attraverso una validazione automatica al momento del caricamento e una verifica continua nel tempo, che include il ricontrollo periodico della pagina di destinazione collegata. Il risultato di quella verifica è quello che si vede nella sezione Diagnostica di Merchant Center: prodotti approvati, in sospeso, o disapprovati, con un motivo specifico per ciascuno. Trattare il feed come «una cosa che si genera una volta e si dimentica» è la causa più comune di un tasso di approvazione che scende senza che nessuno se ne accorga.

Gli attributi che contano: obbligatori e consigliati

Google richiede un set minimo di attributi per accettare un prodotto, e ne consiglia altri che non sono obbligatori ma influenzano pesantemente sia l'idoneità sia la qualità del match con le query di ricerca. Vale la pena capire cosa fa ciascuno, non solo che è richiesto:

• id — identificativo univoco e stabile della singola variante (non del prodotto padre). Deve restare invariato nel tempo: cambiarlo equivale, agli occhi di Google, a cancellare un prodotto e crearne uno nuovo, con perdita della cronologia di performance.
• title — il nome del prodotto così come compare nelle schede Shopping. È il campo con più peso sul matching con la query di ricerca, e lo trattiamo a parte nella prossima sezione.
• description — il testo descrittivo usato per il matching semantico, non per persuadere: deve elencare caratteristiche verificabili (materiale, uso, compatibilità) più che benefici astratti.
• availability — in_stock, out_of_stock o preorder. È uno dei due attributi, insieme al prezzo, che Google ricontrolla più spesso confrontandolo con la pagina live.
• price — deve corrispondere esattamente, valuta inclusa, a ciò che un utente vede sulla pagina di destinazione al momento dell'acquisto, sconti e IVA compresi secondo le regole del mercato di destinazione.
• gtin e brand — il codice prodotto globale (EAN, UPC, ISBN a seconda della categoria) più il marchio identificano univocamente un articolo esistente a catalogo; per prodotti generici o senza marchio serve dichiararlo esplicitamente, non lasciare il campo vuoto.
• condition — new, refurbished o used: incide sia sull'idoneità sia su come il prodotto viene presentato accanto a concorrenti dello stesso articolo.
• image_link — l'URL dell'immagine principale usata nella scheda; ha requisiti tecnici propri, trattati più sotto.

Il titolo è il campo con più leva — e non è il tag title della pagina

Se dovessi ottimizzare un solo attributo del feed, sarebbe il titolo. È il primo elemento testuale con cui Google fa matching tra la query di un utente e i tuoi prodotti, ed è anche il testo più visibile nella scheda stessa. Ma un titolo di feed efficace segue una logica diversa da un tag title pensato per la SERP organica.

Un title tag di pagina può permettersi persuasione: superlativi, un beneficio, un richiamo alla marca in chiusura. Un titolo di feed deve invece anteporre gli attributi su cui le persone cercano davvero, nell'ordine in cui probabilmente li digitano: marca, tipo di prodotto, attributi distintivi come colore, misura o materiale, e infine il modello se rilevante. «Nike Pegasus 40 Scarpe da Running Uomo Nero 42» funziona meglio di «Le scarpe da running più comode per i tuoi allenamenti», perché la seconda versione, pur essendo un ottimo title di pagina, non contiene nessuno dei termini con cui un utente cercherebbe quello specifico articolo.

Il motivo è strutturale: il titolo del feed compete per un match con una query transazionale breve, non per un posizionamento editoriale. Copy emotivo, tutto maiuscolo o parole ripetute per keyword stuffing non aumentano la pertinenza percepita da Google — la riducono, perché occupano spazio che dovrebbe contenere un attributo verificabile.

• Evita: testo tutto maiuscolo, emoji, frasi promozionali («SPEDIZIONE GRATIS», «OFFERTA LIMITATA»), punteggiatura ripetuta.
• Anteponi sempre: marca, tipo di prodotto, poi le variabili che distinguono la variante specifica (taglia, colore, capacità, materiale).
• Lascia il modello o il codice articolo alla fine, utile per chi cerca già sapendo esattamente cosa vuole.

Requisiti delle immagini e i motivi di rifiuto più frequenti

L'immagine principale deve mostrare il prodotto reale che si sta vendendo, non un'illustrazione generica, un'icona segnaposto o un'immagine con testo promozionale sovrapposto. Google richiede una risoluzione minima sufficiente per evitare che l'immagine appaia sgranata quando viene ingrandita nella scheda, e penalizza sia lo stiramento innaturale di un'immagine troppo piccola sia la presenza di watermark, loghi del rivenditore o cornici decorative sovrapposte al prodotto.

I rifiuti legati alle immagini seguono quasi sempre uno di questi schemi, in ordine di frequenza:

• immagine sostituita da un'icona o da un placeholder («immagine non disponibile») invece del prodotto reale;
• testo promozionale, watermark o loghi sovrapposti che coprono parte del prodotto;
• immagine palesemente non corrispondente al prodotto descritto nel titolo, spesso per un errore di mappatura tra id e URL immagine, non per cattiva fede;
• risoluzione troppo bassa o immagine stirata per adattarla a un formato che non è il suo.

Prezzo e disponibilità: perché è la causa numero uno di disapprovazione

Se un solo aspetto del feed dovesse ricevere priorità assoluta di manutenzione, sarebbe la corrispondenza esatta tra prezzo e disponibilità dichiarati nel feed e quelli mostrati sulla pagina di destinazione al momento in cui Google la ricontrolla: è, in pratica, la causa più frequente di disapprovazione a livello di singolo prodotto, e nei casi ripetuti diventa un problema a livello di intero account, perché Google la classifica come rappresentazione ingannevole del prodotto, non come un semplice errore tecnico.

Il problema quasi mai nasce da malafede: nasce da un disallineamento tra sistemi. Un prezzo aggiornato sul sito ma non rigenerato nel feed, uno sconto applicato lato checkout ma non riportato come sale_price, una disponibilità aggiornata nel gestionale con un ritardo di sincronizzazione: sono tutti scenari in cui ogni sistema, preso da solo, è corretto, ma la combinazione produce un mismatch che Google intercetta al primo ricontrollo.

La soluzione strutturale è generare il feed a partire dalla stessa fonte dati che alimenta il sito — lo stesso database prodotti, non un foglio di calcolo mantenuto a parte che inevitabilmente diverge nel tempo. Ogni livello intermedio tra la fonte dati reale e il feed è un punto in cui prezzo o disponibilità possono disallinearsi senza che nessuno se ne accorga, fino alla disapprovazione.

Dove il feed e i dati strutturati Product si parlano — e dove no

I dati strutturati Product (schema.org/Product, con i suoi blocchi offers, price e availability) inseriti nelle pagine prodotto del sito servono principalmente ai risultati arricchiti nella ricerca organica: prezzo, disponibilità e valutazioni possono comparire direttamente nello snippet. Google può anche usare questi dati come segnale di verifica incrociata rispetto a ciò che il feed dichiara per lo stesso URL, il che significa che un disallineamento tra markup e feed è un ulteriore modo, oltre alla pagina visibile, in cui un'incoerenza può emergere.

Quello che i dati strutturati non fanno è sostituire il feed come meccanismo di invio a Merchant Center: restano due canali distinti, e solo il feed determina l'idoneità di un prodotto per Shopping o per le schede gratuite. Tenerli sincronizzati — stesso prezzo, stessa disponibilità, stesso identificativo di riferimento dove possibile — riduce la superficie di errore, invece di trattarli come due lavori separati fatti da due persone diverse in due momenti diversi, che è spesso l'origine reale del disallineamento quando succede.

Schede prodotto gratuite e Shopping a pagamento condividono lo stesso feed

Un punto spesso frainteso: le schede prodotto gratuite — quelle che compaiono nella scheda Shopping senza che sia attiva nessuna campagna a pagamento — e gli annunci Shopping a pagamento non sono due feed diversi. Attingono allo stesso feed prodotti caricato in Merchant Center; la differenza è quale livello si aggiunge sopra: un'offerta a pagamento con targeting e budget, oppure nessuna offerta e visibilità organica sulla superficie Shopping.

La conseguenza pratica è che la qualità del feed non è un problema solo per chi gestisce campagne Shopping: un prodotto disapprovato o con dati scadenti perde idoneità anche per la visibilità gratuita. Curare titolo, immagine, prezzo e disponibilità ha quindi un ritorno che precede qualunque discorso di budget o strategia di offerta — quelli restano fuori dal perimetro di questo articolo, dove l'oggetto è il feed, non come impostare le campagne che lo usano.

Regole del feed e feed supplementari: correggere i dati senza toccare il sito

Non sempre è possibile intervenire alla fonte in tempi brevi: un campo che manca nel gestionale, una categoria mal mappata, un brand scritto in modo incoerente. Merchant Center offre due meccanismi per questo scenario, entrambi senza toccare il codice del sito.

Le regole del feed trasformano o derivano il valore di un attributo a partire da altre colonne già presenti — estrarre una porzione di testo, sostituire un valore, unire due campi — applicate a tutte le righe interessate in un colpo solo, invece di correggere prodotto per prodotto.

Un feed supplementare è invece una seconda fonte dati, più piccola, unita al feed primario tramite l'id comune per aggiungere o correggere attributi specifici: tipicamente quando il sistema che genera il feed principale non ha accesso a un dato che esiste altrove, per esempio un elenco di GTIN raccolto a parte.

• derivare product_type in modo coerente a partire da una colonna categoria che nel sito ha una tassonomia diversa da quella che Google si aspetta;
• correggere valori di availability scritti in modo non standard da un'integrazione legacy, senza aspettare una modifica del gestionale;
• aggiungere GTIN mancanti tramite un feed supplementare quando il catalogo storico non li ha mai registrati;
• normalizzare la scrittura del brand quando proviene da fornitori diversi con convenzioni diverse tra maiuscole, spazi e abbreviazioni.

Diagnosticare le disapprovazioni in modo sistematico, non prodotto per prodotto

Il punto di partenza corretto è la sezione Diagnostica di Merchant Center raggruppata per problema, non l'elenco dei singoli prodotti disapprovati. Cento prodotti disapprovati per lo stesso motivo — per esempio un formato di GTIN non riconosciuto proveniente da un unico fornitore — sono un solo problema da risolvere a livello di regola o di fonte dati, non cento correzioni manuali separate.

Vale anche la pena distinguere un errore che un occhio umano non vedrebbe da un problema visibile: se il prezzo viene iniettato via JavaScript dopo il caricamento iniziale della pagina, un controllo manuale nel browser, che esegue il JavaScript, può sembrare corretto mentre il sistema di verifica del prezzo, a seconda di come recupera la pagina, può registrare un valore diverso. In questi casi conviene controllare cosa viene effettivamente restituito da un semplice recupero della pagina, non solo cosa si vede aprendo il sito normalmente.

Infine, è più utile monitorare l'andamento del tasso di approvazione nel tempo che il numero assoluto di prodotti disapprovati in un dato momento: un catalogo che cresce genera fisiologicamente più disapprovazioni in valore assoluto, ma un tasso che peggiora settimana dopo settimana segnala un problema strutturale nella pipeline dei dati, mentre un tasso stabile su un catalogo in crescita è, nella sostanza, un feed sano.