HTML semantico per la SEO

TL;DR — L’HTML semantico significa usare tag che descrivono cosa è il contenuto — <article>, <nav>, <main>, <header> — invece di avvolgere tutto in semplici <div>. Aiuta i motori di ricerca e i lettori di schermo a comprendere la tua pagina, ma non è un fattore di ranking. Usare <article> non ti farà posizionare più in alto. La stessa regola vale anche oltre i landmark: <a href> per i link, <button> per le azioni, <table> per i dati tabulari, testo alt reale sulle immagini. Usa il tag giusto per lo scopo e sei già a buon punto.

Cos’è l’HTML semantico

Ogni parte di una pagina web è costruita con elementi HTML. L’HTML semantico significa semplicemente scegliere l’elemento che corrisponde a ciò che il contenuto è realmente, invece di usare un contenitore generico per tutto.

Confronta queste due versioni della stessa struttura di pagina:

<!-- Non-semantic: "div soup" -->
<div class="top"> ... </div>
<div class="menu"> ... </div>
<div class="content"> ... </div>
<div class="sidebar"> ... </div>
<div class="bottom"> ... </div>

<!-- Semantic: the tags describe the roles -->
<header> ... </header>
<nav> ... </nav>
<main> ... </main>
<aside> ... </aside>
<footer> ... </footer>

Entrambe possono apparire identiche sullo schermo — il CSS gestisce lo stile. La differenza è che la seconda versione dice a una macchina (un motore di ricerca, un lettore di schermo, un crawler AI) quale parte è la navigazione, quale è il contenuto principale e quale è una sidebar. La prima versione fa indovinare a tutti.

Gli elementi che userai davvero

• <header> — contenuto introduttivo in cima alla pagina (o in cima a una sezione).
• <nav> — un blocco di link di navigazione.
• <main> — il contenuto primario e unico della pagina. Uno per pagina.
• <article> — un pezzo autonomo che potrebbe reggersi da solo (un post del blog, una scheda prodotto, un commento).
• <section> — un raggruppamento tematico di contenuti che ha la propria intestazione.
• <aside> — contenuto tangenziale al contenuto principale (una sidebar, un riquadro).
• <footer> — contenuto di chiusura (copyright, link secondari).

La stessa idea di “usare il tag giusto” vale anche al di sotto del livello di layout della pagina: <a href> per i link, <button> per le azioni sulla pagina, <table> per dati realmente tabulari e testo alt basato sullo scopo per le immagini. I falsi link costruiti con <div> stilizzati sono l’errore di accessibilità più comune — vedi la scheda Avanzate per l’elenco completo.

La cosa che la maggior parte delle persone sbaglia

Avvolgere il tuo contenuto in <article> non aumenta il tuo posizionamento. John Mueller di Google ha detto che l’elemento <article> non ha “alcun effetto particolare” nella Ricerca Google, e che l’HTML semantico “non è un moltiplicatore magico.” L’HTML semantico aiuta i motori di ricerca a comprendere la tua pagina — semplicemente non è una leva che tiri per posizionarti più in alto.

Il valore è reale, semplicemente non è “punti di ranking.” Un markup semantico pulito rende più facile per i motori di ricerca distinguere il tuo contenuto principale dal boilerplate (menu, footer, annunci), rende la tua pagina funzionante correttamente per le persone che usano lettori di schermo, ed è più facile da leggere per gli strumenti AI. Queste sono tutte buone ragioni per farlo — nessuna di esse è “è un fattore di ranking.”

Un’altra trappola: L’HTML semantico non è la stessa cosa della “SEO semantica.” L’HTML semantico riguarda la struttura del markup. La SEO semantica riguarda argomenti ed entità nel tuo contenuto. Stessa parola, cosa totalmente diversa.

Vuoi il quadro completo — cosa segnala ogni elemento, cosa dicono realmente Google e Bing, come si inserisce nell’estrazione del contenuto principale e una checklist di retrofit? Passa alla scheda Avanzate.

TL;DR — L’HTML semantico usa elementi per il loro significato strutturale previsto (<main>, <article>, <section>, <nav>, <header>, <aside>) così che il markup comunichi cosa il contenuto è, non come appare. Non è un fattore di ranking — Mueller: “non un moltiplicatore magico,” e <article> “non ha alcun effetto particolare.” Ciò che fa è ridurre l’ambiguità: l’annotazione centerpiece di Google separa il contenuto principale dal boilerplate tramite NLP indipendentemente dal fatto che il tuo markup sia semantico, ma una semantica pulita rende quel lavoro più affidabile. Fabrice Canel di Bing lo inquadra più fortemente (“un vantaggio nella SEO”) — noto quella differenza onestamente piuttosto che armonizzarla. La stessa Guida introduttiva di Google dice che la maggior parte del web non è HTML valido, quindi raramente dipende dalla semantica delle specifiche. L’uso corretto batte la presenza: un <main>, <article> per contenuti autonomi, <section> per un gruppo tematico con un’intestazione — non un sostituto di <div>. Lo stesso test si estende a <a href> vs. <button> (navigare vs. agire), vere <table> per dati tabulari, testo alternativo delle immagini basato sullo scopo, e <details>/<summary> per widget di divulgazione — e non fare affidamento sull’annidamento di <section> per implicare un livello di intestazione; quell‘“algoritmo di struttura del documento” non è mai stato implementato e la specifica non definisce più le strutture in quel modo. Non confondere l’HTML semantico con la SEO semantica.

Cos’è realmente l’HTML semantico

L’HTML semantico è la pratica di scegliere elementi HTML per il significato strutturale che sono stati progettati per trasmettere, piuttosto che ricorrere a <div> e <span> per tutto. <article>, <section>, <nav>, <header>, <main>, <aside>, e <footer> dichiarano ciascuno un ruolo. Il markup descrive cosa un blocco della pagina è; CSS decide come appare. La guida di stile per sviluppatori di Google mette la regola nel modo più semplice possibile: “Usa gli elementi HTML per gli scopi per cui sono stati progettati.”

