Schema AudioObject

TL;DR — Lo schema AudioObject è codice che aggiungi a una pagina per etichettare un contenuto audio — «questo è un episodio di podcast», «questa è la sua durata», «questo è il percorso del file». È importante dirlo subito: aggiungerlo non ti dà un risultato audio speciale su Google. Non sblocca alcuna scheda o badge audio. Il suo valore consiste soprattutto nell’inserire correttamente l’audio dentro altri contenuti marcati, oltre a un aiuto plausibile — ma non dimostrato — per il modo in cui motori di ricerca e strumenti AI comprendono l’audio, non nell’ottenere una funzione visibile.

Che cos’è lo schema AudioObject

Quando una pagina contiene un player audio — un episodio di podcast, la versione narrata di un articolo, un clip sonoro — puoi vedere e ascoltare di che cosa si tratta. Un motore di ricerca vede soprattutto testo semplice e un file multimediale sul cui significato deve fare ipotesi. Lo schema AudioObject lo esplicita nel codice usando il vocabolario condiviso di schema.org: assegna all’audio un name, indica dove si trova il file (contentUrl), quanto dura (duration) e qual è il formato (encodingFormat).

Come la maggior parte degli schemi, è scritto come JSON-LD: un piccolo blocco di codice che vive nella pagina senza cambiarne l’aspetto.

La parte onesta: che cosa non fa

Ecco ciò che molte guide non ti dicono chiaramente. Alcuni tipi di schema producono un risultato di ricerca più ricco — Recipe crea la scheda della ricetta, VideoObject può creare una miniatura video. AudioObject no. Al momento non esiste affatto un risultato avanzato Google dedicato: il tipo non compare nell’elenco ufficiale Google dei dati strutturati supportati e le due pagine guida che ti aspetteresti (/structured-data/podcast e /structured-data/media-clip) semplicemente non esistono: restituiscono «not found».

Quindi, se l’unico motivo per aggiungere AudioObject è «otterrò un risultato podcast su Google», la risposta onesta è: non lo otterrai. Non è un motivo per allarmarsi; è solo un motivo per sapere che cosa stai davvero ottenendo.

Perché allora aggiungerlo?

Restano due motivi legittimi:

• Aiutare le macchine a capire l’audio. I motori di risposta AI e i sistemi di ricerca leggono sempre più spesso i dati strutturati per capire che cosa contiene una pagina. Un markup AudioObject pulito è una scommessa ragionevole in quella direzione — «questa pagina contiene un episodio podcast di 42 minuti chiamato X» — anche se nessuno ha pubblicato una prova diretta che AudioObject, nello specifico, produca un effetto sui sistemi AI. Consideralo quindi un beneficio plausibile, non dimostrato, non una garanzia.
• Inserire l’audio dentro altri contenuti. Se hai un articolo con una versione audio narrata, puoi annidare un AudioObject nel markup dell’articolo per collegare formalmente i due elementi.

Tre cose che vengono confuse

• AudioObject non è un risultato avanzato podcast. Oggi non esiste una funzione Google di questo tipo.
• Lo schema non è la stessa cosa di un feed RSS. Ciò che inserisce davvero il podcast in Apple Podcasts e Spotify è il tuo feed RSS, non lo schema nella pagina.
• AudioObject non è PodcastEpisode. Google ha tipi separati per i podcast e neppure quelli producono un risultato avanzato.

Vuoi l’elenco delle proprietà, il confronto AudioObject-PodcastEpisode-RSS e un semplice modello «ne vale la pena?». Passa alla scheda Advanced.

TL;DR — schema.org/AudioObject (di solito JSON-LD) marca i contenuti audio con contentUrl, duration, name e encodingFormat. Il dato centrale verificato è questo: non ha un risultato avanzato Google dedicato. È assente dall’elenco ufficiale dei tipi di dati strutturati supportati da Google e le due URL plausibili delle guide (/structured-data/podcast e /structured-data/media-clip) restituiscono 404. Serve per inserire l’audio in altri contenuti marcati (per esempio, associatedMedia di un Article), oltre a un aiuto plausibile — ma non verificato indipendentemente — alla comprensione di entità e contenuti sulle superfici rivolte all’AI, non a creare una scheda SERP. Non confonderlo con PodcastSeries/PodcastEpisode (tipi separati di Google per la gestione dei podcast, anch’essi senza risultato avanzato) né con i feed RSS (il meccanismo reale per far scoprire i podcast nelle app Apple/Spotify, indipendente dallo schema nella pagina). Consideralo uno dei tipi a priorità più bassa di questo cluster.

