Schema Article: marcare articoli e news con i dati strutturati

Lo schema Article è il vocabolario di schema.org con cui dichiari a Google che una pagina è un articolo, e ne descrivi titolo, autore, date e immagini in un formato leggibile da una macchina. Non è obbligatorio, non garantisce un risultato speciale e non si traduce in un boost di posizionamento. Serve a togliere ambiguità: la pagina è davvero un contenuto editoriale, chi l'ha scritto, quando è uscito e quando è stato aggiornato.

La parte che crea più confusione è la scelta del tipo. Article, NewsArticle e BlogPosting sono tre tipi imparentati, e molti siti usano quello sbagliato per abitudine o perché lo ha scelto un plugin. In questa guida vediamo la gerarchia, i campi che contano davvero, come trattare date e autore senza creare incoerenze e quali errori vengono fuori più spesso quando si controlla il markup di un sito editoriale.

Article, NewsArticle e BlogPosting: la gerarchia dei tipi

In schema.org i tre tipi sono in relazione di parentela. Article è il tipo generale. NewsArticle e BlogPosting sono sottotipi di Article, e ne ereditano tutte le proprietà. Esiste anche un ramo più specifico, per esempio per i resoconti di cronaca o per le pagine di reportage, ma nella pratica quotidiana di un sito si sceglie quasi sempre fra questi tre.

Questo significa che nessuna scelta è tecnicamente un errore: un post di blog marcato come Article è valido, così come un articolo giornalistico marcato come BlogPosting. La differenza sta nella precisione semantica, che conta quando un sistema deve capire che cosa ha davanti. Un motore che legge NewsArticle si aspetta un contenuto legato all'attualità, con una data di pubblicazione che ha un peso. Un BlogPosting dichiara un registro più personale e periodico.

Il criterio pratico è guardare la natura della pagina, non il nome della sezione del sito. Una guida evergreen pubblicata sotto la cartella /news/ non diventa una notizia. Al contrario, un comunicato di aggiornamento su un fatto recente, pubblicato nel blog aziendale, può essere una notizia a pieno titolo.

• Article: la scelta neutra per contenuti editoriali che non sono né notizie né post di blog in senso stretto, come guide, approfondimenti e analisi.
• BlogPosting: adatto ai post di un blog, aziendale o personale, con taglio di opinione, tutorial o aggiornamento periodico.
• NewsArticle: per articoli di attualità pubblicati da una testata o da un sito che fa informazione, dove la data di uscita è parte del valore del contenuto.

Quale tipo scegliere nei casi dubbi

Se hai un dubbio reale, Article è la risposta prudente. Dichiararsi NewsArticle senza essere una fonte di notizie è il caso più rischioso, perché fa una promessa sulla natura del contenuto che il resto del sito non mantiene. Per i siti che fanno informazione, poi, vale anche un ragionamento editoriale: chi compare nelle superfici dedicate alle notizie di Google è soggetto a criteri separati, che riguardano trasparenza su autori e redazione, non il tipo di dato strutturato.

Un esempio concreto: un negozio online ha un blog con tre tipi di contenuto. Le guide all'acquisto evergreen, i racconti dal laboratorio e gli avvisi su una variazione dei tempi di consegna dovuta a uno sciopero. Le prime si marcano come Article, i secondi come BlogPosting, il terzo può essere un NewsArticle se è davvero un avviso di attualità con una data che conta. Nessun template dovrebbe però forzare un unico tipo su tutte e tre le categorie senza distinguere.

Un errore frequente è usare tipi diversi per la stessa pagina in punti diversi del codice: il tema dichiara BlogPosting, il plugin SEO aggiunge Article, un secondo plugin di condivisione inserisce NewsArticle. Il risultato è una pagina con tre entità concorrenti che descrivono lo stesso contenuto. Conviene avere un'unica fonte di verità per il markup e disattivare le altre.

I campi che contano: obbligatori, consigliati, facoltativi

La documentazione di Google sul markup degli articoli non indica proprietà strettamente obbligatorie: il documento elenca solo proprietà consigliate. Questo non vuol dire che si possa marcare una pagina vuota. Più il markup è completo e coerente con il contenuto visibile, più è utile a chi lo legge. La scelta dei campi va fatta su questa logica, non sulla caccia a un segno di spunta verde nei test.

Le proprietà che in pratica non dovrebbero mai mancare sono poche e sono tutte verificabili dal visitatore leggendo la pagina.

• headline: il titolo dell'articolo. Deve corrispondere a ciò che si vede nella pagina. Google avverte di tenerlo conciso, quindi evita di infilarci sottotitoli e slogan.
• author: una Person o un'Organization, con name e, se possibile, url verso una pagina che presenta l'autore.
• datePublished: data e ora di pubblicazione in formato ISO 8601.
• dateModified: data e ora dell'ultima modifica sostanziale, sempre in ISO 8601.
• image: una o più immagini rappresentative, raggiungibili da Google e coerenti con la pagina.
• mainEntityOfPage: l'URL canonico della pagina che contiene l'articolo, utile a legare l'entità alla pagina.
• publisher: l'organizzazione che pubblica, con nome e logo. Non è tra le proprietà richieste da Google per l'articolo, ma descrive bene il contesto editoriale.

Le date: datePublished, dateModified e i problemi di fuso orario

Le date sono il punto dove il markup degli articoli sbaglia più spesso, e in modo silenzioso. Il formato corretto è ISO 8601, con data, ora e fuso, per esempio 2026-09-30T08:30:00+02:00. Una data senza fuso orario è ammessa, ma lascia al motore l'interpretazione e può produrre uno scarto di ore, che diventa un giorno intero vicino alla mezzanotte.

Il secondo problema è la coerenza con ciò che vede l'utente. Se la pagina mostra 'Pubblicato il 12 marzo' e il JSON-LD dichiara 2026-03-14, hai creato una discrepanza che un controllo editoriale o un sistema automatico può notare. Le date nel markup devono derivare dallo stesso campo del database che alimenta la data visibile, non da un secondo campo compilato a mano.

Il terzo problema è dateModified. Aggiornarlo a ogni salvataggio, anche per una virgola corretta, è una scorciatoia che svaluta il segnale: quando una data di modifica cambia ogni giorno senza che il testo cambi davvero, smette di dire qualcosa. Google indica di non presentare come aggiornato un contenuto che non lo è. Regola pratica: dateModified si muove quando cambia l'informazione (un dato, un passaggio, una raccomandazione), non quando cambia la punteggiatura.

Infine, se il tema mostra la data in pagina, meglio mostrare sia quella di pubblicazione sia quella di aggiornamento quando le due differiscono in modo significativo. Il lettore capisce quanto fidarsi, e il markup riflette ciò che la pagina già dice.

L'autore: Person, Organization e pagine autore

Per l'autore Google chiede un oggetto Person o Organization, con almeno la proprietà name. Il valore deve contenere solo il nome: titoli come 'Dott.', qualifiche professionali o la frase 'a cura della redazione' nel campo name sono un uso scorretto. Se c'è più di un autore, si usa un array di oggetti, uno per persona.

La proprietà url dell'autore dovrebbe puntare a una pagina che identifichi quella persona: una scheda sul sito con biografia, altri articoli e collegamenti ai profili professionali. A questo scopo si può usare anche sameAs, con gli indirizzi dei profili esterni. Non sono campi decorativi: aiutano a capire che l'autore di un articolo è la stessa entità di un altro articolo, invece di due stringhe di testo simili.

Quando non c'è un autore umano ha senso dichiarare l'organizzazione, ma solo se è davvero quello che succede. Marcare un nome fittizio o un profilo di fantasia per sembrare più autorevoli è una pratica da evitare: il markup deve descrivere un fatto, non costruire una reputazione. Lo stesso vale per un autore che compare nel markup ma non in nessun punto della pagina visibile.

Immagini e titolo: i dettagli che sfuggono

Per le immagini, Google consiglia di fornire più versioni con proporzioni diverse, per esempio 16:9, 4:3 e 1:1, in modo che i diversi punti di visualizzazione possano scegliere quella più adatta. Le immagini devono essere scansionabili e indicizzabili, quindi non bloccate da robots.txt, e devono rappresentare l'articolo, non essere un logo generico usato per tutte le pagine.

Sul titolo vale una distinzione utile: headline non è necessariamente uguale al tag title della pagina. Il title è scritto per la pagina dei risultati e può contenere il nome del sito; l'headline è il titolo dell'articolo come lo leggerebbe il lettore sopra il testo. Se i due coincidono non c'è nulla di male, ma non serve copiare ossessivamente uno nell'altro.

Un altro dettaglio: il contenuto del markup deve essere visibile anche nella pagina. Se nel JSON-LD metti una descrizione, un'immagine o un autore che l'utente non trova da nessuna parte, stai dichiarando cose non verificabili, e le linee guida sui dati strutturati sono chiare sul fatto che il markup deve rispecchiare il contenuto reale.

Un esempio di JSON-LD per un articolo di blog

Il formato consigliato da Google è JSON-LD, inserito in un blocco script di tipo application/ld+json nella pagina. Descriviamo la struttura di un BlogPosting ben fatto senza riportare il codice riga per riga, così puoi adattarla al tuo template.

L'oggetto radice ha @context impostato su schema.org e @type su BlogPosting. Dentro ci sono headline con il titolo dell'articolo, mainEntityOfPage con l'URL canonico e image con un array di tre indirizzi di immagini. Poi datePublished e dateModified, entrambi con ora e fuso. La proprietà author è un oggetto Person con name e url verso la scheda autore, e publisher è un oggetto Organization con name e logo.

Se la pagina appartiene a un sito con più entità, per esempio un'organizzazione e un sito web, si può usare @graph per raccoglierle in un unico blocco e collegarle con identificatori @id. Il vantaggio è che l'autore e l'editore vengono dichiarati una volta e richiamati da ogni articolo, invece di essere riscritti ogni volta con piccole differenze.

Errori comuni e come controllarli

Il controllo si fa in due passaggi. Il Rich Results Test di Google mostra se la pagina è idonea a funzionalità specifiche e segnala problemi sulle proprietà che Google usa. Lo Schema Markup Validator, invece, verifica la correttezza rispetto al vocabolario schema.org in generale, anche per tipi e proprietà che Google non sfrutta. Usarli entrambi evita di concludere che tutto va bene solo perché uno dei due non segnala nulla.

Dopo la pubblicazione, Search Console non offre un rapporto dedicato al markup Article, quindi conviene controllare periodicamente il sito con un crawler che estrae i dati strutturati di tutte le pagine. Per un blog con centinaia di pagine è l'unico modo realistico di accorgersi che un aggiornamento del tema ha rotto il markup a tutti gli articoli.

• Markup duplicato: tema e plugin che generano ciascuno un proprio blocco Article sulla stessa pagina.
• Date non coerenti con la pagina visibile, o senza fuso orario.
• dateModified aggiornato automaticamente a ogni salvataggio o a ogni caricamento della pagina.
• Autore indicato come stringa semplice, con qualifiche nel campo name, oppure con un profilo inesistente.
• Immagine che rimanda a un file bloccato, reindirizzato o generico.
• Tipo NewsArticle applicato a guide evergreen e pagine di prodotto.
• Markup Article su pagine che non sono articoli, come categorie, tag o pagine archivio.