Dati strutturati per ricette: guida allo schema Recipe

Lo schema Recipe è il tipo di dato strutturato che permette a Google di mostrare una ricetta come rich result: la card con foto, tempo di preparazione, valutazione e calorie che compare nei risultati di ricerca, in Google Immagini e in Discover. Per un blog di cucina è probabilmente il markup con il rapporto più alto tra sforzo di implementazione e visibilità ottenuta, perché intercetta un intento di ricerca preciso, «voglio cucinare questo piatto», in cui l'utente decide quale risultato aprire guardando prima l'immagine e i tempi, non il titolo.

Questa guida non ripete cos'è lo schema markup in generale: si concentra sulle proprietà specifiche del tipo Recipe, quali sono obbligatorie, come si formattano tempi e valori nutrizionali, come si struttura un video o un elenco di passaggi, e su un problema che la documentazione lascia spesso in secondo piano: un markup sintatticamente valido non garantisce che il rich result compaia. Vedremo perché succede e come si valida un markup Recipe in modo specifico, non generico.

Cosa rende il markup Recipe diverso da uno schema generico

Il tipo Recipe di schema.org è, dal punto di vista della sintassi, un oggetto JSON-LD come qualsiasi altro. Quello che cambia è che Google applica alle ricette un secondo livello di controllo, documentato separatamente dalle regole generali di schema.org: le linee guida specifiche per i risultati arricchiti delle ricette. Un markup può essere valido secondo lo standard schema.org e restare comunque inammissibile per il rich result: a Google non basta che i dati esistano, devono corrispondere a proprietà precise, in un formato preciso, e descrivere il contenuto realmente visibile nella pagina.

Il markup va inserito una sola volta per pagina, e la pagina dovrebbe presentare una sola ricetta per essere pienamente ammissibile al rich result.

• JSON-LD è il formato che Google raccomanda esplicitamente per le ricette, più semplice da mantenere nel tempo rispetto a Microdata o RDFa
• I dati dichiarati nello schema devono corrispondere al contenuto realmente visibile all'utente sulla pagina, non solo al codice

Le due proprietà davvero obbligatorie

Per essere anche solo candidato al rich result, Google richiede due proprietà: name, il titolo della ricetta, e image, almeno un'immagine. Senza queste due, il markup non genera alcun errore di sintassi ma semplicemente non viene considerato per l'arricchimento: la pagina resta indicizzata normalmente, senza card. È l'errore più comune nei blog che copiano un template di plugin senza controllare cosa il plugin ha effettivamente compilato: il campo name eredita a volte il titolo dell'articolo invece del nome del piatto, e image punta a un placeholder generico invece della foto della ricetta.

• name: deve corrispondere al nome del piatto, non al titolo SEO dell'articolo se sono formulati diversamente
• image: accetta una URL singola, un array di URL o un oggetto ImageObject; i requisiti tecnici sono trattati più avanti

Le proprietà fortemente raccomandate

Oltre al minimo obbligatorio, Google elenca proprietà che non bloccano il rich result se assenti ma che ne determinano la ricchezza visiva. recipeYield indica il numero di porzioni; recipeCategory il tipo di piatto (primo, dolce, antipasto); recipeCuisine la cucina di riferimento; keywords è un elenco libero utile alla categorizzazione interna di Google, distinto dalle keyword SEO della pagina. author identifica chi ha creato la ricetta, datePublished la data di pubblicazione.

Due proprietà meritano un discorso separato perché, sebbene lo standard schema.org le indichi come opzionali, nella pratica sono quasi indispensabili: recipeIngredient, l'elenco degli ingredienti, e recipeInstructions, i passaggi. Una pagina con name e image corretti ma senza ingredienti o istruzioni può comunque ottenere il rich result di base, ma perde l'ammissibilità a funzionalità aggiuntive come la lettura vocale della ricetta tramite assistenti Google.

• recipeYield: numero o breve descrizione, ad esempio "4" oppure "4 porzioni"
• recipeCategory e recipeCuisine: stringhe libere, non da un elenco fisso di valori ammessi
• recipeIngredient: un elemento per ingrediente, non un unico blocco di testo con tutti gli ingredienti insieme
• recipeInstructions: preferibile come elenco strutturato, trattato nella sezione dedicata ai passaggi

Le immagini: i requisiti tecnici che Google controlla davvero

