Inizia dalla pagina e da una funzionalità supportata
Non iniziare aggiungendo tutti i tipi di schema.org che sembrano collegati al tuo business. Schema.org è un vocabolario ampio condiviso, mentre la Search Gallery di Google documenta le funzionalità dei risultati arricchiti che supporta e le proprietà di cui hanno bisogno. Una pagina prodotto, evento o articolo dovrebbe prima essere utile anche senza markup.
Per ogni template, definisci il suo soggetto principale e i fatti di supporto visibili. Poi leggi la guida corrente di Google per la funzionalità corrispondente. Product, Recipe, Article, Breadcrumb, Event, Organization, Local business e Video sono esempi. Un tipo del vocabolario da solo non crea una funzionalità Google; sono le proprietà richieste di quella funzionalità a determinare l'idoneità.
Rendi l'elemento visibile primario l'elemento principale anche nel markup.
Usa la guida di Google per il comportamento della funzionalità e schema.org per il vocabolario.
Fai della pagina visibile la fonte di verità
Il markup deve rappresentare il contenuto principale della pagina, non materiale nascosto, irrilevante o fuorviante. Se indica che un interprete sarà presente, la pagina deve descrivere quell'interprete. Se marca un rating aggregato, i visitatori devono poter vedere quel rating. Questo evita che un template deraghi in un sommario fuorviante.
Costruisci testo della pagina e markup dagli stessi record approvati. Un feed prodotto, un sistema eventi o un CMS possono fornire entrambi, ma i valori devono essere rivisti prima della pubblicazione. Non copiare un prezzo, stato di magazzino, data o totale recensioni in un campo presente solo nel markup che potrebbe essere dimenticato. Aggiorna o rimuovi il markup quando l'informazione visibile cambia.
Mantieni nomi, date, prezzi, disponibilità e valutazioni allineati con la pagina.
Non compilare mai proprietà con valori ipotizzati o obsoleti.
Usa JSON-LD come layer dati manutenibile
JSON-LD è un formato di linked data basato su JSON inserito in un documento HTML. Google supporta JSON-LD, Microdata e RDFa, e dichiara che JSON-LD è in genere il più facile da implementare e mantenere su larga scala. La sua separazione dal markup visibile può rendere più semplice modellare informazioni annidate.
Usa un oggetto dati chiaro per ogni elemento reale, con un tipo schema.org appropriato e proprietà supportate e accurate. Per ogni template, documenta la guida alla funzionalità, il campo sorgente, il comportamento dei campi richiesti e il responsabile. Ispeziona anche l'output renderizzato: un plug-in o un componente può aggiungere markup duplicato o in conflitto.
Scegli il formato che il tuo team può mantenere in modo coerente.
Non inventare un valore richiesto quando i dati sorgente sono assenti.
Valida il codice e la pagina accessibile
La validazione risponde a due domande. Primo, il markup è sufficientemente completo per una funzionalità supportata? Il Rich Results Test accetta codice incollato o un URL pubblicamente accessibile e segnala i risultati arricchiti che possono essere generati dai dati strutturati. Testa esempi rappresentativi per ogni template, non una pagina eccezionalmente completa.
Secondo, Google riesce ad accedere alla pagina rilasciata e alle risorse? Non bloccare le pagine con markup tramite robots.txt, noindex o controlli di accesso. Controlla gli URL delle immagini rilevanti. Il test non è una garanzia di qualità: problemi di contenuto visibile o di policy possono comunque impedire la visualizzazione.
Testa il codice prima e poi verifica un URL pubblico accessibile.
Confronta pagina renderizzata, sorgente e risultato del test quando gli strumenti aggiungono markup.
La potenziale visualizzazione non è una promessa della visualizzazione effettiva.
Rilascia come una modifica template rivolta agli utenti
I dati strutturati spesso dipendono da template, feed e regole di pubblicazione. Un redesign, un cambiamento di integrazione dell'inventario, un aggiornamento di localizzazione o la rimozione di un componente possono rompere molti elementi. Aggiungi controlli rappresentativi del markup alla revisione pre-rilascio usata per tag canonici, titoli e immagini. Registra il template, esempi di pagina, campi sorgente e data di rilascio.
Quando un template emette markup errato, correggi la sorgente condivisa o il template, valida un piccolo campione, deploya la modifica meno invasiva possibile e ritesta gli URL interessati. Se la correzione si comporta inaspettatamente, usa il normale processo di rollback. L'obiettivo è la remissione basata su evidenze di una capacità web degradata, non un alert di outage.
Controlla insiemi rappresentativi di pagine, non un singolo URL.
Registra la modifica e il componente di markup prima di una correzione successiva.
Mantieni, misura e accetta il limite di visualizzazione
Dopo il deployment, usa il report pertinente di Search Console sui risultati arricchiti per indagare problemi e confermare le correzioni. I report sono campioni anziché inventari completi e i conteggi si riferiscono a elementi (items), non a pagine. Ispeziona un URL specifico quando necessario.
Misura con cautela. Google suggerisce un confronto prima/dopo su pagine stabili e sufficientemente lette nel tempo su Search Console. Registra la data di rilascio e altri cambiamenti di pagina. Correggere il markup abilita solo l'idoneità; è Google a determinare la presentazione nella ricerca.
Ricontrolla dopo aggiornamenti di CMS, template, feed, policy o modello di contenuto.
Evita confronti dove altri cambiamenti importanti di pagina differiscono.