Dati strutturati su WordPress: come aggiungerli agli articoli senza duplicare il plugin

Aggiungere i dati strutturati a un articolo su WordPress, nove volte su dieci, non vuol dire scrivere codice nuovo. Vuol dire leggere il JSON-LD che il plugin SEO genera già, capire quali proprietà mancano o sono sbagliate e completarle nel punto giusto, senza creare un secondo blocco che contraddice il primo.

Le guide italiane su questo tema partono quasi tutte da zero: cos'è Schema.org, l'elenco dei plugin, il copia e incolla del codice. Ma WordPress è usato dal 40,1% di tutti i siti web secondo W3Techs (rilevazione di ottobre 2026, dato mondiale), Yoast SEO dichiara oltre 10 milioni di installazioni attive e Rank Math oltre 4 milioni. Chi apre questa pagina ha quasi sempre un grafo già attivo, e il lavoro vero è sistemarlo.

Per capire dove si sbaglia di solito, il 7 ottobre 2026 ho letto il markup delle pagine che si posizionano in prima pagina su Google.it proprio per le ricerche su come aggiungere i dati strutturati. I risultati sono nella tabella più sotto, e dicono più di qualsiasi elenco di consigli.

Prima di aggiungere qualcosa, guarda cosa c'è già

Il controllo richiede due minuti. Apri un articolo pubblicato, visualizza il sorgente della pagina e cerca application/ld+json. Se usi Yoast troverai un blocco con la classe yoast-schema-graph, con Rank Math uno con rank-math-schema, con All in One SEO uno con aioseo-schema. Dentro c'è un @graph: una lista di nodi collegati tra loro tramite @id, di solito Organization, WebSite, WebPage, Article, BreadcrumbList e Person.

Se i blocchi ld+json sono due o più, chiediti da dove arriva ciascuno. Le fonti tipiche di un secondo blocco sono il tema, un plugin di recensioni, un page builder, un tag inserito anni fa in Google Tag Manager. Due blocchi non sono un errore in sé: le linee guida generali di Google ammettono sia elementi annidati sia elementi separati, e consigliano @id per collegarli. Il problema nasce quando due fonti descrivono la stessa cosa in modo diverso, per esempio due Organization con nomi differenti o due Article con autori diversi.

Per leggere il grafo senza decifrare il JSON a mano ci sono due strumenti gratuiti. Il Rich Results Test di Google dice se la pagina è idonea a un risultato arricchito supportato. Lo Schema Markup Validator mostra tutti i nodi, anche quelli che Google non trasforma in nulla di visibile. Per un articolo di blog serve soprattutto il secondo, perché Article non produce un rich result dedicato e il Rich Results Test tende a dire poco.

Cosa c'è nel markup delle guide italiane sul tema

Ho preso i risultati organici della prima pagina di Google.it per «dati strutturati wordpress» e «come aggiungere dati strutturati», ho tolto le pagine che non sono articoli (documentazione cloud, centri assistenza) e ho scaricato le 15 URL rimaste. Due non hanno risposto (un timeout e un 403), le altre 13 le ho analizzate estraendo ogni blocco JSON-LD e contando tipi, proprietà dell'articolo e nodi autore.

La parte tecnica, quella che un plugin fa da solo, è quasi sempre a posto: date, immagine, breadcrumb. Le quattro anomalie, invece, non hanno niente di tecnico. Una guida evergreen del 2018 è marcata come NewsArticle, cioè come notizia. Un sito ha aggiunto a mano un secondo BreadcrumbList che elenca tre articoli scollegati invece del percorso della pagina. Un altro dichiara come autore una Person che ha il nome di una società a responsabilità limitata. Il quarto ha l'@id dell'articolo su un dominio di staging, rimasto lì dopo la messa online.

Sono errori di impostazione, non di codice: nessun validatore li segnala, perché sintatticamente il JSON è corretto. È anche il motivo per cui il controllo va fatto con gli occhi e non solo con lo strumento.

Le proprietà di Article che contano su un blog

La documentazione di Google sul markup Article, aggiornata l'8 settembre 2026, ha una caratteristica che spiazza chi arriva dalle guide: non ci sono proprietà obbligatorie. Google scrive di aggiungere quelle che si applicano al contenuto. Le raccomandate sono sette, e su WordPress ognuna ha un punto preciso da cui prende il valore.

Tre di queste sette si rompono senza che nessuno se ne accorga. L'immagine manca quando l'articolo non ha un'immagine in evidenza: è l'unico caso della tabella precedente senza image, e i suggerimenti per le dimensioni sono nella guida all'ottimizzazione delle immagini per la SEO. La dateModified si aggiorna anche quando correggi una virgola: su una delle pagine analizzate, una guida pubblicata nel 2018, il markup dichiara una modifica del novembre 2023, mentre il testo indica ancora come strumento ufficiale l'evidenziatore di dati di Search Console e non nomina il Rich Results Test. La data è quella dell'ultimo salvataggio, non dell'ultima revisione. Il nome dell'autore, infine, finisce nel markup esattamente come è scritto nel campo Nome visualizzato del profilo, quindi un «Dott. Mario Rossi, SEO Specialist» va contro l'indicazione di Google di lasciare solo il nome.