La proprietà image è obbligatoria, ma essere presente non basta per la resa visiva migliore. Google richiede che l'immagine sia raggiungibile dal crawler, non bloccata da robots.txt né protetta da autenticazione, in un formato comune (JPEG, PNG, WebP), con una risoluzione minima di 696 pixel di larghezza per la card standard e almeno 1200 pixel per i formati con presentazione più grande. Raccomanda inoltre di fornire la stessa immagine in almeno uno di tre rapporti di aspetto, 16:9, 4:3 e 1:1, come oggetti ImageObject distinti, non come varianti nascoste in un carosello che il markup non descrive.

• Larghezza minima 696px, consigliata 1200px o più per la resa nei formati grandi
• Rapporti di aspetto accettati: 16:9, 4:3, 1:1; fornirne più di uno aumenta la probabilità di comparire in più superfici (ricerca classica, Google Immagini, Discover)
• L'URL dell'immagine deve essere accessibile pubblicamente, non dietro un CDN che richiede autenticazione o una protezione hotlink che blocca Googlebot
• Evitare watermark grandi o testo sovrapposto: peggiorano la resa nella card senza aggiungere valore all'utente

Tempi di preparazione e cottura: il formato ISO 8601 che spezza tutto se sbagliato

prepTime, cookTime e totalTime non accettano testo libero come "30 minuti": vanno espressi in formato di durata ISO 8601, dove PT è il prefisso, H indica le ore e M i minuti. Trenta minuti si scrive PT30M, un'ora e un quarto PT1H15M, due ore PT2H. È l'errore più frequente in chi compila questi campi a mano invece di lasciarli a un plugin: scrivere "30M" senza il prefisso PT, o "PT30" senza l'unità, produce un valore che i validatori segnalano come non conforme e che Google ignora silenziosamente: il rich result può comunque comparire, semplicemente senza mostrare il tempo.

totalTime, quando presente, dovrebbe essere coerente con la somma di prepTime e cookTime: non è un controllo che invalida il markup, ma una ricetta con 10 minuti di preparazione, 5 di cottura e 90 di tempo totale genera una card poco credibile, anche se tecnicamente valida. recipeYield, già citato, resta comunque una proprietà separata e non va confusa con una misura di tempo.

• PT30M significa 30 minuti; PT1H significa 1 ora; PT1H30M significa 1 ora e 30 minuti
• Il prefisso PT è obbligatorio anche quando c'è solo un valore in minuti
• Un formato errato non invalida l'intero markup: la singola proprietà viene semplicemente ignorata

Valori nutrizionali: come si dichiarano, non quanto valgono

La proprietà nutrition usa il tipo NutritionInformation, con sottoproprietà come calories, fatContent, carbohydrateContent, proteinContent e sodiumContent. Ognuna si dichiara come testo con l'unità inclusa: calories, ad esempio, è un numero seguito dalla parola "calories". Questi valori vanno riferiti a una singola porzione, coerente con recipeYield: dichiarare le calorie dell'intera preparazione mentre recipeYield indica quattro porzioni produce un numero fuorviante se mostrato come se fosse a porzione.

Non esiste un obbligo di includere nutrition: è raccomandata, non richiesta. Vale la pena includerla quando i valori derivano da un calcolo reale, un plugin che li calcola dagli ingredienti o una fonte verificata, perché un valore inventato è esattamente il tipo di discrepanza tra markup e contenuto che le linee guida sui dati strutturati considerano un problema di qualità.

• calories: numero seguito dall'unità testuale, riferito alla singola porzione
• fatContent, carbohydrateContent, proteinContent, sodiumContent: stesso principio, grammi o milligrammi per porzione
• Nessun obbligo di completezza: si può dichiarare solo calories senza le altre sottoproprietà

Video e passaggi: HowToStep e VideoObject

recipeInstructions accetta tre forme: un unico blocco di testo, un array di stringhe con un passaggio per elemento, o, nella forma più strutturata, un array di oggetti HowToStep. Ogni HowToStep ha una proprietà text con la descrizione del passaggio, e opzionalmente name (titolo breve), image (una foto di quel passaggio specifico) e url (un ancoraggio alla sezione della pagina che lo mostra). Questa struttura è quella che permette a Google, e agli assistenti vocali, di leggere o mostrare i passaggi uno alla volta invece di trattarli come un unico paragrafo indistinto.