Una cosa che confonde le persone: un nome di classe non crea semantica. Dare a un <div> class="article" o class="main-nav" non gli conferisce il modello di contenuto dell’elemento <article> o il ruolo di navigazione implicito dell’elemento <nav> — è ancora un <div> generico per quanto riguarda un browser, uno screen reader o un crawler. La semantica vive nell’elemento che scegli, non in come lo stili o lo etichetti.

Questo articolo riguarda specificamente gli elementi semantici. Il quadro più ampio “come Google analizza il tuo HTML, la gerarchia delle intestazioni, la validità” appartiene all’hub SEO HTML sotto cui questa pagina si trova — lo incrocerò piuttosto che ri-discuterlo qui.

L’HTML semantico aiuta davvero la SEO?

Risposta breve: aiuta la comprensione, non è un fattore di ranking, e i due motori di ricerca lo inquadrano un po’ diversamente. Ecco la versione onesta.

Cosa dice Google

La posizione di Google, ripetuta da John Mueller, è che l’HTML semantico vale la pena di essere fatto ma non è una leva di ranking. Come Search Engine Journal ha riportato, Mueller ha detto “L’HTML semantico aiuta a capire una pagina. Tuttavia, non è un moltiplicatore magico per far salire un sito web nel ranking,” e separatamente: “Per favore usa l’HTML semantico. Non è un fattore di ranking, ma può aiutare i nostri sistemi a capire meglio i tuoi contenuti.”

Sull’elemento <article> in particolare — quello di cui tutti chiedono — Mueller è stato schietto in una sessione di Office Hours: l’elemento <article> “non ha alcun effetto particolare nella Ricerca Google,” e ha aggiunto il motivo per usarlo comunque: “A volte ci sono ragioni di accessibilità o semantiche per usare un tipo specifico di markup, quindi non concentrarti solo sulla SEO.”

Google afferma anche esplicitamente di non dipendere da una semantica perfetta. La sua Guida introduttiva alla SEO nota che “Avere le intestazioni in ordine semantico è fantastico per gli screen reader, ma dal punto di vista della Ricerca Google, non importa se le usi fuori ordine. Il web in generale non è HTML valido, quindi la Ricerca Google può raramente dipendere da significati semantici nascosti nella specifica HTML.” Questa è una sfumatura importante, non una contraddizione: l’HTML semantico aiuta ai margini, non richiede perfezione e non è un segnale a punteggio.

Come si inserisce nel modo in cui Google trova i tuoi contenuti principali

Ecco il meccanismo che rende utile l’HTML semantico anche se non è un fattore di ranking. Google deve separare il contenuto principale di una pagina dalla boilerplate (nav, header, footer, sidebar, annunci) prima di poter decidere di cosa tratta una pagina. Martin Splitt ha descritto il meccanismo: “Abbiamo una cosa chiamata Centerpiece Annotation, per esempio, e ci sono alcune altre annotazioni in cui guardiamo il contenuto semantico.” Il modo in cui Google capisce l’argomento è l’elaborazione del linguaggio naturale sul contenuto, non i nomi dei tag: “Sembra che da tutta l’elaborazione del linguaggio naturale che abbiamo fatto su questo intero contenuto testuale qui, sembra che questo sia principalmente sull’argomento A, cibo per cani.” E declassa il resto: “Capiamo cosa sembra boilerplate e poi, anche quello viene pesato in modo diverso.”

Il punto chiave: quell’estrazione funziona che il tuo markup sia semantico o meno. Google può districare una pagina costruita interamente con <div>. Ma alla domanda diretta se l’HTML5 semantico aiuti, la risposta di Splitt è stata “Ci aiuta, ma non è l’unica cosa che cerchiamo. Sì.” Quindi l’HTML semantico non ti fa ottenere un punteggio più alto — riduce le congetture in un passaggio che Google fa già, ed è esattamente per questo che è un segnale di fiducia ed efficienza piuttosto che di ranking. Per essere precisi su ciò che non fa: un markup semantico corretto non garantisce nemmeno una specifica presentazione nei risultati di ricerca — è un livello separato dalle regole di idoneità che governano i rich results (ne parleremo più avanti).

Cosa dice Bing (e perché differisce)

Bing inquadra questo aspetto in modo più forte di Google, e lascerò questa differenza intatta piuttosto che nasconderla. Fabrice Canel di Microsoft ha dichiarato che le pagine con HTML5 semantico correttamente implementato hanno “un vantaggio in termini di SEO” rispetto a quelle che non lo hanno. Questa è un’affermazione più forte di quella di Google “ci aiuta a capire” — Bing collega l’HTML5 semantico direttamente a un vantaggio SEO. Entrambi i motori di ricerca convergono su “aiuta meccanicamente,” ma non usano le stesse parole, e dovresti saperlo quando leggi indicazioni contrastanti. Nessuno dei due, per essere chiari, lo descrive come un fattore di ranking con punteggio nel modo in cui lo sono i link o la rilevanza.

Gli elementi semantici principali e come usarli correttamente

La presenza non è il punto — l’uso corretto lo è. La modalità di errore più comune è cospargere i tag semantici come decorazione, o sostituire <div> con <section> senza pensare a cosa significhi ogni elemento.

<header> e <footer>

<header> contiene contenuto introduttivo e <footer> contiene contenuto conclusivo — ed entrambi sono contestuali. A livello di documento, <header> è il banner del tuo sito e <footer> è il footer del tuo sito. Ma possono anche essere annidati all’interno di un <article> o <section> per contrassegnare l’introduzione e la conclusione di quel blocco (il titolo/la firma di un articolo in un <header>, i suoi tag in un <footer>). Puoi averne molti; assicurati solo che ognuno racchiuda contenuto introduttivo o conclusivo per il suo contesto, non scatole arbitrarie.