Che cos’è lo schema AudioObject — e la verità onesta su ciò che non fa

schema.org/AudioObject è un sottotipo di MediaObject per rappresentare un contenuto audio: un episodio di podcast, un articolo narrato, un clip sonoro. Il vocabolario è reale e stabile. Ciò che non è reale è una funzione Google Search associata a questo tipo.

L’ho verificato direttamente ed è giusto dirlo senza attenuazioni: AudioObject non ha un trattamento Google dei risultati avanzati confermato. Tre fatti concreti lo dimostrano:

• Non compare tra le voci dell’elenco ufficiale dei dati strutturati supportati di Google (la «search gallery»). Ogni tipo che ottiene un risultato avanzato compare in quell’elenco. AudioObject no.
• Le due URL delle guide che ti aspetteresti — developers.google.com/search/docs/appearance/structured-data/podcast e .../media-clip — restituiscono entrambe 404. Non esiste una pagina documentale perché non esiste una funzione.
• Nella guida Video di Google, il markup per i clip è riunito sotto VideoObject/Clip/BroadcastEvent. Non esiste un carosello AudioObject parallelo, un badge o una tabella di proprietà obbligatorie/consigliate documentata su developers.google.com/search.

Sono favorevole al markup schema finché permette di ottenere una funzione di ricerca. Questo è il caso più chiaro dell’intero cluster di dati strutturati di un markup che non la produce: la cosa utile è essere diretti, non creare urgenza artificiale.

AudioObject vs. PodcastSeries/PodcastEpisode vs. feed RSS

Questo trio viene confuso continuamente e separarlo è gran parte del valore pratico dell’articolo.

• AudioObject — il tipo generico di schema.org per «un contenuto audio». Nessun risultato avanzato Google.
• PodcastSeries / PodcastEpisode — i tipi separati e specifici per podcast di Google. Storicamente legati alle superfici di gestione dei podcast, non a un risultato avanzato Search. Nel vocabolario schema.org, un PodcastEpisode può riferirsi al file multimediale tramite la proprietà associatedMedia: l’AudioObject resta l’entità a livello di file, collegata all’episodio ma non coincidente con lo stesso nodo. Nota che Google Podcasts ha chiuso nel 2024, eliminando una delle poche superfici in cui questo markup aveva un possibile consumatore diretto: un ulteriore motivo per tenerlo a bassa priorità, non una nuova opportunità.
• MusicRecording — un punto di confusione che vale la pena correggere: MusicRecording è un tipo CreativeWork di schema.org, non un sottotipo di AudioObject. Se stai marcando un brano musicale, modella il brano come MusicRecording e, se vuoi descrivere separatamente il file audio effettivo, collegagli un AudioObject distinto invece di supporre che un tipo erediti dall’altro.
• Feed RSS — è ciò che molti devono capire: ciò che fa elencare un podcast in Apple Podcasts, Spotify e altre app è il tuo feed RSS, inviato a quelle directory. È un meccanismo completamente diverso dallo schema nella pagina. Nessuna quantità di markup AudioObject inserisce il programma in un’app podcast: lo fa il feed.

Quando un responsabile chiede «dovremmo aggiungere lo schema podcast per la SEO?», la risposta corretta di solito separa tre domande: vuoi un risultato avanzato Google (non ne esiste alcuno), vuoi distribuire il podcast nelle app (serve RSS, non schema) o vuoi una leggibilità generale per le macchine (qui AudioObject ha un valore modesto).

Dove vale ancora la pena implementarlo

Anche senza un risultato avanzato, ci sono motivi difendibili per aggiungere AudioObject:

• Inserire l’audio in un Article. Se una pagina è principalmente un articolo con una versione audio narrata, annidare un AudioObject nell’Article (per esempio come associatedMedia) collega formalmente i due elementi. L’Article può avere il suo valore; AudioObject rende semplicemente esplicita la componente audio.
• Comprensione di entità e contenuti per le superfici AI. AI Overviews e altri sistemi rivolti agli LLM leggono sempre più spesso i dati strutturati per capire il contenuto delle pagine e un markup AudioObject completo può plausibilmente aiutarli a riconoscere l’audio per ciò che è. È un’ipotesi ragionevole in base all’uso generale dei dati strutturati, non un’affermazione sostenuta da uno studio specifico su AudioObject o da una dichiarazione Google: trattala con cautela e non venderla come garantita.
• Completezza schema.org nei siti che lavorano già molto sui dati strutturati. Se stai già marcando tutto il resto in modo pulito, aggiungere AudioObject costa poco e mantiene coerente il grafo: non aspettarti però un vantaggio nella SERP.

Implementazione di base — le proprietà che vale la pena usare

Poiché non esiste una tabella dei requisiti Google, appoggiati direttamente al vocabolario schema.org. Queste sono le proprietà che vale la pena documentare anche senza un risultato avanzato:

Una proprietà merita una segnalazione a parte: transcript. È un campo AudioObject reale e valido — schema.org lo documenta direttamente — ma non è dimostrato che mettere una trascrizione solo nel JSON-LD renda le parole pronunciate indicizzabili, citabili o idonee a uno snippet in evidenza; questo beneficio lato consumatore non è stato verificato. Se vuoi che la trascrizione abbia peso SEO o nelle risposte AI, pubblicala anche come testo visibile e accessibile nella pagina. Considera la proprietà schema come un registro leggibile dalle macchine accanto a quel testo visibile, non come un suo sostituto.

Un blocco JSON-LD minimo:

{
  "@context": "https://schema.org/",
  "@type": "AudioObject",
  "name": "Episode 12: Structured Data Myths",
  "contentUrl": "https://example.com/audio/ep12.mp3",
  "encodingFormat": "audio/mpeg",
  "duration": "PT42M30S",
  "uploadDate": "2026-06-01",
  "description": "We separate the schema hype from what actually earns a search feature."
}

E annidato come versione audio di un Article:

{
  "@context": "https://schema.org/",
  "@type": "Article",
  "headline": "Structured Data Myths",
  "associatedMedia": {
    "@type": "AudioObject",
    "name": "Structured Data Myths (narrated)",
    "contentUrl": "https://example.com/audio/narrated.mp3",
    "encodingFormat": "audio/mpeg",
    "duration": "PT42M30S"
  }
}

Conviene? Un framework per stabilire la priorità

Poiché preferisco che tu investa lo sforzo dove produce valore, ecco il triage onesto:

1. Vuoi un risultato avanzato Google da questo markup? Allora AudioObject è lo strumento sbagliato: non ne esiste alcuno. Dedica il tempo a un tipo con una funzione documentata.
2. Vuoi il podcast su Apple/Spotify? Ti serve il feed RSS, non lo schema. Verifica che il feed sia corretto e inviato.
3. Stai già marcando tutto il resto e vuoi una comprensione pulita di entità/AI? Aggiungere AudioObject è un completamento ragionevole e poco costoso: calibra però le aspettative su «leggibilità per le macchine», non su «scheda SERP».

Per la maggior parte dei siti AudioObject è quasi in fondo alla lista di priorità dei dati strutturati. Non è una critica al vocabolario: è una lettura accurata del beneficio attuale. Per capire la posizione del markup audio rispetto ai tipi affini, guarda VideoObject, CreativeWork e il lavoro più ampio su Schema Markup / Structured Data di questo sito.

Riepilogo AI

Una sintesi della versione Advanced:

• Che cos’è: markup schema.org/AudioObject (di solito JSON-LD) che etichetta contenuti audio — episodi di podcast, articoli narrati, clip sonori — tramite proprietà come contentUrl, duration, name e encodingFormat.
• Dato centrale verificato: AudioObject non ha un risultato avanzato Google dedicato. È assente dall’elenco ufficiale dei dati strutturati supportati da Google; le due URL plausibili delle guide (/structured-data/podcast e /structured-data/media-clip) restituiscono entrambe 404. Non esiste alcuna scheda, badge o carosello audio che sblocchi.
• A che cosa serve davvero: inserire l’audio dentro altri contenuti marcati (per esempio associatedMedia di un Article), oltre a un aiuto plausibile — ma non verificato indipendentemente — alla comprensione di entità e contenuti sulle superfici AI. Non è una funzione SERP visibile.
• Quattro cose da non confondere:
  • AudioObject = tipo audio generico, senza risultato avanzato.
  • PodcastSeries/PodcastEpisode = tipi separati di Google per la gestione dei podcast, anch’essi senza risultato avanzato (e Google Podcasts ha chiuso nel 2024); un PodcastEpisode può riferirsi al file tramite associatedMedia, ma AudioObject resta l’entità a livello di file.
  • MusicRecording = tipo CreativeWork, non un sottotipo di AudioObject: modella un brano come MusicRecording e, se serve, il relativo file audio come AudioObject separato.
  • Feed RSS = il meccanismo reale che inserisce un podcast in Apple Podcasts/Spotify, indipendente dallo schema nella pagina.
