Schema Markup 2026: come ottimizzare i dati strutturati per le AI Overviews di Google

Le AI Overviews di Google sono arrivate in Italia a marzo 2025 con un impatto immediato e misurabile sulla SERP: blocchi di risposta sintetizzata che occupano l'intera viewport prima di qualsiasi risultato organico tradizionale. Non si tratta di una funzionalità sperimentale. È la nuova realtà per milioni di query informazionali in italiano.

Il meccanismo è ormai documentato: Google utilizza il suo modello Gemini per aggregare informazioni da più fonti, presentarle in forma di risposta diretta e, in alcuni casi, citare le pagine da cui ha estratto i contenuti. Il click diventa accessorio. La visibilità no.

La domanda che interessa qualunque SEO tecnico è: quali segnali alimentano questo sistema di estrazione? La risposta non è unica, ma un elemento emerge con coerenza nei casi di studio e nella documentazione ufficiale: i dati strutturati. Markup machine-readable che non servono più solo ad abilitare rich snippet nella SERP tradizionale, ma a rendere il contenuto interpretabile da sistemi di intelligenza artificiale che non leggono tra le righe, ma seguono una grammatica precisa.

Questa guida affronta l'implementazione dei dati strutturati in modo tecnico e operativo. Troverai gli schemi più rilevanti per blog e siti aziendali, esempi JSON-LD completi e commentati, i sette errori che compromettono il riconoscimento da parte di Google, le strategie avanzate per intercettare le AI Overviews e un metodo di audit praticabile da subito, con o senza tool a pagamento.

Non è una guida per chi inizia da zero. È per chi implementa schema markup e vuole capire perché, nel 2026, farlo correttamente fa la differenza tra essere citati da un'AI o essere ignorati.

Cosa sono i dati strutturati (e perché non sono solo per i rich results)

HTML per gli umani, schema markup per le macchine

HTML descrive la struttura visiva di una pagina: intestazioni, paragrafi, immagini, link. Un crawler sa che <h1> contiene probabilmente il titolo principale, ma non sa se quella pagina parla di una ricetta, di un evento o di un profilo aziendale. Il markup semantico aggiunge quel livello di interpretazione.

I dati strutturati sono annotazioni formali che dichiarano esplicitamente il tipo di contenuto e le sue proprietà. Seguono un vocabolario condiviso, definito da Schema.org, un progetto collaborativo lanciato nel 2011 da Google, Microsoft, Yahoo e Yandex. Il vocabolario copre oltre 800 tipi di entità, da Article a MedicalCondition, da Product a Event.

Il principio è semplice: invece di lasciare che il motore di ricerca inferisca il significato dal testo, si dichiara esplicitamente "questo è un articolo, pubblicato in questa data, scritto da questo autore, che appartiene a questa organizzazione". L'ambiguità scompare. La fiducia del sistema di parsing aumenta.

Fino al 2024, l'incentivo principale per implementare i dati strutturati era ottenere rich results: stelle di valutazione, sitelink search box, FAQ espandibili nella SERP, carousel di ricette. Funzionalità visive che aumentano il CTR. Utili, ma non critiche.

Con l'avvento delle AI Overviews, l'incentivo si sposta su un piano diverso. Il markup non serve più solo a rendere la SERP più ricca visivamente: serve a rendere il contenuto estraibile da un modello linguistico che deve sintetizzare una risposta. Questa è una distinzione fondamentale.

Come Google usa lo schema markup per costruire le AI Overviews

Google non ha pubblicato documentazione esaustiva su come Gemini utilizza i dati strutturati per generare AI Overviews. Ma dall'analisi delle pagine citate e dai test pubblicati dalla community SEO nel 2025 emergono alcune costanti.

Le pagine che appaiono nelle AI Overviews per query informazionali tendono ad avere:

