Lingue

SEO dell’HTML

Come la struttura HTML, gli elementi e la semantica influenzano la SEO — come Google analizza e renderizza il tuo markup, quali elementi legge direttamente, l'errore di head malformato che elimina silenziosamente i tag, e perché l'HTML valido/semantico aiuta la comprensione senza essere un fattore di ranking diretto.

Prima pubblicazione: 2 lug 2026 · Ultimo aggiornamento: 24 ago 2026 · Avanzato
AIScritto daAI v2

L'HTML SEO consiste nello scrivere e strutturare il markup in modo che i motori di ricerca possano eseguire la scansione, il rendering, l'analisi e la comprensione di una pagina. Il fatto più liberatorio: Google afferma che 'il web in generale non è HTML valido', quindi raramente si basa su una rigorosa correttezza semantica — esegue tutto attraverso un lexer/normalizzatore HTML, analizza l'HTML grezzo per link e contenuti, poi esegue il rendering con un Chromium headless (il Web Rendering Service) e indicizza il DOM renderizzato. Elementi specifici vengono letti direttamente — title, heading, a href, img alt e og:title alimentano elementi come il titolo del link nei risultati di ricerca. Il modo di errore poco coperto: un elemento non valido all'interno della head fa sì che Google ignori tutto ciò che segue, eliminando silenziosamente un title, canonical o hreflang. L'HTML valido non è un fattore di ranking e l'HTML semantico non è un 'moltiplicatore magico' (Mueller: non è un segnale di qualità, ma 'ci aiuta a comprendere meglio le pagine') — l'obiettivo è evitare gli errori di parsing che la validità avrebbe rilevato, non inseguire un validatore verde. Questo hub rimanda all'approfondimento sull'HTML semantico per una trattazione elemento per elemento.

TL;DR — L’HTML SEO consiste nel strutturare il markup in modo che i motori di ricerca possano indicizzare, renderizzare, analizzare e comprendere una pagina. Il fatto liberatorio: Google dice “il web in generale non è HTML valido, quindi Google Search può raramente dipendere da significati semantici nascosti nella specifica HTML.” Normalizza tutto attraverso un lexer HTML, analizza l’HTML grezzo per link/contenuti, poi renderizza con un Chromium headless (il Web Rendering Service) e indicizza il DOM renderizzato. Elementi specifici alimentano direttamente la SERP — <title>, intestazioni e og:title sono input nominati per il titolo del link. Il fallimento netto e poco coperto: un elemento non valido in <head> fa sì che Google ignori tutto ciò che viene dopo, eliminando silenziosamente un <title>, canonico o hreflang. L’HTML valido non è un fattore di ranking; l’HTML semantico “ci aiuta a comprendere meglio le pagine” (Mueller) ma non è un segnale di qualità. Cerca i modi di fallimento che la validità catturerebbe, non un validatore verde.

Prova a sostegno di questa affermazione Google reliably crawls links when they are HTML a elements with resolvable href attributes. Ambito: Googlebot link discovery requirements. Attendibilità: alta · Verificato: Google Search Central: Crawlable links Prova a sostegno di questa affermazione Google processes only supported elements in the document head and may ignore elements appearing after an invalid head element. Ambito: Google's parsing of metadata in the HTML head. Attendibilità: alta · Verificato: Google Search Central: Valid page metadata

Cos’è realmente l’HTML SEO

L’HTML SEO è la pratica ampia che copre qualsiasi elemento HTML o scelta strutturale che influisce su come un motore di ricerca esegue la scansione, analizza, renderizza e comprende una pagina. È il livello sottostante alle questioni di contenuti e link in cui si concentra la maggior parte delle conversazioni SEO — il markup che decide se Google può persino vedere il tuo titolo, i tuoi link e il tuo canonical in primo luogo.

Si sovrappone, ma non è la stessa cosa, dell’HTML semantico — la pratica più ristretta di scegliere elementi come <article>, <nav>, <main> e <section> per il loro significato strutturale piuttosto che ripiegare su <div> non stilizzati. Questa profondità elemento-per- elemento è un argomento a sé (vedi l’approfondimento sull’HTML semantico annidato sotto questo hub); qui voglio il quadro completo di come il markup incontra la pipeline di ricerca.

Come Google analizza e renderizza effettivamente il tuo HTML

Questa è la parte che quasi ogni checklist “tag HTML per la SEO” salta, ed è la parte che spiega effettivamente perché i consigli sui tag funzionano nel modo in cui funzionano.