• Proprietà che vale comunque la pena usare: name, contentUrl, duration (ISO 8601), encodingFormat (tipo MIME), oltre a description/uploadDate. Anche transcript è un campo valido, ma non è verificato che una trascrizione solo JSON-LD renda le parole indicizzabili o idonee a uno snippet: se questo risultato conta, pubblica anche la trascrizione visibile.
• Priorità: uno dei tipi a priorità più bassa del cluster. Aggiungilo per completezza e per un’ipotesi ragionevole, non dimostrata, di comprensione AI nei siti che già fanno un lavoro ampio sui dati strutturati: non per una funzione di ricerca che non esiste.
• Triage: vuoi un risultato avanzato? Strumento sbagliato. Vuoi distribuire nelle app? Serve RSS. Vuoi una leggibilità pulita per le macchine? AudioObject è un completamento ragionevole e poco costoso.

Documentazione ufficiale

Riferimenti primari — e, fatto insolito, qui il dato più importante è ciò che la documentazione non contiene.

Il dato chiave: non esiste una pagina di funzionalità AudioObject

• L’elenco dei dati strutturati supportati di Google (la «search gallery») è l’indice canonico di ogni tipo che ottiene un risultato avanzato. AudioObject non compare.
• https://developers.google.com/search/docs/appearance/structured-data/podcast → 404 (pagina non trovata). Non esiste una guida Google a una funzione «podcast structured data».
• https://developers.google.com/search/docs/appearance/structured-data/media-clip → 404 (pagina non trovata). Non esiste una guida Google a una funzione «media clip» (audio).

Quei due 404 e l’assenza dall’elenco dei tipi supportati sono il punto centrale. Quando un tipo ha una funzione Google Search, ha una pagina guida documentata e una voce nella gallery. AudioObject non ha né l’una né l’altra.

Dove il markup audio/clip è documentato davvero (video, non audio)

• Video structured data (VideoObject / Clip / BroadcastEvent) — il markup dei clip di Google vive qui, unificato sotto VideoObject. Non esiste una tabella di requisiti AudioObject parallela.

La documentazione podcast separata di Google (RSS/gestione, non un risultato avanzato)

• Le guide Google «About podcasting on Google» e per la gestione dei podcast (ora riunite nell’assistenza Podcast Publisher Center di Google) riguardano l’invio e la gestione del feed RSS, non il markup schema.org/AudioObject che alimenta un risultato avanzato Search. (Google Podcasts ha chiuso nel 2024, restringendo ulteriormente la rilevanza di questa superficie.)

Il vocabolario

• schema.org/AudioObject — la definizione del tipo e l’elenco completo delle proprietà, dato che Google non ne pubblica uno specifico per una funzione.

Bing / Microsoft

• Non esiste una guida Bing specifica per AudioObject o podcast: c’è solo la panoramica dei dati strutturati (supporto schema.org, JSON-LD consigliato, Markup Validator generico).

Citazioni dalla fonte

In modo insolito, qui c’è poco da citare — ed è proprio il punto. Google non pubblica una guida sui risultati avanzati AudioObject, quindi non esiste un passaggio ufficiale da citare che prometta una funzione. La «citazione» verificata su questo argomento è in realtà un’assenza: nessuna voce nella gallery dei tipi supportati, nessuna pagina di funzionalità (entrambe le URL candidate restituiscono 404). Non inventerò una dichiarazione Google che non esiste.

L’unica frase riportata da una persona che vale la pena mettere in apertura è mia, perché riassume esattamente il motivo per cui AudioObject è in fondo alla lista di priorità:

Patrick Stox

