Contenuti Frontmatter: Campi e Metadati SEO

Il frontmatter è l’elemento della pagina che i lettori non vedono mai come blocco unico, ma da cui ogni sistema di pubblicazione dipende. Dà a un documento un’identità, un contratto di rendering, un’anteprima di ricerca, una registrazione di proprietà, le date e gli input per lo schema. Un frontmatter danneggiato può selezionare il template sbagliato, creare conflitti canonici, perdere l’autore o emettere markup che contraddice la pagina.

L’esemplare dal vivo è un record a livello di documento, mostrato come codice perché il frontmatter non deve diventare un riquadro decorativo nel corpo.

+++
entity = "guide-how-to"
id = "reset-api-key"
title = "How to Reset an API Key"
seoTitle = "How to Reset an API Key Safely"
description = "Reset an API key safely, replace it in every dependent service, verify the new credential, and revoke the exposed key without avoidable downtime."
url = "/academy/reset-an-api-key/"
image = "/images/academy/reset-api-key.png"
imageAlt = "API key settings with the Rotate key action highlighted"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "reset API key", "rotate API key", "revoke API key" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/reset-an-api-key/"

[[faq]]
question = "Does rotating an API key revoke the old key immediately?"
answer = "Not necessarily. Confirm the provider's rotation behavior before changing dependent services."
+++

Perché esiste il frontmatter

Per un lettore, i metadati riducono l’incertezza. Un titolo preciso definisce l’ambito, una descrizione utile guadagna il clic, le identità rendono le affermazioni verificabili e le date rivelano se le informazioni potrebbero essere invecchiate. Questi segnali non possono compensare contenuti deboli, ma la loro assenza costringe il lettore a fare supposizioni.

Per le macchine, il frontmatter sostituisce l’inferenza con valori nominati. I template mappano i campi ai titoli del browser, ai link canonici, ai record delle persone, alle date, ai feed, agli indici e al JSON-LD senza dover analizzare la prosa. Questa è estraibilità meccanica: i fatti importanti hanno una posizione e un tipo coerenti.

Segui le regole di scrittura degli elementi: i metadati appartengono al livello del documento; gli elementi destinati al lettore appartengono al corpo. Una firma può essere renderizzata dal frontmatter, ma il suo identificatore autorevole rimane lì.

Quando usarlo — e quando no

Ogni pagina indicizzabile necessita di un record di frontmatter per identità, rendering e instradamento. Le bozze ne hanno bisogno quando entrano in produzione, così la validazione può fallire presto.

Non nascondere i fatti dell’articolo nel frontmatter. Limitazioni di prodotto, avvertenze di sicurezza, dichiarazioni di affiliazione, metodi e fonti devono rimanere visibili dove i lettori possono valutarli. Un valore strutturato non sostituisce mai una divulgazione.

I casi limite causano i danni maggiori:

• Etichette di navigazione, testi promozionali e didascalie social che variano indipendentemente sono impostazioni di canale; non sovraccaricare title.
• I fatti organizzativi condivisi su tutto il sito appartengono al record organizzativo del sito, non copiati in ogni pagina dove si discosteranno.
• Una sezione di domande e risposte appartiene a [[faq]] solo quando lo stesso contenuto viene visualizzato. Un FAQ nascosto solo per lo schema non è valido.
• Un’etichetta tematica appartiene a taxonomy; non deve sostituire entity che identifica il tipo di post del documento.
• Un reindirizzamento appartiene alla configurazione di instradamento o a un campo alias approvato. canonical identifica la versione preferita; non reindirizza i visitatori.

Dove posizionarlo

Il frontmatter inizia al primo byte con +++ e termina al delimitatore corrispondente prima del corpo. Nessun titolo, commento, nota, shortcode o blocco di metadati può precederlo. I campi e gli array TOML appartengono all’interno di quel singolo record.

Il corpo inizia dopo il delimitatore di chiusura. Il frontmatter non può trovarsi tra l’H1 e l’introduzione, accanto a uno screenshot, all’interno di un componente o alla fine. Un byte order mark o un commento fuori posto possono impedirne il riconoscimento. Chiavi duplicate, delimitatori YAML e secondi blocchi non sono validi.

Anatomia

La legenda renderizzata rimane nella pagina in modo che sia leggibile e traducibile indipendentemente dall’immagine:

1. Confine: i delimitatori di apertura e chiusura +++ definiscono l’unica regione di metadati.
2. Identità: entity, id, type e url dicono ai sistemi cos’è il documento e dove si trova.
3. Scoperta: title, seoTitle, description, image, imageAlt e keywords supportano le anteprime e il recupero.
4. Provenienza: date, updated, author e reviewedBy indicano chi è responsabile e quando il lavoro è stato validamente modificato.
5. Classificazione: taxonomy collega la pagina a raccolte tematiche controllate senza ridefinirne l’identità.
6. Controllo duplicati: canonical nomina l’URL pubblico preferito quando versioni equivalenti sono raggiungibili altrove.
7. Raccolte strutturate: ogni [[faq]] crea un record tipizzato di domanda e risposta per il rendering visibile e lo schema.

Esempi di design

Il frontmatter ha varianti di contratto dati, non stili visivi. Gli screenshot abbinano i record sorgente con la relativa anteprima o firma risultante.

Parametri

Questi sono limiti editoriali anche quando un parser accetta di più. “Condizionale” significa obbligatorio quando la sua condizione dichiarata è vera.

Riferimento per campo

Questo riferimento definisce il contratto di pubblicazione per ogni campo. “Obbligatorio” significa che la validazione dovrebbe bloccare la pubblicazione quando il campo o la sua derivazione valida è assente. “Condizionale” significa che il requisito è attivato da un fatto dichiarato, come la visualizzazione di un’immagine o lo svolgimento di una revisione indipendente. Un default è sicuro solo quando produce lo stesso significato che un editor avrebbe scelto deliberatamente.

Identità e instradamento

title, h1 e seoTitle

