I Product structured data collegano ciò che l’utente vede sulla scheda prodotto con informazioni leggibili dalle macchine: identità del prodotto, offerte, prezzo, disponibilità, recensioni, spedizione e resi. Per un e-commerce non sono un’aggiunta cosmetica. Sono parte di un sistema che comprende pagina, dati di catalogo, feed Merchant Center e modalità con cui Google rappresenta l’offerta.
La difficoltà non sta nel copiare un esempio JSON-LD. Sta nel mantenere coerenti fonti che cambiano con frequenze diverse e nel modellare correttamente prodotti, varianti e offerte.
Product snippet e merchant listing non sono la stessa cosa
Google documenta esperienze prodotto differenti. Le pagine in cui non è possibile acquistare direttamente possono essere idonee ai product snippet; le pagine merchant, dove l’utente può comprare, possono fornire dati più ricchi per le merchant listing. I requisiti e le proprietà supportate non sono identici.
Prima di implementare, identifica il ruolo della pagina. Una recensione editoriale, una pagina di categoria e una scheda acquistabile non dovrebbero ricevere lo stesso markup soltanto perché mostrano un nome e un prezzo.
Pagina, markup e feed: una sola verità commerciale
Il prezzo nel JSON-LD deve coincidere con quello visibile e applicabile all’utente. Lo stesso vale per valuta, disponibilità e condizione. Se il feed Merchant Center viene aggiornato ogni ora, la pagina ogni giorno e il markup da una cache separata, le discrepanze sono prevedibili.
Mappa quindi la provenienza di ogni proprietà:
- identità: SKU, GTIN, MPN, brand e nome dal catalogo;
- offerta: prezzo, valuta, disponibilità e condizione dal sistema commerciale;
- contenuto: descrizione e immagini approvate dal PIM o CMS;
- policy: spedizione e resi dalle regole effettivamente applicate;
- reputazione: recensioni e rating da una fonte conforme e riferita al prodotto corretto.
Prodotto e offerta: modellare la relazione
Product descrive il bene; Offer descrive le condizioni con cui viene venduto. Confonderli porta a identificatori instabili e prezzi associati all’oggetto sbagliato. Nei cataloghi marketplace, lo stesso prodotto può avere più offerte. Nei negozi monomarca, una pagina può rappresentare un modello con varianti acquistabili.
Evita di usare il titolo SEO come nome del prodotto se include messaggi promozionali variabili. Il dato strutturato dovrebbe riflettere l’identità commerciale stabile, mentre title e contenuto possono rispondere al search intent.
SKU e GTIN non identificano la stessa cosa
Lo SKU è il codice usato dal venditore per gestire l’articolo; il GTIN, quando assegnato, identifica il prodotto nel relativo standard commerciale. Non copiare lo SKU nel campo GTIN per eliminare un avviso. Per una variante controlla che identificatore, colore, taglia, prezzo e disponibilità appartengano alla stessa offerta selezionata.
Crea campioni con prodotto semplice, variabile, scontato e non disponibile. Confronta i dati visibili con Product, Offer e feed, registrando l’orario: una discrepanza può essere un ritardo di aggiornamento. La guida Google alle varianti descrive ProductGroup e le relazioni tra articoli. Usa solo identificatori reali e valida i requisiti del risultato a cui la pagina è effettivamente idonea.
Varianti: colore, taglia e URL
Una variante può avere SKU, prezzo, disponibilità, immagini e URL propri. La decisione su un URL separato non nasce dal markup: dipende da esperienza utente, domanda, architettura e possibilità di condividere uno stato stabile. Se il cambio variante avviene solo nel browser e l’URL non cambia, un crawler potrebbe non vedere le stesse informazioni dell’utente.
Google supporta il markup delle varianti tramite modelli specifici. Qualunque approccio scegli, mantieni coerenza tra URL canonico, variante selezionata, dati visibili e proprietà strutturate. Non dichiarare contemporaneamente tutte le varianti come disponibili se la pagina mostra un’opzione esaurita.
Prezzo e disponibilità: i campi più fragili
Promozioni, prezzi per paese, tasse, membership, bundle e disponibilità per magazzino rendono questi dati delicati. Il prezzo strutturato deve corrispondere a quello che l’utente può realmente ottenere nelle condizioni espresse dalla pagina. Un prezzo “a partire da” non dovrebbe essere presentato come offerta universale se richiede una variante specifica non selezionata.
Controlla anche gli stati di stock supportati e la velocità di aggiornamento. Una pagina esaurita non deve necessariamente essere rimossa: può conservare valore, alternative e domanda. La gestione va coordinata con la strategia delle pagine categoria e del catalogo.
Spedizione e resi
Le proprietà relative a spedizione e resi possono rendere l’offerta più comprensibile, ma richiedono regole precise per mercato, soglia, destinazione e finestra temporale. Non tradurre una policy complessa in un dato semplificato che promette condizioni non disponibili.
Quando le stesse informazioni sono gestite anche in Merchant Center, stabilisci quale sistema è la fonte e come vengono sincronizzate. La coerenza conta più della copertura massima di ogni proprietà facoltativa.
Recensioni: evitare scorciatoie rischiose
Il rating deve riferirsi al prodotto rappresentato nella pagina e derivare da recensioni genuine disponibili all’utente. Non aggregare valutazioni della categoria, del negozio o di prodotti simili per riempire aggregateRating. Oltre a essere fuorviante, questo indebolisce la fiducia nei dati.
Verifica anche cosa accade quando non ci sono recensioni, quando una moderazione ne rimuove alcune o quando varianti diverse condividono lo stesso insieme. I casi vuoti devono produrre markup pulito, non valori fittizi.
QA tecnico dei Product structured data
Testa un campione stratificato: prodotti disponibili, esauriti, in promozione, con varianti, senza GTIN, con più immagini e in più mercati. Per ogni URL confronta pagina renderizzata, JSON-LD, API catalogo e feed. Il test automatico può segnalare divergenze; la revisione umana serve per interpretare condizioni commerciali e policy.
Inserisci almeno questi controlli:
- una sola identità coerente del prodotto;
- prezzo, valuta e stock uguali nelle fonti;
- URL canonico e variante allineati;
- immagini accessibili e pertinenti;
- nessun dato demo o placeholder;
- validazione con strumenti ufficiali;
- monitoraggio dopo modifiche a tema, app o feed.
Merchant Center e Search Console
Merchant Center può segnalare problemi di feed, policy e corrispondenza della pagina. Search Console mostra report relativi ai risultati prodotto supportati. Leggili insieme: un errore di disponibilità può avere origine nel catalogo, nella cache della pagina, nel markup o nel feed.
Misura la copertura per template e mercato, non soltanto il numero totale di elementi validi. Collega le anomalie ai rilasci e verifica gli URL con impression reali. Il markup è un componente della SEO audit e-commerce, non un progetto isolato.
La priorità è la coerenza
Un’implementazione minima ma affidabile vale più di molte proprietà incomplete o discordanti. Parti da identità, offerta e URL; definisci le fonti; aggiungi spedizione, resi e varianti quando il modello dati può sostenerli; infine monitora la produzione.
La fonte primaria deve essere esplicita
Product structured data, feed Merchant Center, pagina e checkout non dovrebbero essere quattro archivi indipendenti. Definisci per ogni attributo una fonte primaria e una latenza accettabile. Il PIM può possedere brand e GTIN, l’ERP disponibilità, il motore prezzi l’offerta e il CMS il testo editoriale; il frontend deve comporre questi dati senza cambiarne il significato.
| Attributo | Fonte tipica | Coerenza da verificare |
|---|---|---|
| Identità | PIM o catalogo | SKU, GTIN, MPN e brand descrivono lo stesso articolo |
| Prezzo | Motore prezzi | Pagina, markup, feed e checkout usano valuta e condizioni compatibili |
| Disponibilità | ERP o inventory service | Stock visibile e valore schema cambiano insieme |
| Variante | Catalogo | item_group_id, colore, taglia e URL identificano la stessa variante |
| Policy | Sistema commerciale | Spedizione e resi sono validi per il mercato |
Esempio di incidente: prezzo non allineato
Supponiamo che una promozione termini a mezzanotte. Il checkout aggiorna subito il prezzo, il feed viene rigenerato dopo due ore e la cache della pagina dura sei ore. Per una parte della notte esistono tre prezzi diversi. Non è un problema risolvibile aggiungendo proprietà allo schema: occorre coordinare evento, invalidazione della cache, generazione del feed e rendering dell’offerta.
Il runbook dovrebbe identificare il sistema responsabile, gli URL coinvolti, la finestra temporale, il meccanismo di aggiornamento e il test di chiusura. La specifica di Google richiede che prezzo e disponibilità inviati corrispondano alla landing page e al checkout; consulta la specifica dei dati di prodotto di Merchant Center accanto alla regola di sincronizzazione, non soltanto a fine articolo.
Varianti: gruppo, articolo e offerta
Una variante non è soltanto un pulsante colore. È un articolo acquistabile con identità, URL o stato selezionabile, immagine, prezzo e disponibilità. Se due varianti condividono la pagina, il markup deve rappresentare correttamente il gruppo e mantenere coerente la selezione mostrata. Se hanno URL separati, ciascuna destinazione deve aprirsi direttamente sul prodotto giusto ed essere raggiungibile con link.
La documentazione sui dati strutturati Product distingue product snippet, merchant listing e supporto alle varianti. La scelta dipende da ciò che la pagina consente realmente di fare; una pagina editoriale che non vende direttamente non va descritta come un’offerta acquistabile.
Controllo di regressione
- Campiona prodotti in stock, esauriti, scontati e con più varianti.
- Confronta valori strutturati con ciò che appare senza interazioni nascoste.
- Verifica che gli identificatori restino stabili durante gli aggiornamenti.
- Controlla diagnostica Merchant Center e report dei risultati avanzati per causa.
- Ripeti i test dopo cambi a feed, tema, cache, valuta o gestione inventario.
Se Google, il feed e la scheda prodotto ricevono versioni diverse della stessa offerta, serve un audit della pipeline prima di aggiungere altro markup. Contattami per verificare template, catalogo e Merchant Center con un’unica matrice di controllo.
