Registro aggiornamenti: mostra cosa è cambiato e quando

Un registro aggiornamenti è una registrazione datata delle modifiche sostanziali a una pagina: cosa è cambiato, perché e se la risposta, la raccomandazione o le prove sono state modificate.

Registro aggiornamenti

27 agosto 2026 — Prezzi e raccomandazione aggiornati
Il piano Starter, non più disponibile, è stato sostituito con l’attuale piano Essentials, la tabella comparativa è stata aggiornata e la raccomandazione per i team che necessitano di esportazioni per audit è stata modificata. Le fonti sono state ricontrollate rispetto alla documentazione dei piani del fornitore.

12 maggio 2026 — Prove rinnovate; conclusione invariata
Sostituiti due riferimenti a funzionalità obsolete e verificati i limiti rimanenti dei piani. L’opzione raccomandata non è cambiata.

Ogni data è associata a un evento verificabile. Un semplice “Aggiornato il 27 agosto 2026” è una dichiarazione non motivata; il registro espone l’ambito e le conseguenze del lavoro svolto.

Perché questo elemento è importante

I lettori non trattano ogni modifica allo stesso modo. Correggere un titolo con un errore ortografico non equivale a invertire una raccomandazione, sostituire un set di dati o correggere un’istruzione pericolosa. Una singola data di aggiornamento comprime tutti questi eventi in un unico segnale. Nelle pagine utilizzate per spendere denaro, seguire una procedura, interpretare una ricerca o comprendere una policy, i lettori devono sapere se la sezione su cui facevano affidamento è cambiata.

Un registro aggiornamenti preserva la cronologia senza costringere i lettori a confrontare copie cache. Risponde a quattro domande: La pagina è stata mantenuta? La modifica mi riguarda? Un errore è stato corretto apertamente? La conclusione è ancora supportata? Risposte chiare creano responsabilità e impediscono una falsa freschezza data da una data avanzata senza un lavoro significativo.

Riporta le conseguenze, non le attività. “Link aggiornati” descrive un’azione. “Fonte ritirata per il totale di mercato 2024 sostituita; valore e conclusione invariati” dice ai lettori cosa rimane affidabile. Se una conclusione è cambiata, dichiaralo chiaramente.

L’estraibilità machine significa che il software può separare ogni evento in data, tipo, riepilogo, dettaglio, sezione interessata e riferimento alle prove. Campi stabili permettono agli audit di trovare correzioni, agli agenti di spiegare raccomandazioni modificate e alle migrazioni di preservare la cronologia. Una prosa inconsistente costringe il software a indovinare dove gli eventi iniziano e finiscono.

Lo scopo tipizzato dell’elemento ha quindi la precedenza su una linea temporale visivamente simile o un elenco puntato. Segui le regole di scrittura degli elementi : quando il contenuto registra le revisioni della pagina corrente, codificalo come registro aggiornamenti. Il renderer può usare un elenco, schede o un archivio espandibile, ma i campi canonici dell’evento devono sopravvivere a ogni presentazione.

Quando usarlo

Usa un registro aggiornamenti quando i lettori potrebbero aver bisogno di confrontare la pagina corrente con una precedente. I fattori scatenanti includono: una raccomandazione modificata, un fatto corretto, un metodo rivisto, un set di dati sostituito, un calcolo alterato, una nuova versione, requisiti di idoneità cambiati, un modello di prezzo aggiornato, istruzioni modificate o un’opzione archiviata.

L’elemento è più prezioso quando l’autorità si accumula nel tempo. Una ricerca può ricevere un denominatore corretto; una documentazione può supportare una nuova interfaccia; un explainer normativo può distinguere un emendamento da una precisazione editoriale. Una riscrittura silenziosa distruggerebbe la cronologia di cui un lettore di ritorno ha bisogno.