• “I’m a fan of schema markup as long as it gets you a search feature.” (traduzione) «Sono favorevole al markup schema finché consente di ottenere una funzionalità nella ricerca». Ahrefs — Strategie SEO enterprise per la massima crescita

È tutta la tensione in una frase. AudioObject è il caso più chiaro di questo cluster di schema che non ti dà una funzione di ricerca: la posizione onesta è aggiungerlo per la comprensione di entità/AI se stai già facendo un lavoro ampio sui dati strutturati e saltarlo se la tua unica motivazione è un vantaggio nella SERP.

Miti ed errori AudioObject da evitare

Mito: «Lo schema AudioObject ti dà un risultato avanzato podcast su Google.» Falso: nella documentazione Google attuale non esiste alcuna funzione simile. AudioObject è assente dalla gallery ufficiale dei dati strutturati supportati e le due URL plausibili delle guide (/structured-data/podcast e /structured-data/media-clip) restituiscono 404. Aggiungere il markup non produce una scheda, un badge o un carosello audio.

Mito: «Lo schema podcast e un feed RSS sono la stessa cosa.» Non lo sono e questa confusione fa sprecare tempo. Il feed RSS è il meccanismo reale che inserisce un podcast in Apple Podcasts, Spotify e altre app. Lo schema nella pagina è un livello separato di markup dell’entità, oggi con un ritorno basso. Se l’obiettivo è la distribuzione nelle app, correggi il feed: lo schema non la realizza.

Mito: «AudioObject e PodcastEpisode sono intercambiabili e uno dei due produce un risultato avanzato.» Sono tipi distinti e nessuno dei due produce un risultato avanzato Google Search. PodcastSeries/PodcastEpisode sono tipi separati di Google per la gestione dei podcast, collegati alle superfici RSS/di gestione, non a una funzione SERP.

Mito: «Dopo la chiusura di Google Podcasts nel 2024, lo schema podcast è completamente inutile.» È un’esagerazione. La chiusura di Google Podcasts ha eliminato un possibile consumatore del markup, motivo per cui questo tipo è a bassa priorità. AudioObject può però ancora aiutare la comprensione generale di entità/AI dell’audio di una pagina: semplicemente non ha mai ottenuto un risultato avanzato Search, quindi la chiusura non ha «tolto» una funzione che esisteva.

Errore: aggiungere AudioObject aspettandosi un vantaggio SEO e trascurare ciò che conta. Se qualcuno insiste per «schema podcast per la SEO», reindirizza lo sforzo: non c’è alcun risultato avanzato da conquistare, quindi verifica che il feed RSS sia corretto (per la scoperta nelle app) e che i contenuti della pagina siano davvero utili (per il ranking) prima di dedicare tempo a markup senza ritorno SERP.

Errore: valori delle proprietà imprecisi. Se lo aggiungi, cura comunque le basi: un contentUrl reale che punti al file audio, duration in ISO 8601 (PT42M30S, non «42:30») e un tipo MIME encodingFormat valido (audio/mpeg, non «mp3»). Valori errati non aiutano nessuno, né le persone né le macchine.

Devo aggiungere AudioObject a questa pagina?

La risposta onesta dipende interamente da ciò che vuoi ottenere davvero con l’audio: un episodio di podcast, un obiettivo di distribuzione nelle app e un articolo narrato richiedono correzioni diverse e solo una di queste è «aggiungi lo schema AudioObject».

I modelli mentali

1. «Questo tipo produce un risultato avanzato?» è una verifica, non un’ipotesi. Prima di presumere che un tipo di schema meriti il tuo tempo, controlla la gallery ufficiale dei dati strutturati supportati di Google. AudioObject non compare e nessuna delle due URL delle guide che ti aspetteresti (/structured-data/podcast, /structured-data/media-clip) risolve. Quando un tipo è davvero assente dalla gallery, considera l’assenza il dato, non una lacuna della ricerca.

2. Distribuzione e markup dell’entità sono due lavori diversi. Portare un podcast in Apple Podcasts o Spotify è un problema di feed RSS. Aiutare un motore di ricerca o un sistema AI a capire che cos’è l’audio è un problema di schema. Non si sostituiscono a vicenda: correggere uno non corregge l’altro, quindi individua il lavoro che devi risolvere prima di ricorrere al markup.