L'autore è la parte che i plugin lasciano a metà

Il nodo Person è quello che dice a Google chi ha scritto il pezzo, ed è il collegamento più diretto tra il markup e l'E-E-A-T. Negli 11 articoli con un nodo Article, 3 autori non hanno un URL e 3 non hanno nessun profilo collegato in sameAs. Il grafo di questo blog non fa eccezione: sull'articolo dedicato allo schema markup il nodo Person ha il nome ma né url né sameAs. Lo cito perché è il caso più comune, non il più grave.

Le indicazioni di Google sull'autore sono quattro, e tutte nella pagina Article: ogni autore va nel suo campo author, mai due nomi nello stesso campo; il tipo deve essere Person per una persona e Organization per un'azienda; il nome non contiene qualifiche; l'URL porta a una pagina che identifica quell'autore. Per quella pagina esiste anche un tipo dedicato, ProfilePage, che Google cita espressamente per le pagine autore dei siti di notizie e per le pagine «chi sono» dei blog. Richiede due cose: mainEntity con la persona e il suo name. I profili esterni vanno in sameAs.

Il sameAs dell'autore è il punto in cui il markup aggiunge un'informazione che sulla pagina non c'è in forma leggibile da una macchina: dice che il Mario Rossi del blog è lo stesso Mario Rossi di LinkedIn. È lo stesso meccanismo che usa l'Organization per entrare nel Knowledge Graph.

Article, BlogPosting o NewsArticle

La documentazione Google è esplicita: «Article objects must be based on one of the following schema.org types: Article, NewsArticle, BlogPosting». Per un blog aziendale la scelta pratica è tra Article e BlogPosting, e non cambia nulla nei risultati. Nelle pagine analizzate tutte e sei quelle con Rank Math usavano BlogPosting. NewsArticle ha senso solo se pubblichi notizie con una data che conta, come una testata o la sezione news di un'azienda quotata. Su una guida che resta valida per anni è un'informazione falsa, piccola ma falsa.

Su Yoast il tipo si cambia per singolo post nella scheda Schema del box del plugin, e per tutti gli articoli nelle impostazioni dei tipi di contenuto. Su Rank Math lo stesso passaggio sta nel generatore di schema del post e nei valori predefiniti per gli articoli. Prima di cambiarlo, controlla che nessun'altra fonte sul sito dichiari un secondo Article.

Come aggiungere ciò che manca senza duplicare

Ci sono quattro strade, in ordine dalla più sicura alla più fragile. La regola che le tiene insieme è una: estendere il grafo che esiste invece di affiancargliene un altro.

1. Le impostazioni del plugin. È la strada che risolve la maggior parte dei casi della tabella: nome dell'organizzazione e logo, tipo di articolo predefinito, archivio autore attivo, campi social del profilo utente compilati. Se usi già un plugin SEO, il confronto tra le opzioni sta nella guida ai plugin SEO per WordPress. Due plugin SEO attivi insieme producono due grafi completi sulla stessa pagina: va tenuto uno solo.

2. I filtri del plugin, in PHP. Yoast espone una Schema API con un filtro per ogni nodo: wpseo_schema_article, wpseo_schema_person, wpseo_schema_organization, wpseo_schema_breadcrumb, wpseo_schema_webpage, più wpseo_schema_graph_pieces per aggiungere un nodo intero. Un esempio che completa il nodo autore con un profilo esterno, da mettere in un plugin personalizzato o nel functions.php del tema child:

add_filter( 'wpseo_schema_person', function ( $data ) {
    $data['sameAs']   = isset( $data['sameAs'] ) ? (array) $data['sameAs'] : array();
    $data['sameAs'][] = 'https://www.linkedin.com/in/nome-autore/';
    return $data;
} );

Il vantaggio rispetto a un blocco scritto a mano è che il nodo resta collegato al resto del grafo tramite lo stesso @id, quindi l'Article continua a puntare alla stessa Person. Rank Math offre filtri analoghi nella sua documentazione per sviluppatori.

3. Google Tag Manager. Google documenta questo metodo (pagina aggiornata il 10 dicembre 2025): un tag HTML personalizzato con il JSON-LD dentro e le variabili di GTM per leggere i valori dalla pagina, «instead of duplicating the information in GTM». Funziona, ma il markup esiste solo dopo il rendering JavaScript, e Google avverte che sul markup Product questo può rendere le scansioni Shopping meno frequenti e meno affidabili. Per un articolo il rischio è minore; resta il fatto che il JSON-LD vive in un posto che chi gestisce il sito spesso non guarda, e che non compare nel sorgente HTML, quindi il controllo dei due minuti descritto sopra non lo vede.