Usa un’entry di revisione con parsimonia quando una revisione con ambito delimitato non ha rilevato modifiche. Etichettala come “Revisionato”, indica cosa è stato controllato e afferma che la conclusione è invariata. Questo è adatto a statistiche volatili, prezzi, capacità dei prodotti o regole; non è un permesso per fabbricare attività.

I casi quasi simili necessitano di un trattamento diverso:

• Una data di pubblicazione o modifica: usa un indicatore di freschezza per esporre le date canoniche della pagina. L’indicatore e il registro possono funzionare insieme, ma l’uno non può sostituire l’altro.
• Cronologia dei rilasci di prodotto o timeline di progetto: questi descrivono cambiamenti nell’oggetto. Un registro aggiornamenti registra le modifiche editoriali alla pagina corrente.
• Output del controllo versione: i messaggi di commit includono rumore di implementazione, identificatori interni e dettagli sensibili alla sicurezza. Non sono registrazioni editoriali rivolte ai lettori.
• Un elenco di fonti: un blocco delle fonti dimostra da dove provengono le affermazioni. Il registro aggiornamenti indica quando e perché tali fonti o affermazioni sono cambiate.
• Manutenzione minore: non registrare correzioni ortografiche, di punteggiatura, di formattazione, compressione immagini, analytics, parametri di monitoraggio o migrazioni di template a meno che la modifica non abbia alterato il significato o l’accessibilità.

Una pagina senza revisioni sostanziali necessita di una data di pubblicazione, non di un pannello vuoto o di una cronologia fittizia.

Dove posizionarlo

Posiziona il registro completo dopo la risposta, le prove, le conclusioni e le fonti, ma prima dei contenuti correlati, del modulo di iscrizione alla newsletter o del call to action finale. I lettori hanno prima bisogno della pagina corrente, poi della sua cronologia. Nelle pagine di ricerca, statistiche e policy, il registro segue comunemente le fonti o la metodologia.

Se l’ultima modifica influisce sul modo in cui la pagina dovrebbe essere letta, aggiungi “Vedi cosa è cambiato” accanto alla data principale e collega al registro completo. Non duplicare l’entry in quella posizione. Una correzione che riguarda sicurezza, denaro, idoneità o la conclusione necessita anche di un avviso accanto all’affermazione corretta.

Il registro può condividere un’area di manutenzione con la paternità quando entrambi rimangono distinti. Non può trovarsi accanto a un pulsante di acquisto, un’offerta a tempo limitato, un countdown, una valutazione, una testimonianza o un badge promozionale; ciò trasformerebbe la cronologia in urgenza o approvazione implicita. Non integrarlo nel blocco delle fonti: il motivo per cui una fonte è cambiata è cronologia editoriale, non una citazione.

Mantieni un unico registro canonico. Una barra laterale può collegarsi ad esso, non duplicarlo. Dopo cinque entry, mostra le ultime tre-cinque e rendi accessibili le rimanenti tramite “Vedi aggiornamenti precedenti”. Mantieni la cronologia completa sulla pagina o in un archivio stabile e governato.

Anatomia

1. Titolo dell’elemento: Usa “Registro aggiornamenti”, “Cronologia revisioni” o un’etichetta approvata più specifica che rimanga chiara al di fuori del design della pagina.
2. Data dell’evento: Mostra una data di calendario assoluta ed espone lo stesso valore come timestamp machine ISO 8601.
3. Tipo di evento: Distingue tra aggiornato, corretto, revisionato, metodo-modificato e archiviato senza affidarsi ai colori.
4. Riepilogo: Indica l’oggetto modificato e il risultato in una riga concisa.
5. Dettaglio: Spiega lo stato precedente, lo stato nuovo e il motivo quando queste informazioni aiutano il lettore a interpretare la pagina.
6. Sezione interessata: Opzionalmente collega all’intestazione stabile o alla figura modificata, usando un frammento che non verrà riutilizzato.
7. Conseguenza: Indica se la risposta, la conclusione, la raccomandazione, l’idoneità o le istruzioni sono cambiate.
8. Riferimento alle prove: Opzionalmente punta a un identificatore di fonte già definito nel blocco delle fonti della pagina.
9. Controllo archivio: Mostra le entry precedenti senza eliminarle dal documento o dall’albero di accessibilità.

