Una mappa dei tipi schema.org per pagine AI search più chiare

Cosa dovrebbe registrare una revisione schema prima di scegliere i tipi?

Un inventario di URL mostra quali pagine hanno bisogno di descrizioni strutturate e quali fatti supportano. Inizia dalla pagina, non da un elenco di tipi schema. Registra il suo scopo, l'entità principale, le affermazioni visibili e il responsabile. Questo crea una base verificabile per le decisioni sul markup.

Per ogni URL prioritario, cattura:

• Scopo della pagina: cosa un visitatore può imparare o fare lì.
• Entità principale: l'organizzazione, persona, prodotto o articolo descritto.
• Evidenza: dove ogni valore proposto appare nella pagina o in una fonte ufficiale.
• Responsabile dell'aggiornamento: chi revisiona la descrizione quando i fatti della pagina cambiano.

Una panoramica aziendale potrebbe descrivere un'organizzazione. Una pagina prodotto dovrebbe identificare il prodotto effettivo e i dettagli supportati. Una pagina editoriale dovrebbe identificare il suo contenuto articolo e la paternità. Se la pagina non mostra un fatto proposto, non aggiungerlo alla descrizione strutturata solo perché sembra utile.

Questo registro aiuta anche a separare le correzioni di contenuto dalle correzioni di markup. I fatti mancanti o poco chiari necessitano prima di attenzione editoriale. I fatti corretti espressi in un formato incoerente necessitano di una revisione dell'implementazione. Per ulteriori indicazioni a livello di pagina, vedi contenuto citabile per assistenti AI.

Quali tipi schema.org si adattano alla pagina che i visitatori vedono?

Lo scopo visibile della pagina dà il primo indizio sul suo tipo schema.org. Scegli un tipo che descriva il contenuto, poi includi solo le proprietà supportate dalla pagina o da una fonte ufficiale identificata. Una mappa dei tipi rende queste decisioni revisionabili su tutto il sito.

Questa è un ausilio alla selezione, non un pacchetto obbligatorio. Una pagina può riguardare un sito e un'organizzazione, ma ogni descrizione necessita di uno scopo chiaro. Evita di assegnare un tipo editoriale a una pagina promozionale quando la pagina non contiene un articolo. Evita di aggiungere proprietà solo per allungare il markup.

Revisiona le definizioni schema.org per i tipi candidati prima di pubblicare. Poi confronta ogni proprietà proposta con l'evidenza di pagina registrata nel tuo inventario. La guida tecnica AEO copre schema insieme ad altre aree di revisione tecnica.

Cosa appartiene a un esempio JSON-LD pratico?

Un record JSON-LD utile contiene un tipo e valori che un revisore può verificare. Mantieni l'esempio abbastanza piccolo da poterlo confrontare con la pagina. Il seguente record organizzativo usa valori di esempio che devono essere sostituiti prima della pubblicazione:

Esempio JSON-LD: {"@context":"https://schema.org","@type":"Organization","name":"Example Project","url":"https://example.org","sameAs":["https://social.example.org/project"]}

Il contesto identifica il vocabolario. Il tipo nomina l'entità descritta. Le proprietà forniscono il suo nome, URL e riferimento al profilo. Non pubblicare gli URL di esempio. Sostituiscili solo con destinazioni verificate che rappresentano la stessa organizzazione.

Usa la stessa revisione per altri tipi. Un record articolo dovrebbe corrispondere al titolo visibile e alla paternità nominata. Un record prodotto dovrebbe descrivere il prodotto mostrato su quella pagina. Se una proprietà non ha evidenza chiara, omettila finché la pagina o una fonte ufficiale non la supporta.

Scegli un'implementazione che il tuo team editoriale possa mantenere. JSON-LD può risiedere in un template o in un campo CMS controllato. Il controllo importante non è solo la posizione. Confronta la pagina renderizzata e il record strutturato pubblicato dopo il deployment.

Come può un team implementare schema senza dividere i suoi fatti?

Una mappa pagina-proprietà mantiene collegati i fatti editoriali e i campi di implementazione. Usa una sequenza di rilascio breve in modo che ogni record pubblicato abbia un responsabile e un punto di revisione. Questo è particolarmente utile quando i template producono markup su più URL.

1. Fai l'inventario degli URL prioritari e registra lo scopo di ogni pagina.
2. Mappa i fatti visibili a un tipo e proprietà adatti.
3. Aggiungi il record tramite un campo CMS controllato o un template.
4. Revisiona l'output pubblicato rispetto alla pagina renderizzata.
5. Ricontrolla i record interessati quando nomi, URL o responsabilità cambiano.

Mantieni una fonte autorevole per i fatti che appaiono in più punti. Ad esempio, usa il nome approvato dell'organizzazione e l'URL ufficiale in modo coerente nella sua pagina e nella descrizione strutturata. Se più team modificano gli stessi dettagli, assegna un responsabile del contenuto e un revisore dell'implementazione. Questa divisione aiuta a identificare valori obsoleti prima che si diffondano.