Google legge il tuo HTML in due fasi. Dalle Nozioni di base sulla SEO JavaScript di Google: prima, “crawling a URL and parsing the HTML response works well for classical websites or server-side rendered pages where the HTML in the HTTP response contains all content,” (traduzione) «la scansione di un URL e l’analisi della risposta HTML funzionano bene per i siti classici o con rendering lato server, quando la risposta HTML contiene tutti i contenuti»; poi “Googlebot then parses the response for other URLs in the href attribute of HTML links and adds the URLs to the crawl queue.” (traduzione) «Googlebot analizza la risposta alla ricerca di altri URL nell’attributo href dei link HTML e li aggiunge alla coda di scansione». Nella seconda fase, “Googlebot queues all pages with a 200 HTTP status code for rendering… Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript,” (traduzione) «Googlebot mette in coda per il rendering tutte le pagine con stato HTTP 200; quando le risorse lo consentono, Chromium headless esegue il rendering della pagina e il JavaScript»; quindi “Googlebot parses the rendered HTML for links again” (traduzione) «Googlebot analizza di nuovo l’HTML renderizzato alla ricerca di link» e “Google also uses the rendered HTML to index the page.” (traduzione) «Google usa anche l’HTML renderizzato per indicizzare la pagina».

Quindi: HTML grezzo prima (veloce, per la scoperta dei link e il contenuto iniziale), poi il DOM renderizzato dopo che un Chromium headless — il Web Rendering Service — esegue il tuo JavaScript. L’indice finale è costruito dall’HTML renderizzato. L’implicazione pratica è quella che sottolineo nel mio lavoro sulla SEO JavaScript: il contenuto presente nella tua risposta iniziale del server viene visto più rapidamente e in modo più affidabile rispetto al contenuto che esiste solo dopo l’esecuzione del JavaScript lato client.

Il lexer HTML — perché Google tollera markup disordinato

Prima di tutto ciò, Google normalizza il tuo HTML. Gary Illyes lo ha descritto su un podcast di Google: “we push all the HTML through an HTML lexer… we normalize the HTML,” (traduzione) «facciamo passare tutto l’HTML attraverso un lexer e lo normalizziamo»; anche i tag di intestazione sono “normalized through rendering,” (traduzione) «normalizzati durante il rendering», mentre Google cerca di “understand the styling that was applied on the h tags, so we can determine the relative importance.” (traduzione) «capire lo stile applicato ai tag h per determinarne l’importanza relativa». Queste righe provengono da una trascrizione del forum del podcast piuttosto che dalla trascrizione primaria di Google — trattale come riportate, non come fonte primaria.

Questo è lo stesso modello che insegno nel mio Come funziona la ricerca deck: lexer HTML → normalizza → albero DOM + CSSOM → albero di rendering → indice. È esattamente il motivo per cui Google non ha bisogno che il tuo HTML sia impeccabile. Non sta leggendo il testo sorgente grezzo alla ricerca di tag perfetti; sta analizzando il tuo markup in un albero normalizzato prima, recuperando dai frammenti rotti come fa un browser. Il che ci porta alla citazione più liberatoria dell’intero argomento.

”Il web in generale non è HTML valido”

La Guida introduttiva alla SEO di Google lo dice chiaramente, in una sezione intitolata letteralmente cose su cui non dovresti concentrarti:

“the web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.” (traduzione) «Il web in generale non è HTML valido, quindi la Ricerca Google può raramente dipendere dai significati semantici nascosti nella specifica HTML».

La stessa guida aggiunge che avere intestazioni in rigoroso ordine semantico è “fantastico per gli screen reader, ma dal punto di vista della Ricerca Google, non importa se le usi fuori ordine,” e che non esiste “un numero magico e ideale di intestazioni che una determinata pagina dovrebbe avere. Tuttavia, se pensi che siano troppe, probabilmente lo sono.”

Leggilo come un permesso di smettere di inseguire un validatore W3C perfettamente verde. La validità non è un fattore di ranking. Il motivo per preoccuparsi del markup rotto è più ristretto e più specifico: certi tipi di invalidità rompono il parsing in modi che nascondono i tuoi contenuti.

Quali elementi HTML Google legge direttamente

Alcuni elementi non vengono solo analizzati per un vago “comprensione” — Google li nomina come input diretti a ciò che appare nella SERP. Dalla documentazione sui Title Links, Google determina il title link da “contenuto negli elementi <title>, titolo visivo principale mostrato sulla pagina, elementi di intestazione, come elementi <h1>, contenuto nei meta tag og:title,” e altro testo in evidenza stilizzato.