• Scopo — title dà al documento il suo nome editoriale duraturo. h1 controlla l’intestazione principale sulla pagina quando il contesto del layout richiede una formulazione diversa. seoTitle controlla il titolo del browser/ricerca quando il default necessita di un qualificatore conciso o di un trattamento del marchio. Separarli impedisce che un’etichetta di navigazione, un’intestazione di pagina e un’anteprima di ricerca siano forzati in un’unica stringa scomoda.
• Tipo e formato — Ciascuno è una stringa di testo semplice. title è il valore sorgente; le sostituzioni assenti devono ricadere su di esso. HTML, Markdown, decorazioni con emoji e marcature di troncamento manuale non sono valori validi.
• Obbligatorio? — title è obbligatorio su ogni pagina pubblica. h1 e seoTitle sono opzionali e dovrebbero essere omessi quando title funziona in tutti e tre i contesti.
• Limiti — Usa 30–70 caratteri per title, 20–80 per h1 e 30–60 per seoTitle come bande editoriali, non come promessa che un’interfaccia di ricerca visualizzerà ogni carattere. Deve esserci un H1 renderizzato.
• Chi o cosa lo consuma — Template di pagina, titoli del browser, adattatori di ricerca e social, card di navigazione, feed, headline dello schema, outline di accessibilità ed elenchi editoriali.
• Regole — Tutte le versioni devono identificare lo stesso soggetto, intento e ambito. Una differenza legittima risolve un vincolo di canale: ad esempio, l’H1 può dire “Come Ruotare una Chiave API Senza Downtime”, mentre il titolo SEO più breve dice “Rotazione Chiave API: Guida Sicura Passo dopo Passo”. La successiva sezione Titolo, H1 e titolo SEO spiega il test editoriale.
• Errori comuni — Ripetere una parola chiave in tutte e tre le varianti, mettere un suffisso del marchio nell’H1, cambiare la promessa per inseguire i clic, incorporare l’anno corrente quando la pagina non è mantenuta annualmente, o creare tre valori semplicemente perché esistono tre campi.

slug e url

• Scopo — Lo slug è il segmento finale del percorso; url è il percorso pubblico relativo al sito che lo contiene. Insieme danno alla pagina un indirizzo stabile per lettori, crawler, link, report e migrazioni. La stabilità è importante perché ogni link guadagnato e ogni segnalibro salvato diventa dipendente da quell’indirizzo.
• Tipo e formato — Usa una stringa di percorso in minuscolo separata da trattini, come /academy/rotate-an-api-key/. Questo repository registra il percorso completo in url; un CMS che ha un campo slug separato deve derivare lo stesso segmento finale.
• Obbligatorio? — Un percorso unico è obbligatorio per ogni pagina pubblica. Può essere generato solo dove una sezione ha una regola deterministica approvata e controlli di collisione; le pagine del playbook usano i loro valori url registrati.
• Limiti — Preferisci uno slug breve e leggibile che preservi il soggetto distintivo, di solito da tre a otto parole utili. Rimuovi punteggiatura e modificatori vuoti. Rimuovi stop word come “il”, “la”, “un”, “una” solo quando il risultato rimane naturale e non ambiguo; non esiste un limite arbitrario di caratteri che giustifichi danneggiare il significato.
• Chi o cosa lo consuma — Instradamento Hugo, link interni, breadcrumb, generazione canonica, sitemap, feed, analisi, reindirizzamenti e riferimenti esterni.
• Regole — Tratta uno slug pubblicato come un impegno permanente. Decidilo in base all’argomento duraturo, non a un titolo di campagna o a un anno transitorio. Quando il titolo cambia ma l’argomento e l’intento no, mantieni il vecchio slug. Se la pagina si sposta davvero, crea il nuovo percorso, mantieni il vecchio percorso in aliases, aggiorna i link interni e testa la destinazione del reindirizzamento.
• Errori comuni — Rigenerare lo slug ogni volta che il titolo cambia, infilare sinonimi nel percorso, mantenere date che fanno sembrare obsoleti i contenuti evergreen, usare maiuscole miste o trattini bassi, creare due URL che differiscono solo per una barra finale e cambiare un percorso senza preservare quello vecchio.

canonical

• Scopo — Un canonical identifica l’URL preferito tra versioni equivalenti o quasi equivalenti accessibili. Consolida l’identità; non sposta un visitatore né giustifica duplicazioni incontrollate.
• Tipo e formato — Un URL HTTPS assoluto, inclusi l’host previsto e il percorso normalizzato: https://amicited.com/academy/rotate-an-api-key/. Il template può derivare un auto-riferimento dal permalink della pagina quando il sito ha un host e una policy di percorso affidabili.
• Obbligatorio? — Ogni pagina indicizzabile deve emettere un canonical. Il campo stesso è condizionale quando un valore corretto di auto-riferimento viene derivato automaticamente; impostalo esplicitamente per un canonical cross-dominio o eccezionale approvato.
• Limiti — Esattamente un target canonical. Il target deve restituire un documento indicizzabile di successo, usare il protocollo e l’host preferiti e rappresentare sostanzialmente lo stesso contenuto.
• Chi o cosa lo consuma — Il <link rel="canonical"> HTML, i motori di ricerca, i controlli di sitemap e link interni, i report di deduplicazione e gli identificatori URL dello schema.
• Regole — Auto-riferimento per default. Usa un canonical cross-dominio solo quando un altro editore possiede l’equivalente preferito ed entrambe le parti intendono il consolidamento. Usa un reindirizzamento, non un canonical, quando il vecchio URL è stato sostituito e gli utenti devono sempre atterrare su quello nuovo. Mantieni allineati canonical, URL sitemap, hreflang, link interni e identità dello schema.
• Errori comuni — Puntare ogni pagina impaginata o localizzata a un genitore generico, canonicalizzare contenuti distinti, puntare a una pagina di reindirizzamento o di errore, mescolare HTTP e HTTPS, usare il campo come sostituto di un alias e presumere che le direttive canonical siano garantite per essere rispettate.

aliases

• Scopo — aliases preserva i percorsi che in precedenza identificavano la stessa pagina, così uno spostamento non trasforma link e segnalibri esistenti in vicoli ciechi. Registra la cronologia del percorso piuttosto che creare identità indicizzabili alternative.
• Tipo e formato — Un array TOML di percorsi relativi al sito, ad esempio aliases = [ "/blog/old-api-key-guide/" ]. Ogni valore include una barra iniziale e finale e deve essere unico in tutto il sito.
• Obbligatorio? — Opzionale per una pagina nuova; obbligatorio quando una pagina pubblicata si sposta da un percorso che il sito controllava.
• Limiti — Includi ogni ex percorso di prima parte noto che riceve ancora link o traffico. Non aggiungere varianti ortografiche speculative o un elenco illimitato di URL con parole chiave.
• Chi o cosa lo consuma — L’output alias di Hugo, l’elaborazione dei reindirizzamenti di deployment dove configurata, QA delle migrazioni, monitor dei link e utenti che seguono vecchi URL. Poiché Hugo può emettere una pagina alias piuttosto che un reindirizzamento HTTP a livello di origine, il comportamento di deployment deve essere verificato invece di essere presunto.
• Regole — Una pagina spostata mantiene funzionante il suo vecchio percorso. Ogni alias deve risolversi in un salto verso il percorso canonico corrente. Aggiorna i link interni al nuovo URL anche quando l’alias funziona e preserva l’alias attraverso modifiche successive a meno che un sistema di reindirizzamento documentato lo sostituisca.
• Errori comuni — Eliminare la vecchia pagina senza un alias, concatenare vecchio percorso a percorso intermedio a percorso corrente, trattare gli alias come percorsi di pubblicazione duplicati, puntare diverse pagine non correlate a una destinazione conveniente o presumere che l’output Hugo locale dimostri lo stato HTTP di produzione.

