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: 3 ago 2026 · Advanced
Lingue
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.

Evidence for this claim Google reliably crawls links when they are HTML a elements with resolvable href attributes. Scope: Googlebot link discovery requirements. Confidence: high · Verified: Google Search Central: Crawlable links Evidence for this claim Google processes only supported elements in the document head and may ignore elements appearing after an invalid head element. Scope: Google's parsing of metadata in the HTML head. Confidence: high · Verified: 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,” e “Googlebot then parses the response for other URLs in the href attribute of HTML links and adds the URLs to the crawl queue.” Poi, fase due: “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,” dopo di che “Googlebot parses the rendered HTML for links again” e “Google also uses the rendered HTML to index the page.”

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 Search Off the Record: “we push all the HTML through an HTML lexer… we normalize the HTML,” e anche i tag di intestazione sono “normalized through rendering,” con Google che cerca di “understand the styling that was applied on the h tags, so we can determine the relative importance.” 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.”

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 Valid Page Metadata for Google Search:

“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.

The validator score is not the problem; the problem is critical metadata landing after the parser has ended the head. Fonte: Google Search Central

A title and meta description placed before an invalid image element in the head can be read normally. The invalid element creates a parsing boundary. Canonical, robots, and hreflang metadata placed after that boundary may be ignored or moved into the body. Verify the consequence by checking source and rendered HTML, not by chasing a perfect validation score.

© 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.”

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.”

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 per farlo è compito dell’articolo dedicato semantic HTML 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.” 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” — descrittori di contenuto, non stile visivo. Le Webmaster Guidelines 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.” 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.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.