<nav>

<nav> è per blocchi principali di link di navigazione — il tuo menu primario, il percorso di breadcrumb, o l’indice dei contenuti nella pagina. Non è per ogni gruppo di link nella pagina (una lista di post correlati nel corpo non deve essere un <nav>). Avvolgere ogni cluster di link in <nav> diluisce il segnale; riservalo alla navigazione genuina.

<main>

<main> racchiude il contenuto primario e unico della pagina — la parte che non viene ripetuta nel sito. La regola che mette in difficoltà le persone: dovrebbe esserci esattamente uno <main> per pagina, e non dovrebbe essere annidato all’interno di <article>, <aside>, <header>, <footer> o <nav>. È il segnale più chiaro che puoi dare su “questo è il contenuto che conta qui.”

<article> vs <section> (quello che tutti sbagliano)

Questa è la distinzione da capire bene:

• <article> è per contenuto autonomo e indipendentemente distribuibile — qualcosa che avrebbe ancora senso se estratto dalla pagina e inserito in un feed. Un post di un blog, una notizia, una scheda prodotto, un post di un forum, un singolo commento utente. Se potesse essere sindacato da solo, è un <article>.
• <section> è un raggruppamento tematico di contenuto che dovrebbe avere la propria intestazione. Un blocco “Recensioni”, un blocco “Specifiche”, un capitolo. Il test: se il contenuto non ha senso con un’intestazione, probabilmente non è una <section> — e se lo stai usando solo per applicare un po’ di CSS, dovrebbe essere un <div>.

<section> non è un contenitore generico. Quando hai bisogno di un gancio per lo stile senza significato semantico, usa <div> — è esattamente a questo che serve. Ricorrere a <section> perché “sembra più moderno” è l’uso improprio più comune.

<aside>

<aside> contrassegna contenuto che è tangenziale al contenuto circostante — una barra laterale, una citazione in evidenza, una casella di link correlati, un insieme di annunci. Segnala “questo è correlato ma non il filo principale,” che è precisamente la distinzione boilerplate-vs-contenuto-principale che Google sta cercando di tracciare comunque. Non usarlo solo perché qualcosa è visivamente a lato; usalo quando il contenuto è genuinamente secondario.

Ottenere correttamente i ruoli landmark (e il mito dell’outline)

Ogni elemento landmark corrisponde a uno specifico ruolo ARIA implicito che la tecnologia assistiva legge direttamente — questa è la stessa struttura calcolata che un utente non vedente usa per navigare, e vale la pena conoscere la mappatura effettiva invece di presumerla:

Un’idea da abbandonare: annidare una <section> non attribuisce alle sue intestazioni un livello inferiore implicito. Le prime versioni di HTML5 definivano un algoritmo di struttura del documento che avrebbe calcolato il livello effettivo di un’intestazione in base alla profondità di annidamento all’interno degli elementi di sezione — quindi un <h1> annidato avrebbe potuto teoricamente “comportarsi come” un <h2>. Nessun browser o screen reader ha mai implementato quell’algoritmo, e la specifica WHATWG lo ha da allora eliminato a favore di una definizione molto più semplice: la struttura è semplicemente tutte le intestazioni nel documento, in ordine di albero. Scrivi i livelli <h1>–<h6> esplicitamente e nell’ordine in cui vuoi che vengano letti — la profondità di annidamento non fa quel lavoro per te.

Link vs. pulsanti — il test azione-versus-navigazione

Questo non è un elemento landmark, ma è l’errore semantico più comune sul web: usare un <div> o <span> stilizzato (o un <button>) dove serve un <a href>, o viceversa. La specifica WHATWG è specifica — <a> con un attributo href è il meccanismo nativo per i collegamenti ipertestuali, e l’elemento <button> è un controllo interattivo etichettato per attivare un’azione. Il test è semplice: questo porta l’utente a qualcosa (un nuovo URL, una nuova pagina, un frammento)? Usa <a href>. Fa qualcosa sulla pagina corrente (invia un modulo, apre una modale, attiva/disattiva un’ ‘impostazione)? Usa <button>. Stilizzare uno per farlo sembrare l’altro non cambia ciò che è nativamente — un <div> con un gestore di clic non ottiene né l’attivazione nativa da tastiera né il ruolo accessibile corretto a meno che non ricostruisca tutto da solo con role, tabindex e gestori di tasti. Usa semplicemente l’elemento giusto.

Le tabelle sono per dati tabulari, non per il layout

Se il contenuto ha davvero righe e colonne — una tabella comparativa, una griglia di prezzi, un set di dati — usa una vera <table>, non una griglia di <div> stilizzati. La specifica WHATWG sulle tabelle definisce un vero modello di dati: <caption> nomina la tabella, e le celle di intestazione <th> (con scope) stabiliscono le relazioni riga/colonna che consentono alla tecnologia assistiva di annunciare “prezzo, $49” invece di un semplice muro di numeri. Una griglia visivamente simile a una tabella costruita con <div> non trasporta alcuno di quei dati relazionali — sembra giusta, ma non si legge giusta. Non usare <table> nemmeno per il layout della pagina; quello è l’abuso più vecchio che questa pratica ha sostituito.

Il testo alternativo dipende dallo scopo dell’immagine