type e layout

• Scopo — Questi campi selezionano il contratto di rendering. type colloca una pagina in una classe di contenuti con template e comportamenti condivisi; layout richiede un template specifico all’interno di quella classe. Una selezione corretta assicura che la pagina riceva la navigazione, lo slot di contenuto, gli asset e il comportamento dello schema previsti.
• Tipo e formato — Stringhe registrate in minuscolo. Questa pagina usa type = "academy". Un valore layout è un nome base di template come single, senza estensione di file o traversal di percorso.
• Obbligatorio? — type è obbligatorio quando la posizione del contenuto non implica in modo sicuro il tipo previsto o quando il contratto del playbook lo impone. layout è opzionale e dovrebbe essere omesso quando il template predefinito del tipo è corretto.
• Limiti — Un valore per ogni campo, scelto solo tra i template mantenuti dal sito. Un nuovo valore è una modifica ingegneristica, non un’improvvisazione editoriale.
• Chi o cosa lo consuma — L’ordine di ricerca di Hugo, template, selezione parziale, inclusione CSS e JavaScript, adattatori schema e regole di validazione.
• Regole — Scegli il tipo di post e il contratto di rendering prima di scrivere. Usa layout solo per una variante genuinamente supportata; non usarlo per compensare contenuti che appartengono a un altro type. Verifica che una sostituzione esista e accetti la forma del frontmatter della pagina.
• Errori comuni — Confondere l’entity editoriale con il type di Hugo, nominare un file template che non esiste, copiare un tipo di landing page su un documento academy, fare affidamento sull’inferenza di cartella durante una migrazione e introdurre nomi di layout una tantum che bypassano i miglioramenti condivisi.

Scoperta

description

• Scopo — La descrizione aiuta un cercatore qualificato o un destinatario di condivisione a decidere se questa pagina risponde all’esigenza. È testo di anteprima, non un’introduzione compressa e non un luogo per dimostrare rilevanza attraverso la ripetizione.
• Tipo e formato — Una frase in testo semplice. Dovrebbe nominare il termine principale in modo naturale, indicare il valore concreto e aggiungere ambito, pubblico, metodo o risultato utili.
• Obbligatorio? — Obbligatorio per ogni pagina indicizzabile in questo playbook.
• Limiti — 150–160 caratteri, inclusi gli spazi. Questa è una banda di coerenza editoriale, non una garanzia di visualizzazione: i motori di ricerca possono troncarla o riscrivere lo snippet dal corpo del testo quando un altro passaggio si adatta meglio alla query.
• Chi o cosa lo consuma — Tag meta description, descrizioni predefinite Open Graph e Twitter, card di elenco, feed, anteprime CMS, controlli di qualità della ricerca e talvolta description dello schema.
• Regole — Scrivi per un clic dal lettore giusto. Rendi la frase abbastanza specifica da distinguere la pagina da un altro risultato con un titolo simile. La sezione Regole della descrizione più avanti fornisce la logica e i test di rifiuto.
• Errori comuni — Duplicare il titolo, elencare parole chiave, iniziare con “Scopri tutto su”, fare un’affermazione non supportata di migliore o più veloce, usare un vago invito all’azione, superare la banda attraverso un suffisso del marchio non visibile o presumere che il testo scritto debba apparire verbatim nei risultati di ricerca.

keywords

• Scopo — In questo repository, keywords registra l’insieme compatto di query e terminologia usato per QA editoriale, ricerca nel corpus, analisi di copertura e strumenti interni. Aiuta gli editor a riconoscere il linguaggio che una pagina deve usare accuratamente; non è una promessa di includere ogni frase meccanicamente.
• Tipo e formato — Un array di stringhe in linguaggio naturale, ordinato dal termine principale attraverso varianti significative e terminologia strettamente correlata.
• Obbligatorio? — Obbligatorio secondo questo playbook, incluse le pagine i cui template pubblici non visualizzano i valori.
• Limiti — Da sei a otto voci distinte. Ogni voce deve rappresentare una frase di query reale o un termine necessario, non una variazione a livello di token.
• Chi o cosa lo consuma — Validatori editoriali, inventari di contenuti, analisi di ricerca e opportunità, recupero interno e strumenti di migrazione. I motori di ricerca pubblici non usano questo campo come segnale di ranking solo perché esiste.
• Regole — Mantieni l’insieme focalizzato sull’ambito di una singola pagina. Unisci maiuscole/minuscole, punteggiatura, singolare/plurale e duplicati banali di ordine delle parole. Usa le frasi per verificare la copertura e la terminologia, mai per dettare una densità innaturale.
• Errori comuni — Trattare il campo come il meccanismo di ranking obsoleto delle meta-keywords, aggiungere dozzine di varianti, ripetere il titolo come otto quasi-duplicati, inserire nomi di concorrenti che il corpo non discute e permettere all’array di sostituire una tassonomia o target di prompt appropriati.

targetPrompts

• Scopo — targetPrompts registra le domande o richieste complete che una persona può dare a un sistema di risposta AI e per le quali questa pagina dovrebbe essere una fonte utile. I target di prompt preservano il contesto conversazionale che le brevi frasi di parole chiave omettono.
• Tipo e formato — Un array di stringhe complete in linguaggio naturale, ad esempio targetPrompts = [ "Come faccio a ruotare una chiave API senza downtime?", "Cosa dovrei controllare prima di revocare una vecchia chiave API?" ]. Mantieni la formulazione come un utente la chiederebbe, incluso pubblico, vincoli o confronto desiderato.
• Obbligatorio? — Condizionale per pagine incluse nel tracciamento dei prompt o in un programma di visibilità AI; opzionale quando non esiste un insieme di prompt tracciati.
• Limiti — Usa un insieme piccolo e intenzionale, normalmente un prompt principale e fino a quattro varianti significative. Un prompt può essere più lungo di una parola chiave perché i suoi qualificatori portano l’intento.
• Chi o cosa lo consuma — Brief dei contenuti, flussi di lavoro di tracciamento dei prompt, audit di recupero e copertura, monitoraggio delle risposte AI e valutazione editoriale. Non viene renderizzato come testo di ricerca nascosto.
• Regole — Separa i prompt per effettiva necessità informativa, non per punteggiatura. Una parola chiave come “rotazione chiave API” nomina un argomento; “Come può un team SaaS ruotare una chiave API senza interrompere le integrazioni?” nomina un pubblico, un compito e un vincolo. La pagina deve rispondere onestamente a ogni prompt memorizzato.
• Errori comuni — Copiare l’array delle parole chiave in questo campo, inventare dozzine di varianti sintattiche, registrare prompt più ampi della pagina, usare i prompt come intestazioni del corpo indipendentemente dal flusso di lettura e affermare una copertura dei prompt quando la risposta dipende da informazioni che la pagina non fornisce.