4. Il blocco HTML dentro l'articolo. Incollare uno <script type='application/ld+json'> in un blocco HTML personalizzato di Gutenberg è la strada che si vede nei tutorial. La sconsiglio per due motivi: su molti siti gli utenti con ruolo Autore non hanno il permesso di salvare tag script, e il blocco resta scollegato dal grafo del plugin, quindi crea esattamente il secondo Article con dati diversi che bisogna evitare. L'unico uso sensato è un tipo che il plugin non gestisce, su una sola pagina.

VideoObject, FAQ e HowTo dentro un articolo

Un articolo di blog spesso contiene altro: un video, una sezione di domande, una procedura. Il markup per ciascuno ha avuto una storia diversa negli ultimi anni.

VideoObject resta utile: è il tipo che rende idoneo il video ad anteprime e momenti chiave, e i dettagli sono nella guida alla SEO per i video. FAQPage invece non produce più niente: la documentazione Google indica che il risultato FAQ non compare nella Ricerca dal 7 maggio 2026, e che il supporto è stato tolto dal Rich Results Test e dai report di Search Console. Quattro delle tredici pagine analizzate lo dichiarano ancora. Non è un errore, Google non penalizza markup che non usa, ma chi ha scritto le FAQ solo per l'accordion in SERP può rivedere a cosa servono: ne parlo nell'articolo sulle FAQ in ottica SEO. HowTo non genera risultati arricchiti da settembre 2023.

Sugli altri CMS il ragionamento è lo stesso

Shopify, Wix, Squarespace e Webflow generano una parte del markup dal tema o dalla piattaforma, e la quantità cambia da tema a tema. Il metodo non cambia: sorgente della pagina, conteggio dei blocchi ld+json, lettura nel validatore, aggiunta solo di ciò che manca. Le differenze di ogni piattaforma, comprese le app che aggiungono un secondo grafo, sono nelle guide alla SEO per Shopify e alla SEO per Wix. Su WordPress il quadro completo, dal markup alla velocità, è nella guida alla SEO per WordPress.

Come si controlla su tutto il blog, non su una pagina

Rich Results Test e Schema Markup Validator lavorano su una URL alla volta. Per un blog con centinaia di articoli servono due strumenti diversi. Il report dei miglioramenti in Google Search Console mostra errori e avvisi sui tipi che Google supporta, sull'intero sito. Screaming Frog SEO Spider, con l'estrazione e la validazione dei dati strutturati attive nella configurazione della scansione, restituisce per ogni URL i tipi trovati e gli errori rispetto a Schema.org e alle regole di Google.

Nell'export della scansione conviene cercare tre cose, le stesse che sono saltate fuori nell'analisi: pagine con due nodi dello stesso tipo, articoli senza image, URL nel markup che non appartengono al dominio di produzione. Il controllo rientra nella SEO tecnica di base, e conviene ripeterlo dopo ogni cambio di tema o di plugin.

Cosa non aspettarsi dal markup di un articolo

Il markup Article non sposta la posizione. Lo dice indirettamente Google stessa: un'azione manuale sui dati strutturati, si legge nelle linee guida, fa perdere l'idoneità ai rich result e «doesn't affect how the page ranks in Google web search».

Non aumenta nemmeno le citazioni nelle risposte AI, almeno sulle pagine già visibili. Lo studio di Ahrefs firmato da Louise Linehan ha seguito 1.885 pagine che hanno aggiunto JSON-LD tra agosto 2025 e marzo 2026, confrontate con 4.000 pagine di controllo: +2,4% di citazioni su Google AI Mode e +2,2% su ChatGPT, entrambe non statisticamente significative, e un calo del 4,6% sugli AI Overviews. Il campione è globale e limitato a pagine che ricevevano già più di 100 citazioni al mese negli AI Overviews. Un dato italiano equivalente non esiste. Il ragionamento completo su cosa rende il markup e cosa no è nell'articolo sullo schema markup nel 2026.

Quello che il markup di un articolo fa davvero è togliere ambiguità su due informazioni: chi l'ha scritto e quando. Se ti serve qualcuno che metta in ordine il grafo insieme al resto del sito, rientra nel lavoro di consulenza SEO, e per la visibilità nelle risposte dei modelli linguistici c'è il servizio di SEO per l'AI.

Una cosa che si dice poco: le quattro anomalie trovate quasi certamente non le ha decise chi ha scritto l'articolo. Il dominio di staging, la società registrata come persona, il breadcrumb aggiunto a mano in un secondo blocco, il tipo notizia su una guida: secondo me sono tutte impostazioni decise una volta, al lancio o a un cambio di tema, e mai più riguardate. Il markup di un blog invecchia con le migrazioni più che con i contenuti. Per questo il controllo del grafo va messo nella checklist di ogni riprogettazione del sito, accanto ai redirect, e non nel piano editoriale.

Domande frequenti sui dati strutturati in WordPress