<img> richiede un attributo alt, ma i requisiti della specifica WHATWG dipendono dallo scopo, non sono uguali per tutti: una foto di prodotto richiede una descrizione di ciò che è mostrato; un’immagine puramente decorativa dovrebbe avere alt="" (vuoto, non mancante) così la tecnologia assistiva la salta invece di annunciare un nome file; un’immagine che è anche un link richiede testo alternativo che descriva la destinazione o l’azione del link, non solo la foto. Non impostare di default testo alternativo pieno di parole chiave su ogni immagine “per la SEO” — quello è il test sbagliato. Il test giusto è: cosa deve sapere un utente di screen reader che altrimenti si perderebbe?

Widget di divulgazione nativi: <details> e <summary>

Per i contenuti “clicca per espandere” — FAQ, schede tecniche, testo spoiler — la coppia <details>/<summary> è un widget di divulgazione nativo: <summary> è l’etichetta sempre visibile, e il contenuto all’interno di <details> si mostra o si nasconde in base allo stato open dell’elemento, senza alcun JavaScript. Include supporto integrato per la tastiera e le giuste semantiche accessibili gratuitamente — ricorrere a un accordion personalizzato con <div> più JavaScript significa reimplementare un comportamento che il browser già ti offre. Testalo nei tuoi browser e screen reader di destinazione effettivi prima di pubblicarlo, però — il rendering e l’esposizione nell’albero di accessibilità per <details>/<summary> sono storicamente variati in base alla combinazione browser e tecnologia assistiva, quindi non dare per scontata una parità che non hai verificato.

Miti comuni sull’HTML semantico e la SEO

1. “Avvolgere il contenuto in <article> migliora il posizionamento.” No — Mueller: l’elemento <article> “non ha alcun effetto particolare in Google Search.”
2. “L’HTML semantico è un fattore di ranking.” No — “non è un moltiplicatore magico” e “Non è un fattore di ranking, ma può aiutare i nostri sistemi a comprendere meglio il tuo contenuto.”
3. “Google richiede HTML semantico valido/rigoroso.” No — secondo la Guida introduttiva, la maggior parte del web non è HTML valido e Google “può raramente fare affidamento sui significati semantici nascosti nella specifica HTML.”
4. “L’ordine delle intestazioni deve essere perfetto per la SEO.” Agli screen reader importa; al ranking di Google no (stessa riga della Guida introduttiva). Il trattamento più approfondito della gerarchia delle intestazioni appartiene all’hub SEO HTML — questa è solo la versione breve.
5. “HTML semantico e SEO semantica sono la stessa cosa.” No — uno è struttura del markup, l’altro è strategia di contenuto topico/entità. Confonderli è il motivo per cui molti risultati di ricerca per query “semantiche” riguardano l’argomento sbagliato.
6. “I dati strutturati rendono superfluo l’HTML semantico.” No — sono complementari. L’HTML semantico dà ai tuoi dati strutturati una base più affidabile; non li sostituisce, e JSON-LD non risolve la zuppa di div. E nessuno dei due garantisce un risultato: l’introduzione ai dati strutturati di Google è esplicita sul fatto che usare markup supportato non garantisce un rich result — l’idoneità per una specifica funzionalità di ricerca è un insieme separato di regole rispetto al fatto che il tuo markup (HTML semantico o JSON-LD) sia tecnicamente valido.
7. “Annidare un <section> dà alle sue intestazioni un rango implicito inferiore — non devi passare da <h1> a <h2> all’interno di una sezione annidata.” No — questo è un residuo del vecchio algoritmo di outline del documento di HTML5, che avrebbe calcolato un rango di intestazione implicito dall’annidamento degli elementi di sezione. Nessun browser o screen reader lo ha mai implementato, e la specifica WHATWG HTML non definisce più il calcolo dell’outline in quel modo — oggi l’outline è semplicemente “tutte le intestazioni nel documento, in ordine di albero.” Usa <h1>–<h6> espliciti e correttamente ordinati indipendentemente da quanto profondo sia il tuo annidamento di <section>/<article>; non fare affidamento sull’annidamento per fare il lavoro di livello delle intestazioni al posto tuo.

HTML semantico vs. SEO semantica — non confonderli

Poiché condividono una parola, questi vengono costantemente confusi, e questo inquina i risultati di ricerca per entrambi:

• HTML semantico = il markup — quali elementi usi per strutturare una pagina.
• SEO semantico = una strategia di contenuti — costruire autorità topica attorno a entità e concetti correlati (il tipo di cosa che vive sotto i pilastri AI Search e contenuti, non qui).

Se sei arrivato qui da una query “semantic SEO” aspettandoti topic modeling, quello è un articolo diverso. Questo riguarda strettamente gli elementi.

HTML semantico e crawler AI/LLM

È qui che l’HTML semantico sta silenziosamente diventando più rilevante, e lo segnalo come opinione di settore piuttosto che dichiarazione dei motori di ricerca. Molti crawler LLM e motori di risposta AI non eseguono JavaScript — analizzano l’HTML che viene loro servito. Un markup semantico pulito è molto più facile da gestire per loro rispetto a una zuppa di <div> profondamente annidati. Come dice Barry Adams, “It’s much simpler for ChatGPT to parse a few dozen semantic HTML tags rather than several hundred (or even thousand) nested <div> tags,” (traduzione) «È molto più semplice per ChatGPT analizzare qualche decina di tag HTML semantici piuttosto che diverse centinaia (o addirittura migliaia) di tag <div> annidati,» e più in generale, “Semantic HTML markup on your webpages can help machine systems better understand your content and its value.” (traduzione) «Il markup HTML semantico sulle tue pagine web può aiutare i sistemi automatici a comprendere meglio i tuoi contenuti e il loro valore.» Jono Alderson fa lo stesso caso lungimirante — che un sito è “an interface. An API. A dataset,” (traduzione) «un’interfaccia. Un’API. Un dataset,» non solo un’esperienza visiva — e la sua frase lapidaria è l’intero argomento per un uso corretto: “If everything is a <div> or a <span>, then nothing is meaningful.” (traduzione) «Se tutto è un <div> o uno <span>, allora nulla è significativo.» Tratta tutto questo come una buona ragione direzionale per mantenere il tuo markup pulito, non come una promessa da Google o Bing.