Fiducia e provenienza

date e updated

• Scopo — date preserva quando la pagina è stata pubblicata per la prima volta; updated riporta l’ultima modifica sostanziale o revisione completata. Due campi preservano la cronologia mostrando al contempo se le informazioni su cui i lettori fanno affidamento sono cambiate.
• Tipo e formato — Stringhe timestamp nella convenzione del sito, YYYY-MM-DD HH:MM:SS. Mantieni una policy di fuso orario uniforme in tutto il corpus così che feed e confronti rimangano deterministici.
• Obbligatorio? — date è obbligatorio per le pagine editoriali pubblicate. updated è opzionale fino a quando non si verifica una modifica qualificante, poi obbligatorio se la pagina presenta una data modificata.
• Limiti — Un valore ciascuno. updated non può precedere date né essere nel futuro. Una correzione fatta minuti dopo la pubblicazione può ancora essere documentata, ma le revisioni di routine delle bozze prima della pubblicazione non creano una data di aggiornamento.
• Chi o cosa lo consuma — Firme visibili e indicatori di freschezza, feed, sitemap, schema datePublished e dateModified, audit di recenza, ordinamento e code editoriali.
• Regole — Reimposta updated per una correzione fattuale, un’istruzione cambiata, evidenze nuove o rimosse, ambito rivisto, raccomandazione materialmente cambiata o una revisione documentata di affermazioni sensibili al tempo. Non reimpostarlo mai per punteggiatura, formattazione, lavoro su template o una modifica solo del timestamp. Vedi Date, autori e revisori per la logica della policy.
• Errori comuni — Sovrascrivere la data originale durante un aggiornamento, datare una pagina nel futuro per sembrare fresca, aumentare le date senza un diff dei contenuti, trattare un deploy automatico come un aggiornamento editoriale e non registrare cosa è cambiato nella cronologia degli aggiornamenti mantenuta.

author

• Scopo — author collega il documento all’entità persona responsabile del suo lavoro. Il collegamento dà a un lettore e a una macchina un percorso da una pagina che contiene affermazioni a un’identità, competenza e altri lavori mantenuti.
• Tipo e formato — Un identificatore stabile dell’autore che si risolve attraverso il registro autori del sito in un URL di profilo e un record Person. Ad esempio, author = "maya-chen" è valido solo se quell’identificatore si risolve; un nome visualizzato come "Maya Chen, Esperta SEO" non è un sostituto del collegamento all’entità.
• Obbligatorio? — Obbligatorio per pagine editoriali sostanziali. Le pagine transazionali possono usare un proprietario organizzativo governato solo quando il template e la policy supportano quel tipo di entità.
• Limiti — Un responsabile principale per default; usa un array documentato di identificatori solo quando lo schema e i template della firma supportano una reale co-autorialità.
• Chi o cosa lo consuma — Firme visibili, link al profilo dell’autore, schema Article, feed, report di proprietà editoriale, flussi di lavoro di revisione e grafi di entità.
• Regole — Risolvi l’identificatore prima della pubblicazione. Il profilo deve identificare la stessa persona mostrata nella firma e rimanere mantenuto. Accredita la persona responsabile del contenuto, non la persona che lo ha semplicemente caricato.
• Errori comuni — Inserire una stringa di nome non collegata, usare “Admin” o un team editoriale inventato, assegnare un dirigente importante che non ha scritto il lavoro, permettere a un identificatore di risolversi in nessun profilo e cambiare la paternità per implicare competenza che non è stata coinvolta.

reviewedBy, reviewedAt e reviewScope

• Scopo — Questi campi registrano una revisione indipendente distinta dalla paternità. reviewedBy identifica l’entità revisore; reviewedAt indica quando la revisione è stata completata; reviewScope dice cosa ha controllato il revisore, così il badge non implica approvazione oltre le evidenze.
• Tipo e formato — reviewedBy è un identificatore stabile che si risolve in un profilo persona mantenuto. reviewedAt usa il formato timestamp del sito. reviewScope è una dichiarazione concisa in testo semplice come “Passaggi di rotazione delle credenziali e avvertenze di sicurezza.”
• Obbligatorio? — Condizionale quando legge, policy di rischio, sensibilità dell’argomento o la specifica del tipo di post richiede una revisione indipendente. Quando reviewedBy è presente, la data e l’ambito della revisione sono obbligatori come dati del record di revisione, anche se un template particolare li memorizza in un record editoriale collegato piuttosto che nel frontmatter pubblico.
• Limiti — Nomina solo revisori reali. L’ambito dovrebbe essere abbastanza specifico da rivelare le esclusioni senza diventare un rapporto di revisione. Un revisore deve avere competenza pertinente e non deve semplicemente duplicare il ruolo dell’autore.
• Chi o cosa lo consuma — Componenti “revisionato da”, join di entità persona, audit di governance, cancelli di pubblicazione ad alto rischio, provenienza strutturata e log di aggiornamento.
• Regole — Completa la revisione dopo che il contenuto è stabile, cattura risultati e risoluzione nella cronologia editoriale e riesamina quando modifiche successive influenzano l’ambito revisionato. Indipendente significa che il revisore verifica il lavoro piuttosto che approvare la propria bozza.
• Errori comuni — Trattare la correzione di bozze come revisione esperta, mostrare un revisore senza data o ambito, nominare qualcuno che non ha mai visto la versione finale, lasciare il badge dopo una riscrittura sostanziale non revisionata e implicare approvazione legale, medica o tecnica al di fuori dell’ambito dichiarato.

Media e social

image e imageAlt

• Scopo — image seleziona l’asset hero e social rappresentativo; imageAlt fornisce l’alternativa testuale funzionale quando quell’asset viene renderizzato come contenuto di pagina significativo. Mantenere la coppia insieme impedisce che le immagini di scoperta diventino un’omissione di accessibilità.
• Tipo e formato — image è un percorso di sito risolvibile o un URL assoluto approvato. imageAlt è testo semplice che descrive l’informazione utile dell’immagine nel suo contesto di pagina, non il suo nome file o la parola chiave target.
• Obbligatorio? — Condizionale per tipo di post e template. Se la pagina richiede un hero o un’immagine social dedicata, image è obbligatorio. imageAlt è obbligatorio ogni volta che quell’immagine viene visualizzata in modo informativo; un rendering puramente decorativo deve usare un attributo alt vuoto nel template, non testo descrittivo inventato.
• Limiti — Usa un asset rappresentativo. Per compatibilità social, fornisci una fonte di 1200 × 630 pixel nel rapporto di ritaglio previsto, mantieni i contenuti importanti lontani dai bordi e mantieni imageAlt conciso — normalmente 5–160 caratteri. Il file deve esistere prima di essere referenziato.
• Chi o cosa lo consuma — Componenti hero, card di elenco, tag Open Graph e Twitter, campi immagine dello schema, feed, pipeline di immagini, lettori di schermo quando visibile e QA degli asset.
• Regole — Scegli un’immagine che comunichi ancora dopo un ritaglio centrale e a dimensione miniatura. Descrivi la sua funzione nel contesto: “Impostazioni chiave API con Rotate key evidenziato” è utile; “Chiave API” non lo è. Non inserire affermazioni essenziali solo all’interno dei pixel.
• Errori comuni — Riferire un asset pianificato che non esiste, usare un logo come immagine di ogni articolo, incorporare testo piccolo che diventa illeggibile nelle condivisioni, scrivere “immagine di,” infilare parole chiave nel testo alternativo e presumere che il testo alternativo social e il comportamento del testo alternativo dell’immagine visibile siano identici su tutte le piattaforme.

