Dati strutturati per gli agenti d'acquisto IA: i campi che decidono se venite citati

La maggior parte dei negozi che fallisce la verifica di idoneità agli agenti fallisce sulla stessa cosa: prezzo, disponibilità e nome del prodotto che vede un cliente sono assemblati da JavaScript nel browser, e l'HTML grezzo che un agente scarica non ne contiene nessuno. I dati strutturati resi lato server sono ciò che rende una pagina prodotto in grado di rispondere — e si verifica con un solo comando. Questa guida illustra cosa leggono davvero gli agenti, quali campi contano e come controllare le vostre pagine.

Ciò che vede un agente non è ciò che vedete voi

Aprite una pagina prodotto in un browser e c'è tutto. Scaricate la stessa URL con un client HTTP semplice e potreste ottenere un guscio: una cornice di pagina, alcuni script e contenitori vuoti che il browser avrebbe riempito.

Assistenti e crawler variano nella quantità di JavaScript che eseguono, e quelli che lo eseguono sono più lenti, più facili da saltare e meno costanti. Contare sul rendering è una scommessa che si perde in silenzio: nulla segnala un errore, semplicemente il vostro prodotto non è nella risposta.

La verifica che conta:

curl -s https://tuonegozio.it/products/tuo-prodotto | grep -c "application/ld+json"

Se restituisce 0, un agente che legge la vostra pagina non ha alcuna descrizione strutturata del prodotto. Poi verificate che l'HTML grezzo contenga davvero titolo e prezzo come testo — non come segnaposto del template.

I campi che decidono se potete essere citati

Il JSON-LD di prodotto ha molti campi facoltativi e una manciata che lavorano davvero. Grosso modo in ordine di impatto:

• name — il nome del prodotto, uguale a quello sulla pagina. Una discrepanza fra JSON-LD e testo visibile è un segnale di qualità contro di voi.
• offers.price e offers.priceCurrency — un numero e un codice valuta ISO. Un prezzo senza valuta è inutilizzabile, e una valuta in contrasto con la pagina è peggio di nessun prezzo.
• offers.availability — un valore esplicito InStock / OutOfStock. Disponibilità assente significa che un assistente esclude il prodotto da una risposta «posso comprarlo adesso» o tira a indovinare.
• image — almeno una, con una URL reale. Gli agenti costruiscono sempre più confronti visivi.
• description — la descrizione vera del prodotto, non lo slogan del negozio ripetuto su ogni scheda.
• sku / gtin — gli identificativi permettono a un agente di associare la vostra offerta allo stesso prodotto altrove. È così che comparite nei confronti invece di restare un articolo non associato.
• brand — economico da includere, usato spesso per filtrare.

È sulle varianti che la maggior parte dei cataloghi diventa vaga. Se un prodotto ha varianti reali con prezzi diversi, una singola offerta con un solo prezzo rappresenta male la pagina. Esprimete l'intervallo con AggregateOffer (lowPrice, highPrice, priceCurrency) oppure elencate le varianti come offerte separate con i propri SKU. Prendere il prezzo di una variante e presentarlo come prezzo del prodotto è l'inizio dei reclami «sul sito c'era 19 EUR».

Una disponibilità onesta

La disponibilità è il campo che più probabilmente è sbagliato, perché è quello che cambia. Due abitudini lo mantengono utile:

• Rispecchiare lo stato reale del magazzino, incluso «ordinabile ma non disponibile» se è ciò che intendete — schema.org ha valori per ordine arretrato e preordine, e usarli è meglio di un InStock generico che diventa un'e-mail di annullamento.
• Non metterlo in cache fino a farlo scadere. Se la pagina è servita da una cache lunga mentre il magazzino si muove, un agente ottiene una risposta sicura che era vera un'ora prima. È il campo per cui vale la pena ragionare sulla durata della cache.

Oltre la pagina prodotto

Il markup di prodotto vi porta nelle risposte sui prodotti. Altri due tipi decidono se entrate nelle domande che precedono e seguono l'acquisto:

• Organization, sulla home — chi siete, il logo, la URL e link sameAs ai luoghi in cui esistete anche. È ciò che permette a un modello di ricondurre il vostro negozio alle altre vostre presenze invece di trattarle come entità sconosciute separate.
• FAQPage, sulle pagine che rispondono davvero a domande — spedizioni, resi, taglie, compatibilità. Un assistente che risponde a «spedite in Austria?» preferisce una risposta strutturata a un paragrafo da interpretare.

Entrambi costano poco, ed entrambi riguardano l'essere risolvibili più che semplicemente presenti. Un agente che non riesce a capire se due menzioni del vostro marchio sono la stessa azienda resterà cauto.

Regole che mantengono affidabile il markup

Dati strutturati in contrasto con la pagina sono peggio di nessun dato — i motori di ricerca li trattano come spam e i modelli imparano a diffidare della fonte.

• Marcate solo ciò che è visibile. Un prezzo nel JSON-LD che non compare da nessuna parte sulla pagina è una violazione, non una scorciatoia.
• Un prodotto per pagina prodotto. Marcare un'intera collezione come un solo prodotto confonde tutto a valle.
• Nessuna recensione inventata. Un AggregateRating con numeri non giustificabili è il modo più rapido di perdere del tutto il markup — e quello che fa scattare un'azione manuale.
• Tenetelo nell'HTML. Un JSON-LD iniettato dopo il caricamento da un tag manager è esattamente tanto invisibile quanto il resto del vostro rendering lato client.

Controllare tutto il catalogo, non una pagina

Una buona pagina prodotto dimostra che il tema ne è capace. Non dimostra che il catalogo sia coerente — e l'incoerenza è normale: prodotti importati in momenti diversi, varianti aggiunte dopo, immagini mancanti nella coda lunga.

I controlli da eseguire su un campione anziché su una singola pagina:

• Ogni prodotto campionato rende titolo e JSON-LD nell'HTML grezzo?
• Ogni offerta porta un prezzo e una valuta?
• La disponibilità è presente e specifica?
• Le immagini esistono e hanno un testo alternativo? Un alt mancante è insieme una lacuna di accessibilità e una descrizione perduta.
• Tipo e categoria del prodotto sono impostati, così che un agente possa collocarlo in una tassonomia?

Sichta esegue questi controlli in modo deterministico su un campione del vostro catalogo dal vivo e segnala ogni prodotto che non passa: più utile di un punteggio unico. Il punto non è il numero — è l'elenco dei prodotti da correggere.

In breve

Scaricate la vostra pagina prodotto con curl prima di credere a qualsiasi cosa sull'idoneità agli agenti. Assicuratevi che nome, prezzo con valuta e disponibilità specifica siano in JSON-LD reso lato server, esprimete le varianti come intervallo o come offerte separate invece di scegliendone una, aggiungete identificativi per essere associabili nei confronti e collocate il markup Organization e FAQPage dove serve. Non marcate mai ciò che non è sulla pagina, e controllate un campione del catalogo invece del vostro prodotto migliore.