Il formato leggibile per una persona non è sempre quello giusto per i dati strutturati. Un caso RSWT e una procedura per verificare il markup del blog.
Il blog può mostrare una data corretta al lettore e inviarne una ambigua ai motori di ricerca. Controllare lo schema Article significa verificare questa seconda versione della pagina: titolo, autore, immagini e date descritti nel codice. Non serve aggiungere campi a caso. Serve rendere coerente ciò che il sito pubblica.
Risposta rapida. Verifica che Article descriva l'articolo visibile, che l'autore sia identificabile e che datePublished e dateModified usino un formato ISO 8601. Se l'errore si ripete su più articoli, correggi il generatore nel CMS o nel template. Non inserire un secondo schema nel corpo per coprire il primo.
In breve: cosa trovi in questa guida
A cosa serve lo schema Article
I dati strutturati sono informazioni organizzate secondo un vocabolario condiviso. In un blog il tipo Article, o un suo tipo più specifico come BlogPosting, descrive un contenuto editoriale. JSON-LD è uno dei formati con cui queste informazioni possono essere inserite nella pagina.
Per chi gestisce il sito la domanda utile è semplice: il codice descrive davvero ciò che il lettore vede? Un nome autore diverso, una copertina non raggiungibile o una data aggiornata automaticamente a ogni visita rendono la risposta meno affidabile, anche se il blocco JSON si può leggere senza errori.
Google Search Central, nella documentazione Article consultata nel 2026, presenta le proprietà consigliate e gli esempi di implementazione. Non descrive il markup come un acquisto di visibilità. Per Article non elenca proprietà obbligatorie: questo non significa che qualunque valore inserito sia corretto.
Il problema che abbiamo trovato nel nostro blog
Il 19 settembre 2026 abbiamo controllato il codice della pagina CMS proprietario italiano: perché l'abbiamo scelto. Lo schema Article conteneva datePublished con valore "09/05/2026" e dateModified con valore "2026-05-09 11:00:20".
Il primo valore usa il formato giorno/mese/anno destinato normalmente al lettore italiano. Il secondo contiene data e ora, ma non esplicita il fuso e usa uno spazio come separatore. Per un'integrazione interoperabile proponiamo al team tecnico un'uscita coerente in ISO 8601, con T e offset quando si pubblica anche l'ora.
Lo stesso formato italiano di datePublished compare nelle due pagine introduttive del corso PHP, con valori "22/03/2025" e "12/09/2025". La ripetizione è un indizio di un comportamento condiviso dal generatore. Per attribuirlo a una funzione precisa occorre leggere il codice del CMS: l'HTML pubblico non permette di identificarla.
Il rilievo è ancora distinto dalla correzione. In questa verifica abbiamo documentato l'output, non modificato il template. Non attribuiamo a quel formato una perdita di ranking misurata. Rendere leggibile una data è un requisito di qualità tecnica; dimostrare un effetto sulle visite richiede altre evidenze.
I campi da controllare prima di aggiungerne altri
| Campo | Domanda da fare | Errore da evitare |
|---|---|---|
| @type | Il contenuto è un articolo, un post o una notizia? | Scegliere NewsArticle soltanto per sperare di apparire nelle notizie |
| headline | Il titolo descrive lo stesso contenuto dell'H1? | Una promessa nel codice che non compare nella pagina |
| author | Nome e pagina autore identificano chi firma? | Attribuire il testo a una persona che non ne è responsabile |
| image | L'immagine è pertinente e raggiungibile? | Un URL provvisorio, protetto o inesistente |
| datePublished | È la data di prima pubblicazione dell'articolo? | Riscriverla a ogni aggiornamento per sembrare più recenti |
| dateModified | Indica un aggiornamento effettivo? | Usare sempre l'ora attuale del server |
Per capire i tipi di valore, consulta anche Schema.org: datePublished e Schema.org: DateTime, verificati nel 2026. Una data senza orario può essere rappresentata come "2026-05-09". Se disponi anche dell'ora, devi sapere quale fuso rappresenta prima di aggiungere un offset.
"2026-05-09T11:00:20+02:00" è un esempio di forma esplicita, valido come rappresentazione di un orario con quell'offset. Non è una correzione automatica del dato RSWT: non abbiamo verificato il fuso con cui il CMS memorizza quella specifica ora. Aggiungere Z a un orario italiano senza conversione, per esempio, cambierebbe l'istante dichiarato.
Come controllare il markup in modo ripetibile
Scegli un piccolo campione. Includi un articolo vecchio, uno recente e uno aggiornato. Annota URL, data della verifica e comportamento atteso.
Apri il sorgente della pagina. Cerca application/ld+json e individua Article, BlogPosting o NewsArticle. Se i dati vengono inseriti via JavaScript, controlla anche il DOM renderizzato negli strumenti del browser.
Leggi i valori effettivi. Non fermarti alla presenza del nome del campo. Confronta date, autore, titolo e immagine con la pagina visibile.
Separa sintassi e significato. Un JSON valido può contenere un giorno inesistente, un autore errato o una data di pubblicazione futura.
Controlla la conformità con strumenti dedicati. Usa il validatore Schema.org e, per le funzionalità supportate da Google, il Test dei risultati avanzati. Conserva messaggi e avvisi con l'URL analizzato.
Ripeti dopo il rilascio. Controlla gli stessi URL pubblici, non soltanto un'anteprima del pannello. Cache e template diversi possono produrre output diversi.
Puoi iniziare dal validatore Schema.org. Un esito favorevole di un validatore è una verifica tecnica, non la prova che Google abbia già aggiornato l'indice o scelto di mostrare una particolare presentazione del risultato.
Cosa deve contenere la richiesta al team tecnico
Una segnalazione utile non dice soltanto "sistemare la SEO". Riporta URL campione, valore attuale, regola attesa, sorgente del dato e controllo da ripetere dopo il rilascio. Nel nostro caso: eliminare la formattazione locale dal dato macchina e mantenere separata la data presentata al lettore.
Il team deve verificare dove nasce il valore: database, modello, template o serializzazione finale. La soluzione va applicata nel punto condiviso corretto. Se il pannello mostra la data in italiano, non è necessario cambiare anche l'interfaccia: presentazione umana e rappresentazione macchina hanno esigenze diverse.
Prima del rilascio, chiedi prove su prima pubblicazione, modifica successiva e passaggio fra ora solare e legale. Verifica inoltre che un semplice caricamento della pagina non cambi dateModified. Se l'orario originale non è disponibile, non ricostruirlo inventandolo.
Evita la scorciatoia di incollare un secondo Article nel corpo: rischia di lasciare informazioni discordanti e non risolve il difetto condiviso. È lo stesso principio che usiamo nella diagnosi delle sovrapposizioni editoriali: prima si chiarisce l'origine del problema, poi si sceglie l'intervento.
FAQPage non è una promessa di spazio aggiuntivo su Google
Le domande frequenti hanno valore se sciolgono dubbi reali del lettore. Il relativo schema è una descrizione di quei contenuti, non un motivo per aggiungere domande ripetitive. Nel registro ufficiale degli aggiornamenti Google del 2026, la voce dell'8 maggio segnala che i risultati avanzati FAQ non vengono più mostrati nella Ricerca dal 7 maggio 2026.
Di conseguenza, non presentiamo FAQPage come un'opportunità garantita di ottenere rich result. Il CMS può continuare a generarlo dalle FAQ utili inserite nei campi dedicati; il beneficio editoriale va valutato nella pagina, senza promettere visualizzazioni speciali o vantaggi automatici nei sistemi AI.
Un markup corretto non decide quali archivi debbano essere proposti alla ricerca: per quel passaggio serve una policy per le pagine tag, basata sulla loro utilità.
Quale priorità dare alla correzione
Se il sito non è accessibile o una pagina importante è esclusa dall'indice per errore, quei problemi vengono prima. Se invece il blog funziona e il formato data errato compare sistematicamente, correggere il generatore evita di replicare l'incoerenza a ogni nuovo articolo.
Il markup non compensa contenuti generici, informazioni commerciali incerte o autori non identificabili. Inseriscilo nella manutenzione SEO del sito, insieme alla verifica dei contenuti visibili. Per un controllo operativo, richiedi una revisione dell'output SEO del CMS: porta URL campione ed errori osservati, così la richiesta può diventare un intervento tecnico verificabile.