Schema di tipo Article o BlogPosting con datePublished aggiornata (freschezza del contenuto verificabile dalla macchina)
FAQPage o HowTo che strutturano la risposta in forma già aggregata
author con markup Person e collegamento a Organization
breadcrumbList che segnala la posizione del contenuto nell'architettura del sito

Il pattern logico è comprensibile: un modello che deve generare una risposta sintetica partirà preferibilmente da fonti che hanno già organizzato l'informazione in modo strutturato e verificabile. Una pagina con FAQPage dice esplicitamente: "questa è una domanda, questa è la risposta". Un modello linguistico non deve inferire quella struttura dal testo grezzo.

Inoltre, i dati strutturati contribuiscono alla valutazione E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness). Quando un articolo dichiara un autore con sameAs che punta al profilo LinkedIn verificato, collegato a un'organizzazione con url e logo, Google può correlare quell'identità digitale con segnali di autorevolezza provenienti da altri sistemi.

JSON-LD vs Microdata vs RDFa: quale scegliere nel 2026

Esistono tre formati per implementare i dati strutturati. La scelta non è indifferente.

Formato	Dove si inserisce	Separazione dal contenuto	Supporto Google	Raccomandato
JSON-LD	`<script>` nel `<head>` o nel `<body>`	Alta: il markup non tocca l'HTML	Completo, preferito	Si
Microdata	Attributi inline negli elementi HTML	Bassa: intrecciato con il markup	Completo	No (legacy)
RDFa	Attributi inline, standard W3C	Bassa: intrecciato con il markup	Completo	No (use case specifici)

Google raccomanda esplicitamente JSON-LD nella documentazione ufficiale per gli sviluppatori. Le ragioni sono tecniche e pratiche:

JSON-LD vive in un tag <script type="application/ld+json"> separato dal DOM: modificarlo non richiede di toccare l'HTML della pagina
Può essere iniettato dinamicamente da JavaScript (con alcune cautele, discusse più avanti)
È più facile da validare, versionare e mantenere
Non rischia di introdurre errori di markup nei tag HTML semantici

Microdata e RDFa esistevano prima che JSON-LD diventasse lo standard de facto. Sono ancora supportati, ma il debito tecnico di gestirli in progetti complessi è alto. Nel 2026 non c'è una ragione valida per sceglierli su un progetto nuovo.

I tipi di schema markup più importanti per blog e siti aziendali

Article e BlogPosting

Article è il tipo base per contenuti editoriali. BlogPosting ne è un sottotipo (più specifico, preferibile per post di blog). Entrambi appartengono alla gerarchia Thing > CreativeWork > Article.

Le proprietà essenziali che Google considera per i rich results e per l'indicizzazione semantica sono:

headline: il titolo dell'articolo (non oltre 110 caratteri)
datePublished: data ISO 8601 (es. 2026-03-16)
dateModified: data dell'ultima modifica significativa
author: oggetto Person o Organization
publisher: oggetto Organization con logo
image: URL assoluta di un'immagine rappresentativa

json

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Schema Markup 2026: Come Ottimizzare i Dati Strutturati per le AI Overviews",
  "datePublished": "2026-03-16",
  "dateModified": "2026-03-16",
  "description": "Guida tecnica ai dati strutturati JSON-LD: implementazione, errori comuni e strategie per le AI Overviews di Google.",
  "image": {
    "@type": "ImageObject",
    "url": "https://www.perseodesign.com/images/schema-markup-ai-overviews-2026.jpg",
    "width": 1200,
    "height": 630
  },
  "author": {
    "@type": "Person",
    "name": "Perseo Design",
    "url": "https://www.perseodesign.com/about/",
    "sameAs": ["https://www.linkedin.com/company/perseodesign/"]
  },
  "publisher": {
    "@type": "Organization",
    "name": "Perseo Design",
    "url": "https://www.perseodesign.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.perseodesign.com/images/logo.png",
      "width": 300,
      "height": 60
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.perseodesign.com/blog/schema-markup-dati-strutturati-ai-overviews-2026/"
  }
}

