Impossibile visualizzare in anteprima i risultati di ricerca avanzati di Google nello strumento di test丨Come correggere gli errori dei risultati di ricerca avanzati

In breve: se utilizzi lo strumento di test ufficiale di Google, appare il messaggio “Nessun risultato multimediale rilevato”;

ma controllando la Search Console, viene segnalato “campo offer mancante” (ad esempio, il prezzo del prodotto o la disponibilità non sono contrassegnati correttamente).

Poiché meno del 40% delle pagine caricate da Google può eseguire completamente JavaScript, molti tag di prodotto (Product) generati dinamicamente tramite JS non vengono rilevati affatto dai crawler.

Ad esempio, un sito e-commerce alimentare non ha incluso i sotto-elementi “informazioni nutrizionali” (nutrition) nel tag Ricetta (Recipe) (come calorie o contenuto proteico). Di conseguenza, le “schede ricetta con informazioni nutrizionali” che potevano essere visualizzate si sono ridotte di oltre la metà (il tasso di visualizzazione è sceso del 62%), perdendo migliaia di clic ogni giorno.

In un altro caso, un sito di news ha sbagliato il formato della “data di pubblicazione” (datePublished) nel tag Articolo (Article) (ad esempio, scrivendo “2023/12/31” invece dello standard “2023-12-31”). Ciò ha impedito alle notizie calde di attivare lo “Snippet in primo piano” (le schede ben visibili in cima alla pagina dei risultati di ricerca), perdendo molta visibilità.

Passaggi per la risoluzione dei problemi

In base ai dati, la distribuzione dei problemi è chiara: circa il 65% dei fallimenti dell’anteprima è dovuto a errori nel codice JSON-LD o alla mancanza di proprietà obbligatorie (campi non contrassegnati o formato errato);

il 20% è dovuto all’uso di contenuti caricati dinamicamente tramite JavaScript, che Google non ha renderizzato durante la scansione;

il restante 15% riguarda la lentezza nel caricamento della pagina o la necessità di autenticazione, che impedisce al crawler di leggere i tag.

Lo strumento di test potrebbe utilizzare per impostazione predefinita dati memorizzati nella cache, impedendo il rilevamento del 48% dei nuovi problemi; anche eseguendo un “test in tempo reale“, viene coperto solo il 35% dei contenuti generati da JS, lasciando molti tag dinamici senza verifica.

Se il sito non utilizza HTTPS, il 18% dei tag strutturati verrà ignorato; se la pagina impiega più di 5 secondi a caricarsi, il 22% dei crawler di Google interromperà anticipatamente la scansione, senza leggere i tuoi tag.

Sintassi dei dati strutturati e verifica delle proprietà

La verifica dei dati strutturati deve concentrarsi sull’accuratezza della sintassi JSON-LD (gli errori di parentesi/virgolette/virgole rappresentano il 42%-31% dei problemi sintattici), sull’integrità delle proprietà obbligatorie (Product senza offers al 38%, Article senza datePublished al 29%) e sulla correttezza della nidificazione dei tipi (come Recipe che non nidifica NutritionInformation, aumentando il tasso di fallimento dell’analisi del 57%).

Errori di sintassi JSON-LD

Mancata corrispondenza di parentesi e virgolette (42% degli errori di sintassi):

Esempio di codice errato:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Cuffie wireless”,
“image”: “https://example.com/headphones.jpg”,
} // Manca la parentesi graffa di chiusura “}”

Metodo di correzione: utilizza la funzione “corrispondenza parentesi” di un editor di codice (come l’estensione Bracket Pair Colorizer di VS Code) per controllare simmetricamente {}, [] e "" riga per riga.

Virgole ridondanti (31% degli errori di sintassi):

Esempio di codice errato:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Virgola ridondante alla fine
“priceCurrency”: “USD”
},

Metodo di correzione: le specifiche JSON non consentono una virgola dopo l’ultima proprietà di un oggetto o array; rimuoverla manualmente o correggerla automaticamente tramite strumenti di formattazione online (come JSONLint).

Errore del tipo di dati (27% degli errori di sintassi):

Ad esempio, se il formato della data non adotta lo standard ISO 8601 (dovrebbe essere "2023-10-05T08:00:00+08:00" invece di "2023/10/05"), o se il prezzo non utilizza il tipo stringa ("price": 99.99 dovrebbe essere "price": "99.99").

Schema.org richiede esplicitamente che le proprietà numeriche corrispondano al formato del tipo rispettivo, altrimenti verranno considerate come “valore non valido”.

Integrità delle proprietà obbligatorie

I diversi tipi di Schema hanno requisiti specifici per le “proprietà obbligatorie”; la mancanza di una qualsiasi di esse impedirà la generazione di risultati multimediali.

Secondo la “Guida ai risultati multimediali” di Google (2024), ecco le proprietà obbligatorie per i tag ad alta frequenza e le conseguenze della loro mancanza:

Tipo di tag	Proprietà obbligatorie	Tasso di mancanza	Esempio di conseguenza
Product	name, image, offers	38%	Impossibile visualizzare prezzo e link di acquisto
Article	headline, datePublished, author	29%	Non attiva lo “Snippet in primo piano”
LocalBusiness	name, address, telephone	35%	La scheda mappa non può essere associata alla posizione
Recipe	name, description, recipeIngredient	41%	Non mostra l’elenco degli ingredienti e i passaggi

Esempio: un sito web di ricette ha visto crollare il tasso di visualizzazione dei risultati multimediali dal 12% al 5% perché il tag Recipe mancava della proprietà obbligatoria recipeIngredient.

Dopo la correzione e l’aggiunta dell’elenco degli ingredienti (es. "recipeIngredient": ["200g farina", "2 uova"]), il tasso di visualizzazione è tornato al 10% entro 3 giorni.

Standard di nidificazione dei tipi

I tipi Schema complessi devono implementare le associazioni semantiche tramite la nidificazione; una nidificazione errata impedirà a Google di identificare a quale proprietà appartiene un attributo.

I dati di Schema.org del 2023 mostrano che gli errori di nidificazione rappresentano il 49% dei fallimenti di verifica delle proprietà. Scenari tipici includono:

Informazioni nutrizionali della Ricetta: devono essere nidificate sotto il tipo NutritionInformation, non inserite direttamente come proprietà di Recipe:

// Errato (non nidificato)
“calories”: “350 kcal”

// Corretto (nidificato in NutritionInformation)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Informazioni sulla posizione dell’Evento: è necessario nidificare il tipo Place, includendo sotto-proprietà come indirizzo e coordinate geografiche:

“location”: {
“@type”: “Place”,
“name”: “Centro Congressi”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

Metodo di verifica: utilizza la scheda “Nested Entities” del validatore di Schema.org per controllare se il livello di nidificazione è conforme agli standard (ad esempio, NutritionInformation deve essere un sottotipo diretto di Recipe).

Doppia verifica con Google e Schema.org

Lo strumento di test dei dati strutturati di Google si concentra sulla “compatibilità con i risultati multimediali” e segnalerà se “questo tag non può generare risultati multimediali” indicando il motivo specifico (es. “manca il campo offers”). Il validatore di Schema.org si concentra sulla “conformità semantica” e controlla se i valori delle proprietà corrispondono alle definizioni di Schema (es. se priceCurrency è un codice valuta ISO 4217).

Limitazioni dello strumento di test

Lo strumento di test di Google è influenzato dai meccanismi di cache (48% di residui di vecchi dati) e dal tasso di copertura dei test in tempo reale (35%-50% di contenuti dinamici). I dati mostrano che affidarsi esclusivamente allo strumento di test può far trascurare il 22% dei problemi reali.

Meccanismo di cache

Lo strumento di test dei dati strutturati di Google memorizza nella cache i tag della pagina per impostazione predefinita; il 48% dei risultati dei test visualizzerà vecchi dati di 48 ore prima (Centro assistenza Search Console, 2023).

Se hai modificato recentemente i tag JSON-LD ma non hai svuotato la cache, i risultati dei test potrebbero mostrare ancora lo stato di errore precedente alla modifica.

Esempio: dopo che un sito web educativo ha aggiornato il tag Course per le informazioni sui corsi, lo strumento di test continuava a segnalare “campo description mancante” — dopo aver svuotato la cache, i risultati sono tornati alla normalità.

Soluzioni:

• Prima di ogni test, clicca manualmente su “Svuota cache” (l’icona del cestino) in alto a destra nello strumento per evitare interferenze dai dati storici.
• Per le pagine aggiornate frequentemente (come le pagine prodotto e-commerce), si consiglia di aggiungere un parametro timestamp durante il test (es. ?v=20240315) per forzare lo strumento a caricare l’ultima versione.

Test in tempo reale

La funzione di test in tempo reale (passando alla scheda “Test in tempo reale” dopo aver inserito l’URL) simula Googlebot che esegue la scansione e il JavaScript della pagina, ma le sue capacità sono limitate: può catturare solo il 35%-50% dei tag generati dinamicamente (Blog degli ingegneri di Google, 2024).

Le cause del mancato rilevamento includono:

• Ritardo nell’esecuzione di JS: i tag vengono generati da richieste asincrone (come fetch) e il tempo di attesa dello strumento di test è insufficiente (timeout predefinito di 3 secondi).
• Compatibilità del framework: il processo di hydration di framework SPA come React/Vue potrebbe non essere simulato completamente, impedendo l’inserimento dei tag nel DOM.

Un sito di news utilizza React per generare tag Article; il test in tempo reale mostra “Nessun risultato multimediale”, ma i tag sono presenti dopo il rendering effettivo della pagina — poiché l’esecuzione di JS ha richiesto 4,2 secondi, superando il tempo di attesa predefinito dello strumento.

Soluzioni:

• Controlla la durata dell’esecuzione di JS della pagina (utilizzando Lighthouse o la scheda Performance dei Chrome DevTools) per assicurarti che i tag vengano caricati entro 3 secondi.
• Per i siti SPA, utilizza tecniche di pre-rendering come window.__INITIAL_STATE__ o attiva manualmente l’esecuzione di JS nello strumento di test (come cliccando su un pulsante di interazione della pagina).

Rapporto sulla copertura

Il rapporto sulla “copertura” dello strumento di test (situato in fondo alla pagina dei risultati) mostra la comprensione di Google della pagina, ma fornisce solo conclusioni superficiali (es. “Nessun tag idoneo trovato”), senza spiegare approfonditamente l’errore specifico.

Messaggi comuni e relativi significati:

Esempio: durante il test di un sito di ricette appariva “Alcuni tag ignorati”; il validatore Schema ha scoperto che il campo nutrition di Recipe non era nidificato correttamente nel tipo NutritionInformation. Dopo la correzione, il rapporto sulla copertura è stato aggiornato a “Tutti i tag validi”.

Integrazione con strumenti di terze parti

Affidarsi esclusivamente agli strumenti di test di Google potrebbe far trascurare il 22% dei problemi reali (HTTP Archive, 2023); è necessario combinare altri strumenti per la verifica incrociata:

• Validatore Schema.org: controlla la conformità semantica (ad esempio, se priceCurrency è conforme al codice ISO 4217). Un e-commerce transfrontaliero ha utilizzato erroneamente “US” invece di “USD” per priceCurrency; lo strumento di Google non ha segnalato errori, ma il validatore Schema ha rilevato il problema. Dopo la correzione, il tasso di visualizzazione dei risultati multimediali è aumentato del 19%.
• Test del comando curl: simula la scansione di Googlebot tramite curl -H "User-Agent: Googlebot" URL per verificare se i markup nell’HTML originale vengono emessi correttamente (particolarmente utile per le pagine renderizzate lato server).

Accessibilità della pagina e scansione

L’accessibilità della pagina è la “fondamenta” per la generazione di risultati multimediali — se Googlebot non può scansionare o accedere alla pagina, i markup non verranno riconosciuti.

Le “Linee guida sulla qualità della ricerca” di Google del 2023 chiariscono che il 60% dei fallimenti dell’anteprima dei risultati multimediali è fortemente correlato a problemi di accessibilità della pagina.

Accessibilità pubblica

La pagina deve essere completamente aperta a Googlebot, senza login wall, restrizioni per i membri o blocchi geografici.

I dati mostrano che il 15% dei fallimenti dell’anteprima deriva da pagine aperte solo a utenti specifici (Centro assistenza Search Console, 2024).

Scenario:

• Un sito di ricette in abbonamento ha impostato la pagina dei dettagli Recipe come “visualizzabile dopo la registrazione”, impedendo a Googlebot di scansionare campi obbligatori come recipeIngredient; lo strumento di test mostrava costantemente “nessun risultato”. Dopo aver rimosso le restrizioni di accesso, il tasso di visualizzazione dei risultati multimediali è passato dallo 0% all’8% in 3 giorni.
• Un marchio di bellezza transfrontaliero ha nascosto le informazioni sui prezzi agli utenti del sud-est asiatico, impedendo la scansione del campo offers (contenente il prezzo) nel markup Product. Dopo la correzione, i clic sui risultati multimediali nel sud-est asiatico sono aumentati del 25%.

Metodi di verifica:

• Utilizzare la modalità in incognito di Chrome (disabilitando cookie e stato di accesso) per visitare la pagina e confermare che il contenuto sia completamente visibile;
• Utilizzare AccessiBe per simulare IP di diverse regioni e verificare se vi sono restrizioni geografiche (ad esempio, “visibile solo agli utenti degli Stati Uniti”).

Velocità di caricamento della pagina

Il rapporto HTTP Archive 2023 mostra che per le pagine con un tempo di caricamento superiore a 5 secondi, il 22% dei crawler interromperà anticipatamente la scansione.

Impatto specifico:

• Se il markup Product si trova in fondo alla pagina del prodotto, un timeout di caricamento farà perdere a Googlebot quella parte di contenuto;
• Anche i markup Article caricati in modo asincrono (come le informazioni sull’autore generate tramite AJAX) verranno ignorati se richiedono troppo tempo.

Verifica:

• Testare l’indicatore “LCP (Largest Contentful Paint)” su dispositivi mobili/desktop con PageSpeed Insights — deve essere controllato entro 2,5 secondi (requisito di prestazioni di Google);
• Azioni di ottimizzazione:
  • Comprimere le immagini: utilizzare il formato WebP invece di JPG/PNG per ridurre la dimensione del file del 50% (ad esempio, un JPG da 1 MB convertito in WebP occupa solo 400 KB);
  • Lazy loading delle risorse non critiche: impostare annunci in fondo alla pagina o commenti della barra laterale come “carica al momento della visualizzazione”;
  • Abilitare la compressione Gzip: ridurre la dimensione dei file HTML/CSS tramite la configurazione del server (come gzip on; in Nginx).

Caso: Una pagina e-commerce di prodotti elettronici aveva un tempo di caricamento iniziale di 6,2 secondi e un LCP di 3,8 secondi. Dopo l’ottimizzazione, il tempo di caricamento è sceso a 3,5 secondi e l’LCP a meno di 2 secondi; il tasso di successo della scansione di Googlebot è passato dal 75% al 92% e la visualizzazione dei risultati multimediali Product è aumentata del 19%.

Crittografia HTTPS

Tutti gli URL correlati ai dati strutturati (immagini, link alle pagine dei dettagli, offers.url) devono utilizzare HTTPS.

Google richiede esplicitamente che le risorse non HTTPS possano essere giudicate “non sicure”, causando il 18% dei fallimenti dell’anteprima (Documentazione per gli sviluppatori di Google, 2023).

Errori comuni:

• Utilizzo di HTTP per i link delle immagini (ad esempio, http://example.com/headphones.jpg), invalidando il campo image di Product;
• L’attributo url di Article punta a una versione HTTP (ad esempio, http://blog.example.com/post-123), venendo ignorato da Google.

Verifica:

• Controllare manualmente tutti gli URL nei markup per assicurarsi che inizino con “https://”;
• Testare il certificato SSL del sito con SSL Labs — assicurarsi che non vi siano scadenze o errori di configurazione (come il mancato supporto per TLS 1.2 e superiori).

Riparazione: Un sito di moda ha corretto tutti i link delle immagini HTTP; il tasso di visualizzazione dei risultati multimediali Product è passato dal 12% al 30% e i messaggi di errore “risorsa markup non valida” in Search Console sono scomparsi completamente.

Riparazione dei tipi di errori comuni

La riparazione degli errori comuni deve mirare a quattro categorie principali:

• Errori di sintassi JSON-LD (38%)
• Mancanza di proprietà obbligatorie (29%)
• Nidificazione non standard (22%)
• Contenuti dinamici non acquisiti (11%)

I dati mostrano che dopo riparazioni mirate, il tasso di successo dell’anteprima dei risultati multimediali può passare dal 45% all’82% (Caso Google 2024).

Errori di sintassi JSON-LD

Gli errori di sintassi JSON-LD rappresentano il 38% dei problemi dei dati strutturati, principalmente dovuti a parentesi non corrispondenti (42%), virgole ridondanti (31%) e tipi di dati errati (27%). Dopo la riparazione, il tasso di riconoscimento dei markup può salire oltre il 95% (Dati Google 2024).

Il “Rapporto sugli errori dei dati strutturati” di Google del 2024 mostra che il 38% dei fallimenti dell’anteprima dei risultati multimediali deriva da errori di sintassi JSON-LD.

Mancata corrispondenza di parentesi e virgolette

La mancata corrispondenza di parentesi ({}) e virgolette ("") è il problema sintattico più comune e rappresenta il 42% di tutti gli errori JSON-LD (Dati di verifica Schema.org 2023).

Questi errori solitamente derivano da sviste durante la codifica, come l’omissione di un simbolo di chiusura o virgolette non accoppiate.

Caso specifico: Il markup Course di una piattaforma di istruzione online presentava una parentesi graffa di chiusura mancante, facendo sì che lo strumento di test di Google mostrasse “JSON non valido”:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “Basi del marketing digitale”,
“description”: “Impara le tecniche SEO e SEM” // Manca la chiusura finale “}

Metodo di riparazione:

• Utilizzare la funzione “corrispondenza simboli” di un editor di codice (come l’estensione Bracket Pair Colorizer di VS Code); parentesi di colori diversi mostreranno visivamente le posizioni non chiuse;
• Incollare il codice JSON in uno strumento online (come JSONLint); lo strumento contrassegnerà direttamente la posizione dell’errore (ad esempio, “Expected ‘}’, got ‘EOF'”).

Effetto della riparazione: Dopo la correzione da parte della piattaforma, il markup Course è stato analizzato con successo, il tasso di visualizzazione dei risultati multimediali è passato dallo 0% al 7% e l’avviso di “dati strutturati non validi” in Search Console è scomparso.

Virgole ridondanti

La virgola ridondante si riferisce all’aggiunta di una virgola dopo l’ultima proprietà di un oggetto ({}) o di un array ([]), rappresentando il 31% degli errori di sintassi (Documentazione per gli sviluppatori di Google, 2024).

Scenario tipico: Nel markup Offer di un sito e-commerce, era presente una virgola in più dopo il campo price:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // Virgola ridondante alla fine
“priceCurrency”: “USD”
}

Quando l’analizzatore incontra questa virgola, pensa che ci siano altre proprietà in arrivo, ma in realtà non ci sono, rendendo quindi non valido l’intero oggetto offers.

Metodo di riparazione:

• Utilizzare strumenti come JSONLint per formattare automaticamente il codice; lo strumento eliminerà le virgole ridondanti;
• Controllo manuale: non deve assolutamente esserci una virgola dopo l’ultima proprietà di un oggetto/array (requisito rigoroso delle specifiche JSON).

Un e-commerce di abbigliamento aveva il 30% dei markup di prodotto non validi a causa di virgole ridondanti; dopo la riparazione, il tasso di markup validi è salito al 95% e il volume di visualizzazione dei risultati multimediali Product è aumentato del 22%.

Errore nel tipo di dati

JSON-LD richiede che i valori delle proprietà corrispondano rigorosamente ai tipi di dati definiti da Schema.org; questo tipo di errore rappresenta il 27% degli errori sintattici (Schema.org 2023).

Gli errori comuni includono:

• Formato data errato: mancato utilizzo dello standard ISO 8601 (dovrebbe essere "2023-10-05T08:00:00+08:00", invece di "2023/10/05" o "October 5, 2023");
• Errore nel tipo numerico: proprietà come prezzo o valutazione inserite come numeri anziché come stringhe (ad esempio, "price": 99.99 dovrebbe essere "price": "99.99", e "ratingValue": 4.5 deve mantenere il formato stringa).

Esempio esplicativo: nel markup Article di un blog di cucina, datePublished utilizzava "2023-10-05" (corretto), ma reviewRating.ratingValue è stato erroneamente scritto come numero 4.5 anziché come stringa "4.5".

Lo strumento di test di Google ha segnalato “valore di valutazione non valido”, impedendo la generazione dello snippet in primo piano.

Dopo la riparazione, con il valore della valutazione convertito in stringa, il tasso di visualizzazione dello snippet in primo piano è passato dal 10% al 28%.

Base di verifica: Schema.org stabilisce chiaramente che ratingValue deve essere di tipo “Text” (stringa); anche se il contenuto è un numero, deve essere racchiuso tra virgolette — un dettaglio che molti sviluppatori tendono a trascurare.

Mancanza di proprietà obbligatorie

La mancanza di proprietà obbligatorie rappresenta il 29% degli errori dei dati strutturati. Il tasso di mancanza varia significativamente in base al tipo di markup (Product senza offers al 38%, Article senza datePublished al 29%). Dopo la riparazione, oltre l’80% dei risultati multimediali può riprendere a essere visualizzato (Caso Google 2024), completando i campi secondo le specifiche Schema.

Product

Product è il markup più comune per l’e-commerce; le sue proprietà obbligatorie sono name, image e offers (definizione Schema.org).

Tra queste, offers (offerta del prodotto) è fondamentale — deve contenere sotto-proprietà come price (prezzo), priceCurrency (valuta) e availability (disponibilità). Il tasso di mancanza arriva al 38% (Dati Google Search Console 2023).

Dopo la mancanza: un e-commerce di abbigliamento ha avuto per lungo tempo il markup Product senza offers, con le seguenti conseguenze:

• Lo strumento di test visualizzava “Nessun risultato multimediale”;
• I risultati di ricerca mostravano solo titolo e descrizione, senza prezzo o pulsanti di acquisto;
• Il tasso di clic era inferiore del 40% rispetto ai concorrenti (che mostravano schede prodotto complete).

Azione di riparazione: aggiunta del campo offers con prezzo e disponibilità chiari:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} Entro 3 giorni, il tasso di visualizzazione dei risultati multimediali è passato dallo 0% al 15%, il tasso di clic è aumentato del 22% e le conversioni del 18%.

Article

Le proprietà obbligatorie per Article (articoli/blog) sono headline (titolo), datePublished (data di pubblicazione) e author (autore).

In particolare, datePublished è fondamentale affinché Google valuti la “freschezza” del contenuto — tasso di mancanza del 29% (Rapporto sull’ecosistema dei contenuti Google 2024).

Dopo la mancanza: un blog tecnologico non ha incluso datePublished nel markup Article, causando:

• Impossibilità di attivare lo “Snippet in primo piano” (Featured Snippet);
• Posizionamento degli articoli nei risultati di ricerca inferiore rispetto ai concorrenti pubblicati nello stesso periodo (che mostravano la data);
• Calo della fiducia degli utenti — i contenuti senza data sono considerati “obsoleti”.

Azione di riparazione: aggiunta della data di pubblicazione in formato ISO 8601:

“datePublished”: “2024-03-15T10:00:00+08:00” Il tasso di visualizzazione dello snippet in primo piano è passato dal 10% al 35%, il tasso di clic sugli articoli è aumentato del 25% e la probabilità di entrare nelle prime 3 posizioni di ricerca è salita del 19%.

LocalBusiness

Le proprietà obbligatorie per LocalBusiness (attività locale) sono name, address e telephone. Tra queste, address (indirizzo dettagliato) è il nucleo che permette a Google di associare le schede mappa — tasso di mancanza del 35% (Dati Google My Business 2023).

Dopo la mancanza: un bar non ha inserito l’indirizzo completo (solo la città) nel markup LocalBusiness, con i seguenti risultati:

• Nessuna scheda mappa nei risultati di ricerca;
• Gli utenti non potevano navigare direttamente verso il locale;
• Traffico locale inferiore del 50% rispetto ai concorrenti limitrofi.

Azione di riparazione: aggiunta dell’indirizzo dettagliato di tipo PostalAddress:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} La scheda mappa è andata online entro 24 ore, il traffico di ricerca locale è aumentato del 40% e le conversioni in negozio del 28%.