La proprietà video, quando presente, usa il tipo VideoObject e richiede name, thumbnailUrl e uploadDate come minimo, con description e duration (in ISO 8601) raccomandate. Serve contentUrl, l'URL diretto del file, oppure embedUrl, l'URL di un player incorporabile: senza almeno uno dei due il video non è verificabile. Un dettaglio trascurato: il video può abilitare i key moments, i timestamp cliccabili verso un passaggio specifico, ma solo se marcati nel markup, non solo perché il video esiste sulla pagina.

• HowToStep: text obbligatorio all'interno dell'oggetto, image e url opzionali ma utili per ricette fotografiche passo-passo
• VideoObject: name, thumbnailUrl, uploadDate come base; contentUrl o embedUrl per rendere il video verificabile
• duration del video in formato ISO 8601, esattamente come prepTime e cookTime

Perché il rich result non compare anche con un markup valido

Un markup che passa ogni controllo sintattico e include tutte le proprietà raccomandate può comunque non produrre alcun rich result visibile, e le ragioni sono quasi sempre estranee alla sintassi. La prima è algoritmica: Google tratta i rich result come un'opzione discrezionale, mai garantita, indipendentemente da quanto sia completo il markup, ed è scritto esplicitamente nella documentazione ufficiale. La seconda, più seria, riguarda la corrispondenza tra markup e contenuto reale: se il codice dichiara recipeIngredient e recipeInstructions ma quel testo non è effettivamente leggibile sulla pagina, perché nascosto o relativo a una ricetta diversa da quella mostrata, Google lo classifica come dato strutturato ingannevole, con conseguenze che vanno dall'esclusione dal rich result fino a un'azione manuale sull'intero sito.

Ci sono poi cause meno drammatiche ma più frequenti. Il ritardo di indicizzazione: Google può impiegare da giorni a settimane prima di rivalutare una pagina dopo una correzione, ed è normale non vedere effetti immediati. La sovrapposizione con ricette quasi identiche pubblicate altrove: quando molti siti ripubblicano la stessa ricetta, Google mostra il rich result solo per una selezione di fonti, e non è garantito che la pagina in questione venga scelta anche con un markup impeccabile. Infine, segnali di qualità che non riguardano il markup in sé: un sito con contenuto duplicato o esperienza utente scadente può vedere i propri rich result soppressi anche quando i dati strutturati della singola pagina sono corretti.

• I rich result sono sempre discrezionali: nessuna proprietà, per quanto completa, li garantisce
• Discrepanza tra markup e contenuto visibile: causa più seria, può portare a un'azione manuale sull'intero sito
• Ritardo di indicizzazione dopo una correzione: da giorni a settimane
• Contenuto duplicato o quasi identico ad altre fonti: riduce la probabilità di selezione anche a parità di markup
• Segnali di qualità complessivi del sito, non specifici della singola pagina

Come validare un markup Recipe, non solo la sintassi JSON-LD

Validare la sintassi di un JSON-LD dice solo che il codice è leggibile, non che è ammissibile per il rich result di una ricetta: sono due controlli diversi, e confonderli è la ragione per cui molti blog di cucina pensano di avere un markup a posto quando manca solo dell'ammissibilità specifica. Lo strumento corretto è il Rich Results Test di Google: incollando l'URL della pagina, il test distingue tra errori, che bloccano l'ammissibilità, e avvisi, proprietà raccomandate assenti che non bloccano ma riducono la resa, per il tipo Recipe in particolare.

Per un monitoraggio che vada oltre la singola pagina, il report Miglioramenti di Search Console dedicato alle ricette mostra l'andamento nel tempo degli elementi validi rispetto a quelli con errori o avvisi su tutto il sito, ed è il posto giusto per accorgersi che una modifica al template ha rotto il markup su centinaia di pagine insieme, cosa che testare una singola URL non farebbe emergere. Dopo una correzione su scala, ha senso richiedere una nuova scansione tramite l'ispezione URL per accelerare la rivalutazione, ma, come visto sopra, anche un markup corretto al 100% non garantisce che il rich result compaia subito, o compaia affatto.

• Rich Results Test: controllo specifico per l'ammissibilità al rich result Recipe, distingue errori bloccanti da avvisi non bloccanti
• Search Console, Miglioramenti, Ricette: monitoraggio nel tempo, utile per errori diffusi su template condivisi
• Richiesta di indicizzazione dopo una correzione: accelera la rivalutazione, non la garantisce