Come fare audit e retrofit delle pagine esistenti

La maggior parte dei siti reali è già una zuppa di div, e non li ricostruisci dall’oggi al domani. Un ordine pragmatico di retrofit:

• Stabilisci prima i landmark. Assicurati che ci sia esattamente un <main>, un <header> di documento, un <footer> e un <nav> per il menu principale. Questi elementi landmark fanno il lavoro maggiore sia per l’estrazione del contenuto principale che per l’accessibilità.
• Converti i blocchi autonomi in <article>. Post di blog, card di prodotto, commenti — qualsiasi cosa che possa stare da sola in un feed.
• Converti i gruppi tematici genuini in <section> — ma solo dove c’è un’intestazione reale. Se non c’è, lascialo come <div>.
• Sposta sidebar e box di contenuti correlati in <aside>.
• Correggi link finti e pulsanti finti. Un <div> stilizzato con un gestore di click dovrebbe diventare un <a href> (se naviga) o un <button> (se agisce sulla pagina) — di solito questa è la correzione singola di maggior valore per utenti di tastiera e screen reader.
• Converti griglie di <div> simili a tabelle in vere <table> dove il contenuto è genuinamente tabulare, con <caption> e <th> per le celle di intestazione.
• Non convertire troppo. Un <div> usato puramente come hook di stile/layout è corretto. Non tutto ha bisogno di un elemento semantico; forzarne uno è un errore a sé.
• Verifica, non presumere. Controlla l’albero di accessibilità nei DevTools del tuo browser — espone i ruoli landmark che il tuo markup produce, che è la stessa struttura che leggono le macchine.

Come questo si inserisce nell’hub SEO HTML

Questo articolo è un approfondimento sotto l’hub SEO HTML genitore, che copre la questione più ampia di come i motori di ricerca analizzano e usano il tuo HTML — gerarchia delle intestazioni, validità HTML e come i parser permissivi gestiscono markup disordinato. Ho deliberatamente mantenuto questa pagina limitata agli elementi semantici stessi e ho lasciato questi argomenti all’hub e ai suoi articoli correlati. L’HTML semantico si abbina anche direttamente con dati strutturati: il markup dà allo schema una base affidabile, e i due fanno lavori complementari.

FAQ

L’HTML semantico aiuta la SEO o serve solo per l’accessibilità? Entrambi: aiuta i motori di ricerca a identificare il contenuto principale ed è essenziale per l’accessibilità. Ma non è un fattore di ranking.

L’uso del tag <article> migliora il posizionamento? No. Mueller: “non ha alcun effetto particolare in Google Search.” (traduzione) «non ha alcun effetto particolare in Google Search.»

Qual è la differenza tra <article> e <section>? <article> è un contenuto autonomo che potrebbe stare da solo in un feed; <section> è un raggruppamento tematico con una propria intestazione. Nessuno dei due è un sostituto di <div>.

Posso avere più di un elemento <main> in una pagina? No: un solo <main> per pagina.

Google richiede HTML valido per posizionare una pagina? No: la maggior parte del web non è HTML valido, e Google “può raramente fare affidamento sui significati semantici nascosti nella specifica HTML.” (traduzione) «può raramente fare affidamento sui significati semantici nascosti nella specifica HTML.»

L’HTML semantico è la stessa cosa della SEO semantica? No: uno è markup, l’altro è una strategia di contenuti basata su argomenti/entità.

Devo usare <a> o <button> per un elemento cliccabile? Dipende da cosa fa. Se porta a un URL o a un frammento, usa <a href>. Se esegue un’azione sulla pagina corrente (invio, attivazione/disattivazione, apertura di una modale), usa <button>. Non simulare uno con un <div> stilizzato e un gestore di clic.

Annidare <section> cambia il livello di intestazione che dovrei usare? No. Il vecchio algoritmo di struttura del documento di HTML5 — che avrebbe calcolato un rango di intestazione implicito dall’annidamento delle sezioni — non è mai stato implementato da nessun browser o screen reader, e la specifica attuale non definisce le strutture in quel modo. Usa <h1>–<h6> espliciti e nell’ordine corretto, indipendentemente dalla profondità di annidamento.

Un HTML semantico corretto o dati strutturati garantiscono un rich result? No. La documentazione sui dati strutturati di Google afferma che il markup supportato non garantisce una presentazione specifica nei risultati di ricerca: l’idoneità per una funzionalità è separata dal fatto che il tuo markup sia tecnicamente valido.

Riepilogo AI

Una sintesi della versione Advanced:

• HTML semantico = usare gli elementi per il loro significato previsto (<main>, <article>, <section>, <nav>, <header>, <aside>, <footer>) così il markup dice cosa è il contenuto. Il CSS gestisce l’aspetto.
• Non è un fattore di ranking. Mueller: “non un moltiplicatore magico”; l’elemento <article> “non ha alcun effetto particolare” nella Ricerca Google. Usalo per accessibilità/chiarezza, non per punti di ranking.
• Aiuta l’estrazione del contenuto principale. L’annotazione centerpiece di Google separa il contenuto principale dal boilerplate tramite NLP indipendentemente dal markup (Splitt), quindi funziona anche su zuppa di div — ma il markup semantico riduce le congetture. Splitt: “Ci aiuta, ma non è l’unica cosa che cerchiamo.”
• Google non richiede HTML valido. Guida introduttiva: la maggior parte del web non è valido, quindi Google “raramente può fare affidamento sui significati semantici nascosti nella specifica HTML.”
• Bing lo inquadra in modo più forte. Fabrice Canel: l’HTML5 semantico dà “un vantaggio nella SEO.” Nota onestamente il divario — la formulazione di Bing è più forte di quella di Google; nessuno dei due lo definisce un fattore di ranking a punteggio.
• L’uso corretto batte la presenza: un solo <main>; <article> = autonomo; <section> = gruppo tematico con un’intestazione, non un sostituto di <div>; <nav> = solo navigazione principale; <aside> = contenuto tangenziale.
• Gli elementi landmark mappano a specifici ruoli ARIA impliciti (<header>→banner, <nav>→navigation, <main>→main, <aside>→complementary, <footer>→contentinfo — solo a livello di documento; annidati in una sezione non sono landmark). <section> è un landmark (region) solo se ha un nome accessibile; <article> non è affatto un landmark.
• Il mito dell’algoritmo di struttura del documento: annidare una <section> non dà ai suoi titoli un rango implicito inferiore. Quell’algoritmo non è mai stato implementato da nessun browser o screen reader e la specifica WHATWG non definisce più le strutture in quel modo — scrivi livelli espliciti <h1>–<h6>.
• Oltre i landmark: usa <a href> per la navigazione vs. <button> per le azioni sulla pagina; vere <table> (con <caption>/<th>) per dati tabellari, non griglie di <div>; testo alt basato sullo scopo nelle immagini (alt="" per decorative); <details>/<summary> per widget di divulgazione nativi — testa il rendering browser/AT prima di pubblicare.
• Angolo AI/LLM (opinione di settore): i crawler LLM spesso non eseguono JS, quindi HTML semantico pulito è più facile da analizzare di <div> annidati (Adams, Alderson).
• Non confonderlo con la SEO semantica (strategia di entità/argomento) — stessa parola, cosa diversa. I dati strutturati completano l’HTML semantico, non lo sostituiscono, e nessuno dei due garantisce un risultato ricco o un guadagno di ranking.

Documentazione ufficiale

Documentazione di fonti primarie e linee guida di stile dai motori di ricerca e dagli organismi di standardizzazione.

Google

• Guida introduttiva alla SEO — la sezione “cose su cui non dovresti concentrarti”, inclusa l’avvertenza sull’ordine dei titoli / significati semantici.
• Guida allo stile per la documentazione per sviluppatori di Google — HTML e tagging semantico — “Usa gli elementi HTML per gli scopi per cui sono stati progettati.”
• web.dev — Impara HTML: HTML semantico — il modulo di apprendimento di Google sugli elementi landmark e i loro ruoli di accessibilità.

Standard / riferimento

• MDN — Semantics (glossario) — la definizione canonica degli elementi semantici rispetto ai wrapper non semantici.
• WHATWG HTML Living Standard — Sections — definizioni di <article>, <section>, <nav>, <aside>, <header>, <footer>, modelli di contenuto e la definizione corrente (non algoritmica) dell’outline di un documento.
• WHATWG HTML Living Standard — Links — l’elemento <a> e la semantica dei collegamenti ipertestuali.
• WHATWG HTML Living Standard — The button element — semantica nativa dei controlli interattivi.
• WHATWG HTML Living Standard — Tabular data — semantica di <table>, <caption>, celle di intestazione e relazioni tra dati.
• WHATWG HTML Living Standard — Images — requisiti del testo alternativo di <img> in base a scopo/contesto.
• WHATWG HTML Living Standard — The details and summary elements — il widget nativo di divulgazione.
• MDN — ARIA roles reference — mapping impliciti dei ruoli landmark per gli elementi di sezionamento.
• W3C WAI — Page Structure Tutorial — come le regioni native e le intestazioni supportano la navigazione con tecnologie assistive.

Bing / Microsoft

• Kalicube — HTML5 Semantic Tags (Fabrice Canel) — la fonte della posizione di Canel sull‘“vantaggio in SEO” dell’HTML5 semantico.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google e Bing. Dove la pagina sorgente lo supporta, ogni collegamento è un deep link che salta al passaggio citato.

Google — non un fattore di ranking (John Mueller)

• “Semantic HTML does help to understand a page. However, it’s not a magical multiplier for making a website rank higher.” (traduzione) «L’HTML semantico aiuta a capire una pagina. Tuttavia, non è un moltiplicatore magico per far posizionare meglio un sito.» — John Mueller, Google, via Search Engine Journal. Leggi la copertura
• “Please use semantic HTML. It’s not a ranking factor, but it can help our systems to understand your content better.” (traduzione) «Per favore, usa HTML semantico. Non è un fattore di ranking, ma può aiutare i nostri sistemi a comprendere meglio i tuoi contenuti.» — John Mueller, Google, stessa fonte. Leggi la copertura

Google — l’elemento <article> specificamente (John Mueller)

• “The <article> HTML element does not have any particular effect in Google Search.” (traduzione) «L’elemento HTML <article> non ha alcun effetto particolare nella Ricerca Google.» — John Mueller, Google SEO Office Hours, via Search Engine Journal. Leggi la copertura
• “Sometimes there are accessibility or semantic reasons to use a specific kind of markup, so don’t only focus on SEO.” (traduzione) «A volte ci sono ragioni di accessibilità o semantiche per usare un tipo specifico di markup, quindi non concentrarti solo sulla SEO.» — John Mueller, Google SEO Office Hours, stessa fonte. Leggi la copertura

Google — estrazione del contenuto principale (Martin Splitt)

• “We have a thing called the Centerpiece Annotation, for instance, and there’s a few other annotations that we have where we look at the semantic content.” — Martin Splitt, Google, via Search Engine Journal. Read the coverage
• “We figure out what looks like boilerplate and then, that gets weighted differently as well.” — Martin Splitt, same source. Read the coverage
• “It does help us, but it’s not the only thing that we look for. Yes.” — Martin Splitt, answering directly whether semantic HTML5 helps Google. Jump to quote