Campi Open Graph e Twitter card

• Scopo — I metadati social controllano come un URL viene riassunto quando condiviso. Un titolo, descrizione, URL, tipo e immagine coerenti aiutano i destinatari a riconoscere la pagina prima di cliccare e riducono la probabilità che una piattaforma selezioni un asset irrilevante.
• Tipo e formato — In questo repository, i template derivano og:title e twitter:title da title, le descrizioni da description, gli URL dal permalink, og:type dal contesto del layout e entrambi i tag immagine da image con un fallback del sito. twitter:card viene emesso come summary_large_image. Questi sono tag generati, non campi di frontmatter duplicati per default.
• Obbligatorio? — I tag di output sono obbligatori sulle pagine pubbliche. Sostituzioni separate sono opzionali e dovrebbero essere introdotte solo attraverso un contratto di template documentato; campi ad hoc non supportati come ogTitle non fanno nulla.
• Limiti — Un’anteprima coerente per pagina e un’immagine rappresentativa di 1200 × 630. Mantieni la formulazione derivata entro le bande di titolo e descrizione, poi testa il comportamento effettivo di ritaglio e sovrapposizione sulle principali superfici di condivisione.
• Chi o cosa lo consuma — Social network, client di messaggistica, unfurler di link, estensioni del browser, strumenti di collaborazione e debugger di anteprime di condivisione.
• Regole — Preferisci la derivazione così le affermazioni di ricerca e social rimangono allineate. Sostituisci solo quando il contesto social necessita genuinamente di una cornice diversa e il template la supporta. Un’immagine sbagliata costa riconoscimento e fiducia: il destinatario può vedere un’interfaccia obsoleta, un altro prodotto, un’affermazione fuorviante o un ritaglio che nasconde il soggetto.
• Errori comuni — Creare campi che nessun template legge, permettere a un fallback globale di mascherare un hero obbligatorio mancante, usare un’immagine verticale o minuscola per una card larga, cambiare il testo social per fare una promessa più forte della pagina e validare solo il sorgente HTML piuttosto che un’anteprima recuperata.

Classificazione

taxonomy, categories e tags

• Scopo — La classificazione collega una pagina a raccolte governate di argomento, formato, pubblico o prodotto. Alimenta archivi e filtri utili solo quando ogni vocabolario ha un significato dichiarato; altrimenti le etichette diventano un cumulo di sinonimi incontrollati.
• Tipo e formato — Array di slug registrati in minuscolo. Usa taxonomy per il vocabolario tematico controllato del repository. Usa categories solo per una piccola gerarchia editoriale mutualmente comprensibile e tags solo per un vocabolario trasversale governato quando quelle tassonomie sono configurate.
• Obbligatorio? — Condizionale in base al tipo di post e al design dell’archivio. Le pagine editoriali tematiche normalmente richiedono uno o più termini controllati; le pagine utilitarie possono non richiederne nessuno. Un campo non deve essere popolato solo perché un CMS lo espone.
• Limiti — Per la tassonomia generale, da uno a cinque valori per vocabolario controllato. Ogni termine necessita di una definizione, un proprietario e una regola di unione. Crea un archivio indicizzabile solo quando il termine rappresenta una domanda duratura dei lettori e l’archivio può offrire un’introduzione unica, un inventario coerente, link interni e manutenzione continua.
• Chi o cosa lo consuma — Pagine archivio, breadcrumb, filtri, sistemi di contenuti correlati, navigazione sfaccettata, audit di contenuti e segmentazione analitica.
• Regole — Scegli il termine registrato più specifico che raggruppa accuratamente la pagina. Mantieni singolare/plurale, abbreviazioni e varianti ortografiche mappate a un valore canonico. Decidi se gli archivi sono indicizzabili a livello di vocabolario, non tag per tag dopo una creazione accidentale.
• Errori comuni — Usare seo, SEO, search-optimization e search engine optimization come valori separati, aggiungere tag una tantum per descrivere ogni sostantivo, confondere un tipo di attività con un argomento, generare archivi indicizzabili di bassa qualità ed eliminare termini senza migrare i loro membri.

Chiavi di join del playbook

• Scopo — playbookPillar, playbookFamily, playbookWave, postTypes, elements, businessTypes, journeyStage e amicitedFeatures sono chiavi di join tipizzate. Permettono a una pagina sorgente di apparire in librerie e matrici generate senza che gli editor copino card a mano. Questa pagina è l’esempio pratico: il suo pilastro identifica un elemento, la sua famiglia raggruppa le linee guida sui metadati e il suo array postTypes dichiara le specifiche che la consumano.
• Tipo e formato — Le chiavi singolari usano slug registrati in minuscolo: playbookPillar e playbookFamily sono stringhe, playbookWave è un intero e journeyStage è una stringa controllata. Le chiavi di relazione — postTypes, elements, businessTypes e amicitedFeatures — sono array di slug registrati dai rispettivi registri.
• Obbligatorio? — playbookPillar e playbookWave sono obbligatori sui record del playbook. playbookFamily è obbligatorio dove il pilastro ha famiglie governate. Gli array di join e journeyStage sono condizionali: popola solo le relazioni che il contratto di pagina effettivamente supporta.
• Limiti — Un pilastro, una famiglia all’interno di quel pilastro, un’onda e una fase del percorso a meno che il modello non permetta esplicitamente più fasi. Gli array contengono chiavi registrate uniche, non etichette di visualizzazione, prosa o URL.
• Chi o cosa lo consuma — Elenchi hub del playbook, matrici tra pilastri, filtri, card di relazione, report di completezza, viste delle onde di rilascio e strumenti interni che trovano capacità AmICited pertinenti.
• Regole — Valida ogni valore rispetto al registro canonico. La direzione conta: una pagina di tipo di post elenca i suoi elements richiesti; una pagina elemento elenca i postTypes applicabili; una pagina di tipo di business elenca i tipi di post utili. Tratta le etichette come presentazione e le chiavi come dati duraturi. Rinomina una chiave solo attraverso una migrazione che aggiorni ogni lato del join.
• Errori comuni — Inventare quasi-sinonimi, memorizzare titoli invece di slug, mescolare interi e stringhe per le onde, aggiungere una relazione perché due pagine si menzionano a vicenda, permettere a array reciproci di contraddirsi e creare markup di elenco gestito manualmente che si discosta dai metadati.