Le entry devono rimanere comprensibili senza stili. Icone, linee e colori non devono mai veicolare da soli il tipo o la conseguenza.

Esempi di design

Le varianti riflettono la densità informativa e il rischio editoriale.

Riga compatta ultima modifica

Usa una riga compatta per una singola revisione semplice. Includi data, tipo, riepilogo e conseguenza. Usa l’elenco standard quando la spiegazione supera le due frasi.

Elenco standard delle revisioni

Usa un elenco dal più recente al più vecchio per due-cinque entry, con lo stesso ordine di campi per tutte.

Variante con correzione

Per un errore sostanziale, etichetta “Correzione”, mostra lo stato errato e quello corretto, indica l’impatto e collega alla sezione interessata. Enfatizza senza linguaggio allarmistico.

Modifica di metodo o versione

Quando un set di dati, una formula, una versione di prodotto, una giurisdizione o un metodo cambia, mostra le versioni vecchia e nuova. Indica quando i risultati precedenti non sono più confrontabili.

Archivio espandibile

Dopo cinque entry, etichetta l’archivio con il conteggio delle entry e l’intervallo di date. Preserva intestazioni e struttura dell’elenco; non fare di JavaScript l’unico modo per raggiungere la registrazione.

Viewport stretto

Impila data, tipo, riepilogo e dettaglio. Non troncare mai le date né nascondere il testo della conseguenza sui dispositivi mobili.

Parametri

I campi genitori controllano la collezione; i campi ripetuti degli item descrivono ogni evento.

Le entry sono item ripetuti, non un singolo campo HTML. La prima intestazione del genitore corrisponde a title; la prima intestazione di ogni item corrisponde a summary e il corpo rimanente corrisponde a detail. Date, tipi, impatto, riferimenti e versioni rimangono attributi.

impact è obbligatorio affinché i lettori non debbano dedurre se la risposta è cambiata. Usa not-applicable solo quando il materiale non ha una conclusione. Una revisione senza modifiche usa type=reviewed e impact=unchanged.

Sintassi ed esempi di codice

Tutte le rappresentazioni preservano gli stessi campi. Gli identificatori delle fonti fanno riferimento al blocco fonti canonico.

Direttiva Markdown portabile

:::update-log{order=newest-first visibleItems=3}
## Update log

::item{date="2026-08-27" type=updated impact=changed affectedSection="plans" evidenceRef="vendor-plans"}
### Pricing and recommendation updated

Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
::

:::

Contratto shortcode Hugo

{{< update-log title="Update log" order="newest-first" visibleItems="3" >}}
  {{< update-log-item date="2026-08-27" type="updated" impact="changed" affectedSection="plans" evidenceRef="vendor-plans" >}}
  ## Pricing and recommendation updated
  Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.
  {{< /update-log-item >}}
{{< /update-log >}}

Questo è un contratto adapter, non uno shortcode esistente. Ogni parametro è denominato.

Blocchi WordPress

<!-- wp:amicited/update-log {"title":"Update log","order":"newest-first","visibleItems":3} -->
<!-- wp:amicited/update-log-item {"date":"2026-08-27","type":"updated","impact":"changed","affectedSection":"plans","evidenceRef":["vendor-plans"]} -->
<h3>Pricing and recommendation updated</h3>
<p>Replaced the discontinued Starter plan with Essentials and updated the comparison. Teams needing audit exports now receive a different recommendation.</p>
<!-- /wp:amicited/update-log-item -->
<!-- /wp:amicited/update-log -->

WordPress dovrebbe esporre controlli strutturati per data, tipo, impatto, sezione e prove.

Esempi

Buona entry di aggiornamento

