Come aggiungere JSON-LD a un articolo di blog nel 2026
JSON-LD è il formato consigliato da Google. Ecco il markup Article, BreadcrumbList e FAQPage che pubblichiamo su ogni articolo, con codice Next.js.
Alla fine di questa guida avrai tre blocchi JSON-LD su ogni articolo del blog: Article (o BlogPosting), BreadcrumbList e, quando la pagina lo merita, FAQPage. Ogni blocco è valido, viene reso lato server e supera il validatore di schema.org. È esattamente la struttura che pubblichiamo su ogni articolo di questo sito.
JSON-LD sta per JavaScript Object Notation for Linked Data. È il formato di dati strutturati che Google consiglia rispetto a Microdata e RDFa, perché il markup vive in un unico tag <script> invece di intrecciarsi con l'HTML visibile. La separazione è il punto: markup e layout smettono di darsi fastidio e puoi generare il blocco a partire dagli stessi dati che rendono la pagina.
Una premessa onesta prima del codice. Nel 2026 i dati strutturati rendono meno nella ricerca Google classica rispetto a due anni fa. Ad agosto 2023 Google ha limitato i rich result FAQ ai siti autorevoli di ambito governativo e sanitario, e il 7 maggio 2026 ha smesso del tutto di mostrarli in ricerca. I rich result HowTo sono stati ritirati da desktop a settembre 2023. Quindi il motivo per pubblicare questo markup oggi non è uno snippet con le stelline. È la leggibilità automatica per i motori che ora stanno davanti al tuo funnel: ChatGPT, Perplexity, Gemini e le AI Overview di Google leggono i dati strutturati per capire di cosa parla una pagina e se citarla.
Cosa ti serve prima di iniziare
- Un blog con pagine articolo rese lato server. Se il testo dell'articolo viene iniettato da JavaScript nel browser, risolvi prima quello: crawler e motori AI hanno bisogno del contenuto e del markup già nell'HTML iniziale.
- Un URL canonico stabile e assoluto per articolo (https://tuodominio.com/blog/slug).
- I metadati reali dell'articolo al momento del render: titolo, data di pubblicazione, data di ultimo aggiornamento, autore, URL dell'immagine di copertina, categoria.
- Accesso a validator.schema.org e al Rich Results Test di Google per la verifica.
Passo 1: pubblica un blocco Article su ogni articolo
Article è il tipo base per i contenuti editoriali. Google accetta tre sottotipi: Article, NewsArticle e BlogPosting. Per un blog usa BlogPosting. Eredita tutte le proprietà di Article e segnala che il contenuto è un articolo, non una notizia di agenzia né una pagina statica.
Le linee guida di Google non elencano più campi strettamente obbligatori, ma si aspettano headline e image, e leggono datePublished, dateModified, author e publisher per capire freschezza e provenienza. Ecco il blocco che pubblichiamo:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://yourdomain.com/blog/json-ld-guide#article",
"headline": "How to add JSON-LD to a blog article",
"image": "https://yourdomain.com/covers/json-ld.jpg",
"datePublished": "2026-07-04T09:00:00Z",
"dateModified": "2026-07-04T09:00:00Z",
"author": { "@type": "Organization", "name": "Your Studio" },
"publisher": {
"@type": "Organization",
"name": "Your Studio",
"logo": { "@type": "ImageObject", "url": "https://yourdomain.com/logo.png" }
},
"mainEntityOfPage": "https://yourdomain.com/blog/json-ld-guide"
}Due dettagli che quasi tutti sbagliano. Tieni headline sotto i 110 caratteri, perché Google tronca quelli più lunghi. E imposta dateModified a partire dal tuo vero segnale di freschezza del contenuto, non da una riga di database che qualsiasi migrazione tocca. Se dateModified mente, il ranking di freschezza ti gioca contro.
Passo 2: aggiungi un BreadcrumbList su ogni pagina
BreadcrumbList dice ai motori dove si colloca la pagina nella gerarchia del sito. Costa poco pubblicarlo, produce ancora la scia dei breadcrumb nella ricerca Google e offre ai motori AI una struttura di percorso pulita su cui ragionare. Pubblicane uno su ogni articolo:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://yourdomain.com/blog" },
{ "@type": "ListItem", "position": 2, "name": "How to add JSON-LD to a blog article", "item": "https://yourdomain.com/blog/json-ld-guide" }
]
}Passo 3: aggiungi FAQPage solo quando la FAQ è reale
FAQPage è ancora un tipo valido di schema.org e Google continua a leggerlo, anche se il rich result visivo è sparito. Resta uno dei blocchi di maggior valore per la citazione AI, perché consegna al motore una coppia domanda-risposta pulita da riprendere alla lettera. C'è una regola non negoziabile: le domande e le risposte nel markup devono esistere, visibili, sulla pagina. Marcare domande che l'utente non vede è una violazione di spam sui dati strutturati, ed è la via più rapida verso un'azione manuale.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Does JSON-LD still help SEO in 2026?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes, for machine-readability. The rich results are mostly gone, but AI engines parse the markup to understand and cite your page."
}
}
]
}Salta questo blocco sugli articoli che non hanno una FAQ vera. Un FAQPage vuoto o gonfiato non aggiunge nulla e attira il flag di spam.
Passo 4: rendilo lato server in Next.js
Poiché JSON-LD è dato, non codice eseguibile, la documentazione di Next.js consiglia un normale tag <script type="application/ld+json"> reso da un Server Component, non il componente next/script. Costruisci l'oggetto, serializzalo e inseriscilo nella pagina o nel layout:
export default function ArticlePage({ post }) {
const jsonLd = buildBlogPosting(post)
return (
<>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify(jsonLd).replace(/</g, "\u003c"),
}}
/>
<Article post={post} />
</>
)
}Il .replace(/</g, "\u003c") non è opzionale. JSON.stringify non fa l'escape delle parentesi angolari, quindi una sequenza </script> dentro un qualsiasi campo (un titolo, una risposta) può uscire dal tag e aprire un buco XSS. Sostituire < con il suo escape Unicode lo chiude. È l'unico dettaglio di sicurezza che quasi tutti i tutorial saltano.
Passo 5: verifica prima di pubblicare
Fai tre controlli, in ordine:
- Validatore schema.org. Incolla l'URL in validator.schema.org. Individua errori di tipo e proprietà malformate.
- Rich Results Test di Google. Conferma che Google riesca a leggere il blocco, anche per i tipi che non producono più un rich result.
- Codice sorgente, non l'inspector. Cerca
application/ld+jsonnell'HTML grezzo. Se compare solo nel DOM idratato e non nel sorgente, è reso lato client e molti crawler lo perderanno.
Errori frequenti e come risolverli
Blocchi duplicati dopo l'idratazione. Un tag script messo in un Server Component può essere reso due volte: una nell'HTML del server, una quando React idrata. Rendilo una sola volta, in alto nell'albero, e verifica che nel sorgente ci sia un unico blocco.
dateModified che si scosta dalla realtà. Se una qualsiasi scrittura aggiorna la colonna updated_at, non collegarci dateModified. Ancoralo a un vero segnale di aggiornamento editoriale, altrimenti i motori imparano che le tue date di freschezza sono rumore.
Markup di contenuto invisibile. Il markup FAQ o HowTo il cui testo non è sulla pagina viola le policy di Google sui dati strutturati. Tieni il markup uno specchio di ciò che il lettore vede.
URL relativi per immagini o @id. Usa URL assoluti https ovunque nel JSON-LD. I percorsi relativi si risolvono in modo incoerente tra i vari parser.
E HowTo?
Pubblica un blocco HowTo solo su articoli davvero procedurali, un passo-passo come questo. Google ha rimosso i rich result HowTo da desktop a settembre 2023, quindi non c'è resa visiva, ma il markup aiuta comunque un motore AI a ricostruire i tuoi passi in ordine. Tieni il text di ogni passo corto e concreto, e punta l'url di ogni passo al titolo corrispondente.
Questo è tutto lo stack: BlogPosting e BreadcrumbList su ogni articolo, FAQPage quando le domande sono reali, HowTo quando l'articolo è procedurale. Quattro blocchi, tutti resi lato server, tutti validati. Per la mappa più ampia di quali tipi di schema meritano un posto su un blog, leggi il nostro articolo sui 7 tipi di schema markup che ogni blog serve. Per capire perché questo markup conta più per i motori AI che per Google oggi, leggi cos'è la GEO e in cosa differisce dalla SEO.
Domande frequenti
- Devo usare Article o BlogPosting per un articolo di blog?
- Usa BlogPosting. È un sottotipo di Article pensato per i contenuti di blog ed eredita tutte le proprietà di Article, quindi non perdi nulla e ottieni un segnale più preciso. Tieni NewsArticle per il giornalismo con scadenza temporale e usa Article generico solo quando una pagina non è né un articolo né una notizia.
- JSON-LD va nel <head> o nel <body>?
- Vanno bene entrambi. Google e i crawler AI accettano un tag script JSON-LD in qualsiasi punto del documento. Ciò che conta è che sia presente nell'HTML reso lato server, non iniettato dopo dal JavaScript del browser. Scegli un punto, mantienilo coerente e verificalo nel codice sorgente.
- Mi serve ancora JSON-LD se ho già Open Graph e meta tag?
- Sì, perché fanno cose diverse. Open Graph controlla come appare un link quando viene condiviso sulle piattaforme social. I meta tag descrivono la pagina a browser e crawler di base. JSON-LD descrive entità e relazioni (chi ha scritto questo, quando, in quale categoria) in una forma che motori di ricerca e modelli AI leggono per capire e citare la pagina. Si completano a vicenda: nessuno sostituisce gli altri.
- Quanti blocchi JSON-LD può avere una pagina?
- Tanti quanti la pagina descrive onestamente. Un articolo di blog ne porta spesso tre o quattro: BlogPosting, BreadcrumbList e, facoltativi, FAQPage o HowTo. Puoi pubblicarli come tag script separati oppure combinarli in un unico array @graph. I parser gestiscono entrambi. L'unico limite è la pertinenza: ogni blocco deve descrivere contenuto davvero presente sulla pagina.
Studio
Inizia un progetto.
Un partner unico per il prodotto digitale che devi costruire. Produzione più veloce, tecnologie moderne, costi ridotti. Un team, una fattura.