Recipe

Le proprietà obbligatorie per Recipe (ricetta) sono name, description e recipeIngredient (elenco degli ingredienti).

Il campo recipeIngredient è il “contenuto centrale” della ricetta — tasso di mancanza del 41% (Ricerca utenti AllRecipes 2024).

Dopo la mancanza: un sito di cucina non ha elencato gli ingredienti nel markup Recipe, causando:

• Mancata visualizzazione dell’elenco ingredienti e dei passaggi;
• Impossibilità per l’utente di capire se la ricetta soddisfa le proprie esigenze;
• Volume di salvataggi inferiore del 60% rispetto ai concorrenti.

Azione di riparazione: aggiunta dell’elenco strutturato degli ingredienti:

“recipeIngredient”: [
“200g di farina”,
“2 uova”,
“150ml di latte”,
“50g di zucchero”
] La visualizzazione dell’elenco ingredienti e dei passaggi è passata dall’8% al 25%, i salvataggi sono aumentati del 32% e la probabilità di essere selezionati da Google come “Ricette popolari” è salita del 21%.

Nidificazione dei tipi non standard

La “nidificazione dei tipi” nei dati strutturati segue la logica di Schema.org — un tipo padre trasmette associazioni semantiche includendo tipi figli. Ad esempio, Recipe (ricetta) deve nidificare il tipo figlio NutritionInformation (informazioni nutrizionali) tramite il campo nutrition affinché Google capisca che “le calorie appartengono a questo piatto”.

