L'etichetta di una pagina deve corrispondere a ciò che il visitatore vede
Il markup Schema.org fornisce al software una descrizione strutturata di una pagina e del suo argomento. Deve spiegare ciò che la pagina dice già, non aggiungere affermazioni che un visitatore non può verificare.
Inizia scrivendo lo scopo della pagina e la sua entità principale. Poi scegli il tipo più semplice che si adatta. La pagina "Chi siamo" di un progetto e una pagina prodotto non sono intercambiabili, anche se appaiono sullo stesso sito web. Questo ti dà un primo controllo utile per lo schema.org per AI visibilità. Una persona può indicare il contenuto visibile dietro ogni fatto marcato?
| Pagina o argomento | Tipo possibile | Un controllo pratico |
|---|---|---|
| Progetto o azienda | Organization | Il nome pubblico e i dettagli sono accurati? |
| Intero sito web | WebSite | Il record descrive il sito stesso? |
| Un URL | WebPage | Identifica la pagina descritta? |
| Risorsa editoriale | Article | Autore e dettagli di pubblicazione sono visibili? |
| Prodotto o software | Product o SoftwareApplication | La pagina descrive genuinamente quell'offerta? |
Preferiamo un set piccolo che il tuo team possa mantenere piuttosto che un record affollato di proprietà non supportate. Per una visione più ampia del lavoro tecnico, vedi guida tecnica AEO.
Parti dai dettagli del progetto che le persone chiedono già
Immagina un founder il cui primo lancio è stato silenzioso. L'unica persona che risponde va in vacanza, e i nuovi visitatori hanno ancora bisogno di dettagli chiari sul progetto.
Inizieremmo dalle pagine di cui quei visitatori hanno bisogno, non da un grande template di markup. Verificheremmo se il nome del progetto, la descrizione del prodotto e i contatti appaiono chiaramente sul sito. Poi mapperemmo solo quei fatti visibili alle proprietà schema.org adatte. La pagina rimane la fonte di verità; il markup la segue.
Immagina che il progetto abbia una pagina prodotto e un breve articolo esplicativo. La pagina prodotto può supportare Product se descrive realmente il prodotto. L'articolo esplicativo può essere adatto ad Article quando autore e dettagli editoriali sono mostrati. Se la pagina non supporta un campo, lascialo fuori e chiedi prima al responsabile del progetto di chiarire la fonte.
Questo rende il lavoro anche più facile da passare. Un collega può seguire la connessione tra ogni campo e la pagina invece di indovinare perché è stato aggiunto. Per saperne di più su come creare pagine fonte utili, visita contenuti citabili per assistenti AI.
Quali tipi di schema si adattano alle diverse parti di un sito di progetto?
Il tipo di schema giusto dipende da ciò che una particolare pagina rappresenta. Un sito web di progetto può usare diversi tipi su URL diversi, purché ciascuno rifletta il contenuto visibile.
Inizia con il sito e le sue pagine
Organization può descrivere il progetto o l'azienda dietro il sito. WebSite descrive il sito web nel suo insieme, mentre WebPage descrive un singolo URL. Questi tipi possono essere collegati dove la relazione è reale e chiara. Mantieni nomi e dettagli pubblici coerenti tra la pagina e il suo markup.
Aggiungi tipi specifici per contenuto solo dove si adattano
Article può essere adatto a una risorsa editoriale con autore visibile o dettagli di pubblicazione. Product può adattarsi a una pagina che presenta genuinamente un prodotto. SoftwareApplication può adattarsi a una pagina che descrive software, se i dettagli rappresentati nel markup sono supportati lì.
Ad esempio, una pagina che spiega una funzionalità software potrebbe essere valutata per l'idoneità a SoftwareApplication. Se discute solo del progetto in generale, aggiungere quel tipo potrebbe descriverla male. Una rapida revisione pagina per pagina impedisce che un template venga copiato su pagine diverse.
Un oggetto JSON-LD può essere piccolo e leggibile. Qui, nome e indirizzo sono illustrativi, non fatti sul tuo progetto:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Progetto Esempio",
"url": "https://example.org/"
}
Usa i dettagli pubblici effettivi del tuo sito, poi verifica che la pagina renderizzata li supporti. Per le pagine con domande, FAQ optimization può aiutarti a pianificare le risposte visibili prima di considerare il markup.
Un tranquillo percorso in cinque passi dall'elenco pagine al JSON-LD verificato
Un elenco di pagine e un breve controllo delle evidenze rendono il lavoro sullo schema più facile da revisionare. Usiamo questa sequenza per mantenere ogni record collegato alla pagina che descrive.
- Scegli gli URL prioritari. Elenca le pagine che contano di più. Annota lo scopo di ogni pagina, l'entità principale e l'indirizzo canonico.
- Scegli un tipo adatto. Decidi se la pagina descrive l'organizzazione, il sito web, un articolo, un prodotto, un software o un altro argomento appropriato.
- Traccia ogni proprietà. Scrivi dove un visitatore può vedere il fatto, o quale fonte affidabile del progetto lo conferma. Rimuovi i campi senza supporto chiaro.
- Aggiungi JSON-LD alla pagina corrispondente. Verifica che i suoi URL puntino alla pagina prevista e che la sintassi sia valida. Confronta il record con il contenuto renderizzato.
- Rivisita dopo le modifiche. Controlla il markup correlato quando cambiano una pagina, un dettaglio di prodotto, un autore o un fatto sull'organizzazione.
Chiederemmo a un editor o al responsabile del prodotto di confermare identità e affermazioni sul prodotto prima della pubblicazione. Quella revisione coglie nomi non corrispondenti e descrizioni obsolete mentre sono ancora facili da correggere. Tieni la checklist con le note della pagina, così un futuro editor può ripetere gli stessi controlli senza ricostruire il ragionamento da zero. Se stai anche considerando come implementare llms.txt, tieni quel compito separato: il file e il markup della pagina fanno lavori diversi.
Il passaggio tra dati strutturati e piattaforme AI
I dati strutturati possono rendere più espliciti i dettagli di una pagina. Ma non possono dirigere come ChatGPT, Perplexity, Google o un'altra piattaforma seleziona o presenta le informazioni. La documentazione di Google descrive i dati strutturati come un modo per aiutarlo a comprendere i contenuti e valutare l'idoneità per le apparenze di ricerca supportate. Se un'apparenza viene mostrata rimane una decisione di Google. Nessun tipo di schema può promettere una citazione o una risposta particolare.
Questo confine dà al tuo team un utile test di qualità. Verifica se la pagina risponde a un reale bisogno del lettore, se le sue affermazioni sono supportate e se il markup riflette il testo visibile. Se i dati sono validi ma la pagina è vaga, migliora la pagina prima di aggiungere più proprietà. Se una descrizione del progetto cambia, aggiorna la pagina e poi rivedi il record correlato.
Tieni note su cosa hai cambiato e perché. In questo modo, la prossima persona può capire se un campo rappresenta un dettaglio reale della pagina o una vecchia supposizione. Quando confronti ciò che ChatGPT e Perplexity mostrano, registra ciò che ogni piattaforma visualizza effettivamente. Non trattare il markup come la causa di una menzione o omissione. La nostra guida alla visibilità AI search copre il quadro editoriale più ampio.
Mantieni un piccolo registro che il tuo team possa rivisitare
Un registro di revisione compatto aiuta il team a tenere separati i fatti della pagina, i controlli del markup e le osservazioni sulla visibilità. Rende anche meno probabile che il prossimo aggiornamento dei contenuti lasci indietro vecchi dettagli.
Per ogni URL prioritario, annota il tipo previsto, l'indirizzo canonico, l'ultima revisione e lo stato di validazione. Aggiungi una breve nota quando la pagina cambia in un modo che potrebbe influenzare i suoi dati strutturati. Poi tieni le osservazioni sulla piattaforma in un posto separato: registra la domanda controllata, la piattaforma, la data del controllo e ciò che ha mostrato. Queste note descrivono ciò che il tuo team ha visto; non stabiliscono perché una piattaforma ha scelto una fonte particolare.
Usa un piccolo set di domande che i visitatori reali potrebbero fare sul progetto. Ripetile quando rivedi la pagina e confronta la risposta con ciò che la pagina pubblicata dice. Se una risposta manca di un dettaglio importante, ispeziona la formulazione e le informazioni sulla fonte prima di modificare lo schema. Questo mantiene il lavoro ancorato a contenuti che le persone possono verificare.
Se desideri una revisione tecnica più ampia, llms.txt e setup AI crawler spiega una parte separata di quel lavoro. Per iniziare la tua revisione, raccogli alcuni URL prioritari, le domande che il tuo pubblico fa e qualsiasi export di schema esistente. Possiamo aiutare a controllare la corrispondenza pagina-markup e restituire correzioni chiare per il tuo team.
Come funziona
- Elenca le pagine prioritarieRegistra lo scopo di ogni URL, l'entità principale e l'indirizzo canonico.
- Seleziona i tipi di paginaScegli tipi che descrivano lo scopo visibile di ogni pagina.
- Traccia i fattiCollega ogni proprietà a un contenuto visibile o a una fonte affidabile del progetto.
- Aggiungi e controlla JSON-LDPosizionalo sulla pagina che descrive, testane la sintassi e confronta i suoi fatti con la pagina renderizzata.
- Rivisita dopo le modificheRicontrolla il markup quando cambiano i contenuti della pagina correlata o i dettagli del progetto.
Domande frequenti
Il markup schema può aiutare ChatGPT o Perplexity a menzionare un progetto?
Schema può descrivere i dettagli della pagina in modo strutturato, ma ChatGPT e Perplexity decidono cosa mostrare e citare. Verifica che la pagina risponda a una chiara domanda del lettore e che i fatti marcati corrispondano al testo visibile. Quando rivedi un risultato, salva la domanda e la piattaforma in modo che il tuo team possa ripetere l'osservazione.
Con quali tipi di schema dovrebbe iniziare un sito web di progetto?
Inizia con le pagine che hai e ciò che ognuna dice effettivamente. Organization può descrivere il progetto, mentre WebSite e WebPage descrivono il sito e un singolo URL. Article, Product o SoftwareApplication possono adattarsi a pagine specifiche quando i loro dettagli visibili supportano quei tipi.
Ho bisogno sia di llms.txt che del markup schema.org?
Non necessariamente. Schema.org descrive i contenuti e le entità della pagina in dati strutturati; llms.txt è una convenzione di file di testo proposta per indicare risorse selezionate del sito. Decidi se ciascuno aiuta per un'esigenza separata e mantieni aggiornate le informazioni solo se il tuo team può mantenerle.
Come posso controllare un esempio JSON-LD rispetto alla mia pagina?
Verifica che la sintassi sia valida, che il tipo si adatti alla pagina e che ogni proprietà abbia supporto visibile o affidabile. Confronta nomi, URL e descrizioni con la pagina renderizzata prima della pubblicazione. Un secondo revisore può confermare dettagli come la paternità o le informazioni sul prodotto quando quei fatti non sono ovvi.
Ogni pagina con domande dovrebbe usare il markup FAQPage?
No. Usa un tipo solo quando descrive accuratamente la pagina e segue i requisiti documentati della piattaforma pertinente. Una pagina può comunque rispondere a domande comuni in modo chiaro senza markup FAQPage. Il controllo chiave è se i visitatori possono trovare le risposte rappresentate nei dati.
Con quale frequenza il nostro team dovrebbe rivisitare il markup schema?
Rivedilo quando la pagina o i dettagli che descrive cambiano. Ad esempio, una descrizione del prodotto rivista o un nome dell'organizzazione dovrebbero richiedere un controllo del record correlato. Tenere URL, tipo previsto e ultima revisione in una breve nota rende quel controllo più facile da ripetere.
Parlaci del tuo progetto
Rispondi a quattro domande rapide e un manager ti invierà un piano, i tempi e una fascia di prezzo entro un'ora. Tutto rimane riservato.
Caricamento del modulo…