18 luglio 2026 — Calcolo corretto
Corretto il denominatore del tasso di conversione da tutte le sessioni alle sessioni di prodotto idonee nella tabella “Performance dei canali”. I valori per la ricerca organica sono passati dal 3,1% al 2,4%; la classifica dei canali e la conclusione dell’articolo non sono cambiate. I conteggi delle sessioni sottostanti non sono stati influenzati.

Questo funziona perché nomina l’errore, le definizioni vecchia e nuova, la sezione interessata, la conseguenza numerica e lo stato della conclusione. I lettori possono giudicare se il lavoro precedente necessita di revisione.

Cattiva entry di aggiornamento

Estate 2026 — Completamente rinnovato!
Abbiamo revisionato questa pagina e apportato diversi miglioramenti in modo che tu possa fidarti che tutto sia aggiornato.

Questo fallisce perché la data è vaga, “completamente” sopravvaluta l’ambito, “diversi miglioramenti” nasconde i fatti e “fidarti” richiede una conclusione non meritata. Se il lavoro era estetico, elimina l’entry. Se sostanziale, nomina ogni modifica rilevante per le decisioni.

Marcatura Schema e accessibilità

Un registro aggiornamenti non ha un tipo Schema.org autonomo. Rimane contenuto all’interno dell’Article, TechArticle o Report che lo racchiude. L’evento sostanziale più recente può supportare dateModified; una revisione senza modifiche non deve farlo. Non sostituire mai datePublished.

Non codificare le entry come CreativeWork, Event, HowToStep o ItemList; questi tipi implicano significati che il registro non ha. Usa HTML prevedibile: una sezione etichettata, elementi di elenco, intestazioni, <time datetime="2026-08-27">27 agosto 2026</time> e frammenti stabili.

Usa un elemento di elenco per evento; il CSS può tracciare una linea temporale senza alterare l’ordine. Indica che le entry sono dalla più recente alla più vecchia. Mostra il tipo in testo, non solo con colore o icone, e usa link descrittivi.

Un archivio necessita di un elemento di apertura/chiusura nativo etichettato con il suo conteggio o intervallo. Tutte le entry devono essere raggiungibili tramite tastiera e screen reader. Non usare una regione ARIA live. Preserva l’ordine delle intestazioni e le date localizzate.

Posiziona un avviso di correzione presso l’affermazione interessata e registralo nel registro. Il primo protegge i lettori immediati; il secondo preserva la cronologia.

Regole di scrittura

Inizia con l’oggetto modificato e un verbo preciso: “Regola di idoneità chiarita”, “Set di dati sostituito” o “Formula corretta”. Mantieni i riepiloghi tra 4 e 14 parole e i dettagli tra 25 e 90 parole. Usa una frase per la modifica e il motivo, un’altra per l’impatto. Usa date assolute localizzate e visualizzazione dalla più recente.

Spiega il motivo prima del risultato. “Il fornitore ha ritirato Starter, quindi lo abbiamo sostituito con Essentials e rivalutato la raccomandazione” registra la causa; “Abbiamo migliorato il nostro confronto” registra un’opinione. Usa il passato neutro.

Ogni entry sostanziale dovrebbe rispondere a queste domande:

• Quale fatto specifico, istruzione, metodo, fonte, ambito o conclusione è cambiato?
• Perché la modifica era necessaria?
• Dove nella pagina è avvenuta?
• La risposta principale, la raccomandazione o la conclusione è cambiata?
• Il lettore deve rifare una decisione o un’azione basata sulla versione precedente?

Crea una entry per evento editoriale, non per battitura. Raggruppa modifiche correlate da una stessa revisione; separa lavori non correlati, impatti diversi o date diverse. Mostra da tre a cinque e mantieni la cronologia sostanziale.

Non includere mai note riservate, dettagli di sicurezza, vulnerabilità, dati personali, attribuzioni di colpa, hash di commit grezzi, ticket non spiegati, marketing, urgenza o una bibliografia. Non promettere mai “100% aggiornato”, cancellare correzioni, riscrivere silenziosamente le entry o ridatare lavori estetici.