FAQPage e HowTo (i formati preferiti dalle AI per generare risposte)

FAQPage è il tipo di schema con il rapporto implementazione/impatto più alto nel contesto delle AI Overviews. Dichiara esplicitamente coppie domanda-risposta, il formato esatto che un modello linguistico usa per generare risposte sintetiche a query interrogative.

La struttura richiede che ogni coppia sia un oggetto Question con una proprietà acceptedAnswer di tipo Answer.

json

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Cosa sono i dati strutturati e a cosa servono per la SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "I dati strutturati sono annotazioni machine-readable che dichiarano esplicitamente il tipo di contenuto di una pagina e le sue proprietà, seguendo il vocabolario Schema.org. Per la SEO servono a due scopi distinti: abilitare rich results nella SERP tradizionale (stelle, FAQ espandibili, carousel) e rendere il contenuto interpretabile da sistemi AI come Google AI Overviews."
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LD è il formato migliore per i dati strutturati?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Google raccomanda JSON-LD come formato preferito per i dati strutturati. Rispetto a Microdata e RDFa, JSON-LD è separato dall'HTML della pagina, più semplice da mantenere e validare, e può essere iniettato dinamicamente. Per qualsiasi progetto nuovo nel 2026 è la scelta corretta."
      }
    }
  ]
}

HowTo è altrettanto rilevante per contenuti procedurali. Struttura una serie di step con name, text e, opzionalmente, image per ciascuno. Google lo utilizza per generare risposte a query del tipo "come fare X".

json

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Come aggiungere il markup JSON-LD a una pagina WordPress",
  "description": "Procedura tecnica per inserire dati strutturati JSON-LD in WordPress senza plugin, direttamente nel template del tema.",
  "totalTime": "PT15M",
  "supply": [
    {
      "@type": "HowToSupply",
      "name": "Accesso al file functions.php o al tema child"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Aprire il file functions.php",
      "text": "Accedere all'editor del tema in WordPress (Aspetto > Editor del tema) o aprire il file functions.php tramite SFTP nel tema child attivo."
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Aggiungere la funzione di output JSON-LD",
      "text": "Usare il hook wp_head per iniettare il tag script con il markup. Condizionare l'output al tipo di pagina con is_single() o is_page() per evitare markup su pagine non appropriate."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Validare con il Rich Results Test",
      "text": "Incollare l'URL della pagina su https://search.google.com/test/rich-results per verificare che il markup venga rilevato correttamente e non ci siano errori nelle proprietà."
    }
  ]
}

BreadcrumbList (architettura + navigazione)

BreadcrumbList segnala a Google la posizione del documento nell'albero informativo del sito. Ha due funzioni concrete: mostrare il percorso di navigazione nei rich results e rinforzare la struttura del sito per il crawl.

json

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://www.perseodesign.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://www.perseodesign.com/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Schema Markup e AI Overviews 2026",
      "item": "https://www.perseodesign.com/blog/schema-markup-dati-strutturati-ai-overviews-2026/"
    }
  ]
}

Organization e WebSite (segnali di autorità del dominio)

Organization e WebSite non generano rich results, ma sono fondamentali come segnali di identità del dominio. Google li usa per costruire il Knowledge Graph relativo all'entità che gestisce il sito.

WebSite con potentialAction di tipo SearchAction abilita il sitelinks search box, ma a prescindere da questa funzionalità, la dichiarazione esplicita di name, url e sameAs rafforza la correlazione tra il sito e le sue presenze digitali.

json

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Perseo Design",
  "url": "https://www.perseodesign.com",
  "logo": "https://www.perseodesign.com/images/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "customer service",
    "areaServed": "IT",
    "availableLanguage": "Italian"
  },
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Firenze",
    "addressCountry": "IT"
  },
  "sameAs": [
    "https://www.linkedin.com/company/perseodesign/",
    "https://github.com/perseodesign"
  ]
}