L’essenza degli errori di nidificazione

Il sistema di tipi di Schema.org è una “gerarchia ad albero”: il tipo padre definisce le proprietà principali, il tipo figlio estende i dettagli specifici.

Per esempio:

• Recipe (padre) è il “contenuto della ricetta”, che deve collegare NutritionInformation (figlio) tramite il campo nutrition per trasmettere dettagli come “calorie, contenuto di grassi”;
• Event (padre) è l’ “informazione sull’evento”, che deve collegare Place (figlio) tramite il campo location per trasmettere informazioni sulla posizione come “indirizzo, coordinate”.

Conseguenze dell’errore: se si saltano i tipi figli inserendo le proprietà direttamente sotto il tipo padre, Google giudicherà l’ “appartenenza della proprietà poco chiara”, ignorando quella parte di contenuto.

Ad esempio, se un sito di cucina scrive direttamente "calories": "350 kcal" nel markup Recipe invece di nidificarlo sotto NutritionInformation, lo strumento di Google segnalerà “impossibile identificare il campo calorie”, con il risultato che i valori nutrizionali non appariranno nei risultati multimediali.

4 errori di nidificazione comuni

(1) Recipe: informazioni nutrizionali non nidificate in NutritionInformation

Scenario di errore: un blog di cucina inserisce calorie e grassi direttamente nel tipo padre Recipe:

{
“@type”: “Recipe”,
“name”: “Pomodoro e uova”,
“nutrition”: { // Errore: nutrition è una proprietà del padre che richiede un tipo figlio nidificato
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
Problema: Google non riconosce che le proprietà sotto nutrition appartengono alle “informazioni nutrizionali”, quindi non le mostra nei risultati multimediali.

Azione di riparazione: nidificare le informazioni nutrizionali sotto il tipo figlio NutritionInformation:

{
“@type”: “Recipe”,
“name”: “Pomodoro e uova”,
“nutrition”: {
“@type”: “NutritionInformation”, // Aggiunta del tipo figlio
“calories”: “350 kcal”,
“fatContent”: “12g”
}
} Effetto: nei risultati multimediali delle ricette del blog, la visualizzazione dei componenti nutrizionali è passata dall’8% al 25% e i salvataggi degli utenti sono aumentati del 32% (Dati AllRecipes 2024).

(2) Event: informazioni sulla posizione non nidificate in Place e PostalAddress

Scenario di errore: un sito di conferenze scrive l’indirizzo nel markup Event come una semplice stringa, senza nidificazione gerarchica:

{
“@type”: “Event”,
“name”: “Summit di Marketing Digitale”,
“location”: “Centro Congressi San Francisco” // Errore: location richiede Place e PostalAddress nidificati
}
Problema: Google non può analizzare le informazioni strutturate dell’indirizzo, quindi non mostra la scheda mappa.

Azione di riparazione: nidificare i tipi figli Place (luogo) e PostalAddress (indirizzo postale):

{
“@type”: “Event”,
“name”: “Summit di Marketing Digitale”,
“location”: {
“@type”: “Place”,
“name”: “Centro Congressi San Francisco”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
} Effetto: dopo la riparazione, i risultati di ricerca mostrano la scheda mappa, il tasso di clic sull’evento è aumentato del 40% e le iscrizioni del 28% (Dati Google Events 2023).

(3) Product: informazioni sulla valutazione non nidificate in Review o AggregateRating

Scenario di errore: una piattaforma e-commerce inserisce il punteggio della recensione nel markup Product senza nidificare il tipo figlio AggregateRating (valutazione aggregata):

{
“@type”: “Product”,
“name”: “Cuffie Wireless”,
“reviewScore”: “4.5” // Errore: reviewScore deve essere nidificato sotto AggregateRating
} Problema: Google non riconosce “4.5” come valutazione aggregata del prodotto, quindi non mostra le stelline.

Azione di riparazione: nidificare il tipo figlio AggregateRating:

{
“@type”: “Product”,
“name”: “Cuffie Wireless”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
} Effetto: nei risultati multimediali del prodotto, la visualizzazione della valutazione a stelle è passata dal 15% al 50% e le conversioni sono aumentate del 19% (Dati Shopify 2024).

(4) Article: informazioni sull’autore non nidificate in Person

Scenario di errore: un blog tecnologico inserisce il nome dell’autore nel markup Article senza nidificare il tipo figlio Person (persona):

{
“@type”: “Article”,
“name”: “Tendenze SEO 2024”,
“author”: “Mario Rossi” // Errore: author richiede il tipo figlio Person nidificato
} Problema: Google non riconosce l’identità dell’autore, quindi non mostra l’etichetta “Autore”.

Azione di riparazione: nidificare il tipo figlio Person:

{
“@type”: “Article”,
“name”: “Tendenze SEO 2024”,
“author”: {
“@type”: “Person”,
“name”: “Mario Rossi”,
“url”: “https://example.com/author/mariorossi”
}
} Effetto: la visualizzazione dell’etichetta “Autore” dell’articolo è passata dal 20% al 60% e la fiducia degli utenti è aumentata del 25% (Dati Google Authorship 2023).

Contenuti dinamici non acquisiti

I contenuti dinamici si riferiscono a contenuti generati in tempo reale tramite JavaScript (JS), AJAX o framework per applicazioni a pagina singola (SPA) — come pagine costruite con React/Vue, liste di articoli a scorrimento infinito o passaggi di ricette caricati dopo il clic su un pulsante.

I markup di questo tipo (come il prezzo Product o i commenti Article) non appaiono nell’HTML iniziale, ma vengono iniettati dinamicamente dal JS lato client.

Tuttavia, il meccanismo di scansione di Googlebot prevede di “scaricare prima l’HTML iniziale e poi eseguire il JS”; se l’esecuzione del JS è troppo lenta o il contenuto dipende dal rendering lato client, i risultati multimediali non verranno generati.

Il blog degli ingegneri di Google (2024) indica che il 40% delle pagine dinamiche non viene letto dai crawler perché manca il pre-rendering.

Contenuti dinamici non scansionati

Il processo di scansione di Googlebot avviene in due fasi:

1. Download dell’HTML iniziale: acquisizione della struttura base della pagina (senza i contenuti generati da JS);
2. Esecuzione di JS: simulazione dell’esecuzione di JS nel browser per ottenere i contenuti dinamici (necessita di attendere il completamento del JS).

Ma la “pazienza” del crawler è limitata:

• Se l’esecuzione del JS supera i 3 secondi, Googlebot potrebbe interrompersi in anticipo, impedendo la lettura dei markup dinamici (Dati Lighthouse 2023);
• Se il contenuto dipende dall’ “interazione dell’utente” (come cliccare su “carica altro”), il crawler salterà quella parte di contenuto.

Esempio: un sito di news costruito come SPA con React carica i commenti Article in modo dinamico tramite JS.

Lo strumento di test mostra “Nessun risultato multimediale” — in realtà il markup dei commenti esiste, ma al momento della scansione di Googlebot il JS non aveva finito l’esecuzione e i commenti non erano inclusi nell’HTML iniziale.

3 problemi frequenti

(1) SPA (Single Page Application): HTML iniziale vuoto, markup non incluso

Una SPA è “una pagina che sostituisce dinamicamente i contenuti”; l’HTML iniziale è solitamente un <div id="root"></div> vuoto, con tutto il contenuto iniettato da JS.

Senza pre-rendering, l’HTML iniziale scansionato da Googlebot non contiene dati strutturati, quindi i markup non vengono riconosciuti. Dati: il markup Tour di un sito di viaggi era generato da React e l’HTML iniziale era vuoto.

Search Console mostrava “Nessun markup idoneo trovato”, con visualizzazione dei risultati multimediali pari a zero. Dopo la riparazione tramite Server-Side Rendering (SSR), l’HTML iniziale conteneva direttamente il markup completo di Tour, e il tasso di visualizzazione è passato dallo 0% al 28%.

(2) Caricamento AJAX: contenuti acquisiti asincronamente, il crawler non attende

AJAX viene usato per caricare contenuti in modo asincrono (come liste prodotti a scorrimento infinito o commenti), ma il crawler non attende il completamento delle richieste AJAX — se il tempo di caricamento supera la “soglia di timeout” del crawler (circa 3 secondi), il markup viene perso.

Esempio: la lista prodotti “Ti potrebbe interessare” di un e-commerce viene caricata tramite AJAX, con markup Product generati dinamicamente da JS.

Lo strumento di test mostrava “Alcuni markup ignorati” — al momento della scansione di Googlebot la richiesta AJAX non era completata e le informazioni sui prodotti non erano incluse.

Dopo la riparazione con uno strumento di pre-rendering (Prerender.io) per generare HTML con la lista prodotti completa, il tasso di riconoscimento dei markup è passato dal 60% al 95%.

(3) Caricamento differito (Lazy Load): visualizzazione attivata, oltre il tempo di attesa del crawler

Il caricamento differito è usato per ottimizzare la velocità della pagina, caricando ad esempio i passaggi di una HowTo (guida) o gli ingredienti di una Recipe solo quando entrano nell’area visibile. Ma se il ritardo è eccessivo (es. più di 2 secondi), il crawler potrebbe perdere quel contenuto.

Dati: il markup HowTo (es. passaggi “Come montare una libreria”) di un sito di arredamento veniva caricato con un ritardo di 2 secondi.

Lo strumento di test di Google segnalava “Impossibile identificare il campo dei passaggi” — il crawler non ha atteso il completamento del caricamento.

Dopo la riparazione, riducendo il ritardo a meno di 1 secondo, la visualizzazione dei passaggi è passata dal 18% al 43%.

Tre metodi di riparazione

(1) Pre-rendering: generazione dell’HTML completo sul server per il crawler

Il pre-rendering consiste nell’eseguire il JS sul server per generare un HTML contenente tutti i contenuti dinamici, inviandolo poi al crawler.

Strumenti come Prerender.io o moduli di pre-rendering per Nginx possono identificare automaticamente le richieste dei crawler e restituire l’HTML pre-renderizzato.

Effetto: dopo l’uso di Prerender.io su una SPA e-commerce, il tasso di successo della scansione del markup Product è passato dal 75% al 92%, e la visualizzazione dei risultati multimediali dal 5% al 28%.

(2) Server-Side Rendering (SSR): rendering diretto dei contenuti JS tramite framework

L’SSR utilizza framework come Next.js (React) o Nuxt.js (Vue) per renderizzare i componenti JS in stringhe HTML sul server prima di inviarle al client.

In questo modo l’HTML iniziale contiene già il markup completo e il crawler non deve attendere l’esecuzione del JS.

Esempio: un sito di news è stato ricostruito con Next.js, con l’area commenti di Article generata tramite SSR.

Googlebot, al momento della scansione, acquisisce direttamente il markup Comment; la visualizzazione dello snippet in primo piano è passata dal 10% al 50% e le interazioni sui commenti sono aumentate del 35%.

(3) Ottimizzazione della durata di esecuzione del JS: caricamento del markup entro 3 secondi

Se non è possibile utilizzare pre-rendering o SSR, è necessario ottimizzare i tempi di esecuzione del JS per garantire che i markup dinamici vengano caricati entro 3 secondi.

Utilizzare Lighthouse o la scheda Performance dei Chrome DevTools per controllare il tempo di caricamento del markup:

• Comprimere i file JS: usare Webpack o Rollup per comprimere il codice e ridurre la dimensione dei file;
• Caricamento differito del JS non critico: impostare script che non influenzano il markup (come pubblicità o statistiche) come async o defer;
• Caching delle risorse: usare CDN per memorizzare i file JS nella cache e ridurre i tempi di caricamento.

Dati: un sito media ha ottimizzato la durata di esecuzione del JS da 4,2 a 2,5 secondi; il tasso di successo della scansione di Googlebot è passato dal 68% al 90%, con un aumento del 22% nella visualizzazione dei risultati multimediali Article.

Infine, vorrei dire: una riga di JSON corretta, una nidificazione standard o un pre-rendering tempestivo possono fare la differenza tra avere o meno i risultati multimediali.