Google — non dipende dalla semantica valida/di specifica (Guida introduttiva alla SEO)

• “Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn’t matter if you’re using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” — Guida introduttiva alla SEO di Google. Vai alla citazione

Google — usa gli elementi per il loro scopo (Guida di stile)

• “Use HTML elements for the purposes that they were designed for.” — Guida di stile per la documentazione per sviluppatori di Google. Leggi la fonte

Bing / Microsoft (Fabrice Canel)

• Fabrice Canel di Microsoft Bing ha affermato che le pagine con HTML5 semantico implementato correttamente hanno un vantaggio nella SEO rispetto a quelle che non lo hanno — la posizione di Bing è più forte di quella di Google (“aiuta la comprensione”), anche se non viene ancora descritto come un fattore di ranking a punteggio. Parafrasato, non citato testualmente: questo è raggiunto tramite una citazione secondaria (Kalicube), non una fonte primaria Bing recuperata — conferma la formulazione esatta rispetto all’originale prima di trattarlo come citazione diretta. Leggi la fonte

Quale elemento serve a questo blocco?

La questione article-vs-section-vs-div (e il resto delle scelte sui landmark) è un vero bivio, non una preferenza di stile. Rispondi onestamente a ogni passaggio — il test è sempre “cosa fa realmente questo contenuto”, non “cosa sembra più moderno”.

Cosa non fare

Questi sono gli errori reali a cui puntano i miti sopra — ciascuno con il motivo per cui è sbagliato e cosa fare invece.

• Avvolgere il contenuto in <article> aspettandosi un aumento del ranking. Perché è sbagliato: Mueller ha detto che l’elemento “non ha alcun effetto particolare in Google Search.” Cosa fare invece: usa <article> quando il contenuto è genuinamente autonomo (potrebbe stare da solo in un feed), per accessibilità e chiarezza — non come leva SEO.

• Trattare l’HTML semantico in generale come un fattore di ranking con punteggio. Perché è sbagliato: è “non un moltiplicatore magico” e non c’è un segnale con punteggio da inseguire. Cosa fare invece: pianificare il lavoro come un investimento in comprensione/accessibilità con un ritorno reale (anche se non misurabile come ranking), non come un progetto di ranking con un miglioramento atteso.

• Ossessionarsi per un ordine perfetto dei titoli o una validità rigorosa per amore di Google. Perché è sbagliato: la stessa Guida introduttiva di Google dice “il web in generale non è HTML valido, quindi Google Search può raramente dipendere da significati semantici nascosti nella specifica HTML.” Cosa fare invece: correggere l’ordine dei titoli e la validità per screen reader e utenti — è lì che conta davvero — non perché Google lo stia valutando.

• Usare <section> come sostituto di <div> perché “sembra più moderno.” Perché è sbagliato: <section> senza un titolo non è un raggruppamento tematico, è decorazione — questo è l’uso errato più comune dell’elemento. Cosa fare invece: se il blocco non ha senso con un proprio titolo, usa <div>.

• Confondere HTML semantico con SEO semantico. Perché è sbagliato: uno è struttura di markup, l’altro è strategia di contenuto topico/entità — confonderli significa ottimizzare la cosa sbagliata per l’obiettivo che hai realmente. Cosa fare invece: tieni i due separati; questo articolo riguarda solo gli elementi.

• Saltare l’HTML semantico perché i dati strutturati esistono già. Perché è sbagliato: JSON-LD non risolve la zuppa di div, e i dati strutturati non sostituiscono la struttura del markup. Cosa fare invece: usa entrambi — dati strutturati si appoggiano su una base semantica, non la sostituiscono. Nessuno dei due garantisce un risultato ricco, comunque — quella è una questione separata di idoneità rispetto alla validità del markup.

• Annidare elementi <section> per far “comportare” i titoli come un livello inferiore. Perché è sbagliato: questo si basa sul vecchio algoritmo di struttura del documento di HTML5, che nessun browser o screen reader ha mai implementato e che l’attuale specifica WHATWG non definisce più in quel modo. Cosa fare invece: scrivi livelli espliciti e correttamente ordinati <h1>–<h6> — non lasciare che la profondità di annidamento sostituisca il livello di titolo che intendi davvero.

• Usare un <div> con un gestore di clic invece di <a href> o <button>. Perché è sbagliato: perdi l’attivazione nativa da tastiera e il ruolo accessibile corretto a meno che non ricostruisca manualmente entrambi con role, tabindex e gestori di tasti. Cosa fare invece: usa <a href> quando l’azione naviga da qualche parte, <button> quando fa qualcosa sulla pagina corrente — e ottieni il comportamento nativo gratuitamente.

Elementi landmark a colpo d’occhio

I sette elementi trattati in questo articolo, a cosa serve ciascuno e il modello di uso errato da evitare.

Regola pratica rapida: se un blocco potrebbe essere distribuito da solo, è <article>; se ha bisogno di un’intestazione per avere senso, è <section>; se non è né l’uno né l’altro, è un <div>.

Oltre i landmark: elementi interattivi e di dati

Prompt per l’adeguamento dell’HTML

Prompt pronti da copiare per il compito specifico trattato in questo articolo: trovare la div soup e convertirla in markup semantico corretto. Incolla l’HTML della tua pagina (visualizza sorgente, non il DOM renderizzato) in un assistente AI con uno di questi.

Segnala la div soup e suggerisci sostituzioni