Campi derivati e strutturali

schemaType

• Scopo — schemaType seleziona la mappatura di dati strutturati supportata più specifica che descrive accuratamente la pagina visibile. Dice all’adattatore dello schema quale contratto di vocabolario applicare; non trasforma la pagina in quella cosa per sola dichiarazione.
• Tipo e formato — Un nome di tipo Schema.org registrato come Article, selezionato tra i tipi supportati dall’adattatore del sito. Maiuscole/minuscole e ortografia devono corrispondere al registro.
• Obbligatorio? — Condizionale. Impostalo dove più mappature schema sono valide per lo stesso tipo Hugo o dove il contratto del tipo di post richiede un tipo esplicito. Altrimenti lascia che il template derivi il suo default sicuro.
• Limiti — Un tipo di pagina primario, con entità nidificate create dall’adattatore dal contenuto reale. Il tipo selezionato deve soddisfare tutte le proprietà richieste e corrispondere a ciò che un lettore può vedere.
• Chi o cosa lo consuma — Adattatori JSON-LD, validazione rich result, QA dei contenuti e report di inventario schema.
• Regole — Scegli in base alla funzione della pagina e alle evidenze visibili, non alla funzionalità di ricerca che un editor desidera. Una pagina di istruzioni senza una procedura visibile completa non può guadagnare accuratezza impostando un tipo how-to. Mantieni URL schema, date, persone e immagini sincronizzati con i loro campi sorgente.
• Errori comuni — Selezionare un tipo più specifico senza il suo contenuto richiesto, emettere diversi tipi primari in conflitto, copiare un valore schema da un template non correlato, presumere che la sintassi valida garantisca l’idoneità e inserire affermazioni in JSON-LD che i lettori non possono ispezionare.

Tempo di lettura

• Scopo — Il tempo di lettura dà al lettore una stima approssimativa dello sforzo. Viene derivato dal corpo finale renderizzabile così la stima cambia quando cambia il carico di lettura effettivo.
• Tipo e formato — Un numero intero calcolato di minuti prodotto dalla policy di conteggio parole del pipeline di contenuti. I blocchi di codice, le tabelle, le didascalie e i media incorporati dovrebbero seguire una regola di conteggio documentata.
• Obbligatorio? — La visualizzazione è opzionale per template. Un campo di frontmatter scritto dall’autore non è consentito come fonte di verità.
• Limiti — Arrotonda coerentemente e applica un minimo di visualizzazione sensato come un minuto. L’assunzione precisa di parole al minuto conta meno dell’usare lo stesso metodo in tutto il sito ed etichettare il risultato come stima.
• Chi o cosa lo consuma — Intestazioni di pagina, card, feed, segmentazione analitica e lettori che decidono se iniziare una guida lunga.
• Regole — Calcola dopo che shortcode e regioni escluse sono state gestite secondo la policy del sito. Ricalcola a ogni build. Se un video o un’attività interattiva cambia materialmente il tempo di completamento, etichettalo separatamente piuttosto che alterare il tempo di lettura.
• Errori comuni — Scrivere readingTime = 8, dimenticare di aggiornarlo dopo una riscrittura, presentare falsa precisione, contare navigazione e boilerplate e trattare un how-to ad alta intensità di esecuzione come otto minuti di lettura più nessun tempo di attività.

[[faq]]

• Scopo — [[faq]] memorizza coppie di domande e risposte visibili una volta sola così la pagina e qualsiasi dato strutturato FAQ idoneo non possono divergere.
• Tipo e formato — Un array TOML di tabelle; ogni elemento contiene una question in testo semplice e una answer stringa auto-contenuta.
• Obbligatorio? — Condizionale quando rimangono genuine domande di follow-up dopo la pagina principale. Non è mai obbligatorio solo per riempire un template o perseguire una funzionalità di ricerca.
• Limiti — Normalmente da quattro a otto elementi utili sulle pagine del playbook. Ogni domanda appare una volta e ogni risposta deve essere completa senza fare affidamento sull’ordine dell’accordion.
• Chi o cosa lo consuma — Renderizzazione FAQ visibile, schema FAQPage dove idoneo, navigazione della pagina, QA dei contenuti ed estrazione delle risposte.
• Regole — Questo è un contratto di riferimento incrociato: segui Perché le FAQ vivono nel frontmatter e le successive linee guida FAQ piuttosto che mantenere copie visibili e schema separate. Memorizza solo domande a cui ogni lettore può accedere sulla pagina.
• Errori comuni — Risposte nascoste solo per schema, intestazioni duplicate camuffate da domande, risposte promozionali, affermazioni non supportate, JSON-LD obsoleto e trattare l’idoneità ai risultati di ricerca come garantita.

[[lnks]]

• Scopo — [[lnks]] registra ogni link interno governato usato nel corpo, abbinando la sua ancora visibile a una destinazione e una descrizione mantenuta. Il record rende i link ispezionabili senza dover analizzare l’HTML renderizzato e supporta migrazione e QA.
• Tipo e formato — Un array TOML di tabelle con text, path e title. text è l’ancora visibile esatta, path è un URL relativo al sito con barra iniziale e finale e title è la descrizione della pagina di destinazione.
• Obbligatorio? — Obbligatorio per ogni link interno nel corpo governato da questa convenzione di contenuti. I deep link alle app e le fonti esterne seguono i propri record e non sono camuffati come voci [[lnks]].
• Limiti — Un record per occorrenza di link nel corpo quando la stessa ancora può puntare a destinazioni diverse; altrimenti i record duplicati esatti dovrebbero essere rimossi. La destinazione deve esistere o essere nel registro degli slug canonici approvati per il rilascio coordinato.
• Chi o cosa lo consuma — Validazione dei link interni, migrazione dei contenuti, analisi delle relazioni, generazione di titoli di link dove supportata e revisione editoriale.
• Regole — Abbina text all’ancora del corpo verbatim, inclusi maiuscole/minuscole e punteggiatura all’interno del link. Usa il percorso canonico relativo al sito. Scrivi title come descrizione accurata della destinazione, non come istruzioni per la pagina corrente. Aggiorna il record e il corpo insieme.
• Errori comuni — Usare un valore text più lungo dell’ancora effettiva, inventare uno slug non registrato, omettere una barra finale, registrare un vecchio percorso che reindirizza, descrivere la fonte invece della destinazione e lasciare un record dopo che il suo link nel corpo è stato rimosso.