Non trattare l'installazione come la fine del compito. Un rilascio del sito può cambiare template, URL di pagina o testo visibile. Aggiungi i controlli schema alla revisione editoriale pertinente. Per una pianificazione più ampia su markup e configurazione crawler, fai riferimento a AEO tecnico.

Quali record mostrano se i controlli di markup e visibilità sono solidi?

Un registro di validazione mostra se il markup pubblicato è presente, leggibile e coerente con la sua pagina. Mantieni quel controllo tecnico distinto dalle osservazioni sulle risposte AI. Un record valido non mostra quali informazioni un particolare motore di risposta ha utilizzato.

Per ogni URL revisionato, registra l'indirizzo della pagina, la data di revisione, il tipo previsto, le proprietà controllate e l'esito. Ispeziona l'output renderizzato oltre al sorgente o all'output CMS. Cerca record duplicati da plugin e template. Confronta nomi, URL, paternità e altri fatti marcati con il contenuto visibile ai visitatori.

Per un'osservazione ripetibile delle risposte, definisci un piccolo protocollo prima di controllare. Un pannello di partenza pratico è 10 prompt pertinenti su 3 motori di risposta, con 2 esecuzioni per prompt. Registra il prompt, il motore, la data, la risposta, le fonti citate e se la pagina o l'organizzazione appare. Questi sono campi di osservazione, non prove del perché una risposta è apparsa.

Mantieni stabile la formulazione del prompt quando confronti cicli di revisione. Salva il testo della risposta o una cattura affidabile con il record. Separa le modifiche al contenuto della pagina dalle modifiche nelle risposte osservate. Questo rende la revisione successiva più utile di una singola ricerca informale. Vedi FAQ optimization per allineare le risposte visibili con le domande dei lettori.

LLMs.txt vs schema.org: quale file risolve quale problema?

Schema.org descrive entità e contenuti di pagina attraverso proprietà strutturate. llms.txt è una convenzione di file di testo separata per riassumere le risorse del sito. Sono artefatti diversi, quindi l'uno non sostituisce l'altro né il testo della pagina stesso.

Usa l'inventario delle pagine per individuare prima il problema. Se l'entità o le relazioni della pagina non sono chiare, revisiona il suo contenuto visibile e considera dati strutturati accurati. Se stai valutando un file llms.txt, revisiona i suoi riassunti e link come un compito editoriale separato. Mantieni un responsabile per ogni artefatto e controlla i suoi contenuti quando le pagine pertinenti cambiano.

Evita di mantenere versioni diverse dello stesso fatto senza un responsabile. Un URL di profilo obsoleto in un file o in un record di markup può entrare in conflitto con la pagina visibile. Per informazioni di base sulla convenzione del file di testo, leggi llms.txt: cos'è e se ti serve. Per considerazioni sull'implementazione, vedi llms.txt e configurazione AI crawler.

Cosa può dirti un record schema su ChatGPT e Perplexity?

Un record schema ti permette di ispezionare cosa una pagina afferma in forma strutturata. Non può rivelare come ChatGPT o Perplexity recuperano, valutano o selezionano le fonti per una risposta. Il loro accesso, elaborazione e scelte di citazione rimangono al di fuori del controllo del proprietario del sito.

Questa distinzione è importante quando si confrontano le citazioni di ChatGPT e Perplexity. Una pagina può avere markup valido mentre le osservazioni delle risposte differiscono per motore, prompt o data di revisione. Tratta un registro delle citazioni come evidenza di ciò che hai osservato, non come prova che schema ha causato l'apparizione. Mantieni la validazione tecnica e il monitoraggio delle risposte in record separati.

Un pacchetto di revisione utile contiene l'inventario degli URL, la mappa pagina-tipo, un esempio JSON-LD, note di validazione e un registro delle osservazioni delle risposte. Usalo per identificare azioni concrete successive: correggi una proprietà obsoleta, chiarisci il testo visibile o ripeti un controllo con prompt stabile. Non aggiungere un tipo solo perché una risposta non ha citato una pagina.

Per iniziare, raccogli da 3 a 5 URL prioritari e le fonti ufficiali che confermano i loro fatti chiave. Possiamo revisionare la mappa delle pagine, segnalare proprietà non supportate e restituire una checklist di implementazione mirata per il tuo team editoriale.

Come funziona

1. Elenca gli URL prioritariRegistra lo scopo di ogni pagina, l'entità principale e il responsabile del contenuto. Inizia con le pagine che spiegano l'organizzazione, i prodotti o il lavoro editoriale.
2. Mappa i fatti ai tipiSeleziona i tipi schema.org adatti. Collega ogni proprietà proposta al contenuto visibile della pagina o a una fonte ufficiale.
3. Prepara il markupAggiungi le proprietà supportate tramite un campo CMS controllato o un template. Tieni un revisore responsabile del controllo delle modifiche.
4. Controlla l'output pubblicatoConfronta il markup con la pagina renderizzata. Registra l'URL, il tipo, le proprietà revisionate e l'esito della validazione.
5. Registra le osservazioni delle risposteUsa prompt stabili e registra il motore, la data, la risposta e le fonti citate. Mantieni questo registro separato dai controlli di sintassi.