Here is the HTML for one of my pages. Identify every <div> or <span> that is standing
in for a semantic landmark, and suggest the correct replacement element from this list:
header, nav, main, article, section, aside, footer. For each suggestion, explain which
test it passes (e.g. "this could stand alone in a feed, so it's an <article>" or "this
has its own heading and one theme, so it's a <section>"). Flag any block that should
stay a <div> because it's purely a styling/layout hook.

[paste HTML here]

Controlla errori strutturali dei landmark

Review this page's HTML for these specific structural mistakes: more than one <main>
element, a <main> nested inside <article>/<aside>/<header>/<footer>/<nav>, a <nav>
wrapping something that isn't major navigation, or a <section> with no heading. List
each problem found with the line/snippet and the fix.

[paste HTML here]

Dai priorità a un ordine di adeguamento

Given this page's HTML, tell me which landmark to fix first for the biggest
accessibility and main-content-extraction benefit: establishing <main>/<header>/
<footer>/<nav>, converting self-contained blocks to <article>, converting themed
groups to <section>, or moving sidebars to <aside>. Order the fixes and say what
"done" looks like for each.

[paste HTML here]

I landmark corrispondono alla struttura prevista

Test da eseguire: Apri l’albero di accessibilità degli strumenti di sviluppo del tuo browser (Chrome/Edge: DevTools → Elements → pannello Accessibility) sulla pagina adeguata. Risultato atteso: I ruoli landmark elencati (banner, navigation, main, complementary, contentinfo) corrispondono agli elementi semantici che hai effettivamente scritto — un main/ruolo “main”, un banner, ecc. Interpretazione del fallimento: Un ruolo landmark mancante o duplicato significa che il markup non ha prodotto la struttura prevista (es. un secondo <main>, o un <div> che avrebbe dovuto essere convertito). Finestra di monitoraggio: Immediata — controlla subito dopo aver distribuito l’adeguamento. Trigger di rollback: Più di un landmark main/“main”, o un landmark annidato dove non dovrebbe essere (es. main dentro article), significa annullare e ricontrollare il markup.

Esattamente un <main> per pagina

Test da eseguire: grep -o "<main" page.html | wc -l sull’HTML renderizzato (o visualizza sorgente), oppure cerca <main nel pannello Elements di DevTools. Risultato atteso: Esattamente una corrispondenza. Interpretazione del fallimento: Zero corrispondenze significa che non è stato impostato alcun landmark di contenuto primario; più di una significa che il “segnale più chiaro” sul contenuto principale è ora ambiguo. Finestra di monitoraggio: Immediata, al momento della distribuzione. Trigger di rollback: Qualsiasi conteggio diverso da esattamente uno.

I crawler che non renderizzano vedono comunque la struttura

Test da eseguire: Recupera la pagina con un client HTTP semplice (curl o “visualizza sorgente pagina”, non il DOM renderizzato) e conferma che gli elementi semantici siano presenti nella risposta grezza, non iniettati successivamente da JavaScript lato client. Risultato atteso: <header>, <nav>, <main>, <article>/<section>, <aside> e <footer> compaiono tutti nel payload HTML iniziale. Interpretazione del fallimento: Se i tag semantici compaiono solo dopo l’esecuzione di JavaScript, i crawler che non eseguono JavaScript (come indicato nel punto sui crawler AI/LLM sopra) non vedono mai la struttura. Finestra di monitoraggio: Immediata — ricontrolla ogni volta che un template o un framework JS cambia il modo in cui la pagina viene renderizzata. Trigger di rollback: I landmark semantici presenti nel DOM renderizzato ma assenti nella risposta HTML grezza.

I livelli di intestazione sono espliciti, non ereditati dall’annidamento

Test da eseguire: Nell’albero di accessibilità degli strumenti di sviluppo del browser (o in un’estensione di controllo dell’outline), elenca i livelli di intestazione in ordine di documento e confrontali con i tag <h1>–<h6> effettivi nel sorgente, indipendentemente da quanto profondamente ogni intestazione sia annidata all’interno di elementi <section>/<article>. Risultato atteso: Il livello di intestazione riportato per ciascuna intestazione corrisponde al suo tag letterale (un <h2> viene riportato come livello 2 non importa in quante sezioni sia annidato) — non c’è alcuna retrocessione implicita dovuta all’annidamento. Interpretazione del fallimento: Se il tuo template o una libreria di componenti si affida all’annidamento di <section> per “abbassare” automaticamente il rango di un’intestazione, questa ipotesi non regge — il vecchio algoritmo di outline del documento non è mai stato implementato e la specifica attuale non calcola gli outline in quel modo. Correggi i tag di intestazione effettivi. Finestra di monitoraggio: Immediata, e ogni volta che un nuovo template o pattern di componenti introduce sezioni annidate. Trigger di rollback: Il livello renderizzato/annunciato di un’intestazione non corrisponde al suo tag <h1>–<h6> letterale.

Link finti e pulsanti finti sono accessibili da tastiera

Test da eseguire: Naviga con Tab attraverso la pagina usando solo la tastiera e prova ad attivare ogni elemento cliccabile con Invio/Spazio; separatamente, controlla nell’albero di accessibilità il ruolo che ogni elemento cliccabile riporta. Risultato atteso: Gli elementi che navigano riportano link (<a href> nativo); gli elementi che agiscono sulla pagina riportano button (<button> nativo) ed entrambi sono raggiungibili e attivabili da tastiera senza codice aggiuntivo di role/tabindex/gestione dei tasti. Interpretazione del fallimento: Un <div> o <span> con un gestore di clic che non è raggiungibile da tastiera, o che riporta un ruolo generico invece di link/button, significa che deve essere convertito nell’elemento nativo piuttosto che corretto con ARIA. Finestra di monitoraggio: Immediata — ricontrolla dopo qualsiasi modifica a librerie di componenti o design system che riguardi elementi interattivi. Trigger di rollback: Qualsiasi controllo cliccabile che non può essere raggiunto o attivato solo con la tastiera.

Mettiti alla prova: HTML semantico

Cinque domande rapide sull’HTML semantico e su cosa fa (e non fa) per la SEO. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche