Pubblicato il 3 Gen 2026 - Aggiornato il 11 Mar 2026

SEO HTML: i tag sono i mattoni che contano davvero per il ranking

SEO

Se il tuo sito è già online, la domanda non è “manca qualcosa in HTML?”, ma quali tag HTML stanno davvero spostando visibilità, performance e vendite — e quali invece sono rumore. Questa guida nasce per chi deve prendere decisioni (o approvare sviluppi) senza perdersi in tecnicismi: capire cosa controllare, cosa chiedere a sviluppatori/agenzie e come verificare che sia stato implementato correttamente.

L’obiettivo è collegare ogni intervento a KPI misurabili: dalla CTR in SERP ai Core Web Vitals, fino al tasso di conversione su categorie, prodotti e checkout così da costruire solide basi per il posizionamento organico.

E se gestisci più progetti (in azienda o in agenzia), qui trovi un approccio replicabile per standardizzare controlli, best practice ed evidenze.

SEO HTML: le fondamenta

Iniziamo dalle basi: cosa intendiamo per SEO, come si collega all’HTML e come i motori interpretano il DOM. Impostare correttamente il documento e la struttura semantica riduce l’ambiguità per crawler e utenti. Qui definisci il perimetro di lavoro e costruisci le fondamenta su cui tutto il resto potrà scalare.

I pilastri della SEO sono rilevanza dei contenuti, autorevolezza (link, citazioni, segnali) e performance tecnica, dentro cui la SEO HTML è una leva diretta e immediata.

L’obiettivo operativo è ridurre gli ostacoli tra il tuo contenuto e l’intento dell’utente: markup chiaro, meta coerenti, struttura gerarchica comprensibile e pagine veloci. Un approccio sistematico alla SEO HTML rende più prevedibili i risultati e più facile la scalabilità.

Differenze tra SEO tecnica, on-page e HTML semantico

La SEO tecnica copre infrastruttura e rendering: status code, sitemap, robots, Core Web Vitals e architettura. La SEO on-page riguarda contenuti, heading, title/description e link interni. L’HTML semantico è il ponte tra le due: tag significativi che comunicano struttura e ruoli ai crawler e ai lettori.

Investire nell’HTML semantico riduce dipendenze da hack o plugin e moltiplica l’effetto di contenuti e link. In pratica, la pagina “parla” più chiaramente a Google, che può fidarsi di più del tuo documento e premiare l’esperienza.

Come Google interpreta DOM, meta tag e struttura dei contenuti

Google esegue crawling, parsing del DOM, rendering (quando serve JavaScript) e indicizzazione. Una struttura pulita con H1–H6 coerenti, title e meta description ottimizzati e link interni chiari accelera comprensione e ranking potenziale.

Meta robots e canonical indirizzano l’indicizzazione; dati strutturati e breadcrumb aiutano a contestualizzare. Se il DOM è rumoroso o i contenuti critici sono nascosti o tardivi nel rendering, rischi di perdere copertura e rich result.

Impostazioni di base del documento HTML per una corretta scansione

Imposta doctype HTML5, lang coerente con la lingua della pagina, charset UTF-8 e viewport per il mobile. Struttura l’head con ordine critico: title, meta charset/viewport, meta robots, link canonical, CSS critici, script defer; nel body mantieni gerarchie chiare con landmark semantici.

Gestisci correttamente gli status code: 200 per pagine attive, 301 per redirect permanenti, 410 per rimozioni definitive. Evita catene di redirect e controlla che non ci siano 404 o 302 superflui su percorsi strategici: sono segnali che disperdono equity e crawl budget.

Mappa di priorità: cosa controllare quando il sito è già online

Quando lavori su un sito già pubblicato, la domanda utile è “qual è il prossimo controllo che ha più probabilità di muovere i KPI?”. Non tutti i tag hanno lo stesso peso: alcuni impattano direttamente indicizzazione e snippet, altri lavorano “di sponda” su CTR, performance e fiducia. Qui sotto trovi una mappa pratica per orientare audit SEO e backlog, utile anche per allinearti con dev e agenzia su cosa viene prima.

Priorità 1: SERP e indicizzazione (prima visibilità, poi traffico)

Se title/canonical/robots sono “storti”, tutto il resto rende meno: puoi avere contenuti ottimi, ma Google mostra lo snippet sbagliato o indicizza la pagina sbagliata. Qui l’impatto è misurabile in modo relativamente rapido: Search Console ti dà segnali su CTR, query, pagine escluse e motivazioni.

Un modo pragmatico per decidere dove intervenire è partire dalle URL che già hanno impression ma CTR basso (snippet migliorabile) e dalle URL che generano revenue ma sono in competizione tra loro (problemi di duplicazione e canonical). Su ecommerce è un classico: categorie con filtri, varianti prodotto, parametri di tracking e pagine di ordinamento che “sporcano” l’indice.

Priorità 2: performance percepita (perché velocità = UX + conversioni)

Molti interventi HTML non “fanno SEO” in senso stretto, ma spostano Core Web Vitals e quindi esperienza, engagement e conversioni. Su siti ecommerce, pochi decimi di secondo possono valere più di una micro-ottimizzazione testuale, soprattutto da mobile.

La cosa importante è evitare interventi che migliorano i numeri “in laboratorio” ma peggiorano l’esperienza reale (ad esempio lazy-load aggressivo sull’immagine principale che peggiora LCP). Qui la priorità è lavorare sulle risorse critiche (immagine hero, CSS essenziale, font) e ridurre ciò che blocca il rendering.

Priorità 3: struttura e chiarezza (capire cosa vendi e dove portare l’utente)

Nel body, i tag servono soprattutto a due cose: rendere esplicita la gerarchia del contenuto (heading) e guidare la scoperta (link interni). Non è solo “SEO tecnico”: è anche usabilità e percorso verso la conversione, perché un catalogo capibile è un catalogo più acquistabile.

Per chi gestisce più progetti, questa è l’area più semplice da standardizzare: pattern coerenti di heading su categorie e schede prodotto, breadcrumb sempre presenti, anchor text descrittivi e immagini sempre con dimensioni definite per evitare salti di layout (CLS).

Ottimizzazione nel <head>: segnali che guidano SERP e crawling

Il tag <head> è il posto in cui spesso si vince o si perde tempo: pochi tag, ma molto “peso specifico”. Qui l’obiettivo non è aggiungere roba, ma assicurarsi che ciò che c’è sia coerente, unico e orientato a snippet/indicizzazione. Se devi validare un rilascio, questa sezione è perfetta per definire criteri di accettazione chiari con sviluppatori e agenzia.

<title>: il tag più “business” di tutta la pagina

Il <title> è uno dei segnali on-page più forti e, soprattutto, è la leva più diretta sul CTR. Su ecommerce funziona bene quando unisce “cosa è la pagina” (categoria/prodotto) e “perché cliccare” (benefit rilevante, marca se ha senso, elementi di fiducia), senza diventare un elenco infinito di keyword.

Dal punto di vista operativo, quello che conta è la unicità su larga scala: template coerenti per categorie e prodotti, ma con variabili che evitano duplicati (nome prodotto completo, attributo distintivo, brand se davvero cercato). Se vedi tanti title identici o quasi, spesso la causa è un feed incompleto o un template troppo generico.

Per validare: controlla un campione di URL top (per traffico o revenue) e un campione “random” di pagine profonde. Se trovi pattern di duplicazione, non è un problema di singola pagina: è un problema di logica di generazione.

Meta description: non fa ranking, ma decide chi entra

La meta description non è un fattore di ranking diretto, ma impatta fortemente la probabilità di click quando lo snippet la usa. In settori competitivi, una description ben scritta può fare la differenza tra “ti vedono” e “ti scelgono”, soprattutto su query dove i risultati sono simili.

Il punto chiave è evitare description auto-generate vuote, tronche o tutte uguali. Su categorie e landing page, lavora con promesse concrete e verificabili (spedizione, resi, assistenza, ampiezza assortimento), senza superlativi generici. Su pagine di prodotto, spesso è più utile una sintesi di benefit e condizioni d’acquisto che una ripetizione del nome prodotto.

Misurazione: dopo l’update, monitora CTR e posizione media in Search Console sulle query principali. Se la posizione resta simile e il CTR sale, hai trovato una leva “pulita” che non richiede stravolgimenti.

Canonical: la cintura di sicurezza contro duplicati e filtri

Il canonical serve a dichiarare qual è la versione “preferita” di una pagina quando esistono duplicati o quasi-duplicati (parametri, filtri, ordinamenti, varianti). Non è un comando assoluto, ma un segnale forte: quando è coerente con il resto (link interni, sitemap, contenuto), aiuta moltissimo a consolidare segnali e ridurre sprechi di crawl.

Su ecommerce il tema tipico è la navigazione a faccette: le URL filtrate possono avere senso per l’utente, ma non sempre devono entrare in indice. Qui la scelta è strategica: alcune combinazioni meritano una pagina indicizzabile (se hanno domanda e margine), la maggior parte no. Il canonical deve riflettere questa decisione, non “sparare nel mucchio”.

Validazione pratica: controlla che il canonical sia assoluto, che punti a una pagina 200 OK, che non sia bloccata e che non ci siano catene (A canonizza B, B canonizza C). Sono errori che generano settimane di “perché non si posiziona?” senza una causa evidente.

Meta robots (e X-Robots-Tag): quando usare noindex senza fare danni

Il meta robots (noindex, nofollow) è una leva delicata: risolve problemi reali (risultati di ricerca interna, pagine utility, filtri inutili), ma se applicata male taglia traffico “buono”. In molti progetti, la perdita improvvisa di visite organiche nasce da un noindex finito nel template sbagliato o attivato da una condizione non prevista.

Da un punto di vista di processo, la cosa più utile è distinguere: “questa pagina deve esistere per l’utente” vs “questa pagina deve essere indicizzabile”. Non sono sempre la stessa cosa. E ricordati che se blocchi una URL via robots.txt, Google potrebbe non vedere il meta robots e il canonical: quindi stai riducendo il controllo, non aumentandolo.

Hreflang (se hai più lingue/paesi): coerenza prima di tutto

Hreflang è fondamentale quando hai versioni linguistiche o geografiche della stessa pagina e vuoi evitare che l’utente italiano atterri su una pagina in un’altra lingua (e viceversa). Non è un “boost”, è una gestione corretta della targetizzazione e dell’esperienza.

Gli errori più comuni sono: hreflang non reciproco (A punta a B ma B non punta ad A), canonical che contraddice hreflang, e URL che restituiscono redirect o 404. In questi casi Google tende a ignorare il segnale, e tu rimani con un setup complesso ma inefficace.

Operativamente in un progetto SEO multilingua conviene testare su un set limitato di URL critiche (homepage, top categorie, top prodotti) prima di estendere a tutto il catalogo. È più sostenibile e riduce i rilasci “a rischio”.

Ottimizzazione nel <body>: struttura, segnali semantici e percorso utente

Nel body l’obiettivo è doppio: aiutare Google a capire rapidamente tema e priorità della pagina, e aiutare l’utente a orientarsi senza attrito. Qui spesso si sblocca crescita con interventi che sembrano “banali” (heading puliti, breadcrumb coerenti, link interni sensati), ma che impattano davvero su crawling e conversioni.

Headings (H1, H2, H3): gerarchia chiara, non styling

Gli heading dovrebbero raccontare la struttura della pagina: un solo H1 che definisce il topic principale (categoria o prodotto), poi H2/H3 per sezioni e sotto-sezioni. Quando gli heading vengono usati per “fare grande un testo” o per inserire keyword in serie, il risultato è confuso sia per Google che per l’utente.

Su una categoria, un pattern sostenibile è: H1 con nome categoria, H2 per blocchi informativi (guida alla scelta, materiali, FAQ brevi), H2 per sotto-categorie o collezioni se esistono. Su una scheda prodotto, H1 con nome prodotto, H2 per descrizione, specifiche, spedizione/resi, recensioni (se presenti). Questo aiuta anche la CRO: le persone trovano più velocemente le informazioni che riducono l’incertezza.

Se devi fare Q&A, chiediti una cosa semplice: gli heading cambiano in modo sensato tra pagine diverse? Se su 50 pagine di prodotto trovi lo stesso H2 “Descrizione prodotto” ripetuto senza contenuto reale, hai un segnale che la pagina sta diventando un template vuoto.

Link interni: il modo più economico per distribuire valore (e guidare il funnel)

I link interni fanno tre lavori contemporaneamente: aiutano il crawling, distribuiscono autorità tra pagine e costruiscono percorsi di navigazione. In ecommerce, i punti caldi sono categorie → sotto-categorie → prodotti, ma anche pagine prodotti → categorie correlate e collezioni, e soprattutto breadcrumb.

L’anchor text conta perché rende esplicita la relazione tra pagine: “sedie in legno” è più informativo di “scopri di più”. Non serve essere iper-ottimizzati, serve essere specifici. E in ottica di conversione, link interni ben pensati riducono rimbalzi e aumentano la scoperta di alternative quando un prodotto non convince.

Immagini: alt, dimensioni e caricamento (SEO + performance insieme)

Per molte categorie ecommerce, le immagini sono parte del contenuto, non un accessorio. L’alt aiuta accessibilità e contestualizzazione; non è il posto per ripetere keyword a caso, ma per descrivere in modo utile ciò che l’immagine mostra (modello, materiale, colore, dettaglio).

Sul lato performance, due aspetti HTML sono spesso sottovalutati: width/height (o dimensioni via CSS coerenti) per evitare CLS, e la gestione del caricamento. Lazy-load va usato con criterio: ciò che definisce la prima impressione della pagina (spesso l’immagine principale) non dovrebbe essere penalizzato.

Se stai validando un rilascio, fai un controllo “da business”: la pagina è più rapida e stabile visivamente? Se la risposta è sì, di solito migliorano anche engagement e conversioni, oltre ai segnali SEO indiretti.

Dati strutturati (Schema.org): rich results senza complicazioni

I dati strutturati non sostituiscono contenuti e architettura, ma aumentano la probabilità di ottenere rich results e, in alcuni casi, migliorare la qualità del traffico. Per un ecommerce sono particolarmente utili su prodotto e breadcrumb: aiutano Google a interpretare offerte, disponibilità e percorso di navigazione.

JSON-LD: la scelta più pratica per team e manutenzione

Tra microdata e JSON-LD, nella maggior parte dei casi il JSON-LD è la scelta più sostenibile: è meno invasivo sul markup e più semplice da versionare e controllare. Questo riduce il rischio di “rompere il layout” e rende più facile inserire le FAQ, anche quando lavori con più template.

La regola d’oro è la coerenza: ciò che dichiari nei dati strutturati deve essere presente anche nella pagina (prezzo, disponibilità, brand). Se i numeri non combaciano o sono generati in modo errato, puoi perdere idoneità ai rich results o generare errori nei test.

Ecommerce: Product, Offer e BreadcrumbList (il trio che vale il tempo)

Su pagine di prodotto inserire  Product con Offer (prezzo, valuta e disponibilità) è spesso il miglior punto di partenza. Il breadcrumb in BreadcrumbList è un secondo passo “facile” e utile, perché rafforza la comprensione della gerarchia e può riflettersi nello snippet.

Per chi gestisce molti progetti, conviene definire uno standard minimo: quali campi sono obbligatori, quali facoltativi, e come gestire casi particolari (prezzo in promo, varianti, out of stock). Non serve inseguire la completezza perfetta: serve una base corretta, stabile e misurabile.

Test e debugging: errori che bloccano i rich results

La parte operativa è: testare, correggere, re-testare. Gli errori più costosi sono quelli “silenziosi”: markup presente ma non idoneo perché manca un campo richiesto, oppure perché c’è un mismatch con il contenuto visibile.

Per la validazione usa i test ufficiali (Rich Results Test e Schema Markup Validator) e poi guarda Search Console nella sezione dedicata ai rich results: è lì che misuri copertura e problemi nel tempo, non solo “se passa il test oggi”.

Performance: pattern HTML che impattano Core Web Vitals

Se la SEO ti porta utenti e la UX li fa restare, la performance è il ponte. Molte ottimizzazioni “vere” sono lato server e bundling, ma ci sono anche scelte HTML che incidono direttamente su LCP, INP e CLS. La cosa utile, per chi decide, è sapere quali richieste fare e come verificare che siano state implementate correttamente.

Script: defer/async e ordine di caricamento (meno blocchi, più reattività)

Gli script sono spesso la causa principale di pagine lente e poco reattive, soprattutto quando tra tag manager, widget e tracker si accumula di tutto. A livello HTML, l’uso corretto di defer (e in alcuni casi async) riduce il blocco del parsing e migliora tempi percepiti.

Non è un “togliere tutto”: è un mettere in ordine. Gli script necessari alla prima interazione devono essere prioritari e leggeri; quelli non essenziali dovrebbero caricarsi dopo, o su eventi specifici. Questo è particolarmente rilevante per INP, che soffre quando il main thread è occupato da codice di terze parti.

Media e stabilità: dimensioni dichiarate e lazy-load intelligente

Per ridurre CLS, l’HTML deve riservare spazio ai contenuti prima che arrivino: immagini, video embed, banner dinamici. Basta poco (attributi di dimensione o container coerenti) per evitare i “saltelli” che peggiorano UX e metriche.

Sul lazy-loading: è ottimo per contenuti sotto la piega, ma è un errore comune applicarlo all’elemento che determina l’LCP (spesso l’immagine principale nei prodotti o hero in categoria). Qui l’obiettivo è caricare velocemente l’essenziale e rimandare il resto, non rimandare tutto.

Font e connessioni: piccoli tag, grandi effetti

I font possono creare ritardi e instabilità visiva. Anche senza entrare troppo nel dettaglio, due concetti sono importanti: ridurre il numero di varianti caricate e gestire la visualizzazione (per evitare testo invisibile). Inoltre, per risorse esterne critiche (CDN, font provider, gateway di pagamento), preconnect può migliorare la latenza percepita.

Validazione HTML: controlli rapidi per parlare bene con dev e agenzie

Una delle difficoltà più comuni è capire se “è stato fatto davvero” ciò che era in backlog. Qui serve un metodo che non richieda di scrivere codice, ma che ti permetta di validare implementazioni e collegarle a KPI. Pensa a questa sezione come a un mini-processo replicabile: utile per singolo sito e indispensabile se gestisci un portafoglio progetti.

Come controllare l’HTML giusto (senza cadere in trappole)

Il primo punto è distinguere tra “HTML consegnato dal server” e “DOM dopo JavaScript”. Per alcune verifiche (title, meta robots, canonical) spesso basta “Visualizza sorgente pagina”. Per altre (contenuti renderizzati, link generati via JS) devi usare DevTools e ispezionare il DOM.

Se il sito usa framework moderni, è facile credere che “si vede a schermo quindi Google lo capisce”. Non sempre: dipende da rendering, tempi, e da come vengono esposti i link. Quando hai dubbi, una verifica con lo URL Inspection di Search Console ti fa vedere cosa Google riesce a renderizzare.

Checklist minima

Per evitare controlli infiniti, qui funziona un approccio “a semaforo”: pochi check che, se falliscono, rendono inutile tutto il resto (contenuti compresi). L’idea è creare una routine che puoi applicare a ogni rilascio: campioni di URL critiche (top traffico/revenue) + campione random di pagine profonde.

Un criterio pratico è validare prima indicizzazione/snippet, poi contenuto realmente disponibile ai crawler, infine performance e markup avanzati. Così riduci il rischio di scoprire dopo settimane che una pagina era noindex o canonizzata altrove.

• Verifica che la URL sia 200 OK (niente redirect “a sorpresa”) e che il robots.txt non stia escludendo risorse essenziali
• Controlla nel sorgente: title, description, canonical, meta robots (coerenza con la strategia SEO)
• Assicurati che l’H1 e i contenuti chiave siano presenti anche senza JS (URL Inspection in GSC se hai dubbi)
• Valida link interni e breadcrumb: anchor comprensibili, niente link rotti, niente pagine importanti isolate
• Verifica immagini: alt sensato, dimensioni dichiarate (CLS), gestione del caricamento coerente con LCP
• Test rapido di dati strutturati e CWV: Rich Results Test + Lighthouse/PageSpeed su 1–2 template principali del sito

Inoltre una scansione del sito fatta con Screaming Frog riduce drasticamente il tempo di controllo di alcuni elementi della pagina, che possono essere analizzati in modo approfondito attraverso l’uso degli xpath.

Esempi di codice: template e snippet pronti (da adattare ai tuoi template)

Quando si parla di ottimizzazione del codice, spesso il blocco non è “cosa fare”, ma “come deve apparire nell’HTML” per essere verificabile. Qui trovi snippet essenziali e sostenibili: pochi tag, ma messi nel posto giusto, con variabili chiare per categorie, prodotti e pagine editoriali. L’obiettivo è darti un riferimento concreto per briefing, sviluppo e controllo finale.

Template base: doctype, lang e struttura semantica

Una pagina pulita parte da fondamenta prevedibili: doctype, attributo lang e una struttura semantica che separi navigazione e contenuto principale. Non è solo “ordine”: aiuta accessibilità, strumenti di audit e riduce ambiguità quando Google deve capire dove sta il contenuto che conta davvero.

In particolare, lang="it" aiuta a contestualizzare la lingua (utile anche con progetti multi-country), mentre main è un landmark chiaro per utenti e tecnologie assistive. Se usi componenti e layout complessi, mantenere questi elementi stabili nei template evita regressioni quando il sito cresce.

<!doctype html>
<html lang="it">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>[Titolo pagina] | [Brand]</title>
  <meta name="description" content="[Sintesi benefit + contenuto + condizioni rilevanti]">
  <link rel="canonical" href="https://www.example.com/url-corretta/">
</head>

<body>
  <header>
    <!-- logo, ricerca, elementi di fiducia -->
  </header>

  <nav aria-label="Navigazione principale">
    <!-- menu -->
  </nav>

  <main id="contenuto">
    <h1>[H1 unico e descrittivo]</h1>
    <!-- contenuto principale -->
  </main>

  <footer>
    <!-- contatti, policy, link utili -->
  </footer>
</body>
</html>

Snippet nel <head>: robots, canonical, hreflang e metadati social

Nel <head> il punto non è accumulare tag, ma evitare contraddizioni: canonical e robots devono raccontare la stessa storia, e hreflang deve puntare a URL valide e coerenti. Quando questi segnali litigano tra loro (o con la sitemap e i link interni), Google sceglie da solo — e spesso non come vorresti.

I metadati social (Open Graph e Twitter Card) non fanno ranking diretto, ma migliorano coerenza e qualità delle condivisioni. Su pagine che ricevono backlink “naturali” (guide, comparatori, studi, landing), avere anteprime pulite aiuta anche la distribuzione e quindi i segnali indiretti.

<!-- Indicizzazione -->
<meta name="robots" content="index,follow">

<!-- Canonical assoluto e stabile -->
<link rel="canonical" href="https://www.example.com/categoria/" />

<!-- Hreflang (multi-lingua/paese) -->
<link rel="alternate" hreflang="it-IT" href="https://www.example.com/it/categoria/" />
<link rel="alternate" hreflang="en-GB" href="https://www.example.com/en/category/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

<!-- Open Graph -->
<meta property="og:type" content="website">
<meta property="og:title" content="[Titolo per social, coerente col contenuto]">
<meta property="og:description" content="[Descrizione breve, orientata al click]">
<meta property="og:url" content="https://www.example.com/categoria/">
<meta property="og:image" content="https://www.example.com/img/cover.jpg">

<!-- Twitter Card -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="[Titolo per Twitter/X]">
<meta name="twitter:description" content="[Descrizione per Twitter/X]">
<meta name="twitter:image" content="https://www.example.com/img/cover.jpg">

Nota pratica: se usi noindex, ricordati che stai dicendo “non entrare in indice”, ma la pagina potrebbe comunque essere utile per l’utente e per il funnel. In questi casi, cura almeno UX e tracciamento (GA4) come faresti per una pagina indicizzabile: spesso sono pagine “supporto conversione”.

Immagini responsive e stabili: srcset, sizes, lazy loading e CLS

Le immagini impattano insieme SEO, performance e conversioni: possono portare traffico da Google Immagini, ma soprattutto influenzano LCP e stabilità della pagina. A livello HTML, due scelte fanno la differenza: rendere le immagini responsive e dichiarare dimensioni per evitare salti di layout (CLS).

Il lazy-load è utile, ma va usato con criterio. Se l’immagine è quella principale (hero o immagine prodotto), trattala come risorsa critica: non vuoi rimandare proprio ciò che definisce la prima impressione e spesso determina l’LCP.

<img
  src="https://www.example.com/img/prodotto-800.jpg"
  srcset="
    https://www.example.com/img/prodotto-400.jpg 400w,
    https://www.example.com/img/prodotto-800.jpg 800w,
    https://www.example.com/img/prodotto-1200.jpg 1200w
  "
  sizes="(max-width: 600px) 100vw, 600px"
  width="600"
  height="600"
  alt="Sedia in legno massello colore noce, vista frontale"
  decoding="async"
/>

Se l’immagine è sotto la piega (es. gallery secondaria o contenuti correlati), allora loading="lazy" ha senso. L’importante è che la regola sia “a template”, non casuale: così eviti regressioni quando cambiano layout e componenti.

Link esterni: attributi rel per qualità e sicurezza

Nel lavoro quotidiano, i link esterni nascono ovunque: recensioni, partner, affiliazioni, contenuti UGC. Qui gli attributi rel ti aiutano a separare fiducia editoriale da contenuti sponsorizzati o generati dagli utenti, e a gestire aspetti di sicurezza quando apri in nuova scheda.

Lato SEO, non è un “trucco”: è un modo per dare segnali puliti e ridurre ambiguità. Lato UX e sicurezza, noopener e noreferrer sono spesso una buona pratica standard quando usi target="_blank".

<a href="https://www.example.com/partner"
   rel="sponsored noopener noreferrer"
   target="_blank">
  Partner ufficiale
</a>

<a href="https://www.example.com/commento-utente"
   rel="ugc">
  Link condiviso dalla community
</a>

JSON-LD essenziale: Product e breadcrumb (base solida, poi iteri)

I dati strutturati danno il meglio quando sono semplici, corretti e coerenti con ciò che l’utente vede. Parti da ciò che puoi mantenere senza errori: su ecommerce, spesso Product + Offer e BreadcrumbList coprono già gran parte del valore.

Per ridurre problemi, collega sempre il markup a variabili “source of truth” (prezzo, disponibilità, SKU) e non a testi manuali sparsi. Se prezzo e disponibilità cambiano spesso, l’errore tipico è avere markup “stale” che genera warning o perdita di idoneità ai rich results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Sedia in legno massello",
  "image": ["https://www.example.com/img/prodotto-1200.jpg"],
  "sku": "SKU123",
  "brand": { "@type": "Brand", "name": "Brand" },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "price": "149.00",
    "availability": "https://schema.org/InStock",
    "url": "https://www.example.com/prodotto/"
  }
}
</script>

Accessibilità e SEO: perché l’HTML semantico migliora entrambe

Accessibilità non è una “feature extra”: è una parte concreta della qualità di implementazione. Un HTML più semantico rende il sito più navigabile per le persone (tastiera, screen reader, contesti mobile) e spesso più chiaro anche per i crawler, perché riduce ambiguità su ruoli, gerarchie e contenuti principali. In più, migliora UX e quindi metriche che spesso correlano con performance organica (engagement, ritorno, conversioni).

Landmark come header, nav, main e footer sono scorciatoie cognitive: dicono “qui è il contenuto”, “qui è la navigazione”. Aiutano l’orientamento immediato a persone (se il CSS è ben strutturato) e bot a individuare elementi comuni nelle pagine come anche sidebar e breadcrumb.

Dai tag SEO ai KPI: metti l’HTML al lavoro (e misura davvero)

I tag HTML non sono “rifiniture”: sono leve operative che decidono quale pagina finisce in SERP, come viene presentata e quanto velocemente si carica. Se vuoi muovere il ranking, migliorare le performance di caricamento e aumentare leconversioni, la logica è sempre la stessa: prima metti in ordine snippet e indicizzazione (per non sprecare contenuti e budget), poi lavori su architettura e linking per guidare l’utente nel funnel, infine ottimizzi media, dati strutturati e caricamento per ridurre attrito e aumentare fiducia. Ogni intervento ha senso solo se è collegato a un KPI leggibile in piattaforme come Search Console, GA4 e nei report di performance.

Il prossimo passo pratico è scegliere un perimetro piccolo ma ad alto impatto (le URL che portano impression, revenue o hanno colli di bottiglia evidenti), fare un audit dei tag “ad alta resa”, implementare, validare e iterare con una dashboard che ti dica cosa è cambiato davvero su CTR, pagine indicizzate, LCP/CLS e tasso di conversione. Se vuoi, cominciamo dai dati: posso aiutarti a trasformare questi controlli in una roadmap chiara e misurabile, con priorità, tempi e metriche condivise.

Mirko Ciesco

Data-Driven Growth Specialist

Aiuto aziende e startup a prendere decisioni migliori per crescere in modo misurabile. Sono specializzato in Web Analytics e performance digitale e lavoro all’intersezione tra dati, strategia e crescita.