3. Annida l’audio nel contenuto che supporta, invece di trattarlo come autonomo. Quando l’audio accompagna altro contenuto — per esempio la versione narrata di un articolo — la mossa di maggior valore è annidare l’AudioObject nel markup di quel contenuto (per esempio, associatedMedia di un Article), non pubblicarlo come blocco isolato senza relazione con la pagina che lo circonda.

4. La priorità cresce con la quantità di dati strutturati già presente sul sito. In un sito che investe già molto nella copertura schema, aggiungere AudioObject è un completamento economico e coerente. In un sito con copertura scarsa e poco tempo, è una delle aggiunte con il ritorno più basso, perché dall’altra parte non attende alcuna funzione SERP.

5. Senza una tabella di requisiti Google, la correttezza viene dal vocabolario, non da una checklist. Google non pubblica una tabella di proprietà obbligatorie/consigliate specifica per AudioObject, quindi il criterio per farlo «bene» è dato dalle definizioni di schema.org: duration in ISO 8601 (PT42M30S, non "42:30"), encodingFormat come tipo MIME reale (audio/mpeg, non "mp3") e un contentUrl che porti davvero al file.

Strumenti per convalidare e generare il markup AudioObject

Poiché non c’è una funzione Google per i risultati avanzati da inseguire, il lavoro utile consiste nel rendere corretto il JSON-LD e nel capire onestamente per che cosa ti renderà (o non ti renderà) idoneo: questi tre strumenti gratuiti coprono il ciclo completo.

• Schema Markup Validator — incolla il JSON-LD AudioObject (autonomo o annidato in associatedMedia di un Article) e ottieni una convalida per gravità rispetto al vocabolario schema.org, inclusi i controlli del grafo @id tra blocchi. È lo strumento giusto per confermare che duration sia ISO 8601 valido, che encodingFormat sia un tipo MIME reale e che contentUrl sia ben formato: proprio ciò che conta ora che non esiste una tabella di requisiti Google.
• Rich-Result Eligibility Checker — esegui il JSON-LD della pagina e verifica, tipo per tipo, per che cosa è o non è idoneo. Per AudioObject, aspettati che confermi il dato onesto di questo articolo: non esiste un risultato avanzato Google legato al tipo, quindi non aspettarti un verdetto idoneo/non idoneo come per il markup Product o Recipe.
• Schema Markup Generator — costruisci il blocco JSON-LD AudioObject (o l’annidamento Article-con-associatedMedia mostrato sopra) con un modulo guidato invece di scrivere a mano le proprietà, poi esportalo pronto da incollare.

Mettiti alla prova: Schema AudioObject

Cinque domande rapide sul vero scopo del markup AudioObject e sulle distinzioni che spesso creano confusione. Scegli una risposta per ciascuna, poi controlla.

Risorse che vale la pena leggere

I miei articoli su questo argomento

Non ho pubblicato una guida AudioObject autonoma e, sinceramente, dato quanto poco questo tipo faccia per Search, non c’è neppure molta copertura di terze parti che valga la pena inseguire. La maggior parte dei riepiloghi sui «tipi di schema» non elenca AudioObject come tipo a sé, cosa che dice qualcosa sulla sua priorità. Invece di riempire questa sezione, il percorso onesto è rimandarti al vocabolario stesso e al lavoro affine sui dati strutturati di questo sito. Per la posizione del markup audio rispetto ai tipi vicini, guarda i fratelli VideoObject e CreativeWork e gli hub più ampi Schema Markup e Structured Data in cui questo articolo è inserito; per l’angolo AI, Schema Markup for AI.

Dalle fonti primarie

• schema.org/AudioObject — definizione del tipo ed elenco completo delle proprietà. Poiché Google non pubblica una guida specifica per una funzione, questo è il riferimento autorevole per il vocabolario.
• Supported structured data types (search gallery) (Google) — l’indice canonico dei tipi che ottengono risultati avanzati. È utile proprio perché AudioObject non compare.
• Video structured data (Google) — dove vive davvero il markup dei clip, unificato sotto VideoObject; non esiste un equivalente AudioObject.
• Podcast Publisher Center help (Google) — il lato di gestione RSS/feed dei podcast, distinto dallo schema nella pagina e da qualsiasi risultato avanzato Search.

Cronologia modifiche