Se un’entry necessita di correzione, preserva la sua data e aggiungi un evento di correzione. Doveri di privacy, sicurezza o legali possono giustificare l’oscuramento; indica che la registrazione è stata modificata e perché a un livello appropriato.

Tipi di post che lo utilizzano

L’array postTypes nel frontmatter è la fonte di questa tabella. “Obbligatorio” significa che la cronologia delle revisioni sostanziali fa parte del contratto di affidabilità del formato; “condizionale” significa che il registro appare dopo che si verifica una modifica qualificante.

Una nuova pagina non necessita di un registro vuoto. Dopo una modifica qualificante, preserva l’elemento.

Checklist QA

• Ogni entry visibile rappresenta un evento editoriale sostanziale, non un cambiamento estetico o automatizzato.
• La data dell’evento è esatta, valida, non futura e corrisponde alla registrazione editoriale approvata.
• Il riepilogo indica l’oggetto modificato e rimane entro 4–14 parole.
• Il dettaglio indica cosa è cambiato e perché prima di descrivere il beneficio.
• L’entry identifica se la risposta, la conclusione, la raccomandazione, l’idoneità o le istruzioni sono cambiate.
• Una correzione sostanziale appare anche accanto all’affermazione interessata.
• I frammenti di sezione e gli identificatori delle prove risolvono target stabili sulla stessa pagina canonica.
• Il registro appare dopo il contenuto principale e le fonti ma prima dei moduli promozionali di chiusura.
• Il registro non è visivamente fuso con un CTA, un’offerta, una valutazione, una testimonianza o un blocco fonti.
• Le date usano valori semantici <time>; i tipi di evento e gli impatti non si basano su colore o icone.
• Il controllo archivio è utilizzabile tramite tastiera, chiaramente etichettato ed espone il suo contenuto completo alla tecnologia assistiva.
• Un’entry di sola revisione non modifica dateModified; un evento sostanziale recente concorda con la data di aggiornamento canonica.
• Note riservate, dati personali, dettagli di sicurezza, cronologia di implementazione grezza e linguaggio di marketing sono assenti.
• Il tipo di post della pagina e il rischio per il lettore giustificano l’elemento.

FAQ

Ogni modifica ai contenuti va inserita nel registro aggiornamenti?

No. Registra solo le modifiche che alterano fatti, istruzioni, prove, ambito, interpretazioni, raccomandazioni o la decisione del lettore. Ometti correzioni ortografiche, spaziatura, monitoraggio, template e altre modifiche non sostanziali.

In cosa si differenzia un registro aggiornamenti da una data di ultimo aggiornamento?

Una data di ultimo aggiornamento segnala che è avvenuta una modifica sostanziale. Un registro aggiornamenti indica cosa è cambiato, perché è cambiato e se la risposta o la conclusione è stata modificata, in modo che la dichiarazione di manutenzione possa essere verificata.

L’aggiornamento più recente o quello più vecchio dovrebbe apparire per primo?

Mostra l’entry più recente per prima su una pagina mantenuta, poiché i lettori di solito hanno bisogno della modifica corrente. Mantieni l’ordine cronologico nell’output machine e fornisci un archivio chiaramente etichettato quando l’elenco visibile viene accorciato.

Un registro aggiornamenti può sostituire gli avvisi di correzione?

No. Un errore sostanziale necessita di una correzione evidente presso l’affermazione interessata oltre a una registrazione permanente nel registro. Il registro preserva la cronologia; non deve nascondere una correzione in fondo alla pagina.

Le revisioni senza modifiche dovrebbero apparire nel registro?

Solo quando lo stato della revisione è importante per i lettori e l’entry è etichettata come “Revisionato”, non “Aggiornato”. Indica l’ambito verificato e che non è stata necessaria alcuna modifica sostanziale; non modificare dateModified.