Questo tipo di schema va inserito nel <head> di ogni pagina del sito, non solo dell'homepage. Ripetere Organization su ogni pagina non è un errore, è una best practice.

Come implementare correttamente un JSON-LD

Dove inserire il tag script

Il tag <script type="application/ld+json"> può essere inserito nel <head> o nel <body>. Google dichiara esplicitamente di supportare entrambe le posizioni, ma la pratica consolidata, e quella raccomandata per la leggibilità del codice, è nel <head>.

Il posizionamento nel <head> garantisce che il markup sia disponibile al parser prima del rendering del body, il che è rilevante se il sito utilizza server-side rendering parziale. Nei casi di Single Page Application (React, Vue, Svelte), il markup deve essere disponibile nel DOM al momento del crawl di Googlebot, non dopo l'idratazione. Si rimanda alla guida JavaScript SEO già pubblicata su questo blog per il dettaglio tecnico.

Un'eccezione giustificata al posizionamento nel <head>: quando il markup è generato dinamicamente da PHP o template engine in base al contenuto della pagina, può essere più pratico iniettarlo prima della chiusura del </body>. Non è un problema per Google.

Esempio base BlogPosting commentato

html

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  /* Il tipo principale: BlogPosting è un sottotipo di Article, più specifico */
  "@type": "BlogPosting",

  /* headline: il titolo esatto dell'articolo, max 110 caratteri */
  "headline": "Schema Markup 2026: Come Ottimizzare i Dati Strutturati per le AI Overviews",

  /* datePublished: formato ISO 8601 con timezone opzionale */
  "datePublished": "2026-03-16T08:00:00+01:00",

  /* dateModified: aggiornare ogni volta che si modifica il contenuto in modo significativo */
  "dateModified": "2026-03-16T08:00:00+01:00",

  /* image: obbligatoria per i rich results di tipo Article */
  "image": {
    "@type": "ImageObject",
    "url": "https://www.perseodesign.com/images/schema-markup-2026-og.jpg",
    "width": 1200,
    "height": 630
  },

  /* author: persona fisica o organizzazione che ha scritto il contenuto */
  "author": {
    "@type": "Person",
    "name": "Luca Perseo",
    "url": "https://www.perseodesign.com/team/luca/",
    /* sameAs: collega l'autore a profili verificabili esterni */
    "sameAs": "https://www.linkedin.com/in/lucaperseo/"
  },

  /* publisher: l'organizzazione che pubblica il contenuto */
  "publisher": {
    "@type": "Organization",
    "name": "Perseo Design",
    "url": "https://www.perseodesign.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.perseodesign.com/images/logo-schema.png",
      "width": 300,
      "height": 60
    }
  },

  /* mainEntityOfPage: la pagina canonica di questo contenuto */
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.perseodesign.com/blog/schema-markup-dati-strutturati-ai-overviews-2026/"
  },

  /* keywords: opzionale, ma utile per il contesto semantico */
  "keywords": ["schema markup", "dati strutturati", "AI Overviews", "JSON-LD", "SEO tecnico"],

  /* inLanguage: dichiara esplicitamente la lingua */
  "inLanguage": "it-IT"
}
</script>

Nota: I commenti con /* */ sono inclusi a scopo illustrativo. Il formato JSON standard non supporta commenti. Nel codice in produzione vanno rimossi.

Come annidare schema (Article, Author, Organization)

L'annidamento permette di costruire un grafo di entità correlate che Google può usare per l'arricchimento semantico. Il pattern Article -> Author (Person) -> Organization è uno dei più efficaci per segnalare E-E-A-T.