Obbligatorio versus opzionale per tipo di post

La matrice applica i contratti sopra ai dodici tipi di post attualmente dichiarati da questo elemento. R significa obbligatorio, C significa condizionale secondo le regole del campo, D significa output obbligatorio che può essere derivato in modo sicuro e O significa opzionale. “Identità” include entity, id, title, type e il percorso stabile. “Scoperta” include description e keywords; i target di prompt rimangono condizionali per ogni riga. aliases è sempre condizionale a uno spostamento, mentre il tempo di lettura scritto non è mai obbligatorio.

“Revisore condizionale” non è un permesso per saltare la revisione dove l’accuratezza o il rischio commerciale lo richiedono. Le pagine miglior-X-e alternative richiedono una revisione indipendente perché le loro raccomandazioni possono influenzare materialmente una decisione e spesso cambiano quando prodotti, prezzi e idoneità cambiano. Per le altre righe, la policy di rischio, non il tempo disponibile di un editor, attiva il requisito. Allo stesso modo, un canonical marcato D è ancora obbligatorio nell’HTML renderizzato; solo l’input del frontmatter può essere omesso quando il template può generare il corretto auto-riferimento.

Validazione del frontmatter

La validazione dovrebbe rifiutare automaticamente i difetti deterministici e riservare il giudizio per questioni che dipendono dal significato, dalle evidenze o dalla competenza professionale. La divisione previene due fallimenti opposti: chiedere ai revisori di catturare sintassi che un parser può catturare perfettamente e fingere che una regola di conteggio caratteri possa decidere se un testo è onesto.

Esegui i controlli deterministici prima della revisione editoriale così il revisore vede un record coerente. Poi rivedi l’HTML renderizzato, non solo il frontmatter: un valore sorgente valido è ancora un difetto di produzione se il template selezionato lo ignora, lo mappa al tag sbagliato, nasconde la provenienza richiesta o genera un canonical che discorda con il percorso pubblico. La pubblicazione è completa solo quando sorgente, rendering e comportamento di destinazione concordano.

Il campo entity

entity risponde a “di quale tipo di post esatto questo documento è un’istanza?” Non risponde a “quale argomento tratta questa pagina?” Questa distinzione è importante perché due documenti possono affrontare lo stesso argomento svolgendo lavori diversi. Una voce di glossario definisce “diagnosi”; un articolo di blog può riportare un cambiamento nelle linee guida diagnostiche. Se entrambi usano entity = "diagnosis", i sistemi downstream non possono scegliere in modo affidabile il template giusto, le regole di validazione, il gruppo analitico o la migrazione.

Usa il prefisso di gruppo più lo slug del tipo di post per le varianti all’interno di una famiglia: guide-how-to, guide-ultimate, comparison-a-vs-b e comparison-alternatives-to-x. Usa il nome nudo per un tipo autonomo: product-page o case-study. Registra l’identificatore una volta, mantienilo stabile e non cambiarlo mai perché l’argomento o la query target cambia. Metti i concetti tematici in taxonomy e il linguaggio di query in keywords.

Titolo, H1 e titolo SEO

Questi valori possono differire per contesto ma devono descrivere la stessa pagina. title è il default duraturo. h1 è l’intestazione visibile e può essere più naturale nel contesto. seoTitle serve il browser e i risultati di ricerca e può aggiungere un differenziatore conciso, un anno legittimo o un suffisso del marchio.

Ad esempio, title = "API Key Rotation", h1 = "How to Rotate an API Key Without Downtime" e seoTitle = "API Key Rotation: Safe Step-by-Step Guide" sono allineati su un unico compito. “Free Security Tool” come titolo SEO sarebbe ingannevole perché cambia la promessa. Non creare differenze solo per inserire più parole chiave.

Regole della descrizione

La descrizione esiste per aiutare un lettore qualificato a decidere di cliccare. Mantienila entro 150–160 caratteri, includi il termine principale in modo naturale, indica il beneficio concreto della pagina e aggiungi un qualificatore significativo come pubblico, ambito o risultato. Scrivi una frase fluente, non un elenco di parole chiave.

Il termine conferma la pertinenza; la ripetizione non aggiunge valore. Non duplicare il titolo, usare “Scopri tutto su”, fare superlativi non supportati o terminare a metà pensiero. I sistemi di ricerca possono comunque selezionare un testo visibile diverso per una query.

Date, autori e revisori

date preserva il timestamp della prima pubblicazione. updated registra l’ultima modifica sostanziale: una correzione fattuale, nuove evidenze, istruzioni cambiate, ambito rivisto, raccomandazione alterata o revisione completa che conferma le affermazioni sensibili al tempo. Registra cosa è cambiato nella cronologia editoriale quando la policy lo richiede.

Correggere la punteggiatura, cambiare lo stile di un pulsante, ricostruire un template o toccare solo il timestamp non reimposta updated. Avanzare una data senza lavoro dietro è una violazione della policy perché dice a lettori e macchine che il contenuto è stato aggiornato quando non lo è. È una falsa rappresentazione, non una tattica di crescita.

I campi di autore e revisore portano identità responsabili nelle firme e nei dati strutturati. L’autore è responsabile del lavoro. Usa reviewedBy solo quando è avvenuta una revisione qualificata e collega entrambi gli identificatori a profili mantenuti. La pagina dei fondamenti della fiducia spiega come paternità, date, evidenze e chiarezza delle entità supportino la fiducia senza garantire posizionamenti.

Perché le FAQ vivono nel frontmatter

Una FAQ è contenuto visibile e una raccolta strutturata. Memorizzarla una volta in [[faq]] permette al template di renderizzare l’accordion e l’identico JSON-LD FAQPage, prevenendo schema nascosto obsoleto.

Includi genuine domande di follow-up visibili a ogni lettore. Non duplicare intestazioni, nascondere promozioni nelle risposte o marcare domande non visualizzate. Il markup valido non garantisce una funzionalità di ricerca.

Sintassi ed esempi di codice

Il contratto cross-platform mappa i campi, non un componente visibile. Il seguente involucro portatile è valido solo in un file di interscambio il cui importatore riconosce le direttive di metadati:

:::frontmatter{entity="guide-how-to" id="reset-api-key" title="How to Reset an API Key"}
description: Reset an API key safely, replace it in dependent services, verify it, and revoke the exposed key without avoidable downtime.
author: maya-chen
:::

Deve essere normalizzato in metadati di pagina nativi durante l’importazione. Non è valido nel corpo di un articolo di produzione. In Hugo, la mappatura corretta è TOML tra delimitatori +++ al primo byte, come mostrato nell’esemplare dal vivo. Non esiste deliberatamente uno shortcode {{< frontmatter >}}: uno shortcode verrebbe eseguito troppo tardi e nella regione sbagliata del documento.