Gli elementi che vale la pena sistemare — e dove andare per approfondimenti sull’implementazione di ciascuno, poiché questo hub instrada piuttosto che riprodurre:

  • <title> — l’input primario per il title link. Approfondimenti su come scriverlo e testarlo si trovano nel dedicato articolo sul title tag.
  • Metadati <head> — canonical, meta robots, hreflang. Il <head> è, secondo Google, “l’elemento primario per specificare metadati su una pagina.” Approfondimenti: canonical tag e meta robots.
  • Intestazioni (<h1>–<h6>) — strutturali e normalizzate attraverso il rendering (Google considera anche il CSS applicato). Approfondimenti su queste si trovano nel dedicato articolo sugli header tags — non ottimizzare eccessivamente l’ordine.
  • Link (<a href>) — il meccanismo per la scoperta degli URL. Se il tuo “link” è un gestore di clic su un <div> senza href, Googlebot potrebbe non mettere mai in coda quell’URL.
  • <img alt> — comprensione delle immagini più accessibilità. Approfondimenti: articolo sull’alt text.
  • og:title e testo in evidenza stilizzato — input aggiuntivi per il title link.

L’unico errore che rompe silenziosamente tutto: un <head> malformato

Questo è il bug HTML SEO più concreto e meno trattato nella documentazione di Google. Da Metadati di pagina validi per la Ricerca Google:

“Se usi un elemento non valido nell’elemento <head>, Google ignora qualsiasi elemento che appare dopo l’elemento non valido.”

I figli validi di <head> sono una breve whitelist: title, meta, link, script, style, base, noscript e template. Se inserisci qualcos’altro lì — un <img> fuori posto, un <iframe>, un tag non chiuso o uno <script> conforme alle specifiche che inietta uno di questi — i browser troncano il <head> in quel punto, spingendo tutto ciò che segue nel <body>. Se il tuo <title>, rel=canonical o i tag link hreflang si trovano dopo l’elemento problematico, Google potrebbe semplicemente non vederli mai. Come dice Google, “usare HTML valido per i metadati della pagina garantisce che Google possa usare i metadati come documentato.”

Questa è la modalità di errore che rende l‘“HTML valido” degno di attenzione — non il punteggio del validatore, ma la conseguenza. Come individuarlo: visualizza il sorgente e conferma che i tuoi tag critici siano dentro <head>; esegui la pagina attraverso un validatore; e usa URL Inspection di GSC per vedere l’HTML renderizzato che Google ha effettivamente ricevuto.

Il punteggio del validatore non è il problema; il problema è che i metadati critici finiscono dopo che il parser ha terminato l'head. Fonte: Google Search Central

Un titolo e una meta description posizionati prima di un elemento immagine non valido nell'head possono essere letti normalmente. L'elemento non valido crea un confine di parsing. I metadati canonical, robots e hreflang posizionati dopo quel confine possono essere ignorati o spostati nel body. Verifica la conseguenza controllando il sorgente e l'HTML renderizzato, non inseguendo un punteggio di validazione perfetto.

© Patrick Stox LLC · CC BY 4.0 ·

HTML vs. HTML semantico: aiuta la comprensione, non è un segnale di ranking

Ecco la tensione che questo hub esiste per risolvere. Usare elementi semantici — <article>, <nav>, <header>, <section> — invece di zuppa di <div> aumenta il tuo ranking?

La risposta più chiara è quella di John Mueller. Rispondendo a un SEO che sosteneva che la gerarchia dei tag semantici debba essere un segnale di qualità, ha detto:

“I don’t see it as a quality signal, but it definitely helps us to better understand pages, so that we can show them better for the appropriate queries in search.” (traduzione) «Non lo vedo come un segnale di qualità, ma ci aiuta certamente a comprendere meglio le pagine, così da mostrarle meglio per le query appropriate nella ricerca».

Tutta la sfumatura è in una frase. L’HTML semantico non è un input diretto di ranking/qualità, ma è un aiuto alla comprensione — e una migliore comprensione può indirettamente aiutare Google a abbinare la tua pagina alle query giuste. Martin Splitt ha detto separatamente che gli elementi semantici usati correttamente danno alle pagine un vantaggio nell’essere comprese. La cornice «vantaggio SEO» di Splitt è parafrasata dalla copertura del webinar, non una citazione verbatim verificata — non la metto tra virgolette. Splitt è stato anche diretto sul fatto che la struttura dei titoli non è un requisito rigoroso: “it does not make a difference if you have an H1 and then H2, H2, H2… fundamentally, it doesn’t make that much of a difference.” (traduzione) «non fa differenza avere un H1 seguito da H2, H2, H2; in sostanza non cambia molto».