json

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Titolo dell'articolo",
  "datePublished": "2026-03-16",
  "author": {
    "@type": "Person",
    "name": "Luca Perseo",
    "jobTitle": "SEO Specialist",
    "worksFor": {
      "@type": "Organization",
      "name": "Perseo Design",
      "url": "https://www.perseodesign.com",
      "foundingDate": "2012",
      "areaServed": {
        "@type": "City",
        "name": "Firenze"
      }
    },
    "sameAs": [
      "https://www.linkedin.com/in/lucaperseo/",
      "https://twitter.com/lucaperseo"
    ]
  }
}

L'uso di @id permette di referenziare la stessa entità in più punti del markup senza ridefinirla. Se Organization è definita con "@id": "https://www.perseodesign.com/#organization" in un blocco separato, nei blocchi successivi si può citare solo con {"@id": "https://www.perseodesign.com/#organization"}.

WordPress: plugin vs codice manuale

Approccio	Pro	Contro
Yoast SEO	Configurazione guidata, copertura completa dei tipi base	Schema generato difficile da personalizzare, overhead JS
RankMath	Schema builder visuale, supporto tipi avanzati	Meno granularità nel controllo del JSON finale
Codice manuale (functions.php)	Controllo totale, nessun overhead plugin	Richiede manutenzione, nessuna UI per il content team
Custom plugin leggero	Controllo + struttura mantenibile	Tempi di sviluppo

La scelta dipende dal contesto. Per un sito gestito da un team content non tecnico, Yoast o RankMath coprono il 90% dei casi. Per un sito con architettura complessa o schema personalizzati (es. eventi, prodotti, corsi), il codice manuale o un plugin custom sono preferibili per evitare che il plugin generi markup errato o incompleto.

I 7 errori più comuni nei dati strutturati

1. Contenuto non corrispondente alla pagina

Il principio fondamentale della Google Search Central è che il markup deve descrivere il contenuto visibile sulla pagina, non informazioni assenti o diverse. Inserire un FAQPage con domande che non compaiono nel testo, o un Product con un prezzo che non corrisponde a quello mostrato all'utente, è una violazione delle linee guida.

Google può penalizzare le pagine con markup ingannevole applicando un'azione manuale specifica per "dati strutturati fuorvianti". La verifica è semplice: ogni proprietà del markup deve avere una controparte verificabile nel DOM.

2. Tag canonical assente o in conflitto col markup

Il mainEntityOfPage nel markup punta all'URL canonico della pagina. Se questo URL differisce dal tag <link rel="canonical"> nell'head, si crea un conflitto che il crawler deve risolvere. Google in genere privilegia il canonical tag, ma la discrepanza genera incertezza nella valutazione del markup.

Caso tipico: un articolo pubblicato su due URL (con e senza trailing slash, o con parametri UTM) dove il markup punta a un URL e il canonical a un altro. Lo strumento corretto per rilevare questo tipo di conflitto è un audit tecnico che legga sia gli header HTTP che il DOM renderizzato.

3. Schema markup su pagine con noindex

Il markup su pagine con <meta name="robots" content="noindex"> o header HTTP X-Robots-Tag: noindex è irrilevante: quelle pagine non sono indicizzate e il loro markup non contribuisce al Knowledge Graph né può generare rich results. Non è tecnicamente un errore, ma è rumore nel codice.

Il caso più critico è l'inverso: pagine che dovrebbero avere schema markup (articoli, prodotti, pagine con FAQ) che vengono accidentalmente escluse dall'indice per via di un noindex errato. L'audit deve incrociare lo stato di indicizzazione con la presenza del markup.

4. Proprietà obbligatorie mancanti

Il Rich Results Test distingue tra errori (missing required property) e avvisi (missing recommended property). Le proprietà obbligatorie variano per tipo di schema. Per Article: author, datePublished, headline, image, publisher. Per FAQPage: mainEntity con almeno un oggetto Question. Per HowTo: name e almeno uno step.

La mancanza di una proprietà obbligatoria non causa una penalizzazione diretta, ma impedisce la generazione del rich result corrispondente. Il markup viene comunque letto da Google per l'arricchimento semantico, ma l'incentivo principale (visibilità nella SERP) viene meno.

5. Nesting errato o schema types incompatibili

Un errore frequente in siti con markup implementato manualmente è usare tipi incompatibili come valori di proprietà. Ad esempio, usare "author": {"@type": "Organization", ...} quando la specifica Schema.org per Article.author accetta Person o Organization, ma molti tool di validazione aspettano Person per contenuti editoriali.

Un errore più grave è il nesting circolare o la referenza a @id non definiti nel documento. Il Rich Results Test segnala questi casi come "unknown property" o genera un parsing error silenzioso.

6. Dati strutturati duplicati o in conflitto

Succede quando un plugin CMS genera automaticamente un Article e il tema aggiunge un secondo blocco Article con proprietà diverse per la stessa pagina. Google riceve due dichiarazioni contradditorie sulle stesse entità.

Non è definito con precisione nella documentazione quale dei due markup prevalga. Nella pratica, Google sceglie in modo non deterministico, il che significa che i rich results possono apparire e scomparire senza una causa apparente. L'audit deve verificare che per ogni tipo di schema ci sia un solo blocco per pagina.

7. Non aggiornare lo schema dopo modifiche al contenuto

dateModified non è solo una formalità: segnala a Google che il contenuto è stato aggiornato. Se si aggiorna un articolo senza aggiornare dateModified, il markup dichiara che il contenuto è rimasto immutato dalla data di pubblicazione originale, il che influisce sulla valutazione di freschezza.

Ancora più critico: se si aggiorna una FAQ nella pagina ma non si aggiorna il markup FAQPage, le AI Overviews possono estrarre la risposta obsoleta dal markup strutturato, non quella aggiornata nel testo. Lo schema deve rispecchiare fedelmente lo stato attuale del contenuto in ogni momento.

Come fare l'audit dei dati strutturati del tuo sito

Google Rich Results Test: come leggerlo

Il Rich Results Test di Google accetta un URL o del codice HTML diretto. Analizza il markup renderizzato (dopo l'esecuzione di JavaScript) e mostra:

I tipi di schema rilevati
Le proprietà obbligatorie presenti e mancanti
Gli avvisi per le proprietà raccomandate assenti
Un'anteprima del rich result (quando applicabile)

Il dettaglio importante è "renderizzato": il test esegue JavaScript prima dell'analisi, quindi è affidabile anche per siti con markup iniettato dinamicamente. Non è uno strumento di audit bulk, ma è il punto di partenza per qualsiasi debug di markup su singola pagina.

Google Search Console: sezione Miglioramenti

La Search Console aggrega i dati di markup per tutto il sito nella sezione "Miglioramenti" (o "Enhancements"). Per ogni tipo di schema rilevato mostra:

Il numero di pagine con errori critici
Il numero di pagine con avvisi
Il numero di pagine valide
Il trend nel tempo

Questo è il modo più rapido per identificare regressioni: se un deploy introduce un errore nel template del markup, il numero di pagine con errori sale immediatamente. La Search Console può inviare notifiche via email per questi eventi.

Audit in bulk su tutto il sito

Per i siti con decine o centinaia di URL, l'analisi manuale pagina per pagina non è praticabile. La validazione in bulk richiede un tool che esegua il crawl dell'intera sitemap, analizzi il markup su ogni URL e aggreghi i risultati.

PerSeo Insights è uno degli strumenti che permette questo tipo di analisi direttamente da sitemap. Inserendo l'URL del sitemap.xml, il tool analizza ogni pagina e restituisce per ciascuna: la presenza di JSON-LD e Microdata, i tipi di schema rilevati, gli errori nelle proprietà, oltre a dati su Core Web Vitals, meta tag e canonical. Utile per una prima mappatura rapida dello stato del markup su progetti esistenti, senza configurazione.

Per dataset più grandi (siti enterprise con migliaia di URL) o per analisi che richiedono maggiore granularità nei report, Screaming Frog SEO Spider con l'estrazione XPath personalizzata è lo standard di mercato. Il workflow tipico prevede di estrarre il contenuto del tag <script type="application/ld+json"> da ogni URL e poi parsarlo con uno script Python o importarlo in un foglio di calcolo per l'analisi.

Configurazione Screaming Frog per l'estrazione JSON-LD:

Configuration > Custom > Extraction
Aggiungere una colonna con XPath: //script[@type='application/ld+json']
Tipo di estrazione: "Extract Inner HTML"
Crawlare il sito con JavaScript rendering attivo (richiede Screaming Frog + Spider JS)

Il risultato è una colonna CSV con il JSON grezzo di ogni pagina, analizzabile programmaticamente.

Dati strutturati e AI Overviews: le strategie avanzate

Perché FAQPage e HowTo aumentano la probabilità di essere estratti dalle AI

Le AI Overviews di Google rispondono prevalentemente a query con intento informazionale. Il modello deve costruire una risposta coerente sintetizzando più fonti. Il suo comportamento preferenziale, documentato empiricamente da ricercatori come Mordy Oberstein e dalla community di SEO sperimentatori, è quello di partire da fonti che hanno già formalizzato la struttura domanda-risposta.

FAQPage fa esattamente questo. Ogni oggetto Question con la sua acceptedAnswer è una coppia semanticamente completa che il modello può citare direttamente o pararafrasare. Il markup riduce l'ambiguità interpretativa al minimo.

HowTo funziona in modo analogo per query procedurali ("come fare", "come configurare", "come installare"). La struttura a step con name e text per ciascuno è quasi identica al formato di output che le AI Overviews usano per rispondere a questo tipo di query.

Strutturare le risposte per l'estrazione semantica

La strategia non si limita al markup. Il contenuto testuale deve essere coerente con la struttura dichiarata nello schema. Le FAQ devono essere presenti nel testo della pagina, non solo nel markup. Gli step di un HowTo devono essere riproducibili nella pagina come sezioni identificabili.

Alcune indicazioni pratiche che emergono dall'analisi delle pagine più frequentemente citate nelle AI Overviews:

Le risposte nelle FAQ del markup sono concise (50-150 parole) e complete in sé stesse, non richiedono contesto aggiuntivo per essere comprese
I titoli H2 e H3 corrispondono semanticamente alle domande nelle FAQ (non necessariamente parola per parola, ma topicamente)
Il testo sotto ogni intestazione risponde a una singola domanda o descrive un singolo concetto, senza divagazioni

Questa coerenza tra struttura HTML, contenuto testuale e markup strutturato è il segnale più forte che si può inviare a un sistema di estrazione semantica.

Il ruolo di author + organization nella E-E-A-T

Google valuta E-E-A-T a livello di pagina, di sito e di autore. I dati strutturati contribuiscono alla componente "verificabile macchina" di questa valutazione.

Dichiarare un author con sameAs che punta a profili esterni verificabili (LinkedIn, Google Scholar per ambiti accademici, profili su piattaforme di settore) permette a Google di correlare l'identità dell'autore con segnali di autorevolezza provenienti da fonti indipendenti. Un autore con storia editoriale verificabile su più piattaforme ha un peso diverso rispetto a un autore dichiarato solo nel markup senza riferimenti esterni.

Lo stesso vale per Organization. Dichiarare foundingDate, address, areaServed e sameAs con link a profili verificabili (Google Business Profile, Wikidata se disponibile, profili su directory di settore) costruisce una rappresentazione dell'entità che va oltre il singolo sito web.

Questo non è uno segnale di ranking diretto, ma è un input per la valutazione di fiducia del dominio che influenza quali fonti Google cita nelle AI Overviews per query su argomenti dove l'autorevolezza è rilevante.

Schema markup e llms.txt: segnali complementari

Il file llms.txt (proposta di Jere Howard, 2024) è una convenzione emergente per comunicare ai modelli linguistici quali contenuti del sito sono disponibili per l'elaborazione e in quale formato. Non è uno standard formale, non ha supporto ufficiale di Google al momento della pubblicazione di questa guida, ma la sua adozione sta crescendo tra i siti tecnici.

Il rapporto con i dati strutturati è di complementarità, non di sovrapposizione. Lo schema markup fornisce metadati semantici strutturati alle singole pagine, leggibili durante il crawl. llms.txt fornisce una vista d'insieme del sito e delle sue risorse, pensata per sistemi che processano il sito come corpus.

Per siti che vogliono massimizzare la leggibilità da parte di sistemi AI, la combinazione di schema markup completo e llms.txt è più efficace della sola implementazione di uno dei due. Lo schema markup rimane lo strumento principale, con documentazione e supporto ufficiale da parte di Google. llms.txt è un segnale aggiuntivo con un orizzonte temporale ancora incerto.

Checklist di audit: 10 punti per verificare i dati strutturati

Prima di pubblicare o dopo ogni modifica significativa al sito, questa checklist permette di identificare le criticità più comuni nel markup strutturato.

Ogni pagina indicizzata ha almeno uno schema rilevante? Verificare che articoli, pagine prodotto, pagine categoria e homepage abbiano il tipo di schema appropriato.
Le proprietà obbligatorie sono tutte presenti? Per Article/BlogPosting: headline, datePublished, author, image, publisher. Validare con il Rich Results Test.
dateModified corrisponde all'ultima modifica effettiva? Confrontare il valore nel markup con la data di ultima modifica reale del contenuto.
Il contenuto del markup è visibile nella pagina? Ogni FAQ, ogni step di un HowTo, ogni informazione nel markup deve avere una controparte testuale verificabile nel DOM.
L'URL in mainEntityOfPage corrisponde al canonical? Confrontare "@id" nel markup con il valore del tag <link rel="canonical">.
Non ci sono blocchi duplicati dello stesso tipo? Controllare che non esistano due Article o due FAQPage per la stessa pagina, generati da plugin o template diversi.
Le pagine con noindex non hanno markup produttivo? Il markup su pagine noindex è irrilevante. Rimuoverlo riduce il rumore.
author.sameAs punta a profili attivi e verificabili? Verificare che i link esterni nel sameAs risolvano correttamente e puntino al profilo corretto.
Il markup JSON-LD è JSON valido? Errori di sintassi (virgole mancanti, parentesi non chiuse) invalidano silenziosamente il blocco. Validare con jsonlint.com o equivalente.
La Search Console segnala errori o avvisi attivi? Controllare la sezione Miglioramenti per eventuali regressioni introdotte da aggiornamenti recenti del CMS, del tema o dei plugin.

Per un audit su larga scala che copra l'intera sitemap, strumenti come PerSeo Insights (per un'analisi rapida URL per URL su siti di medie dimensioni) o Screaming Frog (per dataset enterprise) permettono di automatizzare i punti 1, 2, 4, 5 e 6 con un singolo crawl.

La documentazione di riferimento per i tipi di schema supportati da Google è disponibile su developers.google.com/search/docs/appearance/structured-data. Il vocabolario completo di Schema.org è consultabile su schema.org/docs/full.html.

Il markup strutturato non è una componente opzionale della SEO tecnica nel 2026. Con le AI Overviews che intercettano una quota crescente di query informazionali, la leggibilità machine-readable del contenuto è diventata un prerequisito per la visibilità organica, non un vantaggio competitivo. I siti che hanno investito in un'implementazione corretta negli ultimi due anni stanno raccogliendo i risultati in termini di citazioni nei blocchi AI. Quelli che non lo hanno fatto stanno affrontando un recupero più lungo di quanto ci si aspettasse.

Richiedi un Preventivo