In WordPress, mappa gli stessi campi canonici ai campi di post registrati e ai post meta, ad esempio post_title, post_excerpt, post_name, _amicited_entity, _amicited_author e _amicited_reviewed_by. Un commento come <!-- wp:amicited/frontmatter --> o uno shortcode [frontmatter] non è valido perché crea un blocco nel corpo piuttosto che metadati del documento. Gli importatori e gli editor possono presentare un pannello di metadati, ma i valori memorizzati devono rimanere allegati al record del post.

Esempi

Buono: un record coerente e responsabile

entity = "guide-how-to"
id = "rotate-api-key"
title = "How to Rotate an API Key"
description = "Rotate an API key safely, update every dependent service, verify the replacement, and revoke the old credential without avoidable downtime."
url = "/academy/rotate-an-api-key/"
date = "2026-08-27 10:00:00"
updated = "2026-09-03 14:30:00"
author = "maya-chen"
reviewedBy = "alex-rivera"
keywords = [ "rotate API key", "API key rotation", "revoke API key", "credential security", "API security", "secret rotation" ]
taxonomy = [ "security", "account-administration" ]
canonical = "https://amicited.com/academy/rotate-an-api-key/"

Questo identifica una variante how-to, preserva la cronologia, nomina le persone responsabili e separa l’argomento dall’identità della pagina. Il timestamp aggiornato è supportato da una modifica documentata delle istruzioni e da una revisione.

Cattivo: il titolo ripetuto come descrizione

title = "How to Rotate an API Key"
description = "How to Rotate an API Key"

La descrizione non aggiunge alcun beneficio, ambito o motivo per cliccare. Spreca anche lo spazio di anteprima che potrebbe distinguere questa pagina da ogni altro risultato che usa lo stesso titolo.

Cattivo: una entity riutilizzata tra due tipi di post

# voce di glossario
entity = "diagnosis"

# guida editoriale
entity = "diagnosis"

L’argomento condiviso ha sostituito l’identità del tipo di post. Usa valori registrati come glossary-term e guide-ultimate, poi assegna “diagnosis” attraverso tassonomia o parole chiave.

Cattivo: una data di aggiornamento senza diff dei contenuti

date = "2026-01-15 09:00:00"
updated = "2026-08-27 10:00:00" # solo la data è cambiata

Nessuna modifica sostanziale o revisione supporta l’affermazione di freschezza. Mantieni updated invariato o omesso fino a quando esiste un cambiamento reale e può essere ispezionato nella cronologia editoriale.

Markup schema e accessibilità

I metadati forniscono valori; il template rimane responsabile per HTML semantico, focus, contrasto, scopo dei link e testo alternativo.

Regole di scrittura

• Mantieni gli identificatori stabili, in minuscolo e sicuri per le macchine. Non riciclare mai un id o cambiare silenziosamente entity dopo la pubblicazione.
• Usa testo semplice nei campi simili a titoli. HTML, link Markdown, decorazioni con emoji e interruzioni di riga forzate non appartengono alle stringhe di metadati.
• Mantieni la descrizione a 150–160 caratteri e gli array di parole chiave a sei o otto frasi distinte per questo playbook.
• Usa persone reali registrate per i campi autore e revisore. Non creare mai un revisore cerimoniale o un’identità generica “Team Editoriale” a meno che non sia un’entità responsabile mantenuta.
• Usa una tassonomia controllata. Varianti ortografiche e duplicati singolare/plurale creano archivi frammentati.
• Riferisci solo immagini che esistono e per cui hai diritti di pubblicazione. imageAlt descrive il contenuto informativo dell’immagine, non il suo target SEO.
• Mantieni le risposte FAQ dirette e auto-contenute. Le affermazioni richiedono comunque le stesse evidenze e divulgazioni della prosa altrove nella pagina.
• Non inserire mai segreti, note private, token di accesso, istruzioni di embargo, dati personali o rivendicazioni legali non revisionate nel frontmatter pubblicabile.

Quali tipi di post usano il frontmatter e dove

Ogni tipo di post usa il frontmatter al primo byte. La profondità richiesta cambia con il rischio, l’intento e lo schema piuttosto che con il design visivo.

Checklist QA

• Il file inizia con +++, contiene TOML valido e chiude il record prima del contenuto del corpo?
• entity è un identificatore di tipo di post esatto registrato piuttosto che l’argomento, la campagna o il nome del sito?
• id è unico e stabile, e url corrisponde al registro degli slug canonici?
• title, l’opzionale h1 e l’opzionale seoTitle descrivono la stessa pagina senza cambiamenti di ambito ingannevoli?
• La descrizione è di 150–160 caratteri, contiene il termine principale in modo naturale e offre un motivo concreto per cliccare?
• Ogni immagine referenziata esiste e imageAlt è accurato per l’immagine che viene visualizzata?
• La data di pubblicazione è preservata e ogni valore updated è supportato da un diff sostanziale o una revisione documentata?
• Gli identificatori di autore e revisore si risolvono in profili reali mantenuti e il revisore nominato ha effettivamente revisionato il lavoro?
• Le parole chiave sono limitate a sei o otto frasi utili e i valori di tassonomia sono tratti da vocabolari controllati?
• Il canonical usa HTTPS, si risolve nella pagina preferita ed è in accordo con la sitemap e i link interni?
• Ogni elemento [[faq]] contiene una domanda utile e una risposta auto-contenuta che vengono visualizzate con la stessa identica formulazione?
• Il JSON-LD generato corrisponde al contenuto visibile, usa identificatori stabili e supera la validazione sintattica senza rivendicare tipi non supportati?
• Segreti, note editoriali private, affermazioni non supportate e divulgazioni solo nel corpo sono assenti dal record?

FAQ

Il frontmatter è visibile sulla pagina pubblicata?

Il record sorgente è nascosto, ma i template possono visualizzare il titolo, le persone, le date e le FAQ. Altri campi alimentano anteprime, tag canonici, feed, sitemap, schema e sistemi interni.

Il campo entity deve contenere l’argomento o il tipo di post?

Identifica il tipo di post esatto. Gli argomenti condivisi appartengono alla tassonomia e alle parole chiave, non al posto dell’identità del documento.

Titolo, H1 e titolo SEO possono essere diversi?

Sì. L’H1 può suonare più naturale e il titolo SEO può aggiungere un differenziatore, ma tutte le versioni devono fare la stessa promessa.

Quando dovrebbe cambiare la data di aggiornamento?

Modificala dopo una revisione o modifica fattuale sostanziale. Non cambiarla per punteggiatura, stile, lavoro su template o un aggiornamento solo della data.

Perché le domande FAQ sono memorizzate nel frontmatter?

L’array strutturato permette a un’unica fonte di visualizzare sia la FAQ visibile sia il JSON-LD FAQPage corrispondente. Questo impedisce allo schema di discostarsi da ciò che i lettori possono ispezionare.