La versione moderna e pratica di questo problema è la div soup: le librerie di componenti React, Vue e Tailwind di default emettono <div> per tutto. Non è una penalità di ranking, ma elimina i punti di riferimento strutturali (sezioni, <nav>, <main>) che aiutano sia la comprensione di Google che l’accessibilità. Raggiungere l’elemento giusto non costa nulla e può solo aiutare. Il caso elemento per elemento è compito dell’articolo dedicato HTML semantico in questo sottocluster — questo hub traccia solo la linea: aiuto alla comprensione, sì; moltiplicatore di ranking magico, no.

L’HTML valido conta per la SEO?

Risposta breve: non come fattore di ranking diretto. Google non ha mai nominato la validità W3C come uno di questi, e “the web in general is not valid HTML.” (traduzione) «il web in generale non è HTML valido». La giusta riformulazione è questa: la validità non è l’obiettivo — evitare i modi di fallimento che la validità avrebbe catturato è l’obiettivo. Un errore di validazione vale la pena di essere corretto quando cambia effettivamente il contenuto, i metadati, i link, l’accessibilità o il rendering che un visitatore o un crawler riceve — non perché il punteggio non è 100%. Un <head> malformato che espelle il tuo canonical, un tag non chiuso che nasconde contenuto, un elemento che spinge hreflang nel <body> — quelli sono problemi SEO reali e indiretti, e capita che siano esattamente le cose che un validatore segnala. Insegui le conseguenze, non il segno di spunta verde.

Come Bing legge l’HTML in modo diverso

Bing inquadra l’HTML strutturale in modo più letterale di Google. La sua descrizione di lunga data di come il bot tratta i tag di intestazione è che “the <h1>, <h2>, and deeper tags… are regarded by the bot as more like XML than HTML in that they describe the data they contain” (traduzione) «i tag <h1>, <h2> e successivi sono considerati dal bot più simili a XML che a HTML, perché descrivono i dati contenuti» — descrittori di contenuto, non stile visivo. Le linee guida per webmaster di Bing nominano esplicitamente le intestazioni come segnali strutturali: “<H1>–<H6> Header tags — Define the structure of your page and helps Bing understand the content of each paragraph.” (traduzione) «I tag di intestazione da H1 a H6 definiscono la struttura della pagina e aiutano Bing a comprendere il contenuto di ogni paragrafo». Entrambe le righe di Bing sono riutilizzate da citazioni già verificate nella ricerca sui tag di intestazione del sito; le pagine di Bing vengono renderizzate via JS e resistono alla ricontrollatura automatica — verifica prima di trattarle come definitive.

Per i siti che ottimizzano per entrambi i motori, il punto è piccolo ma reale: la lettura di Google è più consapevole del render-tree/contesto CSS (pesa lo stile applicato), mentre Bing si affida di più ai tag strutturali grezzi come descrittori di dati. Una struttura pulita e significativa serve entrambi.

Errori comuni di SEO HTML

  • <head> malformato — il grande problema sopra; un elemento non valido elimina ogni tag successivo.
  • Contenuto renderizzato solo da JS lato client senza fallback server-rendered — indicizzato in ritardo, nel secondo passaggio (render), se non mai.
  • Div soup senza punti di riferimento semantici — nessuna penalità, ma segnale strutturale perso e accessibilità peggiore.
  • “Link” che non sono <a href> — gestori di click su <div> che Googlebot non può accodare come URL.
  • Direttive <head> multiple o in conflitto — due canonical, o una canonical che contraddice la tua meta robots.
  • Titoli scelti per dimensione visiva, non per struttura (e testo stilizzato con CSS che si spaccia per titolo) — Google normalizza e pesa lo stile renderizzato, quindi la discrepanza offusca la tua struttura.

Dove si colloca questo hub

Questo è l’hub per il sottocluster SEO HTML. Il suo compito è la copertura e la navigazione, non la profondità esaustiva su ogni singolo elemento. L’articolo dedicato HTML semantico annidato sotto di esso gestisce il trattamento elemento per elemento di <article>, <section>, <nav>, <header>, <main> e <aside>. L’attributo lang HTML ha il suo approfondimento dedicato — cosa dichiara realmente <html lang="en">, come differisce da hreflang, e perché Google lo ignora per il rilevamento della lingua mentre Bing lo tratta come un segnale minore. La profondità dei titoli vive in tag title, la profondità dei titoli vive in tag header, la profondità delle immagini vive in testo alt, la profondità delle direttive <head> vive in tag canonical e meta robots, e la storia del rendering approfondisce in SEO JavaScript. Inizia qui per il modello mentale; dirama per i dettagli.

Aggiungi una nota dell’esperto

Fissa una citazione dell’esperto

Persona nuova? Crea il suo profilo non rivendicato in /admin/experts/ → Fissa una citazione dell’esperto prima.