Il Controllo Dati Strutturati di Screpy esamina JSON-LD da una pagina pubblica o da codice incollato. Individua gli errori di parsing, elenca le entità dichiarate e segnala problemi in proprietà selezionate di cinque tipi di schema supportati. Usa il rapporto per decidere cosa correggere e cosa richiede una verifica più ampia. Sintassi valida, controlli supportati e idoneità a un risultato avanzato di Google sono questioni distinte: uno stato verde non risponde a tutte e tre.
Scegli un URL di pagina o JSON-LD incollato
Seleziona URL della pagina per esaminare una pagina pubblicata, come una scheda prodotto o una pagina di contatto aziendale. Inserisci il suo indirizzo pubblico HTTP o HTTPS invece di usare sempre la homepage: modelli diversi possono contenere markup diverso. La modalità URL legge l’HTML restituito dalla pagina. Una pagina privata o protetta da password non fornisce le stesse evidenze pubbliche; un errore di recupero non dimostra che i suoi dati strutturati siano errati.
Seleziona Incolla codice per esaminare una bozza, uno script estratto o HTML già disponibile. Scegli JSON-LD per il JSON stesso, senza un elemento <script> esterno. Scegli HTML se l’input contiene blocchi <script type="application/ld+json">. L’indirizzo di un file JSON autonomo non è una pagina HTML: incolla il contenuto in modalità JSON-LD. L’input incollato è limitato a 256 KiB misurati in byte UTF-8; il numero di caratteri consentito dipende quindi dal testo.
I controlli tramite URL non eseguono JavaScript. Il markup inserito dopo il caricamento della pagina può mancare nel sorgente recuperato. Google può elaborare JSON-LD inserito dinamicamente, quindi l’assenza di un blocco nel rapporto non dimostra che Google non lo veda. Esamina il markup renderizzato pertinente o usa il test delle funzionalità di Google quando questa distinzione conta. Incollare codice verifica ciò che hai fornito, senza stabilire cosa restituisca la pagina pubblicata.
Leggi il rapporto sui dati strutturati
Parti dalla copertura, poi leggi i rilievi e la tabella delle entità. Blocchi JSON-LD conta gli script rilevati nell’HTML; JSON-LD incollato viene considerato un blocco. Entità conta gli oggetti conservati con un tipo dichiarato e JSON analizzato correttamente; uno script può contenere più entità. Errori di sintassi conta i blocchi elaborati che non è stato possibile analizzare. Sono quantità diverse: una pagina con tre blocchi non ha necessariamente tre entità. In un rapporto parziale, il numero di blocchi rilevati non dimostra che siano stati esaminati tutti.
Ogni riga distingue Sintassi e Ambito. La sintassi valida in verde significa che il parser JSON ha accettato il blocco. I controlli supportati in verde indicano che l’entità soddisfaceva le condizioni dei controlli di proprietà selezionate dello strumento. Leggi anche i suoi rilievi: nessuna etichetta conferma che tutte le proprietà siano corrette. Il rosso identifica errori di parsing o rilievi di errore, il giallo evidenzia avvisi e copertura parziale, il grigio indica evidenze non supportate o non disponibili. Considera lo stato scritto insieme al colore.
La colonna Percorso aiuta a individuare gli oggetti annidati. Per esempio, $.author indica l’oggetto autore nella radice, mentre $.@graph[1] indica il secondo oggetto di un array @graph. I percorsi sono relativi al rispettivo blocco JSON-LD: lo stesso percorso può comparire in più script. Il JSON scaricato include i numeri dei blocchi per distinguerli.
La colonna Nome legge name, non la proprietà di visualizzazione di ogni tipo. Un Article con headline valido può quindi avere la cella Nome vuota. Esamina la proprietà e il rilievo pertinenti prima di considerare quel vuoto un difetto del contenuto.
Correggi la sintassi JSON prima degli avvisi sulle proprietà
Un blocco non valido non fornisce rilievi affidabili sulle entità. Ripara prima il JSON e ripeti il controllo prima di interpretare gli avvisi sulle proprietà mancanti. Cause comuni sono apici singoli per nomi o stringhe, una virgola aggiuntiva dopo l’ultima proprietà, una parentesi di chiusura mancante e una virgoletta non sottoposta a escape nel testo. JSON usa stringhe tra virgolette doppie e virgole tra i membri; RFC 8259 ne definisce la grammatica.
Questa Organization fittizia è un esempio minimo di sintassi per Incolla codice → JSON-LD:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
L’esempio fornisce le due proprietà che questo strumento cerca per Organization. Non è un modello completo per alcuna funzionalità di ricerca Google. Sostituisci i valori fittizi con informazioni reali della pagina e consulta i requisiti della funzionalità pertinente prima della pubblicazione.
Il solo JSON valido non dimostra che i dati strutturati siano utilizzabili. Una stringa o un numero isolato può essere JSON valido, ma non descrive l’entità prevista; lo strumento segnala che la radice deve essere un oggetto o un array. Allo stesso modo, un oggetto analizzato senza @type dichiarato può non produrre righe di entità. Controlla la struttura effettiva prima di aggiungere proprietà soltanto per eliminare gli avvisi dal rapporto.
Quali proprietà dello schema vengono controllate?
Il Controllo Dati Strutturati applica controlli selezionati a cinque tipi esatti quando ne riconosce il contesto. Usa la tabella per comprendere un rilievo, non come elenco completo di proprietà Schema.org o campi obbligatori di Google.
| Tipo dichiarato | Cosa esamina questo strumento | Come usare il rilievo |
|---|---|---|
Organization |
Presenza di name e url |
Verifica che descrivano l’organizzazione reale e il suo sito corretto. |
LocalBusiness |
Presenza di name e address |
Esamina identità e indirizzo reali dell’attività; i componenti dell’indirizzo non vengono validati completamente. |
Article |
Presenza di headline, author, datePublished e image |
Confronta i valori con l’articolo e controlla i formati separatamente. |
Product |
Presenza di name; disponibilità di almeno uno tra offers, review o aggregateRating |
Usa soltanto dati del prodotto veritieri e pertinenti. Non inventare offerte o recensioni per rimuovere un avviso. |
BreadcrumbList |
Array itemListElement non vuoto; position intero positivo e name testuale non vuoto di ogni elemento esaminato |
Correggi l’elemento indicato, poi verifica separatamente l’intero percorso di navigazione e gli URL di destinazione. |
La maggior parte sono controlli di presenza. Un valore può esistere anche se URL, data, immagine, struttura dell’oggetto o contenuto fattuale sono errati. Un oggetto vuoto può soddisfare un controllo di presenza e non tutti i controlli rifiutano valori composti solo da spazi. Uno stato supportato non conferma quindi che indirizzo, autore o offerta siano completi.
I controlli dei breadcrumb esaminano anche i valori selezionati degli elementi, ma non confermano posizioni consecutive o uniche, URL item corretti o la semantica completa di ListItem. Il rapporto conserva al massimo 100 rilievi di proprietà per entità. Un percorso lungo o un’entità con molti difetti ripetuti può richiedere un ulteriore esame dopo questi rilievi.
Correggi il rilievo nel contesto della pagina. Se l’autore dell’articolo è una persona, conserva la struttura corretta dell’autore anche quando la Person annidata appare fuori dall’ambito del controllo. Modificare markup veritiero solo per ottenere etichette verdi può nascondere il problema originale invece di risolverlo.
Perché un markup valido risulta non supportato o parziale?
Non supportato significa che lo strumento non ha applicato i suoi controlli di proprietà selezionate a quell’entità. Non significa che Schema.org vieti il tipo. Un Article supportato, per esempio, può contenere un autore Person annidato. Article riceve i controlli selezionati, ma Person appare non supportato e rende la copertura parziale. Anche Restaurant resta fuori dai cinque tipi esatti supportati, sebbene sia un tipo di attività più specifico. Mantieni il tipo che descrive accuratamente il soggetto e usa un validatore più ampio per i controlli restanti.
Il contesto può produrre la stessa distinzione. Questo strumento riconosce un contesto semplice http://schema.org o https://schema.org, con o senza barra finale, anche se ereditato da un oggetto padre. Non risolve contesti costituiti da oggetti o array. Tali forme possono essere legittime secondo la specifica W3C dei contesti JSON-LD. Se un’entità dichiara più tipi, tutti devono appartenere all’insieme supportato affinché vengano eseguiti i controlli delle proprietà.
Anche la copertura ha dei limiti. Lo strumento considera i primi 50 blocchi JSON-LD e conserva fino a 500 righe di risultati, incluse quelle dei blocchi non validi. Interrompe il percorso oltre 32 livelli di annidamento o 10.000 valori visitati per blocco. Questi limiti possono lasciare entità successive non controllate. Anche Microdata o RDFa rilevati nell’HTML rendono il rapporto parziale, perché questi formati non vengono validati qui.
Per input incollati di grandi dimensioni, dividi blocchi JSON-LD completi in controlli separati; non tagliare un oggetto a metà creando un nuovo errore di sintassi. Conserva la fonte originale e identifica le parti coperte da ciascun rapporto. Questi controlli non vengono combinati automaticamente in un audit completo della pagina.
Verifica la pagina dopo aver corretto il markup
Confronta prima il markup con ciò che un visitatore può leggere sulla pagina. Verifica identità, date, indirizzi, dettagli del prodotto ed eventuali recensioni rispetto al contenuto reale. Le linee guida di Google sui dati strutturati richiedono informazioni pertinenti e accurate e il rispetto dei requisiti applicabili delle funzionalità; un parser non può confermare questi fatti. Non aggiungere dettagli inventati per soddisfare un avviso sulle proprietà.
Scegli il controllo successivo in base alla domanda ancora aperta. Usa il Validatore di Markup Schema.org per un esame più ampio del markup Schema.org, inclusi Microdata e RDFa. Ha anch’esso dei limiti: non recupera né interpreta altri URL di contesto. Usa il Test dei risultati avanzati di Google per esaminare le funzionalità di ricerca Google supportate e i relativi errori o avvisi. Superare un test non garantisce che Google mostri un risultato avanzato.
Se prepari markup aziendale, il Generatore Schema per Attività Locali può produrre JSON-LD dai tuoi dati reali. Esamina l’output prima di pubblicarlo. Tipi di attività specifici e oggetti PostalAddress annidati possono restare non supportati in questo strumento; generazione e validazione selezionata sono attività distinte.
Dopo una correzione, ripeti il controllo pertinente sulla pagina pubblicata, non soltanto sulla bozza. Conferma che il markup restituito contenga la modifica prevista e confronta i rilievi restanti. Usa Scarica JSON per conservare numeri di blocco, percorsi delle entità, rilievi e copertura di quell’esecuzione. Mantieni input e ambito insieme all’esportazione, così un altro revisore può comprendere le evidenze. Un rapporto salvato documenta un controllo; non monitora continuamente le future modifiche a modelli o contenuti.