**Perché conta.** È uno dei segnali on-page più forti per capire l’argomento della pagina ed è ciò che (spesso) viene mostrato come link blu nella SERP, influenzando direttamente il CTR. Un title pertinente e unico aiuta i crawler a comprendere e differenziare le pagine, mentre title duplicati o generici confondono l’indicizzazione e fanno perdere clic; Google può comunque riscrivere il title se lo ritiene poco rappresentativo. _Motivazioni: Ranking · Crawler/Indicizzazione · Conversione · Esperienza utente — Priorità: Alta_ **Best practice.** Scrivi un title unico per pagina, ~50-60 caratteri, con la keyword principale verso l’inizio e il brand in coda; descrittivo e non keyword-stuffed. ``` Scarpe da Trail Running Impermeabili | NomeBrand ``` ### <meta name=’description’> **Perché conta.** Non è un fattore di ranking diretto, ma fornisce lo snippet che spesso appare sotto il title in SERP: una description chiara e invitante aumenta il CTR e quindi le visite e le conversioni. Se assente o duplicata, Google genera uno snippet dal contenuto, talvolta meno efficace; serve quindi a controllare il messaggio commerciale, non a posizionarsi. _Motivazioni: Conversione · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Scrivi una description unica per pagina di ~150-160 caratteri, con un riassunto persuasivo e una call to action, includendo naturalmente i termini chiave; non riempirla di keyword. ``` ``` ### <link rel=’canonical’> **Perché conta.** Indica ai motori l’URL preferito quando esistono più versioni della stessa pagina (parametri, http/https, www/non-www, ordinamenti, sessioni): consolida i segnali di ranking e il link juice su un solo URL evitando contenuti duplicati e cannibalizzazione, e ottimizza il crawl budget evitando che lo spider sprechi risorse su duplicati. È un suggerimento (hint) per Google, non un comando assoluto. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Usa un solo canonical per pagina, con URL assoluto e autoreferenziale di default; punta sempre a una pagina indicizzabile (200, non noindex/redirect) e mantieni coerenza con sitemap e link interni. ``` - ``` ### <meta name=’robots’> (index/noindex, follow/nofollow) **Perché conta.** Controlla a livello di pagina se i motori possono indicizzarla (index/noindex) e seguire i suoi link (follow/nofollow): è lo strumento corretto per tenere fuori dall’indice pagine di servizio, filtri o thank-you page senza bloccare il crawling. Attenzione: la direttiva va letta dal crawler, quindi la pagina NON deve essere bloccata in robots.txt, altrimenti il noindex non viene visto; noindex insieme a link interni rilevanti può anche disperdere link juice. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Usa noindex per escludere pagine dall’indice (e lasciale crawlabili, non in robots.txt); usa index,follow (o ometti il tag) per le pagine da posizionare; non mettere noindex sulle pagine importanti per errore. ``` ``` ### <meta name=’robots’> (max-snippet, max-image-preview, max-video-preview) **Perché conta.** Direttive granulari che regolano come Google mostra l’anteprima del contenuto in SERP: max-snippet limita la lunghezza dello snippet di testo, max-image-preview la dimensione dell’anteprima immagine, max-video-preview i secondi di anteprima video. Influiscono su appeal del risultato e CTR, e sono rilevanti anche per il modo in cui i contenuti vengono mostrati/usati da funzioni come Discover; impostazioni troppo restrittive possono ridurre la visibilità. _Motivazioni: Crawler/Indicizzazione · Conversione · Esperienza utente — Priorità: Media_ **Best practice.** Per massima visibilità usa max-image-preview:large e max-snippet:-1 (nessun limite); restringi solo se hai esigenze editoriali/licenze specifiche. ``` ``` ### <link rel=’alternate’ hreflang> **Perché conta.** Segnala ai motori le versioni della pagina destinate a lingue/regioni diverse, così Google mostra all’utente la variante corretta riducendo bounce e migliorando l’esperienza; aiuta inoltre a gestire contenuti quasi-duplicati tra mercati simili (es. it-IT e it-CH). Gli hreflang devono essere reciproci (ogni pagina linka tutte le altre e se stessa) e includere x-default per il fallback, altrimenti i segnali non vengono recepiti. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Implementa cluster hreflang bidirezionali con URL assoluti, codici ISO lingua (e regione) validi e un x-default; mantieni il canonical autoreferenziale su ciascuna variante e non far puntare il canonical di una lingua a un’altra. ``` ``` ### <link rel=’icon’> / favicon **Perché conta.** Definisce l’icona del sito mostrata nella scheda del browser, nei preferiti e, soprattutto, accanto al risultato nella SERP mobile: una favicon nitida e riconoscibile rafforza il brand e può aumentare il CTR. Google la usa nei risultati solo se è raggiungibile, di formato corretto e associata in modo coerente all’home; assente o rotta, peggiora la percezione di affidabilità. _Motivazioni: Conversione · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Fornisci una favicon quadrata (multipli di 48px, es. 48×48/96×96) in formato supportato, dichiarata nel <head> e stabile nel tempo; aggiungi anche le icone per dispositivi Apple e il manifest. ``` ``` ### <meta name=’theme-color’> **Perché conta.** Suggerisce ai browser supportati (soprattutto Chrome su Android e le PWA) il colore della barra dell’interfaccia, integrando la pagina con la chrome del browser: non è un fattore di ranking, ma migliora la coerenza visiva del brand e l’esperienza utente percepita, in particolare per i siti installabili. Supporta anche varianti per tema chiaro/scuro tramite media query. _Motivazioni: Esperienza utente · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Imposta un theme-color coerente con la palette del brand; valuta una versione per dark mode con l’attributo media. ``` ``` ### <base href> **Perché conta.** Definisce l’URL di base per risolvere tutti i link e le risorse relative della pagina: usato male è una fonte frequente di bug, perché altera silenziosamente la destinazione di ogni href/src relativo, può rompere ancore interne (#) e creare link errati o duplicati che confondono i crawler e disperdono link juice. Va usato con cognizione, non per abitudine. _Motivazioni: Rendering/Compatibilità · Crawler/Indicizzazione · Link juice/PageRank — Priorità: Bassa_ **Best practice.** Evita <base> se non strettamente necessario; preferisci URL assoluti. Se lo usi, dichiaralo una sola volta e prima di qualsiasi risorsa relativa nel <head>, verificando l’impatto su link e ancore. ``` ``` ### <meta http-equiv> (Content-Security-Policy, X-UA-Compatible, refresh) **Perché conta.** Emula header HTTP dal markup. Alcuni usi sono utili (es. una CSP minima a difesa contro XSS, anche se l’header HTTP reale è preferibile), altri sono obsoleti o dannosi per la SEO: X-UA-Compatible serviva per i vecchi IE e oggi è inutile, mentre http-equiv=’refresh’ per i redirect va evitato perché peggiora l’esperienza utente, non passa correttamente i segnali come un 301 e può essere visto come tecnica spam. _Motivazioni: Sicurezza · Rendering/Compatibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Per i redirect usa sempre 301/302 lato server, mai meta refresh. Imposta le policy di sicurezza via header HTTP; usa meta http-equiv solo quando l’header reale non è disponibile. ``` ``` ### X-Robots-Tag (header HTTP) **Perché conta.** È l’equivalente HTTP del meta robots, ma applicabile anche a risorse non-HTML (PDF, immagini, documenti) dove il meta tag non può essere inserito; permette di impostare noindex/nofollow a livello di server, per singolo file o pattern. Come per il meta robots, perché la direttiva noindex sia letta la risorsa NON deve essere bloccata in robots.txt, altrimenti il crawler non vede mai l’header. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank — Priorità: Media_ **Best practice.** Usa X-Robots-Tag per controllare l’indicizzazione di PDF e file non-HTML, mantenendoli crawlabili; verifica con un controllo header che la direttiva venga effettivamente inviata e non duplichi/contraddica il meta robots. ``` HTTP/1.1 200 OK Content-Type: application/pdf X-Robots-Tag: noindex, nofollow ``` ### Ordine degli elementi nel <head> **Perché conta.** L’ordine influisce su correttezza e performance: <meta charset> deve venire prima di qualsiasi contenuto/testo per evitare re-parsing e mojibake, mentre risorse render-blocking come CSS e gli hint di connessione (preconnect, dns-prefetch) posizionati in alto velocizzano il primo render migliorando i Core Web Vitals (LCP), che sono segnali di esperienza pagina. Un <head> ordinato riduce reflow e accelera la pagina per utenti e crawler. _Motivazioni: Performance · Rendering/Compatibilità · Ranking · Esperienza utente — Priorità: Media_ **Best practice.** Ordina il head così: charset → viewport → title → preconnect/dns-prefetch → CSS critico/preload → script/meta secondari; evita di anteporre tag che ritardano la lettura del charset. ``` ... ``` ### <meta name=’keywords’> **Perché conta.** Tag storico in cui si elencavano le parole chiave della pagina: oggi Google dichiara esplicitamente di NON usarlo come fattore di ranking (fu abusato con keyword stuffing) e va quindi considerato inutile per il posizionamento. Anzi, esporre l’elenco delle keyword target può solo dare informazioni gratuite alla concorrenza, quindi nella maggior parte dei casi è meglio ometterlo. _Motivazioni: Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Non inserire il meta keywords per scopi SEO su Google; ometterlo. Eventualmente mantienilo solo se richiesto da motori interni/legacy specifici. ``` ``` ### Resource hints (preconnect / dns-prefetch / preload) **Perché conta.** Sono direttive nel <head> che anticipano il caricamento di risorse o connessioni critiche: dns-prefetch e preconnect aprono in anticipo la connessione verso domini terzi (font, CDN, analytics), mentre preload forza il download prioritario di risorse chiave come font o l’immagine LCP. Usati con criterio migliorano i Core Web Vitals (LCP, riduzione del tempo a primo byte percepito), che impattano esperienza utente e segnali di ranking; usati in eccesso sprecano banda. _Motivazioni: Performance · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Usa preconnect per i 2-4 domini terzi più critici e preload solo per la risorsa LCP o i font above-the-fold; non abusarne per non saturare la banda iniziale. ``` ``` ## 2. Struttura semantica & HTML on-page ### Heading H1 (un solo H1 per pagina) **Perché conta.** L’H1 dichiara l’argomento principale della pagina ed è uno dei segnali più forti che crawler e modelli AI usano per capire di cosa tratta il contenuto, rafforzando la pertinenza in fase di ranking; per gli utenti (e per gli screen reader) è il titolo visivo che orienta la lettura. Un solo H1 evita ambiguità sul tema portante: anche se Google con HTML5 tollera più H1, mantenerne uno solo resta la pratica più pulita per gerarchia, accessibilità e GEO/AI. _Motivazioni: Crawler/Indicizzazione · Ranking · Accessibilità · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Usa un unico <h1> per pagina, coerente con il <title> ma non identico, che contenga la keyword principale in linguaggio naturale; tienilo descrittivo e collocato in alto nel <main>. ``` # Scarpe da trail running impermeabili: guida all'acquisto ``` ### Gerarchia heading H2-H6 (ordine logico, niente salti) **Perché conta.** I sottotitoli H2-H6 formano lo scheletro semantico del documento: i crawler li usano per segmentare il contenuto in argomenti e sotto-argomenti, i modelli AI per estrarre passaggi e generare risposte/featured snippet, gli utenti per scansionare la pagina. Saltare livelli (da H2 a H4) o usare gli heading solo per la dimensione del font rompe la struttura ad albero e peggiora l’accessibilità per chi naviga con screen reader saltando di intestazione in intestazione. _Motivazioni: Crawler/Indicizzazione · Accessibilità · Esperienza utente · GEO/AI · Ranking — Priorità: Alta_ **Best practice.** Annida gli heading in ordine sequenziale (H1 > H2 > H3…) senza saltare livelli; usa gli H per la struttura logica, mai per ottenere una certa grandezza del testo (per quello c’è il CSS). ``` # Guida ## Tipologie ### Trail leggere ### Trail tecniche ## Come scegliere ``` ### <header> (intestazione di pagina/sezione) **Perché conta.** Il tag <header> raggruppa il contenuto introduttivo (logo, titolo, navigazione, claim) e comunica ai crawler e alle tecnologie assistive il ruolo di quel blocco senza affidarsi a classi CSS generiche; espone implicitamente la landmark ARIA banner quando è figlio diretto del <body>, migliorando l’accessibilità e aiutando gli user agent a distinguere intestazione e contenuto principale. _Motivazioni: Crawler/Indicizzazione · Accessibilità · Rendering/Compatibilità · Esperienza utente — Priorità: Media_ **Best practice.** Usa <header> per l’intestazione del sito e, all’interno di article/section, per le intro locali; evita di usarlo come semplice contenitore stilistico al posto di un <div>. ``` [![Nome Brand](/logo.svg)](/) ... ``` ### <nav> (navigazione) **Perché conta.** Il <nav> marca esplicitamente i blocchi di link di navigazione: i crawler vi riconoscono i percorsi strutturali del sito (menu, breadcrumb) distinguendoli dai link contestuali del contenuto, contribuendo alla distribuzione del link juice; per l’accessibilità genera la landmark navigation, permettendo agli utenti di screen reader di saltare direttamente ai menu. Usare più <nav> richiede etichette per distinguerli. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Accessibilità · Esperienza utente — Priorità: Media_ **Best practice.** Racchiudi i menu principali e i breadcrumb in <nav> e, se ne hai più di uno, distinguili con aria-label; non avvolgere ogni singolo link in un <nav>. ``` 1. [Home](/) 2. Scarpe ``` ### <main> (contenuto principale) **Perché conta.** Il <main> isola il contenuto unico e centrale della pagina rispetto a boilerplate ripetuto (header, sidebar, footer): questo aiuta i crawler e i motori AI a identificare il blocco che porta valore informativo e meritevole di indicizzazione, riducendo il rumore del template. Espone la landmark main e, con il link ‘salta al contenuto’, migliora drasticamente la navigazione da tastiera e da screen reader. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Alta_ **Best practice.** Usa un solo <main> visibile per pagina, contenente esclusivamente il contenuto centrale; abbinalo a uno skip link iniziale (es. <a href=”#main”>Vai al contenuto</a>). ``` [Vai al contenuto](#main) ... # ... ``` ### <article> e <section> **Perché conta.** <article> identifica un’unità di contenuto autonoma e riutilizzabile (un post, una scheda prodotto, una recensione) mentre <section> raggruppa parti tematiche correlate: questa distinzione semantica aiuta i crawler e gli LLM a capire i confini dei contenuti e a estrarre blocchi citabili, e supporta l’accessibilità quando le sezioni hanno un’intestazione. Non vanno usati come <div> generici: ogni section dovrebbe avere un proprio heading. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Media_ **Best practice.** Usa <article> per contenuti che hanno senso da soli e <section> per raggruppamenti tematici dotati di heading; se serve solo un contenitore per il layout/CSS, usa <div>. ``` ## Recensione modello X ### Pro ... ``` ### <aside> (contenuto correlato/secondario) **Perché conta.** Il tag <aside> marca contenuti tangenziali (box correlati, approfondimenti, pubblicità, widget): comunica a crawler e modelli AI che si tratta di materiale complementare, non del corpo principale, aiutandoli a pesare correttamente cosa è core e cosa è contorno; per l’accessibilità genera la landmark complementary, facilitando l’esplorazione della pagina. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Usa <aside> per box di approfondimento, link correlati o promo affiancati al contenuto; evita di metterci dentro il contenuto principale solo perché è in colonna laterale nel layout. ``` ## Leggi anche ... ``` ### <footer> (piè di pagina) **Perché conta.** Il <footer> raccoglie informazioni di chiusura (contatti, copyright, link legali, mappa secondaria): segnala a crawler e tecnologie assistive il ruolo del blocco (landmark contentinfo se figlio diretto del body) e i link al suo interno partecipano comunque al flusso di link juice verso pagine utili come privacy, contatti e categorie principali. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Accessibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Usa <footer> per il piè di pagina del sito e per le chiusure di article/section; mantieni i link essenziali ed evita footer sovraccarichi di centinaia di link (keyword/link stuffing). ``` [Privacy](/privacy) © 2026 Brand ``` ### Paragrafi <p> **Perché conta.** Il <p> definisce l’unità di testo discorsivo: separare correttamente i paragrafi (invece di usare <br> o <div>) dà al contenuto una struttura che crawler e LLM possono spezzare in passaggi semanticamente coerenti per snippet e risposte; per gli utenti paragrafi brevi migliorano la leggibilità e la scansione, riducendo il carico cognitivo e il bounce. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente · Accessibilità — Priorità: Media_ **Best practice.** Racchiudi ogni blocco di testo in <p>; mantieni i paragrafi brevi (2-4 frasi) e non usare <br> ripetuti per simulare spaziatura tra paragrafi. ``` Le scarpe da trail impermeabili proteggono dalla pioggia leggera. Per il fango profondo conta di più il battistrada. ``` ### Liste <ul> e <ol> **Perché conta.** Le liste strutturano informazioni enumerabili (passaggi, caratteristiche, vantaggi) in modo che crawler e modelli AI le riconoscano come elenchi e le riusino per featured snippet a lista e risposte generative; gli utenti le scansionano molto più rapidamente del testo continuo. La distinzione è semantica: <ol> quando l’ordine conta (procedure), <ul> quando non conta (elenchi di pari livello). _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente · Accessibilità — Priorità: Media_ **Best practice.** Usa <ol> per sequenze ordinate (istruzioni step-by-step) e <ul> per elenchi non ordinati; metti ogni voce in un <li> e non costruire pseudo-liste con trattini dentro un singolo paragrafo. ``` 1. Allenta i lacci 2. Inserisci il piede 3. Stringi dall'alto ``` ### Tabelle <table> (con <th>, scope, <caption>) **Perché conta.** Le tabelle dati ben marcate permettono a crawler e LLM di interpretare relazioni riga/colonna (confronti, specifiche, prezzi) e sono candidate ideali per snippet comparativi e dati strutturati; le intestazioni <th> con scope e la <caption> rendono i dati comprensibili agli screen reader. Vanno usate solo per dati tabellari reali, mai per impaginare il layout (anti-pattern obsoleto che danneggia accessibilità e responsività). _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Usa <table> solo per dati relazionali, con <thead>/<tbody>, <th scope=”col|row”> per le intestazioni e una <caption> descrittiva; per il layout usa CSS Grid/Flexbox. ``` | Modello | Peso | | --- | --- | | X1 | 280g | ``` ### <strong> ed <em> (semantica) vs <b>/<i> (stile) **Perché conta.** <strong> ed <em> trasmettono importanza ed enfasi a livello semantico, informazione che gli screen reader possono vocalizzare e che aiuta crawler e LLM a cogliere i concetti enfatizzati; <b> e <i> sono puramente visivi e privi di significato. Usare quelli giusti migliora accessibilità e comprensione del contenuto, ma il grassetto eccessivo (keyword in bold ovunque) non porta vantaggi di ranking ed è solo rumore. _Motivazioni: Accessibilità · GEO/AI · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Usa <strong> per importanza ed <em> per enfasi reale; riserva <b>/<i> a casi puramente stilistici senza valore semantico (es. nomi di prodotto) e non abusare del grassetto sulle keyword. ``` **Attenzione:** il modello _non_ è impermeabile al 100%. ``` ### <blockquote> e <cite> (citazioni) **Perché conta.** Il <blockquote> marca citazioni testuali estese e <cite> il riferimento alla fonte: questo segnala a crawler e modelli generativi quali porzioni sono citazioni di terzi (utile per E-E-A-T e per evitare che il testo citato venga scambiato per contenuto originale), e migliora l’accessibilità con una struttura chiara. L’attributo cite con URL documenta la provenienza. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Usa <blockquote cite=”URL”> per citazioni in blocco e <q> per quelle inline; indica la fonte con <cite> e non usare blockquote solo per ottenere un rientro grafico. ``` > Il 60% dei runner sceglie la traspirabilità. — Studio Esempio 2026 ``` ### Indice / sommario (TOC) con ancore **Perché conta.** Un sommario con link interni alle sezioni migliora la navigazione su contenuti lunghi, distribuisce link juice verso i blocchi interni e fornisce a Google segnali per i sitelink ‘jump to’ nei risultati; per crawler e LLM gli anchor con id mappano la struttura del documento e rendono i singoli passaggi indirizzabili e citabili. Aiuta anche l’accessibilità offrendo un accesso rapido alle parti. _Motivazioni: Esperienza utente · Link juice/PageRank · Crawler/Indicizzazione · GEO/AI · Accessibilità — Priorità: Media_ **Best practice.** Genera il TOC dai tuoi H2/H3 con link ad anchor (#id) coerenti; mettilo vicino all’inizio dei contenuti lunghi e assicurati che gli id siano stabili e descrittivi. ``` 1. [Come scegliere](#scelta) ... ## Come scegliere ``` ### Contenuto above-the-fold **Perché conta.** Ciò che è visibile senza scroll determina la prima impressione e influenza fortemente bounce rate e tempo di permanenza, segnali di esperienza utente; mostrare subito il contenuto principale (H1, risposta sintetica, valore) invece di banner, popup e annunci aiuta anche i crawler a trovare presto il testo rilevante e i modelli AI a estrarre una risposta immediata. Un above-the-fold ingombro di pubblicità è penalizzante (intrusive interstitials). _Motivazioni: Esperienza utente · Ranking · GEO/AI · Conversione — Priorità: Media_ **Best practice.** Posiziona H1 e una sintesi/risposta chiave entro il primo viewport; evita popup intrusivi e blocchi pubblicitari che spingono il contenuto sotto la piega, soprattutto su mobile. ### Rapporto contenuto vs boilerplate **Perché conta.** Crawler e sistemi AI estraggono il contenuto principale scartando il boilerplate (header, menu, sidebar, footer ripetuti su ogni pagina): se il template domina e il testo unico è scarso, la pagina rischia di sembrare thin content o duplicata, con impatto su indicizzazione e ranking. Marcare bene <main> e usare HTML5 semantico aiuta gli algoritmi a isolare il valore reale della pagina. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Ranking · Esperienza utente — Priorità: Media_ **Best practice.** Massimizza il contenuto unico nel <main> e riduci il peso del boilerplate ripetuto; evita pagine in cui il template supera nettamente il testo originale e usa la semantica HTML5 per delimitare le aree. ### Profondità e lunghezza del contenuto **Perché conta.** La lunghezza non è un fattore di ranking diretto, ma una copertura completa dell’intento (entità, sotto-domande, casi correlati) aumenta la pertinenza topica percepita da crawler e LLM e le chance di vincere snippet e citazioni in risposte generative; al contempo riempire la pagina di testo ridondante per allungarla danneggia leggibilità e qualità. Conta la profondità informativa, non il conteggio parole. _Motivazioni: Ranking · GEO/AI · Crawler/Indicizzazione · Esperienza utente — Priorità: Bassa_ **Best practice.** Copri l’intento di ricerca in modo esaustivo rispondendo alle domande correlate, senza padding; misura la qualità sulla completezza topica, non sul numero di parole. ### Leggibilità del testo **Perché conta.** Frasi brevi, paragrafi spezzati, sottotitoli frequenti e linguaggio chiaro riducono il carico cognitivo e tengono l’utente sulla pagina (segnale di esperienza positivo) e rendono il testo più facile da segmentare per gli LLM in passaggi citabili; una buona leggibilità migliora anche l’accessibilità per utenti con difficoltà di lettura. Un muro di testo denso aumenta l’abbandono e ostacola l’estrazione di risposte. _Motivazioni: Esperienza utente · GEO/AI · Accessibilità · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Scrivi frasi e paragrafi brevi, alterna heading, liste e grassetti semantici per spezzare il testo; punta a un linguaggio adeguato al pubblico e verifica con metriche di leggibilità. ## 3. Link interni, anchor & navigazione ### Link interni contestuali (<a href> nel corpo del testo) **Perché conta.** I link interni inseriti nel corpo del contenuto sono il principale veicolo con cui i crawler scoprono nuove URL e ne capiscono il rapporto semantico; trasmettono link juice/PageRank tra le pagine indirizzandolo verso quelle strategiche, aiutano gli utenti ad approfondire i temi correlati migliorando l’esperienza e il tempo sulla pagina, e rafforzano la pertinenza tematica (topical authority) che incide sul ranking. Per gli LLM/risposte AI un buon networking interno aiuta a ricostruire le entità e i loro collegamenti. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Inserisci link contestuali pertinenti verso pagine correlate dello stesso cluster tematico, dando priorità alle pagine importanti/da spingere; usa link veri in HTML (non solo JS) e mantieni un numero ragionevole, evitando di intasare il paragrafo. ``` Per approfondire vedi la nostra [guida alla SEO tecnica](/guida-seo-tecnica/). ``` ### Anchor text descrittiva **Perché conta.** L’anchor text dice a crawler e utenti di cosa parla la pagina di destinazione: un’ancora descrittiva e ricca di contesto migliora la comprensione semantica della pagina linkata (e quindi il suo ranking per i termini pertinenti), aiuta l’accessibilità per chi naviga con screen reader o salta di link in link, e migliora l’esperienza utente perché chiarisce cosa si trova al clic. Va evitato il generico ‘clicca qui’ / ‘leggi di più’ perché privo di valore informativo. _Motivazioni: Crawler/Indicizzazione · Ranking · Accessibilità · Esperienza utente — Priorità: Alta_ **Best practice.** Usa ancore brevi e descrittive che riflettono il contenuto di destinazione; varia naturalmente la formulazione invece di ripetere sempre la stessa keyword, e non usare ancore generiche tipo ‘qui’ o ‘clicca qui’. ``` [scarpe da running](/scarpe-running/) [clicca qui](/scarpe-running/) ``` ### Over-optimization dell’anchor text (anchor spam) **Perché conta.** Ripetere ossessivamente la stessa anchor a exact-match keyword su molti link (interni o, soprattutto, in entrata) crea un pattern innaturale che gli algoritmi anti-spam possono interpretare come manipolazione, con rischio di svalutazione o penalizzazione invece di beneficio sul ranking; peggiora anche l’esperienza utente rendendo il testo ripetitivo e poco naturale. _Motivazioni: Ranking · Crawler/Indicizzazione · Esperienza utente — Priorità: Media_ **Best practice.** Mantieni un profilo di ancore naturale e vario (brand, URL, frasi descrittive, sinonimi); evita di forzare la stessa exact-match keyword su tutti i link verso la stessa pagina. ### Breadcrumbs (briciole di pane) **Perché conta.** Le breadcrumbs devono esserci perché i crawler le usano (al pari di sitemap e menu) per capire la struttura gerarchica del sito, ma servono anche ad agevolare la navigazione degli utenti che capiscono dove si trovano e risalgono di livello, e contribuiscono a far sì che tutte le pagine ricevano juice distribuendo i link verso le categorie superiori. Con i dati strutturati BreadcrumbList Google può mostrare il percorso direttamente nella SERP. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Mostra breadcrumbs coerenti con la gerarchia reale del sito su tutte le pagine profonde e marcale con structured data BreadcrumbList; usa link reali e l’ultimo elemento (pagina corrente) senza link. ``` 1. [Home](/) 2. [Scarpe](/scarpe/) 3. Running ``` ### Menu di navigazione principale **Perché conta.** Il menu primario definisce le sezioni chiave del sito ed è uno dei primi elementi che i crawler seguono per mappare l’architettura e distribuire il PageRank verso le pagine più importanti; per l’utente è la bussola che orienta la navigazione e riduce i rimbalzi. È fondamentale che i link del menu siano in HTML nativo e non generati solo via JavaScript al clic, altrimenti i crawler potrebbero non seguirli. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente · Rendering/Compatibilità · Accessibilità — Priorità: Alta_ **Best practice.** Usa una navigazione con <nav> e link <a href> reali verso le pagine cardine; mantienila essenziale e gerarchica, accessibile da tastiera e indicizzabile senza dipendere dall’esecuzione JS. ``` [Prodotti](/prodotti/) - [Blog](/blog/) ``` ### Footer link **Perché conta.** I link nel footer aiutano a raggiungere pagine secondarie ma utili (privacy, contatti, hub tematici) e sono seguiti dai crawler, contribuendo alla copertura del sito e a evitare pagine orfane; danno anche supporto alla navigazione utente. Vanno però usati con criterio: un footer gonfio di centinaia di link a bassa pertinenza diluisce il link juice e può apparire spammoso, perché i link sitewide ricevono in genere meno peso di quelli contestuali. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente — Priorità: Media_ **Best practice.** Limita i link del footer a quelli realmente utili (legali, sezioni chiave, hub principali) evitando elenchi keyword-stuffed; non usare il footer come deposito di link a fini SEO. ### Link esterni / outbound **Perché conta.** Collegare a fonti esterne autorevoli e pertinenti rafforza la credibilità e l’esperienza dell’utente, fornisce contesto e segnali di qualità ed E-E-A-T del contenuto, e può aiutare crawler e modelli AI a comprendere l’ecosistema di entità a cui la pagina si riferisce. Linkare verso fonti scadenti o spam, invece, può associare il tuo contenuto a vicinati di bassa qualità. _Motivazioni: Esperienza utente · Ranking · Crawler/Indicizzazione · GEO/AI — Priorità: Media_ **Best practice.** Cita fonti esterne pertinenti e affidabili quando aggiungono valore; verifica che i link non siano rotti e valuta il target appropriato e gli attributi rel per i link non editoriali. ``` [studio di riferimento](https://esempio-autorevole.org/studio/) ``` ### rel=”nofollow” **Perché conta.** Indica ai motori che il link non è un endorsement editoriale: oggi Google lo tratta come un hint, non come una direttiva rigida, sia per il crawling sia per il passaggio di segnali di ranking. Usato correttamente serve a non trasmettere PageRank verso link non garantiti o di terzi e a mantenere pulito il profilo di link, evitando di sembrare coinvolti in scambi/manipolazioni. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Media_ **Best practice.** Applica nofollow ai link di cui non vuoi farti garante (es. contenuti non verificati); per i casi specifici preferisci gli attributi più precisi ugc e sponsored. ``` [link non garantito](https://sito-terzo.com/) ``` ### rel=”ugc” e rel=”sponsored” **Perché conta.** Sono le qualificazioni introdotte per distinguere la natura dei link non editoriali: ‘ugc’ marca i link generati dagli utenti (commenti, forum) e ‘sponsored’ i link a pagamento/affiliazione. Comunicano ai crawler il contesto corretto, riducono il rischio di violazioni delle policy sui link a pagamento e aiutano i motori a pesare in modo più accurato i segnali, proteggendo il sito da azioni manuali sugli schemi di link. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Media_ **Best practice.** Usa rel=”sponsored” per link pubblicitari/affiliati e rel=”ugc” per contenuti generati dagli utenti; puoi combinare più valori (es. ugc nofollow) quando appropriato. ``` [offerta partner](https://aff.example/?id=123/) ``` ### rel=”noopener” (e noreferrer) su target=”_blank” **Perché conta.** Quando un link apre una nuova scheda con target=”_blank”, la pagina di destinazione può accedere all’oggetto window.opener e potenzialmente manipolare la pagina d’origine (tabnabbing): rel=”noopener” recide questo legame proteggendo la sicurezza dell’utente, e impedisce inoltre cali di performance dovuti alla condivisione del processo. È quindi una pratica di sicurezza e robustezza, non un segnale SEO. _Motivazioni: Sicurezza · Performance · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Aggiungi rel=”noopener” (o noopener noreferrer) a tutti i link con target=”_blank”; i browser moderni lo applicano di default ma dichiararlo esplicitamente garantisce compatibilità. ``` [apri in nuova scheda](https://esterno.com/) ``` ### Link orfani vs pagine orfane **Perché conta.** Una pagina orfana è una URL a cui nessun link interno punta: i crawler faticano a scoprirla (spesso vi arrivano solo da sitemap o link esterni), non riceve link juice e tende a posizionarsi male o a non essere indicizzata, mentre l’utente non può raggiungerla navigando. È un classico spreco di contenuti di valore non collegati al resto del sito. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Verifica periodicamente (crawl + log + sitemap) che ogni pagina utile abbia almeno qualche link interno in entrata da pagine pertinenti; collega le orfane ai relativi hub/categorie. ### Profondità di click (click depth) **Perché conta.** Il numero di clic necessari per raggiungere una pagina dalla home indica quanto è ‘centrale’ nell’architettura: pagine troppo profonde vengono scoperte e ricrawlate meno spesso, ricevono meno PageRank e sono più difficili da trovare per l’utente, con effetto negativo su indicizzazione e ranking. Un’architettura piatta porta valore e crawler più velocemente alle pagine importanti. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Mantieni le pagine importanti a pochi clic dalla home (idealmente entro 3) usando hub, categorie e link contestuali; appiattisci la struttura dove le pagine chiave risultano troppo sepolte. ### Paginazione (rel=prev/next, storico) **Perché conta.** Le serie paginate vanno rese comprensibili ai crawler perché possano scoprire tutti gli elementi delle pagine successive e distribuire il juice. Attenzione a un mito comune: Google ha dichiarato di non usare più rel=”prev”/”next” come segnale (sebbene resti utile per accessibilità e altri motori); l’approccio attuale è basare la scoperta su normali link <a href> verso le pagine 2, 3, ecc. e su URL paginate indicizzabili. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Accessibilità — Priorità: Media_ **Best practice.** Esponi link <a href> reali alle pagine successive (non solo JS), usa URL paginate uniche e canoniche a se stesse; rel=prev/next puoi mantenerlo per accessibilità ma non aspettarti effetti da Google. ``` [Pagina successiva](/blog/page/2/) ``` ### Infinite scroll / caricamento lazy dei contenuti **Perché conta.** L’infinite scroll basato solo su eventi JS senza URL navigabili nasconde i contenuti ai crawler, che non scrollano: gli elementi caricati dinamicamente rischiano di non essere scoperti né indicizzati, e l’utente non può salvare o condividere uno stato preciso. È un caso in cui rendering e crawlability entrano in conflitto con l’esperienza. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Esperienza utente — Priorità: Media_ **Best practice.** Affianca all’infinite scroll una paginazione tradizionale con URL e link <a href> indicizzabili (progressive enhancement), così i crawler scoprono tutti gli elementi indipendentemente dallo scroll. ### Contenuti correlati / related links **Perché conta.** I blocchi di articoli o prodotti correlati creano collegamenti contestuali aggiuntivi che aumentano la profondità tematica del cluster, distribuiscono link juice verso pagine affini, riducono le pagine orfane e migliorano l’esperienza tenendo l’utente nel sito; aiutano inoltre crawler e modelli AI a comprendere le relazioni semantiche tra contenuti dello stesso argomento. _Motivazioni: Link juice/PageRank · Crawler/Indicizzazione · Esperienza utente · GEO/AI · Conversione — Priorità: Media_ **Best practice.** Genera i correlati per pertinenza tematica reale (stesso cluster/entità) e non in modo casuale; assicurati che siano link HTML reali e non solo widget JS non indicizzabili. ``` [Titolo correlato](/articolo-correlato/) ``` ### Distribuzione del link juice / PageRank interno **Perché conta.** Il PageRank si propaga lungo i link interni e ogni pagina ne ripartisce una quota tra i link che contiene: una struttura ben progettata convoglia il valore verso le pagine che devono posizionarsi (categorie, money page), mentre link sparsi verso pagine a basso valore (login, filtri, tag inutili) lo disperdono. Governare questo flusso è leva diretta su crawling prioritario e ranking. _Motivazioni: Link juice/PageRank · Ranking · Crawler/Indicizzazione — Priorità: Alta_ **Best practice.** Concentra i link interni verso le pagine prioritarie e limita o gestisci (canonical, noindex, parametri) quelli verso URL a basso valore; cura il flusso da home e hub ad alta autorità verso le pagine strategiche. ### Self-link e link a se stessa nella navigazione **Perché conta.** Un link che punta alla pagina su cui ci si trova (es. la voce di menu attiva o l’ultimo livello del breadcrumb) non aggiunge valore di navigazione, può confondere l’utente e spreca un link che potrebbe distribuire juice altrove; per accessibilità è meglio indicare lo stato corrente che linkarlo. _Motivazioni: Esperienza utente · Accessibilità · Link juice/PageRank — Priorità: Bassa_ **Best practice.** Rendi non cliccabile l’elemento corrispondente alla pagina attiva (menu/breadcrumb) marcandolo con aria-current=”page” anziché linkarlo a se stesso. ``` - Pagina attuale ``` ## 4. URL, redirect & crawlability ### URL parlanti / slug descrittivi **Perché conta.** Uno slug leggibile (parole reali separate da trattini) comunica a colpo d’occhio l’argomento della pagina sia ai crawler, che lo usano come segnale debole di pertinenza e per costruire l’anchor quando l’URL viene incollato nudo, sia agli utenti, che cliccano più volentieri risultati comprensibili in SERP e li condividono con più fiducia. URL puliti riducono inoltre il rischio di parametri inutili e duplicazioni, e migliorano la percezione di qualità del brand. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Usa slug brevi, in minuscolo, con parole chiave reali separate da trattini (-), niente underscore, spazi, accenti, maiuscole o stop-word inutili; mantieni lo slug stabile nel tempo per non rompere i link. ``` https://sito.it/scarpe-running-uomo (NON /prodotto?id=8493&cat=12) ``` ### Gerarchia e profondità di click (click depth) **Perché conta.** Una struttura a cartelle coerente (/categoria/sottocategoria/pagina) aiuta i crawler a capire la tassonomia del sito e distribuisce il link juice dall’alto verso il basso, mentre per l’utente rende la navigazione prevedibile. Le pagine raggiungibili in pochi click dalla home ricevono più PageRank interno e vengono crawlate più spesso; pagine sepolte a 5-6 livelli rischiano scarsa indicizzazione e crawl raro. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente — Priorità: Media_ **Best practice.** Tieni le pagine importanti entro 3 click dalla home, mantieni la gerarchia di cartelle allineata alla struttura logica e ai breadcrumb, ed evita silos troppo profondi o cartelle vuote di valore. ``` /blog/seo-tecnico/canonical-tag/ (3 livelli, non 6) ``` ### HTTPS / certificato TLS **Perché conta.** HTTPS è confermato da Google come fattore di ranking (leggero) ed è prerequisito per HTTP/2 e molte API browser; protegge i dati in transito da intercettazioni e manomissioni, rimuove il marchio ‘Non sicuro’ di Chrome che fa abbandonare gli utenti e preserva il referrer verso altri siti HTTPS. Un sito misto HTTP/HTTPS genera mixed content e perdita di fiducia. _Motivazioni: Sicurezza · Ranking · Esperienza utente · Performance — Priorità: Alta_ **Best practice.** Installa un certificato valido, forza HTTPS con redirect 301 da http a https, abilita HSTS e correggi ogni risorsa caricata in HTTP (mixed content); usa URL relativi o https:// per asset interni. ``` Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ``` ### Canonicalizzazione del dominio (www vs non-www, HTTP vs HTTPS) **Perché conta.** Lo stesso contenuto raggiungibile su http/https e www/non-www crea fino a quattro varianti duplicate che diluiscono i segnali di ranking e sprecano crawl budget. Scegliere una sola versione e reindirizzare le altre concentra il link juice su un unico URL e dà ai crawler un segnale univoco di quale host indicizzare. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Decidi una versione canonica (es. https://www.sito.it), reindirizza con 301 tutte le altre verso di essa in un solo hop, e mantieni coerenti canonical, sitemap e link interni sulla versione scelta. ``` http://sito.it/ , http://www.sito.it/ , https://sito.it/ → 301 → https://www.sito.it/ ``` ### Trailing slash (slash finale) **Perché conta.** /pagina e /pagina/ sono tecnicamente URL diversi: se entrambi rispondono 200 con lo stesso contenuto creano duplicazione e split dei segnali, mentre i link interni incoerenti generano hop di redirect superflui che bruciano crawl budget. Una regola unica e applicata ovunque mantiene chiara la versione canonica. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank — Priorità: Media_ **Best practice.** Scegli una convenzione (con o senza slash finale), applicala a livello server con 301 verso la forma scelta, e usa link interni e canonical sempre coerenti; nota che per i file (es. .html) lo slash finale non va aggiunto. ``` /servizi → 301 → /servizi/ (e canonical su /servizi/) ``` ### Redirect 301 (permanente) **Perché conta.** Il 301 dice ai crawler che una risorsa si è spostata definitivamente: trasferisce i segnali di ranking e l’equity di link verso la nuova URL, aggiorna l’indice e per l’utente garantisce di arrivare sempre alla pagina giusta evitando 404. È lo strumento corretto per migrazioni, cambio dominio, consolidamento di pagine e fix di URL duplicati. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente — Priorità: Alta_ **Best practice.** Usa il 301 per ogni spostamento definitivo, punta sempre alla destinazione finale (mai a un altro redirect) e aggiorna i link interni alla nuova URL invece di affidarti al solo redirect. ``` HTTP/1.1 301 Moved Permanently Location: https://www.sito.it/nuova-pagina/ ``` ### Redirect 302/307 (temporanei) **Perché conta.** 302 (HTTP/1.0) e 307 (HTTP/1.1, che preserva il metodo HTTP) segnalano uno spostamento temporaneo: i crawler mantengono indicizzata l’URL originale e in linea di principio non trasferiscono pienamente i segnali come il 301. Usarli per spostamenti permanenti rallenta o impedisce il passaggio di equity e tiene a indice l’URL sbagliato. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank — Priorità: Media_ **Best practice.** Riserva 302/307 a casi davvero temporanei (manutenzione, A/B test, geo/lingua provvisoria); per qualsiasi spostamento definitivo usa 301 (o 308 se devi preservare il metodo POST). ``` HTTP/1.1 307 Temporary Redirect (manutenzione) Location: /manutenzione/ ``` ### Redirect 308 (permanente che preserva il metodo) **Perché conta.** Il 308 è l’equivalente permanente del 307: come il 301 indica spostamento definitivo e consolida i segnali, ma a differenza del 301 garantisce che il metodo e il body della richiesta restino invariati (un POST resta POST). Conta soprattutto per API ed endpoint applicativi; per le pagine HTML tipiche il 301 resta lo standard più sicuro e universalmente compreso. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Link juice/PageRank — Priorità: Bassa_ **Best practice.** Usa il 308 quando devi reindirizzare in modo permanente preservando il metodo HTTP (es. endpoint POST/API); per redirect di pagine normali continua a usare il 301. ``` HTTP/1.1 308 Permanent Redirect Location: https://api.sito.it/v2/risorsa ``` ### Catene e loop di redirect **Perché conta.** Una catena (A→B→C) costringe crawler e browser a richieste multiple, ritarda il rendering, fa disperdere progressivamente i segnali di ranking a ogni hop e consuma crawl budget; un loop (A→B→A) blocca del tutto l’accesso restituendo errore al bot e all’utente. Entrambi degradano performance e indicizzazione. _Motivazioni: Crawler/Indicizzazione · Performance · Link juice/PageRank · Esperienza utente — Priorità: Alta_ **Best practice.** Appiattisci ogni catena facendo puntare la sorgente direttamente alla destinazione finale (un solo hop), elimina i loop e ricontrolla periodicamente le regole con un crawler per scovare hop accumulati nel tempo. ``` /a → /b → /c ✗ ⇒ /a → /c e /b → /c ✓ ``` ### robots.txt **Perché conta.** È il primo file che i crawler leggono: governa il crawling (non l’indicizzazione) indicando quali percorsi non scansionare e dove trovare la sitemap, aiutando a preservare crawl budget su aree inutili (carrelli, filtri, ricerche interne). Attenzione: un errore di sintassi o un Disallow troppo ampio può oscurare l’intero sito ai motori. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Alta_ **Best practice.** Blocca solo percorsi realmente inutili, NON usare Disallow per nascondere pagine dall’indice (vedi noindex), dichiara la sitemap e non bloccare CSS/JS necessari al rendering; testalo prima di pubblicare. ``` User-agent: * Disallow: /cart/ Disallow: /*?orderby= Sitemap: https://www.sito.it/sitemap_index.xml ``` ### noindex vs Disallow (differenza chiave) **Perché conta.** Sono cose diverse e spesso confuse: Disallow in robots.txt impedisce il crawling ma una URL bloccata può comunque finire indicizzata (senza snippet) se linkata altrove; noindex (meta robots o header X-Robots-Tag) impedisce l’indicizzazione ma richiede che la pagina sia crawlabile per essere letta. Bloccare in robots una pagina che vuoi de-indicizzare è l’errore classico: il bot non vedrà mai il noindex. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Alta_ **Best practice.** Per togliere una pagina dall’indice usa noindex e lasciala crawlabile (non metterla in Disallow); usa il Disallow solo per risparmiare crawl budget su risorse che non devono mai essere scansionate. ``` oppure X-Robots-Tag: noindex ``` ### sitemap.xml e sitemap index **Perché conta.** La sitemap fornisce ai crawler una lista pulita degli URL canonici da scoprire, accelerando l’indicizzazione di siti grandi, nuovi o con link interni deboli, e comunica con lastmod quando una pagina è cambiata. Il sitemap index permette di organizzare in più file (limite 50.000 URL / 50 MB ciascuno), utile per siti molto ampi. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Alta_ **Best practice.** Includi solo URL canonici, indicizzabili e che rispondono 200 (niente noindex, redirect, 404, parametri o pagine bloccate), aggiorna lastmod in modo veritiero, dichiarala in robots.txt e inviala in Search Console. ``` https://www.sito.it/pagina/2026-05-30 ``` ### Tag canonical (<link rel=”canonical”>) **Perché conta.** Indica ai motori l’URL preferita tra più varianti con contenuto identico o molto simile (parametri di tracking, ordinamenti, versioni stampa), consolidando i segnali di ranking su una sola pagina ed evitando che il duplicato competa o disperda equity. È un suggerimento, non un comando: Google può ignorarlo se incoerente con altri segnali. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Inserisci un canonical assoluto e self-referencing su ogni pagina, fai puntare i duplicati alla versione preferita, e mantieni canonical coerente con sitemap, link interni e redirect (no canonical verso pagine noindex o redirezionate). ``` - ``` ### Parametri URL e contenuti duplicati **Perché conta.** Parametri di sessione, tracking (utm), filtri e ordinamenti generano infinite URL diverse che servono lo stesso contenuto: questo crea duplicazione, frammenta i segnali di ranking e, su e-commerce con faccette, può intrappolare i crawler in spider trap che divorano il crawl budget senza indicizzare pagine utili. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Performance — Priorità: Media_ **Best practice.** Canonicalizza le varianti con parametro verso l’URL pulita, blocca in robots.txt i parametri di puro filtro/ordinamento che non devono essere crawlati, evita utm nei link interni e mantieni un ordine stabile dei parametri. ``` /scarpe?color=red&utm_source=fb → canonical: /scarpe ``` ### Paginazione (rel next/prev e canonical) **Perché conta.** Le serie paginate (?page=2,3…) devono essere gestite perché ogni pagina abbia un canonical self-referencing e resti crawlabile: così i motori scoprono e indicizzano i prodotti/articoli delle pagine profonde. Nota: Google ha dichiarato di non usare più rel=next/prev come segnale di indicizzazione, quindi NON canonicalizzare le pagine 2..N verso la pagina 1, perché ne nasconderesti i contenuti. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Media_ **Best practice.** Dai a ogni pagina paginata un canonical a se stessa (non alla pagina 1), tienile indicizzabili e ben linkate, e valuta una pagina ‘view-all’ canonica solo se carica velocemente. ``` Su /blog?page=2 → ``` ### Codici di stato HTTP corretti **Perché conta.** Lo status code è il modo in cui il server dichiara ai crawler lo stato reale di una risorsa: 200 = indicizzabile, 301/308 = spostata, 404 = inesistente, 410 = rimossa definitivamente, 5xx = errore server. Codici errati (es. una pagina mancante che risponde 200) confondono l’indice, e i 5xx ripetuti possono ridurre la frequenza di crawl perché Google interpreta il sito come instabile. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Performance — Priorità: Media_ **Best practice.** Restituisci sempre lo status veritiero: 404/410 per pagine rimosse, 301 per spostamenti, monitora i 5xx e correggili rapidamente; non servire mai contenuto reale con codici di errore né errori con codice 200. ``` Pagina cancellata definitivamente → HTTP/1.1 410 Gone ``` ### Soft 404 **Perché conta.** Un soft 404 è una pagina vuota o ‘non trovato’ che però risponde 200: il crawler la tratta come valida, sprecando crawl budget per scansionare e indicizzare contenuto inutile, e l’utente atterra su una pagina senza valore. Search Console li segnala perché diluiscono la qualità percepita del sito. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Performance — Priorità: Media_ **Best practice.** Fai restituire un vero 404 (o 410) alle pagine inesistenti/vuote; per prodotti esauriti o contenuti rimossi reindirizza con 301 a un’alternativa pertinente solo se sensato, altrimenti 404/410. ``` Risultato ricerca senza match: deve dare 404, non 200 con 'Nessun risultato' ``` ### Crawl budget **Perché conta.** È la quantità di URL che un motore è disposto a scansionare in un dato periodo, funzione di crawl rate (capacità del server) e crawl demand (interesse verso il sito). Su siti grandi, sprecarlo su duplicati, parametri, redirect e soft 404 significa che le pagine nuove o importanti vengono scoperte e aggiornate più lentamente. Server veloci e architettura pulita ne migliorano l’efficienza. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Media_ **Best practice.** Riduci gli sprechi (elimina catene di redirect, blocca/canonicalizza i parametri inutili, correggi soft 404, comprimi le sitemap a soli URL validi) e migliora velocità di risposta del server e link interni verso le pagine prioritarie. ### llms.txt **Perché conta.** Proposta emergente (non uno standard ufficiale dei motori) per offrire a LLM e motori di risposta AI una mappa curata in Markdown dei contenuti più rilevanti del sito, facilitando il recupero e la citazione in risposte generative (GEO). Va distinto da robots.txt e dai meccanismi di controllo crawler AI (es. blocco di GPTBot, CCBot via robots o header): llms.txt guida, non blocca. _Motivazioni: GEO/AI · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Pubblica /llms.txt con link Markdown alle pagine chiave e una breve descrizione; gestisci l’accesso dei crawler AI separatamente in robots.txt o via X-Robots-Tag, senza aspettarti che llms.txt influenzi il ranking sui motori tradizionali. ``` # Nome Sito > Descrizione breve ## Documentazione - [Guida SEO](https://www.sito.it/guida.md): panoramica ``` ## 5. Immagini, video & media ### Attributo alt (alt text) **Perché conta.** L’attributo alt descrive il contenuto dell’immagine in modo testuale: serve agli screen reader per descrivere l’immagine agli utenti non vedenti (accessibilita), viene letto dai crawler per capire il soggetto dell’immagine e indicizzarla in Google Immagini, e fornisce contesto semantico utile al ranking della pagina; inoltre funge da testo di fallback se l’immagine non si carica (rendering/compatibilita). Per i motori generativi/AI e un segnale chiave per capire cosa raffigura un’immagine non comprensibile altrimenti. _Motivazioni: Accessibilità · Crawler/Indicizzazione · GEO/AI · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Scrivi alt brevi ma descrittivi (circa 5-15 parole) che descrivono cosa si vede e il contesto, includendo keyword pertinenti solo se naturali; evita keyword stuffing e frasi come ‘immagine di’. ``` ![Scarpa da running rossa Nike Pegasus 41 vista laterale](scarpa-running-rossa.webp) ``` ### Decorative vs informative (alt=”” e role) **Perché conta.** Distinguere immagini decorative da quelle informative evita rumore per gli screen reader: un’immagine puramente estetica con alt vuoto (alt=””) viene saltata dagli assistive technology migliorando l’esperienza degli utenti non vedenti (accessibilita), mentre un’immagine informativa senza alt costringe lo screen reader a leggere il nome file. Per i crawler, segnalare correttamente le decorative evita di attribuire valore semantico a elementi irrilevanti (crawler/indicizzazione). _Motivazioni: Accessibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Usa alt=”” (vuoto, non assente) per immagini puramente decorative o spostale in CSS background; riserva l’alt descrittivo solo alle immagini che veicolano contenuto informativo. ``` ``` ### Attributi width e height (CLS) **Perché conta.** Specificare width e height permette al browser di riservare lo spazio corretto prima del download dell’immagine, evitando il Cumulative Layout Shift (CLS), una metrica dei Core Web Vitals che impatta sia il ranking sia l’esperienza utente (lo spostamento del layout durante il caricamento e frustrante e causa clic accidentali); il browser calcola l’aspect-ratio e mantiene il layout stabile (rendering/performance). _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Indica sempre width e height (o aspect-ratio in CSS) coerenti con le proporzioni reali del file; con immagini responsive usali insieme a CSS che imposta height:auto per non deformare. ``` ![...](foto.webp) ``` ### Lazy loading (loading=”lazy”) **Perché conta.** Il lazy loading rinvia il caricamento delle immagini fuori viewport finche l’utente non scrolla, riducendo il peso iniziale della pagina, accelerando il First Contentful Paint e risparmiando banda (performance ed esperienza utente); migliora indirettamente i Core Web Vitals e quindi il ranking. Va pero evitato sulle immagini above-the-fold per non penalizzare l’LCP. _Motivazioni: Performance · Esperienza utente · Ranking — Priorità: Alta_ **Best practice.** Applica loading=”lazy” solo alle immagini sotto la piega; NON usarlo sull’immagine LCP/hero, che anzi va caricata con priorita alta (eager + fetchpriority). ``` ![...](galleria-8.webp) ``` ### fetchpriority **Perché conta.** L’attributo fetchpriority indica al browser quali risorse scaricare per prime: impostarlo a ‘high’ sull’immagine LCP (es. hero) ne anticipa il download migliorando il Largest Contentful Paint, una metrica dei Core Web Vitals che incide su ranking ed esperienza utente; impostarlo a ‘low’ su immagini secondarie libera banda per cio che conta. E un fine-tuning della performance percepita. _Motivazioni: Performance · Ranking · Esperienza utente — Priorità: Media_ **Best practice.** Usa fetchpriority=”high” sull’immagine LCP (con loading=”eager”) e lascia il default o ‘low’ alle altre; non assegnarlo a piu immagini contemporaneamente o perde efficacia. ``` ![...](hero.webp) ``` ### Responsive images (srcset e sizes) **Perché conta.** srcset e sizes permettono al browser di scegliere la variante di immagine piu adatta a risoluzione e larghezza dello schermo (mobile, retina, desktop), evitando di scaricare un file enorme su uno smartphone: cio riduce peso e tempi di caricamento (performance) migliorando l’esperienza utente e i Core Web Vitals (ranking), e garantisce nitidezza sui display ad alta densita (rendering/compatibilita). _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Fornisci piu varianti dimensionali con srcset e descrivi gli slot di layout con sizes; per art direction (ritagli diversi per device) usa l’elemento <picture> con <source media>. ``` ![...](foto-800.webp) ``` ### Formati moderni (WebP, AVIF) **Perché conta.** WebP e AVIF offrono una compressione molto superiore a JPEG/PNG a parita di qualita visiva, riducendo drasticamente il peso dei file: questo accelera il caricamento e migliora i Core Web Vitals (performance, esperienza utente, ranking). Vanno serviti con fallback per i browser piu datati (rendering/compatibilita); Google li raccomanda esplicitamente in PageSpeed Insights. _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Servi AVIF/WebP con fallback JPEG/PNG tramite <picture> o content negotiation; AVIF per la massima compressione, WebP come compromesso ampiamente supportato. ``` ![...](img.jpg) ``` ### Compressione e peso del file **Perché conta.** Il peso delle immagini e spesso la prima causa di pagine lente: ottimizzare compressione e dimensioni reali (no immagini 4000px ridotte via CSS) riduce i tempi di download, migliora LCP e i Core Web Vitals (performance, ranking) e l’esperienza su connessioni mobili lente; immagini leggere riducono anche il consumo dati e il bounce rate (conversione). _Motivazioni: Performance · Esperienza utente · Ranking · Conversione — Priorità: Alta_ **Best practice.** Ridimensiona alla dimensione massima effettivamente visualizzata, comprimi con qualita 75-85% e rimuovi metadati EXIF superflui; punta a pochi centinaia di KB per immagine in pagina. ### Naming del file immagine **Perché conta.** Un nome file descrittivo e con parole chiave (separate da trattini) aiuta i crawler a comprendere il soggetto dell’immagine in Google Immagini e fornisce un debole segnale di rilevanza (crawler/indicizzazione, ranking); migliora anche l’organizzazione e l’accessibilita dell’URL. Nomi come IMG_0423.jpg non comunicano nulla ai motori. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Media_ **Best practice.** Usa nomi descrittivi minuscoli con trattini e senza spazi/accenti (es. torta-cioccolato-fatta-in-casa.webp); evita stringhe generiche e keyword stuffing. ``` scarpa-running-nike-pegasus-41.webp ``` ### Didascalie, figure e figcaption **Perché conta.** Il testo della didascalia e tra i contenuti piu letti vicino alle immagini e fornisce contesto semantico forte ai crawler (oltre all’alt); <figure>/<figcaption> associano semanticamente la didascalia all’immagine migliorando l’accessibilita e la comprensione del contenuto da parte dei motori e degli LLM (GEO/AI), e aiutano l’utente a interpretare cio che vede (esperienza utente). _Motivazioni: Crawler/Indicizzazione · Accessibilità · Esperienza utente · GEO/AI — Priorità: Media_ **Best practice.** Usa <figure> con <figcaption> per legare didascalia e immagine quando la didascalia aggiunge informazione; la didascalia integra l’alt, non lo duplica. ``` ![Andamento vendite 2025](grafico.webp) Vendite trimestrali 2025, in crescita del 12% ``` ### Image sitemap (sitemap immagini) **Perché conta.** Le immagini caricate via JavaScript, lazy loading o in gallerie complesse possono sfuggire al crawler; dichiararle in una sitemap XML (o con le estensioni image nella sitemap principale) aiuta Google a scoprirle e indicizzarle in Google Immagini (crawler/indicizzazione), aumentando la visibilita nella ricerca per immagini e il traffico potenziale. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Includi le immagini importanti con il tag image:image nella sitemap XML, soprattutto quelle caricate dinamicamente; non serve per immagini gia facilmente raggiungibili nel markup statico. ``` https://sito.it/paginahttps://sito.it/foto.webp ``` ### Open Graph image (og:image) **Perché conta.** og:image definisce l’immagine mostrata quando la pagina viene condivisa su social e app di messaggistica: una preview accattivante aumenta CTR e condivisioni (esperienza utente, conversione) e quindi il traffico social; pur non essendo un fattore di ranking diretto, influenza i segnali di engagement. Twitter/X usa anche twitter:image. Le anteprime corrette riducono il rischio di card vuote (rendering/compatibilita). _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Imposta og:image con URL assoluto, formato 1200x630px (ratio 1.91:1), peso contenuto e og:image:alt descrittivo; verifica con i debugger social. ``` ``` ### Video: VideoObject schema (dati strutturati) **Perché conta.** Il markup VideoObject in JSON-LD permette a Google di comprendere contenuto, durata, miniatura e data di un video, abilitando rich result, key moments e l’indicizzazione in Google Video (crawler/indicizzazione, ranking); migliora la visibilita nella SERP e fornisce dati strutturati che i motori AI possono citare (GEO/AI), aumentando CTR ed engagement. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Includi name, description, thumbnailUrl, uploadDate e contentUrl/embedUrl; aggiungi duration e hasPart con clip per i key moments quando rilevante. ``` ``` ### Video: transcript e sottotitoli **Perché conta.** Una trascrizione testuale e i sottotitoli rendono il contenuto del video indicizzabile e comprensibile ai crawler e agli LLM (i motori non ‘guardano’ davvero il video), arricchendo la pagina di testo rilevante (crawler/indicizzazione, ranking, GEO/AI); migliorano l’accessibilita per utenti sordi o in contesti senza audio (accessibilita) e l’esperienza utente, e aumentano il tempo sulla pagina. _Motivazioni: Accessibilità · Crawler/Indicizzazione · Ranking · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Pubblica la trascrizione completa nel testo della pagina e fornisci sottotitoli/closed caption (file VTT) sul player; evita di affidarti solo alle caption auto-generate non riviste. ``` ``` ### Decoding e async decoding (decoding=”async”) **Perché conta.** L’attributo decoding=”async” consente al browser di decodificare l’immagine fuori dal thread principale, evitando che la decodifica di immagini pesanti blocchi il rendering e la reattivita della pagina; contribuisce a una migliore performance percepita e fluidita di caricamento (performance, esperienza utente), con effetto indiretto positivo sui Core Web Vitals. _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Aggiungi decoding=”async” alle immagini non critiche; combinalo con loading=”lazy” per le immagini sotto la piega. ``` ![...](foto.webp) ``` ### Preload dell’immagine LCP **Perché conta.** Precaricare l’immagine LCP con <link rel=”preload”> (specie quando e referenziata in CSS o caricata tardi) anticipa il suo download, migliorando il Largest Contentful Paint e quindi i Core Web Vitals e l’esperienza utente percepita; e una leva diretta di performance che incide sul ranking. Va usato con imagesrcset per le immagini responsive. _Motivazioni: Performance · Ranking · Esperienza utente — Priorità: Bassa_ **Best practice.** Precarica solo l’immagine LCP critica con as=”image” e, se responsive, imagesrcset/imagesizes coerenti; non abusare del preload per non saturare la banda. ``` ``` ## 6. Dati strutturati (Schema.org / JSON-LD) ### JSON-LD (formato consigliato vs Microdata/RDFa) **Perché conta.** JSON-LD è il formato raccomandato ufficialmente da Google perché disaccoppia i dati strutturati dal markup visibile: lo inserisci come blocco <script> nel <head> o nel <body> senza intrecciarlo con l’HTML, riducendo errori di parsing e facilitando la manutenzione e l’iniezione lato server o tramite tag manager. I crawler lo interpretano in modo affidabile per costruire la propria comprensione dell’entità di pagina, mentre Microdata e RDFa, sparsi tra gli attributi dei tag, sono più fragili e soggetti a rotture quando cambi il template. Una migliore comprensione semantica alimenta l’eleggibilità ai rich results e, sempre più, l’estrazione di entità per risposte AI/GEO. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · GEO/AI — Priorità: Alta_ **Best practice.** Usa JSON-LD come formato unico, un blocco <script type=”application/ld+json”> per pagina (o più blocchi coerenti tra loro), e mantieni i valori allineati al contenuto realmente visibile. ``` ``` ### Organization (entità del sito/brand) **Perché conta.** Il markup Organization dichiara in modo esplicito chi è l’editore del sito (nome legale, logo, contatti, sedi) e funge da nodo centrale del knowledge graph del brand: aiuta i crawler a consolidare l’identità dell’entità, può alimentare il Knowledge Panel e fornisce ai motori e ai sistemi AI un riferimento autorevole su chi pubblica i contenuti, fattore che pesa nella valutazione di affidabilità (E-E-A-T). Il campo logo va a determinare quale immagine può comparire accanto al brand nei risultati e in alcune feature SERP. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Inserisci Organization una sola volta a livello di sito (tipicamente in home), con name, url, logo (ImageObject con dimensioni adeguate) e sameAs verso i profili ufficiali; usa @id stabile per referenziarla dalle altre entità. ``` { "@type": "Organization", "@id": "https://esempio.it/#org", "name": "Esempio SRL", "url": "https://esempio.it/", "logo": "https://esempio.it/logo.png", "sameAs": ["https://www.linkedin.com/company/esempio"] } ``` ### WebSite + SearchAction (Sitelinks Searchbox) **Perché conta.** Il markup WebSite identifica il sito come entità e, abbinato a potentialAction di tipo SearchAction, segnala a Google la presenza di una ricerca interna, abilitando in teoria la Sitelinks Searchbox direttamente in SERP: un beneficio sia di visibilità (occupa più spazio nel risultato) sia di esperienza utente (l’utente cerca dentro il sito senza passaggi intermedi). Va precisato che Google ha ridotto fortemente la comparsa di questa feature, quindi il valore principale oggi resta la chiara definizione dell’entità WebSite nel knowledge graph del sito più che la searchbox in sé. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · GEO/AI — Priorità: Media_ **Best practice.** Dichiara WebSite con name e url in home, e includi SearchAction solo se esiste davvero una ricerca interna funzionante con il parametro corretto in query-input. ``` { "@type": "WebSite", "url": "https://esempio.it/", "potentialAction": { "@type": "SearchAction", "target": "https://esempio.it/?s={search_term_string}", "query-input": "required name=search_term_string" } } ``` ### BreadcrumbList **Perché conta.** Lo schema BreadcrumbList esplicita la gerarchia di navigazione della pagina e permette a Google di sostituire l’URL grezzo in SERP con un percorso a briciole di pane leggibile, migliorando la comprensione della struttura del sito da parte dei crawler e il CTR percepito dagli utenti. Funziona in sinergia con i breadcrumb HTML visibili e con la distribuzione del link juice verso le pagine di categoria padre; deve riflettere esattamente il percorso mostrato nella pagina, altrimenti è considerato markup incoerente. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Link juice/PageRank — Priorità: Alta_ **Best practice.** Genera BreadcrumbList con itemListElement ordinati (position crescente), name e item (URL) per ogni livello tranne eventualmente l’ultimo (la pagina corrente), allineato al breadcrumb visibile. ``` { "@type": "BreadcrumbList", "itemListElement": [ {"@type":"ListItem","position":1,"name":"Home","item":"https://esempio.it/"}, {"@type":"ListItem","position":2,"name":"Blog","item":"https://esempio.it/blog/"} ] } ``` ### Article / BlogPosting / NewsArticle **Perché conta.** Il markup Article descrive un contenuto editoriale fornendo a crawler e sistemi AI segnali strutturati su titolo, autore, date di pubblicazione e modifica, editore e immagine principale: questo migliora la comprensione del documento, può abilitare feature come Top Stories e l’arricchimento del risultato, e i campi datePublished/dateModified aiutano i motori a valutare freschezza e cronologia del contenuto. Collegare author e publisher a entità Person/Organization rafforza i segnali E-E-A-T, sempre più rilevanti per il ranking dei contenuti informativi e per la citazione nelle risposte generative. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Scegli il sottotipo corretto (BlogPosting per blog, NewsArticle per notizie), valorizza headline, author (Person o Organization), publisher, datePublished, dateModified e image; mantieni headline coerente con l’H1. ``` { "@type": "BlogPosting", "headline": "Come ottimizzare i Core Web Vitals", "author": {"@type":"Person","name":"Mario Rossi"}, "datePublished": "2026-05-01", "dateModified": "2026-05-20" } ``` ### LocalBusiness **Perché conta.** LocalBusiness (e i suoi sottotipi come Restaurant o Dentist) struttura i dati dell’attività locale – nome, indirizzo (PostalAddress), coordinate geo, orari di apertura, telefono – permettendo ai crawler di associare il sito all’entità locale e supportando la coerenza NAP che è centrale per il ranking nella ricerca locale e nel pacchetto mappe. Migliora l’esperienza dell’utente che trova subito orari e contatti e fornisce ai sistemi AI dati affidabili per rispondere a query con intento locale. _Motivazioni: Crawler/Indicizzazione · Ranking · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Usa il sottotipo più specifico disponibile, mantieni name/address/telefono identici a Google Business Profile e altre citazioni, e aggiungi openingHoursSpecification, geo e priceRange dove pertinente. ``` { "@type": "Dentist", "name": "Studio Bianchi", "address": {"@type":"PostalAddress","streetAddress":"Via Roma 1","addressLocality":"Milano","postalCode":"20100"}, "telephone": "+390212345678" } ``` ### Product + Offer **Perché conta.** Il markup Product con il nodo Offer fornisce ai crawler prezzo, valuta, disponibilità e condizione del prodotto, dati necessari per l’eleggibilità ai rich results di e-commerce (prezzo e disponibilità in SERP) e per il Merchant listing: questo aumenta la visibilità e il CTR e fornisce informazioni che incidono direttamente sulla decisione d’acquisto. I valori devono rispecchiare quanto mostrato sulla pagina di prodotto, perché incongruenze di prezzo o disponibilità sono una violazione delle linee guida che può causare manual action. _Motivazioni: Crawler/Indicizzazione · Conversione · Ranking — Priorità: Alta_ **Best practice.** Includi name, image, description e offers con price, priceCurrency, availability e priceValidUntil; allinea i valori al front-end e aggiorna la disponibilità in tempo reale. ``` { "@type": "Product", "name": "Scarpa Running X", "offers": {"@type":"Offer","price":"89.90","priceCurrency":"EUR","availability":"https://schema.org/InStock"} } ``` ### Review / AggregateRating **Perché conta.** Le proprietà review e aggregateRating consentono di mostrare le stelle di valutazione nei rich results, un elemento che incrementa fortemente il CTR e la fiducia dell’utente fornendo prova sociale già in SERP. Google richiede che le recensioni siano genuine, di prima parte e riferite a un’entità idonea (Product, LocalBusiness, ecc.); l’auto-review o il markup di valutazioni non visibili in pagina viola le linee guida e può portare a penalizzazioni o alla perdita del rich result. _Motivazioni: Conversione · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Applica aggregateRating solo con recensioni reali e visibili sulla pagina, includendo ratingValue, reviewCount/ratingCount e bestRating; non marcare valutazioni sull’intera azienda nella home. ``` { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "128", "bestRating": "5" } ``` ### FAQPage **Perché conta.** FAQPage struttura coppie domanda/risposta presenti sulla pagina rendendole comprensibili ai crawler e potenzialmente espandibili nei risultati; va però precisato che dal 2023 Google limita il rich result FAQ a siti governativi e sanitari autorevoli, quindi per la maggior parte dei siti il rich result non compare più. Il valore residuo è la chiarezza semantica del contenuto, utile per l’estrazione di risposte da parte dei sistemi AI/GEO e per organizzare informazioni che rispondono a query specifiche degli utenti. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Usa FAQPage solo per vere FAQ visibili in pagina, con Question/acceptedAnswer; non abusarne su pagine commerciali e non aspettarti il rich result se il sito non rientra nelle categorie ammesse. ``` { "@type": "FAQPage", "mainEntity": [{"@type":"Question","name":"Quanto costa la spedizione?","acceptedAnswer":{"@type":"Answer","text":"La spedizione è gratuita sopra i 50 euro."}}] } ``` ### HowTo **Perché conta.** HowTo descrive una procedura passo-passo (step, strumenti, materiali, tempo) aiutando i crawler a interpretare guide e tutorial; come per le FAQ, Google ha deprecato il rich result HowTo nei risultati standard, quindi oggi serve soprattutto come struttura semantica leggibile dagli LLM e dai motori per estrarre istruzioni in risposte generative. Resta un modo pulito per modellare contenuti istruttivi quando il contenuto è realmente una sequenza di passaggi. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente — Priorità: Bassa_ **Best practice.** Applica HowTo solo a guide procedurali reali con step ordinati (HowToStep con name, text, eventuale image); evita di usarlo per articoli discorsivi e non aspettarti più il rich result classico. ``` { "@type": "HowTo", "name": "Come cambiare una gomma", "step": [{"@type":"HowToStep","text":"Allenta i bulloni."}] } ``` ### DefinedTerm / DefinedTermSet **Perché conta.** DefinedTerm e DefinedTermSet modellano voci di un glossario o tassonomia come entità definite, collegando un termine alla sua definizione e a uno schema concettuale: questo aiuta i crawler e soprattutto i sistemi AI/GEO a disambiguare il significato dei termini di settore e a riconoscere il sito come fonte autorevole su un dominio semantico. Pur non generando rich result, rafforza la mappatura entità-concetto utile per topical authority e per essere citati in risposte generative. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Usa DefinedTermSet per il glossario e DefinedTerm per ogni voce con name, description e inDefinedTermSet; collega i termini con @id stabili e, dove utile, sameAs verso fonti autorevoli (es. Wikidata). ``` { "@type": "DefinedTerm", "name": "Crawl budget", "description": "Numero di pagine che un crawler scansiona in un dato periodo.", "inDefinedTermSet": "https://esempio.it/glossario/#set" } ``` ### Person / author (E-E-A-T) **Perché conta.** Marcare l’autore come entità Person, con name, url alla pagina autore, jobTitle, sameAs verso profili e affiliazioni, fornisce ai motori e ai sistemi AI segnali strutturati su chi ha prodotto il contenuto, elemento chiave dell’E-E-A-T (esperienza, competenza, autorevolezza, affidabilità). Collegare l’autore tra articoli, bio e profili esterni aiuta a consolidare l’entità autore nel knowledge graph, rafforzando la credibilità percepita del contenuto, fattore che incide su come Google valuta e potenzialmente cita le pagine, soprattutto su temi YMYL. _Motivazioni: Ranking · GEO/AI · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Definisci Person con @id stabile, name, url (pagina autore reale), sameAs e knowsAbout; riusa lo stesso @id come author negli Article per consolidare l’entità. ``` { "@type": "Person", "@id": "https://esempio.it/autori/mario-rossi/#person", "name": "Mario Rossi", "jobTitle": "SEO Specialist", "sameAs": ["https://www.linkedin.com/in/mariorossi"] } ``` ### ImageObject **Perché conta.** ImageObject descrive un’immagine come entità (url, larghezza, altezza, didascalia) e va usato per i campi image di Article, Product, Organization (logo) e simili, perché Google preferisce dimensioni esplicite e immagini ad alta risoluzione per popolare rich result e anteprime. Fornire ImageObject strutturati migliora l’eleggibilità alle feature visive in SERP, la comprensione del contenuto multimediale da parte dei crawler e la qualità delle anteprime mostrate all’utente. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Per le immagini chiave usa ImageObject con url, width e height; fornisci immagini abbastanza grandi (lato lungo idealmente >=1200px) e in più aspect ratio quando richiesto dalla feature. ``` { "@type": "ImageObject", "url": "https://esempio.it/img/copertina.jpg", "width": 1200, "height": 675 } ``` ### sameAs **Perché conta.** La proprietà sameAs collega un’entità (Organization, Person, brand) ai suoi profili e riferimenti ufficiali su altri siti – social, Wikipedia, Wikidata, LinkedIn – fornendo ai motori prove di identità che aiutano la disambiguazione e il consolidamento dell’entità nel knowledge graph. È uno dei segnali più diretti per costruire l’autorevolezza dell’entità lato GEO/AI e per associare correttamente il brand o l’autore alle fonti note, riducendo confusione con omonimi. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Ranking — Priorità: Media_ **Best practice.** Inserisci in sameAs solo URL ufficiali e controllati dall’entità (profili social, scheda Wikidata/Wikipedia), evitando link irrilevanti o non posseduti. ``` "sameAs": [ "https://www.wikidata.org/wiki/Q12345", "https://www.linkedin.com/company/esempio", "https://twitter.com/esempio" ] ``` ### @id e collegamento tra entità (grafo) **Perché conta.** Assegnare un @id stabile a ciascuna entità e referenziarlo da altri nodi (es. l’Organization come publisher dell’Article, la Person come author) trasforma blocchi isolati di markup in un grafo coerente che i crawler e i sistemi AI possono attraversare per ricostruire le relazioni tra brand, autore, pagina e contenuto. Questo evita duplicazioni, riduce ambiguità e rafforza la comprensione semantica complessiva del sito, migliorando l’affidabilità dei segnali E-E-A-T e l’estrazione di entità per le risposte generative. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Ranking — Priorità: Media_ **Best practice.** Definisci ogni entità ricorrente una sola volta con @id assoluto e univoco, poi referenziala altrove con {“@id”:”…”} invece di ripetere i dati. ``` { "@type": "Article", "publisher": {"@id": "https://esempio.it/#org"}, "author": {"@id": "https://esempio.it/autori/mario-rossi/#person"} } ``` ### Eleggibilità ai rich results e validazione **Perché conta.** Avere dati strutturati validi è condizione necessaria ma non sufficiente per ottenere i rich results: Google decide se mostrarli e richiede che siano presenti le proprietà required, che il markup rispetti le linee guida e che il contenuto sia realmente sulla pagina. Validare con il Rich Results Test e monitorare il report Miglioramenti in Search Console intercetta errori e warning che bloccano l’eleggibilità, mentre il markup corretto ma su contenuto debole non garantisce comunque la feature. _Motivazioni: Crawler/Indicizzazione · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Testa ogni tipo con il Rich Results Test e lo Schema Validator, copri tutte le proprietà required/recommended e monitora gli errori nei report di Search Console dopo il deploy. ### Errori comuni: markup non visibile, spam e incoerenza **Perché conta.** L’errore più penalizzante è marcare informazioni non presenti o non visibili nella pagina (prezzi, recensioni, FAQ nascoste) o gonfiare le valutazioni: viola le linee guida sui dati strutturati e può causare manual action, perdita dei rich result o azioni anti-spam. Altri errori frequenti sono campi required mancanti, tipi errati, valori non coerenti tra markup e front-end e duplicazione della stessa entità senza @id; tutti riducono l’affidabilità dei segnali che crawler e sistemi AI usano per fidarsi del sito. _Motivazioni: Crawler/Indicizzazione · Ranking · Sicurezza — Priorità: Alta_ **Best practice.** Marca solo ciò che è visibile all’utente, evita auto-review e dati gonfiati, mantieni i valori coerenti col contenuto reale e correggi gli errori segnalati prima di affidarti alla feature. ## 7. Social / sharing meta ### <meta property=”og:title”> **Perché conta.** Definisce il titolo che appare quando la pagina viene condivisa su Facebook, LinkedIn, WhatsApp e altre piattaforme che leggono il protocollo Open Graph; non è un fattore di ranking diretto su Google, ma controlla l’anteprima social e quindi incide sul CTR e sulla propensione alla condivisione. Senza di esso la piattaforma fa fallback sul <title> o su euristiche, spesso troncate o poco accattivanti; un og:title curato e distinto dal <title> permette di ottimizzare separatamente il messaggio per i social rispetto a quello per i motori di ricerca. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Conversione — Priorità: Alta_ **Best practice.** Imposta sempre og:title in modo esplicito (anche se coincide spesso col title), mantienilo conciso (circa 60-70 caratteri per evitare troncamenti) e centrato sul contenuto della singola pagina; va dichiarato nel <head>. ``` ``` ### <meta property=”og:description”> **Perché conta.** Fornisce il testo descrittivo dell’anteprima nelle condivisioni social; come la meta description per la SERP, non è un segnale di ranking ma agisce sull’esperienza dell’utente e sul CTR perché spiega cosa troverà nella pagina prima del clic. In assenza di og:description le piattaforme ripiegano sulla meta description o su frammenti casuali del testo, con risultati spesso incoerenti; un valore esplicito garantisce un messaggio controllato e coerente con l’immagine e il titolo dell’anteprima. _Motivazioni: Esperienza utente · Conversione · Crawler/Indicizzazione — Priorità: Alta_ **Best practice.** Scrivi una descrizione persuasiva e pertinente alla pagina, idealmente entro circa 110 caratteri perché alcune piattaforme (es. mobile) troncano presto; evita keyword stuffing e rendila complementare al titolo. ``` ``` ### <meta property=”og:image”> **Perché conta.** Specifica l’immagine mostrata nell’anteprima quando la pagina viene condivisa; è l’elemento che più di ogni altro determina l’impatto visivo e quindi il CTR e la viralità della condivisione, pur non essendo un segnale di ranking organico. Una pagina senza og:image viene condivisa con un riquadro vuoto o con un’immagine scelta a caso dal crawler social, riducendo drasticamente l’attrattiva del post; definirla esplicitamente assicura che venga usata l’immagine giusta, ben renderizzata su tutte le piattaforme. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Usa un URL assoluto (con https), un’immagine dedicata e di alta qualità, e affianca og:image:width/height e og:image:alt per rendering affidabile e accessibilità; verifica l’anteprima con i debugger ufficiali delle piattaforme. ``` ``` ### Dimensioni e peso di og:image (1200×630, rapporto 1.91:1) **Perché conta.** Il rapporto e la risoluzione dell’immagine determinano se l’anteprima viene mostrata grande e nitida oppure ritagliata, compressa o relegata a thumbnail; 1200×630 px (rapporto 1.91:1) è lo standard che genera l’anteprima a immagine grande su Facebook/LinkedIn e si abbina alla Twitter Card summary_large_image. Dimensioni troppo piccole (sotto 600×315) o proporzioni errate compromettono il rendering cross-piattaforma e riducono l’efficacia visiva, con effetto diretto su CTR e percezione di qualità del brand. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Esporta l’immagine social a 1200×630 px (minimo 600×315, rapporto 1.91:1), tienila sotto i ~5-8 MB e in formato JPG/PNG/WebP supportato; centra gli elementi importanti per resistere a eventuali crop. ``` ``` ### <meta property=”og:url”> **Perché conta.** Indica l’URL canonico dell’oggetto condiviso: serve a consolidare le interazioni social (like, condivisioni, conteggi) sulla stessa risorsa anche quando la pagina è raggiunta con parametri di tracciamento (UTM) o varianti di URL, evitando frammentazione del ‘social juice’ e doppioni nelle cache delle piattaforme. Pur non essendo il canonical SEO, agisce con logica analoga lato social e mantiene coerente l’identità della pagina nelle anteprime e nei grafi delle piattaforme. _Motivazioni: Link juice/PageRank · Crawler/Indicizzazione · Esperienza utente — Priorità: Media_ **Best practice.** Imposta og:url all’URL canonico, assoluto e pulito (senza parametri di sessione/tracking), coerente con <link rel=”canonical”>. ``` ``` ### <meta property=”og:type”> **Perché conta.** Dichiara il tipo di oggetto (website, article, product, video, ecc.) e influenza come la piattaforma interpreta e arricchisce l’anteprima, abilitando proprietà aggiuntive specifiche (per esempio article:published_time o i campi product); un tipo corretto migliora il rendering e la coerenza semantica del contenuto condiviso. Un valore mancante o errato fa ripiegare le piattaforme sul tipo generico, perdendo metadati arricchiti utili a contesto ed esperienza utente. _Motivazioni: Rendering/Compatibilità · Crawler/Indicizzazione · Esperienza utente — Priorità: Media_ **Best practice.** Usa ‘website’ per pagine generiche e ‘article’ per contenuti editoriali (abbinando le proprietà article:* quando rilevanti); scegli ‘product’ per le schede prodotto e-commerce. ``` ``` ### <meta property=”og:site_name”> **Perché conta.** Indica il nome del sito/brand che compare nell’anteprima della condivisione, rafforzando il riconoscimento del brand e la fiducia dell’utente nel momento del clic; non incide sul ranking ma contribuisce alla coerenza dell’identità e indirettamente al CTR. È particolarmente utile quando lo stesso dominio ospita un brand riconoscibile, perché distingue la fonte rispetto al solo URL. _Motivazioni: Esperienza utente · Conversione — Priorità: Bassa_ **Best practice.** Imposta un og:site_name costante su tutte le pagine, uguale al nome ufficiale del brand/sito. ``` ``` ### <meta property=”og:locale”> **Perché conta.** Specifica la lingua e l’area geografica del contenuto (es. it_IT) aiutando le piattaforme a presentare l’anteprima in modo coerente con l’audience e a gestire correttamente versioni multilingua tramite og:locale:alternate; migliora l’esperienza per utenti in lingue diverse ed evita rendering incoerenti. Non è un fattore di ranking, ma supporta la corretta localizzazione delle condivisioni in siti internazionali. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Imposta og:locale nel formato lingua_PAESE (es. it_IT) e aggiungi og:locale:alternate per ogni versione linguistica disponibile, in linea con la strategia hreflang. ``` ``` ### <meta name=”twitter:card” content=”summary_large_image”> **Perché conta.** Definisce il formato della Twitter Card (anteprima su X/Twitter); ‘summary_large_image’ attiva l’anteprima con immagine grande, molto più visibile e performante in termini di CTR rispetto alla ‘summary’ a thumbnail. Non è un segnale di ranking, ma determina l’aspetto della condivisione sulla piattaforma; in assenza di tag twitter:*, X tende a fare fallback sui tag Open Graph, quindi spesso basta integrare il solo twitter:card con OG ben configurati. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Usa ‘summary_large_image’ per contenuti con un’immagine d’impatto e ‘summary’ per contenuti minimali; non serve duplicare tutti i campi OG, perché X ne fa fallback, ma dichiara almeno twitter:card. ``` ``` ### <meta name=”twitter:title”> **Perché conta.** Stabilisce il titolo specifico per l’anteprima su X/Twitter quando vuoi differenziarlo dall’og:title; in mancanza, X usa come fallback l’og:title, quindi è opzionale ma utile per ottimizzare il messaggio sul tono e i limiti della piattaforma. Incide su CTR e condivisione, non sul ranking organico. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Specifica twitter:title solo se serve un titolo diverso da og:title (es. più breve o più colloquiale); altrimenti affidati al fallback su Open Graph per evitare ridondanza. ``` ``` ### <meta name=”twitter:description”> **Perché conta.** Imposta la descrizione dell’anteprima su X/Twitter; se assente, viene usato l’og:description come fallback, perciò serve solo quando vuoi un testo dedicato alla piattaforma. Agisce sull’esperienza utente e sul CTR del tweet, non è un fattore di ranking; X tronca la descrizione, quindi conta la sintesi. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Mantieni la descrizione molto sintetica (circa 120-200 caratteri) e usala solo per differenziarti dall’og:description; in caso contrario lascia agire il fallback. ``` ``` ### <meta name=”twitter:image”> **Perché conta.** Indica l’immagine dell’anteprima su X/Twitter; se non presente, X fa fallback su og:image, quindi è opzionale ma utile quando vuoi un’immagine differente o ottimizzata per il formato della card. È l’elemento visivo che traina l’engagement del tweet e dunque il CTR, senza alcun effetto sul ranking organico. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Usa un URL assoluto e, per summary_large_image, un’immagine in rapporto ~1.91:1 (es. 1200×630); aggiungi twitter:image:alt per l’accessibilità. Se identica a og:image, basta affidarsi al fallback. ``` ``` ### <meta name=”twitter:site” e twitter:creator”> **Perché conta.** Associano la card all’account X del sito (twitter:site) e all’autore del contenuto (twitter:creator), aggiungendo attribuzione e rafforzando il riconoscimento del brand e dell’autore nell’anteprima; favoriscono il follow e la fiducia, con un effetto indiretto su engagement e condivisioni. Non incidono sul ranking nei motori di ricerca. _Motivazioni: Esperienza utente · Conversione — Priorità: Bassa_ **Best practice.** Inserisci gli handle con la @ (es. @brand e @autore) quando esistono account ufficiali; lascia stare i tag se non hai profili da attribuire. ``` ``` ### Fallback al <title> e <meta name=”description”> in assenza di tag social **Perché conta.** Quando mancano i tag Open Graph/Twitter, le piattaforme ricostruiscono l’anteprima usando come fallback il <title>, la meta description e immagini individuate euristicamente nella pagina; il risultato è spesso povero, troncato o incoerente, con ricadute negative su CTR e percezione del brand. Capire questa catena di fallback evita di duplicare inutilmente i tag, ma chiarisce anche perché conviene dichiarare almeno og:title, og:description e og:image per non lasciare l’anteprima al caso. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Assicurati che <title> e meta description siano comunque ottimali (fungono da rete di sicurezza), ma definisci esplicitamente i tag OG essenziali per controllare l’anteprima invece di affidarti al fallback. ``` Guida completa al SEO tecnico 2026 ``` ### Open Graph / Twitter Cards e ranking (chiarimento) **Perché conta.** I meta social NON sono fattori di ranking diretto: Google non usa Open Graph né Twitter Cards per posizionare le pagine. Il loro valore è indiretto ma reale: migliorano l’anteprima nelle condivisioni, aumentano CTR ed engagement sui social, possono incrementare traffico e segnali di brand e talvolta favorire l’acquisizione di link naturali, con un effetto di secondo ordine su autorevolezza e visibilità. È un mito attribuire a questi tag un peso diretto nell’algoritmo organico. _Motivazioni: Conversione · Esperienza utente · Link juice/PageRank — Priorità: Media_ **Best practice.** Tratta i tag social come leva di marketing e CTR (non di ranking): implementali bene per massimizzare condivisioni e traffico, ma non aspettarti che da soli migliorino le posizioni in SERP. ### Coerenza e validazione delle anteprime (debugger ufficiali) **Perché conta.** Le piattaforme social mettono in cache i metadati, quindi un tag errato o un’immagine sbagliata può restare ‘incastrato’ nelle anteprime anche dopo la correzione; validare con i debugger ufficiali forza il re-scraping, mostra come la card verrà renderizzata e segnala tag mancanti o immagini non raggiungibili. Questo garantisce rendering corretto cross-piattaforma e protegge CTR ed esperienza utente al momento della condivisione. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Dopo ogni modifica ai meta social, testa l’URL con i validatori ufficiali (Facebook Sharing Debugger, LinkedIn Post Inspector, X Card Validator) per forzare il refresh della cache e verificare l’anteprima. ## 8. Performance, Core Web Vitals & mobile ### LCP (Largest Contentful Paint) **Perché conta.** L’LCP misura il tempo di rendering dell’elemento di contenuto piu grande nel viewport (spesso l’hero image, un video poster o un blocco di testo): e una metrica di percezione della velocita centrale per l’esperienza utente, perche un utente considera la pagina ‘utile’ quando vede il contenuto principale. E un fattore di ranking confermato (Core Web Vital nel page experience signal) e, indirettamente, un buon LCP riduce la bounce rate e aumenta la conversione. Per i crawler/render di Google un caricamento lento puo penalizzare il crawl budget su siti grandi. _Motivazioni: Esperienza utente · Ranking · Performance · Conversione — Priorità: Alta_ **Best practice.** Tenere LCP sotto 2,5s al 75esimo percentile: ottimizzare e precaricare la risorsa LCP, servire immagini in formato moderno (AVIF/WebP) dimensionate correttamente, eliminare il render-blocking, usare un buon TTFB e CDN. Evitare lazy-loading sull’elemento LCP. ``` ``` ### CLS (Cumulative Layout Shift) **Perché conta.** Il CLS quantifica gli spostamenti inattesi del layout durante il caricamento: e una metrica di stabilita visiva fondamentale per l’esperienza utente, perche layout che ‘saltano’ causano click errati e frustrazione (es. si preme un bottone che si e spostato). E un Core Web Vital usato come segnale di ranking; un layout stabile migliora anche la conversione e riduce l’abbandono. Spesso causato da immagini/iframe/ads senza dimensioni, font che cambiano (FOIT/FOUT) e contenuti iniettati dinamicamente sopra il fold. _Motivazioni: Esperienza utente · Ranking · Rendering/Compatibilità · Conversione — Priorità: Alta_ **Best practice.** Tenere CLS sotto 0,1: riservare sempre lo spazio con width/height (o aspect-ratio) su immagini, video, iframe e annunci; non iniettare contenuti sopra contenuti esistenti; usare font-display ben gestito e transform invece di proprieta che ricalcolano il layout. ``` img { aspect-ratio: 16 / 9; width: 100%; height: auto; } ``` ### INP (Interaction to Next Paint, ex FID) **Perché conta.** L’INP ha sostituito FID a marzo 2024 come Core Web Vital di reattivita: misura la latenza di tutte le interazioni dell’utente (click, tap, input da tastiera) lungo l’intera visita, riportando il valore peggiore. A differenza di FID, che valutava solo il primo input, INP cattura la reattivita reale durante l’uso. Influisce direttamente sull’esperienza utente (una UI che ‘non risponde’ frustra), e un segnale di ranking ed e tipicamente degradato da JavaScript pesante che blocca il main thread. _Motivazioni: Esperienza utente · Ranking · Performance — Priorità: Alta_ **Best practice.** Tenere INP sotto 200ms: spezzare i long task, fare yield al main thread, ridurre/posticipare il JS di terze parti, usare web worker per calcoli pesanti e debouncing sugli handler. Evitare di eseguire lavoro sincrono costoso negli event handler. ``` button.addEventListener('click', () => { showSpinner(); requestIdleCallback(doHeavyWork); }); ``` ### TTFB (Time To First Byte) **Perché conta.** Il TTFB misura il tempo tra la richiesta e la ricezione del primo byte di risposta dal server: e un prerequisito a monte di tutte le altre metriche, perche un TTFB alto ritarda inevitabilmente LCP e FCP. Dipende da latenza di rete, tempo di elaborazione server, query al database e configurazione di caching/CDN. Un TTFB lento peggiora l’esperienza utente percepita, puo erodere il crawl budget (Googlebot rallenta su server lenti) e indebolisce i Core Web Vitals a valle. _Motivazioni: Performance · Crawler/Indicizzazione · Esperienza utente — Priorità: Alta_ **Best practice.** Puntare a TTFB sotto 800ms: usare caching server-side e a livello di pagina, CDN con edge caching, connessioni keep-alive/HTTP-2, ottimizzare query e backend, e ridurre i redirect. Servire HTML statico o cache-warmed quando possibile. ``` Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=600 ``` ### Render-blocking CSS/JS **Perché conta.** Risorse CSS e JS bloccanti nel <head> impediscono al browser di renderizzare la pagina finche non sono scaricate, parsate ed eseguite: questo ritarda First Paint e LCP, peggiorando velocita percepita ed esperienza utente. Il CSS e bloccante per costruzione (necessario al CSSOM); il JS sincrono blocca il parser HTML. Ridurre il render-blocking e una delle leve piu efficaci su LCP/FCP e quindi sul page experience signal usato nel ranking. _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Inlinare il CSS critico ed estrarre il resto in caricamento differito; aggiungere defer o async agli script non essenziali e spostarli prima di </body>; rimuovere CSS/JS inutilizzato e suddividere il codice (code splitting). ``` ``` ### Minificazione e tree-shaking (CSS/JS/HTML) **Perché conta.** La minificazione rimuove spazi, commenti e caratteri superflui e accorcia i nomi delle variabili, riducendo il peso dei file trasferiti: meno byte significano download piu rapidi, parsing/esecuzione piu veloci e migliore LCP/INP, con beneficio diretto su performance ed esperienza utente, soprattutto su mobile e reti lente. Il tree-shaking elimina codice morto dai bundle. E un’ottimizzazione a basso rischio e alto impatto, soprattutto combinata con la compressione. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Automatizzare la minificazione in fase di build (Terser, esbuild, cssnano) e abilitare il tree-shaking; servire i file minificati in produzione mantenendo i source map separati per il debug. ``` // build: esbuild app.js --minify --tree-shaking=true --bundle ``` ### Compressione gzip / Brotli **Perché conta.** La compressione testuale a livello di trasporto riduce drasticamente i byte trasferiti per HTML, CSS, JS, SVG e JSON: Brotli supera generalmente gzip (10-20% in meno sul testo) ed e supportato da tutti i browser moderni. Meno byte sulla rete equivalgono a download piu rapidi, miglior LCP/FCP e minor consumo dati su mobile, con impatto diretto su performance ed esperienza utente. E complementare alla minificazione (si minifica e poi si comprime). _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Abilitare Brotli (livello 4-6 dinamico, max per asset statici) con fallback gzip via Accept-Encoding; comprimere solo risorse testuali (non immagini/video gia compressi) e pre-comprimere gli asset statici. ``` Content-Encoding: br Vary: Accept-Encoding ``` ### Caching del browser (Cache-Control / ETag) **Perché conta.** Le intestazioni di caching dicono al browser per quanto e come riutilizzare le risorse senza riscaricarle: un caching corretto rende quasi istantanee le visite ripetute e la navigazione tra pagine, migliorando esperienza utente e performance e riducendo carico server e banda. Asset versionati (fingerprint nel nome) possono avere cache lunghissima e immutabile, mentre l’HTML resta a revalidate per restare fresco. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Cache lunga e immutable per asset versionati (CSS/JS/font/immagini con hash nel nome), short cache o no-cache con revalidate per HTML; usare ETag/Last-Modified per la validazione condizionale. ``` Cache-Control: public, max-age=31536000, immutable # /app.4f2a.js ``` ### CDN (Content Delivery Network) **Perché conta.** Una CDN distribuisce gli asset (e spesso l’HTML cache-warmed) su server edge geograficamente vicini all’utente: riduce la latenza e quindi il TTFB e i tempi di download, migliorando LCP ed esperienza utente soprattutto per audience internazionali. Offre inoltre offload del traffico, terminazione TLS rapida, HTTP/2-3, compressione e protezione DDoS, e puo migliorare anche l’efficienza di crawling servendo risposte veloci a Googlebot. _Motivazioni: Performance · Esperienza utente · Crawler/Indicizzazione · Sicurezza — Priorità: Media_ **Best practice.** Servire tutti gli asset statici (e idealmente l’HTML cacheable) tramite CDN con edge caching, HTTP/2-3, Brotli e TLS moderno; configurare regole di cache coerenti con il versioning degli asset. ### Resource hints: preload, preconnect, dns-prefetch **Perché conta.** I resource hint anticipano al browser quali risorse e connessioni serviranno, ottimizzando la coda di rete: preload forza il download anticipato di risorse critiche (font, immagine LCP, CSS critico); preconnect apre in anticipo connessione + DNS + TLS verso origini terze (es. CDN, Google Fonts); dns-prefetch risolve solo il DNS come fallback piu leggero. Usati bene riducono i tempi di scoperta delle risorse e migliorano LCP; usati male (troppi preload) competono per la banda e peggiorano la performance. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Precaricare solo le risorse veramente critiche e above-the-fold con as corretto; preconnect alle origini di terze parti essenziali (max 3-4) e dns-prefetch per quelle secondarie. Non abusare di preload. ``` ``` ### Lazy loading (immagini e iframe) **Perché conta.** Il lazy loading rinvia il caricamento delle risorse fuori dal viewport finche l’utente non vi si avvicina scrollando: riduce i byte iniziali e il lavoro del browser, accelerando LCP/FCP e risparmiando banda su mobile, con beneficio su performance ed esperienza utente. L’attributo loading=lazy nativo evita JS aggiuntivo. Attenzione: non va applicato all’immagine LCP/above-the-fold, perche ne ritarderebbe il rendering e peggiorerebbe proprio l’LCP. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Usare loading=lazy su immagini e iframe sotto il fold; mantenere eager (o nessun lazy) e fetchpriority=high sull’immagine LCP; specificare sempre width/height per evitare CLS. ``` ![...](/foto.avif) ``` ### font-display: swap (e ottimizzazione web font) **Perché conta.** font-display controlla come il browser gestisce il testo mentre il web font carica: il valore swap mostra subito il testo con un font di fallback e lo sostituisce poi col font definitivo, evitando il FOIT (testo invisibile) e migliorando la velocita percepita. Va bilanciato perche lo swap puo causare un piccolo layout shift (CLS) se i font hanno metriche diverse; per questo si abbinano font-fallback con size-adjust o si precarica il font. _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Usare font-display: swap (od optional per evitare shift), servire WOFF2, sottoinsiemizzare i glifi, precaricare i font critici e definire fallback con size-adjust/ascent-override per minimizzare il CLS. ``` @font-face { font-family:'Inter'; src:url(/inter.woff2) format('woff2'); font-display:swap; } ``` ### Immagini dimensionate, responsive e formati moderni **Perché conta.** Immagini senza dimensioni esplicite causano layout shift (CLS), mentre immagini sovradimensionate sprecano banda e rallentano LCP: specificare width/height (o aspect-ratio) e servire la risoluzione giusta per il dispositivo via srcset/sizes evita entrambi i problemi. I formati moderni AVIF/WebP riducono molto il peso a parita di qualita rispetto a JPEG/PNG. Insieme migliorano stabilita visiva, performance, esperienza utente e consumo dati su mobile. _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità · Conversione — Priorità: Alta_ **Best practice.** Indicare sempre width/height; usare srcset+sizes (o <picture>) per servire dimensioni e formati adatti; preferire AVIF/WebP con fallback; comprimere e usare lazy loading sotto il fold. ``` ![...](foto.jpg) ``` ### Mobile-first / responsive design **Perché conta.** Google usa l’indicizzazione mobile-first: indicizza e valuta principalmente la versione mobile del sito, quindi contenuti, link e dati strutturati devono essere presenti e accessibili anche su mobile, pena perdita di ranking. Un design responsive (un solo HTML che si adatta) garantisce parita di contenuto, evita problemi di URL separati e offre una buona esperienza su qualsiasi schermo, riducendo bounce rate e favorendo la conversione. E anche piu efficiente da crawlare rispetto a versioni mobile/desktop separate. _Motivazioni: Crawler/Indicizzazione · Ranking · Esperienza utente · Conversione — Priorità: Alta_ **Best practice.** Adottare un design responsive con CSS fluido e media query (mobile-first), assicurando contenuto e markup identici tra desktop e mobile; testare con il test di compatibilita mobile e con rendering di Googlebot. ``` @media (min-width: 768px) { .grid { grid-template-columns: repeat(3,1fr); } } ``` ### <meta name=”viewport”> **Perché conta.** Il meta viewport indica al browser mobile come scalare e dimensionare la pagina rispetto alla larghezza del dispositivo: senza di esso i dispositivi assumono un viewport desktop e mostrano la pagina rimpicciolita/da zoomare, rovinando l’esperienza mobile e segnalando una pagina non mobile-friendly (con impatto su usabilita e ranking mobile-first). E un requisito di base per qualsiasi layout responsive e per l’accessibilita su mobile. _Motivazioni: Esperienza utente · Rendering/Compatibilità · Ranking · Accessibilità — Priorità: Alta_ **Best practice.** Inserire nel <head> width=device-width, initial-scale=1; non disabilitare lo zoom utente (evitare user-scalable=no e maximum-scale=1) per non danneggiare l’accessibilita. ``` ``` ### Tap target adeguati (dimensione e spaziatura) **Perché conta.** Su mobile gli elementi interattivi (link, bottoni) devono essere abbastanza grandi e distanziati per essere toccati con il dito senza errori: target troppo piccoli o ravvicinati causano tap errati, frustrazione e abbandono, e vengono segnalati come problema di usabilita mobile. Tap target corretti migliorano esperienza utente, accessibilita (utenti con mobilita ridotta) e tasso di conversione su mobile. _Motivazioni: Esperienza utente · Accessibilità · Conversione — Priorità: Media_ **Best practice.** Dimensionare i tap target ad almeno ~48x48px (CSS) con spaziatura adeguata (~8px) tra elementi cliccabili; ampliare l’area cliccabile con padding piuttosto che con margini. ``` .btn { min-height: 48px; min-width: 48px; padding: 12px 16px; } ``` ### Critical CSS (CSS critico inline) **Perché conta.** Estrarre e inlinare nel <head> solo il CSS necessario a renderizzare l’above-the-fold elimina la dipendenza da un foglio di stile esterno bloccante per il primo paint: cosi il browser disegna subito il contenuto visibile, migliorando FCP/LCP e velocita percepita, mentre il CSS completo viene caricato in modo asincrono. E una tecnica avanzata e potente contro il render-blocking, da gestire con cura per evitare CSS critico troppo pesante (gonfia l’HTML). _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Generare automaticamente il critical CSS dell’above-the-fold e inlinarlo nel <head>, caricando il resto in modo non bloccante; mantenere l’inline ridotto e rigenerarlo quando cambia il design. ``` ``` ### HTTP/2 e HTTP/3 (QUIC) **Perché conta.** I protocolli moderni eliminano colli di bottiglia di HTTP/1.1: HTTP/2 introduce multiplexing (molte richieste su una sola connessione, senza head-of-line blocking applicativo), compressione degli header e prioritizzazione, mentre HTTP/3 sposta tutto su QUIC/UDP riducendo la latenza di handshake ed eliminando l’head-of-line blocking a livello di trasporto, con grandi vantaggi su reti mobili instabili. Il risultato e un caricamento di molte risorse piu veloce, migliorando performance ed esperienza utente. _Motivazioni: Performance · Esperienza utente — Priorità: Bassa_ **Best practice.** Abilitare HTTP/2 (e HTTP/3 dove supportato dal CDN/server) con TLS moderno; con HTTP/2+ evitare lo sharding dei domini e la concatenazione eccessiva, perche il multiplexing rende controproducenti questi vecchi workaround. ``` Alt-Svc: h3=":443"; ma=86400 ``` ## 9. GEO/AI, E-E-A-T, Local & contenuto ### Passaggi answer-ready / auto-conclusivi (citabili dalle AI) **Perché conta.** I sistemi generativi (AI Overview, ChatGPT, Perplexity) non leggono la pagina intera: estraggono e citano singoli passaggi che rispondono in modo autosufficiente alla query. Un paragrafo che apre con la risposta diretta (40-60 parole), senza dipendere dal contesto precedente, ha molte più probabilita di essere selezionato come grounding citato; questo si traduce in visibilita nelle risposte AI e, di riflesso, in autorita topica e traffico referral qualificato verso il dominio. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Apri ogni sezione con una risposta diretta e autoconclusiva (chi/cosa/quando in 1-3 frasi), poi approfondisci; usa un’entita o un dato verificabile per frase così che il passaggio resti citabile estratto dal contesto. ``` ## Quanto costa un sito WordPress? Un sito WordPress costa in media 800-3.000 euro per una vetrina aziendale nel 2026, esclusi hosting (50-200 euro/anno) e manutenzione. Il prezzo dipende da numero di pagine, e-commerce e personalizzazione del tema. ``` ### FAQ strutturate per AI Overview e featured snippet **Perché conta.** Coppie domanda/risposta esplicite mappano direttamente sul formato con cui i motori generativi e gli snippet costruiscono le risposte: i crawler le associano alle query a coda lunga e in forma di domanda, le AI le riusano come blocchi citabili e migliorano l’esperienza utente offrendo la risposta a colpo d’occhio. Attenzione pero: dal 2023 Google mostra FAQ rich result quasi solo per siti governativi/sanitari, quindi il valore principale oggi è il contenuto citabile, non il rich snippet. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Scrivi FAQ con domande reali (prese da ‘People Also Ask’ / reverse-prompt) e risposte brevi e complete; marca con schema FAQPage solo se le domande sono visibili in pagina e non duplicate, senza aspettarti il rich result al di fuori delle nicchie ammesse. ``` ``` ### llms.txt e versioni testuali/markdown per crawler AI **Perché conta.** I crawler AI (GPTBot, PerplexityBot, ClaudeBot, Google-Extended) digeriscono meglio testo pulito che HTML pieno di markup, script e UI. Esporre una versione markdown/testuale dei contenuti chiave (o un indice llms.txt) riduce il rumore di parsing, aumenta la probabilita di estrazione/citazione corretta e dà controllo su cosa offrire agli LLM; va inteso come proposta emergente (non standard ufficiale Google) complementare, non sostitutiva, di un buon HTML semantico. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Performance — Priorità: Media_ **Best practice.** Pubblica /llms.txt con titolo, descrizione e link agli URL prioritari; offri per gli articoli chiave un endpoint testuale (es. .md) con solo contenuto, e decidi consapevolmente in robots.txt quali bot AI ammettere (GPTBot, Google-Extended). ``` # /llms.txt # Nome Sito — guida per LLM > Sintesi del sito in una riga. ## Pagine chiave - [Servizi](https://esempio.it/servizi): cosa offriamo - [Guida prezzi](https://esempio.it/prezzi.md): listino in testo ``` ### Controllo accesso crawler AI (robots.txt: GPTBot, Google-Extended, PerplexityBot) **Perché conta.** Bloccare o ammettere i bot AI è una scelta strategica: ammetterli aumenta la probabilita di essere citati nelle risposte generative (visibilita GEO) ma cede i contenuti all’addestramento; bloccarli protegge l’IP editoriale ma esce dalle citazioni. Va deciso in modo esplicito perché impatta crawl budget, visibilita nelle AI e tutela del contenuto, e perché alcuni bot (PerplexityBot live) servono risposte in tempo reale citando la fonte. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Sicurezza — Priorità: Media_ **Best practice.** Distingui i bot in robots.txt: tieni aperti i bot ‘live/RAG’ che citano la fonte (PerplexityBot) e valuta Google-Extended/GPTBot caso per caso; ricorda che robots.txt è un’indicazione, non un blocco tecnico. ``` User-agent: GPTBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: PerplexityBot Allow: / ``` ### Copertura entita e topical authority (cluster tematici) **Perché conta.** I motori e i sistemi generativi valutano la competenza non sulla singola keyword ma sulla copertura completa di un’entita e dei suoi sotto-temi (clustering semantico dei passaggi attorno a un centroide, come nei brevetti di thematic search). Coprire in modo esaustivo entita correlate consolida l’autorita topica del dominio, aiuta i crawler a capire di cosa tratta il sito e migliora il ranking sull’intero cluster anziché su singole URL isolate. _Motivazioni: GEO/AI · Ranking · Crawler/Indicizzazione · Link juice/PageRank — Priorità: Alta_ **Best practice.** Costruisci topic cluster pillar+supporto coprendo tutte le entita e domande del tema; usa un’analisi vettoriale per individuare i gap di copertura e collega internamente i contenuti dello stesso cluster. ``` Pillar: "Guida al marketing locale" ├─ Cluster: Google Business Profile ├─ Cluster: recensioni e reputazione └─ Cluster: SEO local on-page (tutti i supporti linkano al pillar e tra loro) ``` ### Allineamento all’intento di ricerca (search intent) **Perché conta.** Un contenuto che non rispetta l’intento dominante della query (informazionale, commerciale, transazionale, navigazionale) non posiziona, per quanto sia ottimizzato: i motori imparano dal comportamento sulla SERP quale formato soddisfa l’utente. Allineare formato e profondita all’intento riduce pogo-sticking, migliora i segnali di soddisfazione e aumenta sia ranking che conversione; per le AI, un intento chiaro rende il passaggio più facilmente abbinabile alla domanda. _Motivazioni: Ranking · Esperienza utente · Conversione · GEO/AI — Priorità: Alta_ **Best practice.** Prima di scrivere, analizza la SERP attuale della keyword: replica il tipo di contenuto che già posiziona (guida vs scheda prodotto vs lista) e assicurati che la pagina soddisfa l’intento prevalente, non quello che immagini. ``` Query "miglior CRM" → intento commerciale-comparativo → tabella comparativa + pro/contro, NON una scheda di vendita di un singolo CRM. ``` ### Freschezza e aggiornamento dei contenuti (content decay) **Perché conta.** La freschezza è un segnale di qualita sia per i ranking (query ‘query deserves freshness’, dati e prezzi datati) sia per la selezione delle fonti da parte delle AI (i sistemi di generative summaries pesano la freschezza tra i segnali di scelta della fonte). Contenuti obsoleti perdono posizioni, citazioni e fiducia; un audit periodico del decadimento intercetta le pagine in calo prima che svaniscano e mantiene viva l’autorita. _Motivazioni: Ranking · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Mostra date di pubblicazione e ultimo aggiornamento reali; rivedi periodicamente i contenuti che calano (content decay audit), aggiorna dati/anno/esempi e aggiorna dateModified solo a fronte di una revisione sostanziale, non cosmetica. ``` Aggiornato il 20 maggio 2026 ``` ### Segnale Author: autore identificato con byline e bio **Perché conta.** L’autorialita è un pilastro E-E-A-T: attribuire il contenuto a una persona reale con competenza dimostrabile aumenta la fiducia di utenti e motori, è cruciale nelle nicchie YMYL (salute, finanza, legale) e aiuta le AI a valutare l’affidabilita della fonte da citare. Una byline cliccabile verso una bio ricca collega esperienza ed expertise all’entita-autore riconoscibile. _Motivazioni: GEO/AI · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Firma ogni articolo con un autore reale collegato a una pagina autore con bio, credenziali, foto e link ai profili; per i temi YMYL evidenzia esperienza diretta ed eventuale revisione di un esperto. ``` [Mario Rossi](/autori/mario-rossi) ``` ### Fonti, citazioni e link esterni autorevoli (Trust) **Perché conta.** Citare fonti primarie e autorevoli con link in uscita è un segnale di trustworthiness e di esperienza: dimostra che le affermazioni sono verificabili (lo stesso principio di grounding/verifica dei brevetti sulle generative summaries) e dà all’utente e ai motori il modo di controllare i dati. Aumenta la credibilita del contenuto, riduce il rischio percepito di disinformazione e rafforza l’E-E-A-T complessivo della pagina. _Motivazioni: GEO/AI · Ranking · Esperienza utente · Accessibilità — Priorità: Media_ **Best practice.** Supporta affermazioni e dati con link a fonti primarie autorevoli (studi, enti, documentazione ufficiale); cita la fonte e l’anno nel testo e collega il dato al riferimento esatto. ``` Secondo l'[ISTAT (2025)](https://www.istat.it/.../), il fatturato del settore è cresciuto del 4,2%. ``` ### Pagine About e Contact (trust di sito) **Perché conta.** Le pagine Chi siamo e Contatti sono tra i primi segnali di trust valutati: dimostrano che dietro il sito c’è un’entita reale, raggiungibile e responsabile, requisito esplicito per i siti YMYL e per la fiducia generale. Forniscono ai motori e alle AI l’entita-organizzazione da disambiguare e collegano il brand al Knowledge Graph, migliorando reputazione e conversione. _Motivazioni: GEO/AI · Ranking · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Pubblica una pagina About con storia, persone e missione e una pagina Contact con indirizzo fisico, telefono ed email reali; marca l’organizzazione con schema Organization e collega i profili ufficiali via sameAs. ``` ``` ### NAP consistente (Name, Address, Phone) **Perché conta.** Per la SEO local la coerenza di nome, indirizzo e telefono su sito, Google Business Profile e directory è un segnale di affidabilita usato per validare l’esistenza e la posizione dell’attivita: incongruenze (abbreviazioni, vecchi numeri) confondono i crawler, frammentano i segnali di citazione e indeboliscono il ranking locale. Un NAP identico ovunque consolida l’entita-attivita e migliora la fiducia dell’utente che ti contatta. _Motivazioni: Ranking · Crawler/Indicizzazione · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Usa esattamente la stessa stringa NAP (stesso formato, stessa via, stesso prefisso) su tutto il sito e in ogni directory; replicala nel footer e marcala con schema LocalBusiness/PostalAddress. ``` Via Roma 10, Napoli +39 081 1234567 ``` ### Google Business Profile ottimizzato **Perché conta.** Il profilo Google Business è il fulcro della visibilita nel local pack e su Maps: categoria, orari, foto, post e prossimita determinano in larga parte il ranking locale, spesso più della pagina web stessa. Un profilo completo e attivo intercetta utenti ad alto intento transazionale (chiamate, indicazioni, visite) e alimenta le AI con dati strutturati sull’attivita, incidendo direttamente su conversione e fiducia. _Motivazioni: Ranking · Conversione · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Compila ogni campo (categoria primaria precisa, servizi, orari, area servita), aggiungi foto reali e aggiornate, pubblica post e rispondi a tutte le recensioni; mantieni il NAP identico a quello del sito. ### Schema LocalBusiness (dati strutturati attivita locale) **Perché conta.** Il markup LocalBusiness comunica ai crawler in modo esplicito nome, indirizzo, coordinate, orari e tipologia dell’attivita, riducendo l’ambiguita di interpretazione e abilitando rich result e knowledge panel. Rafforza il collegamento tra sito e profilo locale, aiuta le AI a recuperare dati affidabili sull’attivita e supporta il ranking nel local pack quando coerente con GBP e NAP. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Implementa LocalBusiness (o sottotipo specifico es. Restaurant) con address, geo, openingHoursSpecification e telephone coerenti col sito; usa JSON-LD e valida con il Rich Results Test. ``` ``` ### Recensioni e gestione reputazione **Perché conta.** Volume, freschezza, valutazione media e risposte alle recensioni sono segnali di reputazione e trust che incidono sul ranking locale e, soprattutto, sulla decisione dell’utente di scegliere l’attivita (conversione). Le recensioni alimentano contenuto fresco e ricco di entita/linguaggio naturale che le AI possono sintetizzare; rispondere a tutte, incluse le negative, dimostra cura e affidabilita. _Motivazioni: Ranking · Conversione · Esperienza utente · GEO/AI — Priorità: Media_ **Best practice.** Sollecita recensioni reali in modo continuo e conforme alle policy, rispondi a ognuna in modo professionale; non usare schema Review auto-attribuito sul tuo sito per stelle nei risultati (Google lo ignora/penalizza per le self-serving reviews). ### Contenuto duplicato e thin content **Perché conta.** Pagine duplicate o di scarso valore diluiscono il crawl budget, frammentano i segnali di ranking tra URL concorrenti e abbassano la qualita percepita del dominio; le AI tendono a ignorarle come fonti. Consolidare il duplicato (canonical/redirect) e arricchire o rimuovere il thin content concentra link juice e autorita sulle pagine giuste e migliora l’esperienza dell’utente che trova risposte complete. _Motivazioni: Crawler/Indicizzazione · Ranking · Link juice/PageRank · Esperienza utente — Priorità: Alta_ **Best practice.** Identifica duplicati e pagine sottili; consolida con canonical o 301 verso la versione migliore, espandi le pagine recuperabili e applica noindex o rimozione a quelle senza valore. ``` ``` ### Internal linking tematico (cluster e flusso di juice) **Perché conta.** I link interni a tema collegano i contenuti dello stesso cluster, distribuiscono il PageRank verso le pagine prioritarie e comunicano ai crawler la struttura semantica e le relazioni tra entita; per le AI, i link interni con anchor descrittiva creano un grafo di contesto che aiuta a capire la rilevanza di ogni passaggio. Una rete interna tematica rafforza l’autorita topica e fa sì che ogni pagina riceva juice, non solo la home. _Motivazioni: Link juice/PageRank · Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Collega i contenuti per affinita semantica (verificata su vettori/embedding, non solo per keyword) con anchor text descrittiva e varia; fai puntare i supporti al pillar e i pillar alle pagine di conversione. ``` Per impostare la scheda locale, vedi la [guida al Google Business Profile](/guida-google-business-profile). ``` ### Keyword cannibalization **Perché conta.** Quando più pagine competono per la stessa query, i motori non sanno quale premiare: i segnali (link, click, autorita) si dividono, le posizioni oscillano e nessuna pagina raggiunge il potenziale. La cannibalizzazione spreca link juice e crawl budget e confonde anche le AI nella scelta della fonte; risolverla consolida i segnali su un’unica URL e ne stabilizza/migliora il ranking. _Motivazioni: Ranking · Link juice/PageRank · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Mappa keyword→URL una a una; in caso di sovrapposizione consolida (merge + 301), differenzia l’intento delle pagine o scegli la pagina canonica e reindirizza/declassa le altre. ``` site:esempio.it "scarpe da corsa" → se compaiono 3 URL per la stessa intent, unisci in una sola guida e 301 le altre. ``` ## 10. Altri controlli importanti ### <meta http-equiv=”refresh”> (redirect/refresh lato client) — da evitare **Perché conta.** Il meta refresh sposta o ricarica la pagina lato client invece di usare un redirect HTTP: i crawler lo interpretano in modo inaffidabile (Google lo tratta come redirect “debole” e ne sconsiglia l’uso), spezza il pulsante Indietro del browser danneggiando l’esperienza utente, e trasferisce link juice in modo incerto rispetto a un 301 server-side. È anche un problema di accessibilità (un refresh a tempo disorienta gli utenti). _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Link juice/PageRank · Accessibilità — Priorità: Media_ **Best practice.** Non usare il meta refresh per redirezionare: implementa redirect 301 (permanenti) o 302 (temporanei) a livello server. Riserva il refresh solo a casi limite documentati e, se inevitabile, evita ritardi a tempo. ``` HTTP/1.1 301 Moved Permanently Location: https://esempio.it/nuova ``` ### Relazione tra og:url e <link rel=”canonical”> (coerenza dei segnali URL) **Perché conta.** og:url indica ai social/scraper l’URL canonico per il social graph, mentre il canonical indica ai motori la versione preferita per l’indicizzazione: se i due divergono (es. canonical senza parametri ma og:url con parametri di tracking) si inviano segnali contraddittori che confondono crawler e consolidamento dei segnali, e possono frammentare condivisioni e metriche. La coerenza tra i due rafforza il consolidamento del link juice sull’URL giusto. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Fai puntare og:url e rel=canonical alla stessa URL assoluta, pulita e auto-referenziale (senza parametri di sessione/tracking), coerente con il dominio canonicalizzato. ``` ``` ### hreflang x-default **Perché conta.** Senza x-default i motori non sanno quale versione servire a utenti la cui lingua/regione non rientra in nessun hreflang dichiarato, generando selezioni errate nei risultati internazionali e una peggiore esperienza per il pubblico non mappato. È il fallback che completa un set hreflang e ne previene errori di reciprocità. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Aggiungi sempre un <link rel=”alternate” hreflang=”x-default”> che punti alla pagina di selezione lingua o alla versione internazionale/di default; assicura che ogni URL del cluster elenchi tutte le alternative (incluso x-default) in modo reciproco e con URL assoluti. ``` ``` ### HSTS (Strict-Transport-Security header) **Perché conta.** HSTS forza il browser a usare solo HTTPS per il dominio, eliminando il redirect HTTP→HTTPS iniziale (più veloce, meno catene di redirect da seguire per i crawler) e proteggendo da attacchi di downgrade/man-in-the-middle. È un segnale di sito sicuro e ben configurato che supporta l’affidabilità (Trust) percepita. _Motivazioni: Sicurezza · Performance · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Imposta l’header Strict-Transport-Security con max-age elevato e includeSubDomains solo dopo aver verificato che tutto il sito (sottodomini compresi) sia raggiungibile in HTTPS; valuta l’inserimento nella preload list solo a configurazione stabile. ``` Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ``` ### Security headers (CSP, X-Content-Type-Options, Referrer-Policy) **Perché conta.** Header di sicurezza ben configurati proteggono gli utenti da XSS/sniffing e migliorano il Trust del sito; una Referrer-Policy corretta preserva il passaggio del referrer per analytics e attribuzione, mentre X-Content-Type-Options: nosniff evita interpretazioni errate dei tipi MIME che possono rompere il rendering o creare vulnerabilità. Non sono fattori di ranking diretti ma supportano sicurezza, affidabilità ed esperienza. _Motivazioni: Sicurezza · Rendering/Compatibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Aggiungi via header HTTP almeno X-Content-Type-Options: nosniff, una Referrer-Policy ragionevole (es. strict-origin-when-cross-origin) e una CSP testata in report-only prima dell’enforcement per non bloccare risorse legittime. ``` X-Content-Type-Options: nosniff Referrer-Policy: strict-origin-when-cross-origin Content-Security-Policy: default-src 'self' ``` ### Pagina 404 personalizzata (utile + stato corretto) **Perché conta.** Una 404 personalizzata trattiene l’utente offrendo ricerca, link alle pagine principali e percorsi di recupero (esperienza e conversione), mentre il codice di stato 404/410 corretto comunica ai crawler che la risorsa non esiste evitando l’indicizzazione di pagine vuote. Distribuire link utili dalla 404 aiuta anche il flusso interno verso pagine valide. _Motivazioni: Esperienza utente · Crawler/Indicizzazione · Conversione · Link juice/PageRank — Priorità: Media_ **Best practice.** Servi un template 404 con messaggio chiaro, barra di ricerca e link alle sezioni chiave, restituendo realmente HTTP 404 (o 410 per contenuti rimossi definitivamente); non reindirizzare massivamente le 404 alla home (genera soft 404). ``` HTTP/1.1 404 Not Found ``` ### Link interni e contenuto generati via JavaScript (crawlabilità del JS) **Perché conta.** I link inseriti solo in onclick/JS o i contenuti renderizzati lato client possono non essere scoperti finché Google non esegue il rendering (seconda ondata, con ritardo), e altri crawler/AI spesso non eseguono JS affatto: i link non in <a href> non passano PageRank in modo affidabile e i contenuti JS-only rischiano di restare fuori dall’indice. Impatta scoperta, indicizzazione e distribuzione del juice. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Rendering/Compatibilità · GEO/AI — Priorità: Alta_ **Best practice.** Usa veri <a href=”…”> per ogni link importante (no navigazione solo via onclick), e rendi disponibile il contenuto critico nell’HTML iniziale tramite SSR/SSG o idratazione progressiva; evita di dipendere dall’esecuzione JS per testo e link indicizzabili. ``` [Scarpe](/categoria/scarpe) Scarpe ``` ### Rendering: SSR / SSG / prerendering per siti JavaScript **Perché conta.** Per SPA e siti JS-heavy, fornire HTML già renderizzato lato server riduce la dipendenza dal rendering differito di Googlebot e abilita i crawler AI/social (che spesso non eseguono JS) a leggere contenuti e meta: migliora velocità di indicizzazione, LCP/TTFB percepiti e la citabilità da parte di motori generativi. Riguarda indicizzazione, performance e GEO/AI. _Motivazioni: Crawler/Indicizzazione · Performance · GEO/AI · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Adotta SSR o pre-rendering (statico/dinamico) per le pagine indicizzabili, assicurando che HTML, meta tag, canonical e dati strutturati siano presenti nella risposta iniziale senza richiedere esecuzione JS; verifica con il test “HTML reso” e con cURL/disattivando il JS. ### Contenuto in <iframe> e <embed> **Perché conta.** Il contenuto in un iframe appartiene a un documento separato e generalmente non viene attribuito alla pagina che lo ospita ai fini dell’indicizzazione: testo e link dentro l’iframe non contano come contenuto/link della pagina padre. Affidare contenuto principale a iframe rischia di renderlo invisibile per ranking e per i crawler AI. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Bassa_ **Best practice.** Non inserire contenuto principale o link SEO-critici in iframe; usa l’iframe solo per embed esterni (mappe, video) e fornisci titolo/contesto in pagina. Se necessario, esponi gli stessi contenuti anche come HTML nativo della pagina. ``` ``` ### Dati strutturati Event **Perché conta.** Lo schema Event abilita rich result per eventi (date, luogo, modalità online/offline, biglietti) in Ricerca e in superfici dedicate, aumentando visibilità e CTR e fornendo a motori e AI dati machine-readable per rispondere a query su eventi. Senza markup, queste informazioni restano solo testo non strutturato. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI · Conversione — Priorità: Bassa_ **Best practice.** Marca gli eventi con Event (name, startDate/endDate con fuso, eventStatus, eventAttendanceMode, location/VirtualLocation, offers); mantieni i dati strutturati coerenti col contenuto visibile e aggiorna stato/date in caso di rinvio o annullamento. ``` {"@context":"https://schema.org","@type":"Event","name":"Webinar SEO","startDate":"2026-07-10T18:00+02:00","eventAttendanceMode":"https://schema.org/OnlineEventAttendanceMode","location":{"@type":"VirtualLocation","url":"https://esempio.it/live"}} ``` ### Speakable (SpeakableSpecification) per ricerca vocale **Perché conta.** Speakable indica quali parti della pagina sono adatte alla lettura vocale (assistenti/TTS), aiutando le superfici voice e potenzialmente le risposte generative a identificare i passaggi sintetizzabili. È un segnale di struttura answer-ready che si integra con i contenuti auto-conclusivi citabili dalle AI. _Motivazioni: GEO/AI · Accessibilità · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Applica Speakable (tramite cssSelector o xpath) solo a sezioni brevi e auto-conclusive (es. sintesi/risposta diretta) di contenuti tipo news; non marcare l’intero articolo e mantieni coerenza col testo visibile. ``` {"@context":"https://schema.org","@type":"WebPage","speakable":{"@type":"SpeakableSpecification","cssSelector":[".risposta-sintetica"]}} ``` ### Landmark ARIA e accessibilità (ruoli, aria-label, skip link) **Perché conta.** Ruoli/landmark coerenti con i tag semantici, etichette ARIA e skip link migliorano la navigazione per screen reader (accessibilità) e rafforzano la chiarezza strutturale che i crawler usano per capire le aree della pagina; un sito accessibile riduce frizioni, amplia il pubblico e sostiene indirettamente engagement e conversioni. Da usare a complemento, non in sostituzione, dell’HTML semantico. _Motivazioni: Accessibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Preferisci sempre l’HTML semantico nativo (<nav>, <main>, <header>); aggiungi ARIA solo dove serve (es. aria-label per più <nav>, aria-current sul link attivo, skip link a inizio pagina). Non duplicare ruoli già impliciti nei tag. ``` [Salta al contenuto](#main) … … ``` ### Sitemap video (video sitemap / markup VideoObject in sitemap) **Perché conta.** Una sitemap video (o le estensioni video nella sitemap) segnala a Google contenuti video con metadati (titolo, descrizione, thumbnail, durata, URL del player/contenuto), favorendone scoperta e indicizzazione e l’eleggibilità a risultati video. Complementa il VideoObject on-page accelerando la crawlabilità dei media. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Includi i video in una sitemap con i campi obbligatori (thumbnail_loc, title, description e content_loc o player_loc); mantieni i metadati coerenti col VideoObject in pagina e aggiorna alla rimozione/scadenza dei video. ``` https://esempio.it/video …/thumb.jpg Titolo… …/video.mp4 ``` ### Sitemap news (Google News) e markup NewsArticle **Perché conta.** Per siti editoriali, la sitemap news comunica gli articoli pubblicati nelle ultime 48 ore con data e testata, accelerando la scoperta e l’idoneità a Google News/Top Stories dove la velocità di indicizzazione è critica. Si integra con NewsArticle e con la freschezza dei contenuti. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Genera una news sitemap separata con solo articoli recenti (max 48h, fino a 1000 URL), includendo news:publication (name, language) e news:publication_date; rimuovi gli articoli più vecchi di 2 giorni e abbinala a markup NewsArticle. ``` https://esempio.it/notizia Testata it 2026-06-01 Titolo ``` ### Last-Modified / If-Modified-Since e <lastmod> in sitemap **Perché conta.** Un Last-Modified accurato (e il supporto a If-Modified-Since con risposta 304) permette ai crawler di rilevare se una pagina è cambiata senza riscaricarla, risparmiando crawl budget e velocizzando il refresh dei contenuti aggiornati; un <lastmod> affidabile in sitemap guida le ri-visite verso le pagine effettivamente modificate. Tocca crawlabilità, performance e freschezza. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Media_ **Best practice.** Imposta Last-Modified coerente con l’effettiva modifica del contenuto e gestisci correttamente le richieste condizionali (304 Not Modified); popola <lastmod> in sitemap solo con date veritiere di aggiornamento sostanziale, non a ogni rigenerazione. ``` Last-Modified: Mon, 01 Jun 2026 10:00:00 GMT …2026-06-01 ``` ### QAPage e Q&A markup (vs FAQPage) **Perché conta.** Per pagine di domande e risposte generate dagli utenti (forum, community), QAPage è il tipo corretto e distinto da FAQPage (riservato alle FAQ redatte dall’editore): usare il markup giusto evita azioni manuali per uso improprio dei dati strutturati e abilita l’eleggibilità ai relativi rich result. È una questione di correttezza e conformità delle linee guida. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Bassa_ **Best practice.** Usa QAPage solo dove c’è una singola domanda con risposte multiple proposte dagli utenti (mainEntity di tipo Question con acceptedAnswer/suggestedAnswer); usa FAQPage solo per FAQ ufficiali del sito, mai per contenuti pubblicitari o di vendita. ``` {"@context":"https://schema.org","@type":"QAPage","mainEntity":{"@type":"Question","name":"Come...?","acceptedAnswer":{"@type":"Answer","text":"..."}}} ``` ### BreadcrumbList in JSON-LD allineato alle breadcrumb visibili **Perché conta.** Il markup BreadcrumbList consente a Google di mostrare il percorso a briciole nello snippet al posto dell’URL grezzo, migliorando comprensione della gerarchia da parte dei crawler e CTR per gli utenti; deve rispecchiare le breadcrumb visibili in pagina per non incorrere in incoerenza dei dati strutturati. Si lega sia ai dati strutturati sia alla navigazione interna. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Genera BreadcrumbList con itemListElement ordinati (position, name, item URL) coerenti al 100% con la breadcrumb HTML visibile; non includere passi inesistenti né la pagina corrente come link. ``` {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://esempio.it/"}]} ``` ### Dimensione e contenuto del DOM / peso della pagina (page weight, # nodi) **Perché conta.** Un DOM eccessivamente grande e pagine molto pesanti rallentano rendering e Core Web Vitals (LCP/INP), aumentano l’uso di memoria su mobile e possono ostacolare il rendering completo da parte dei crawler; pagine più leggere costano meno crawl budget e offrono un’esperienza migliore. Impatta performance, esperienza e indicizzazione. _Motivazioni: Performance · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Mantieni il DOM contenuto (linea guida indicativa: evitare migliaia di nodi e nesting profondo), limita il peso totale, usa paginazione/virtualizzazione per liste enormi e rimuovi markup superfluo; monitora con Lighthouse. ### PWA / Web App Manifest e installabilità **Perché conta.** Il manifest (con name, icone, theme_color, display) abilita l’installazione come app e una migliore integrazione mobile, rafforzando engagement e ritorni; pur non essendo un fattore di ranking diretto, supporta esperienza utente mobile e coerenza del branding insieme a theme-color e favicon. Va distinto dai segnali di ranking veri e propri. _Motivazioni: Esperienza utente · Performance · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Fornisci un manifest valido referenziato nel <head>, con icone in più dimensioni e theme_color coerente; non aspettarti benefici diretti di ranking, ma migliori metriche di engagement su mobile. ``` ``` ### Gestione dei contenuti duplicati cross-domain e scraping/syndication **Perché conta.** Quando lo stesso contenuto è ripubblicato su altri domini (syndication) o copiato da scraper, senza un canonical cross-domain o un accordo di attribuzione il motore può attribuire ranking e link juice alla copia invece che all’originale, cannibalizzando visibilità e autorità. È un tema di indicizzazione, consolidamento dei segnali e Trust. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Media_ **Best practice.** Per i contenuti dati in syndication, chiedi un rel=canonical cross-domain verso l’originale (o almeno un link attribuito); pubblica per primo sull’originale e usa la Search Console per monitorare la corretta attribuzione. ``` ``` ### Internazionalizzazione: struttura ccTLD / sottodominio / sottocartella + geotargeting **Perché conta.** La scelta tra ccTLD (.it, .fr), sottodomini o sottocartelle determina come i motori associano il sito a un Paese e come si distribuisce l’autorità: le sottocartelle concentrano il link juice su un unico dominio, i ccTLD danno un forte segnale geografico ma frammentano l’autorità. Va coordinata con hreflang per servire la versione giusta agli utenti corretti. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking · Esperienza utente — Priorità: Bassa_ **Best practice.** Scegli una struttura coerente (spesso sottocartelle per lingua su un dominio principale per consolidare l’autorità), abbinala a hreflang reciproci con x-default ed evita redirect automatici basati solo su IP che bloccano i crawler. ``` esempio.com/it/ esempio.com/en/ (sottocartelle) vs esempio.it / esempio.fr (ccTLD) ``` ### Markup prezzo/disponibilità avanzato (shippingDetails, MerchantReturnPolicy, priceValidUntil) **Perché conta.** Per l’e-commerce, arricchire Offer con disponibilità, validità prezzo, spese di spedizione e politica di reso abilita rich result più completi (anche nelle schede prodotto e in superfici shopping) e fornisce a motori e AI dati accurati, riducendo discrepanze che generano warning in Search Console. Migliora visibilità, fiducia e conversione. _Motivazioni: Crawler/Indicizzazione · Ranking · Conversione · GEO/AI — Priorità: Media_ **Best practice.** In Offer specifica price, priceCurrency, availability e priceValidUntil; aggiungi shippingDetails e hasMerchantReturnPolicy quando disponibili, mantenendo i valori sincronizzati col prezzo/stock reali mostrati in pagina. ``` {"@type":"Offer","price":"49.90","priceCurrency":"EUR","availability":"https://schema.org/InStock","priceValidUntil":"2026-12-31"} ``` ### Profile/Author bio collegata (Person + knowsAbout, E-E-A-T) **Perché conta.** Collegare l’autore a una vera pagina profilo con Person (sameAs ai profili ufficiali, knowsAbout, credenziali) rafforza i segnali di esperienza/autorevolezza che alimentano E-E-A-T e la fiducia di utenti e motori, e fornisce alle AI un’entità autore identificabile e citabile. Va oltre la semplice byline collegandola al grafo delle entità. _Motivazioni: Ranking · GEO/AI · Esperienza utente · Link juice/PageRank — Priorità: Media_ **Best practice.** Crea pagine autore reali con bio, foto, sameAs ai profili autorevoli e markup Person collegato via @id all’author dell’Article; mantieni coerenza tra byline visibile, pagina profilo e dati strutturati. ``` {"@type":"Person","@id":"https://esempio.it/autori/mario#person","name":"Mario Rossi","knowsAbout":["SEO"],"sameAs":["https://www.linkedin.com/in/mariorossi"]} ``` ### Cookie banner / interstitial e contenuti intrusivi **Perché conta.** Banner cookie a tutto schermo, pop-up e interstitial intrusivi che coprono il contenuto principale subito dopo l’arrivo da ricerca degradano l’esperienza mobile e sono esplicitamente scoraggiati da Google (intrusive interstitials); possono inoltre peggiorare CLS/INP e frenare le conversioni. Riguarda esperienza, performance e, indirettamente, ranking mobile. _Motivazioni: Esperienza utente · Performance · Ranking · Conversione — Priorità: Media_ **Best practice.** Usa cookie banner non intrusivi (barra/box che non oscura il contenuto), evita interstitial a tutto schermo subito dopo il click dalla SERP, e assicura che il consenso non blocchi crawl/rendering dei contenuti indicizzabili né causi layout shift. ### Coerenza tra contenuto per i crawler e per gli utenti (no cloaking) **Perché conta.** Mostrare a Googlebot un contenuto diverso da quello servito agli utenti (cloaking) viola le linee guida e può portare ad azioni manuali e deindicizzazione; tecniche di personalizzazione/A-B test devono restare neutre verso i crawler. È un tema di conformità, Trust e sicurezza dell’indicizzazione, particolarmente rilevante con rendering JS e geo/user-agent detection. _Motivazioni: Crawler/Indicizzazione · Ranking · Sicurezza — Priorità: Media_ **Best practice.** Servi a crawler e utenti lo stesso contenuto sostanziale; per A/B test usa redirect 302 e rel=canonical verso l’originale e non discriminare per user-agent Googlebot; evita reindirizzamenti o contenuti differenziati basati su geolocalizzazione che nascondano contenuto ai crawler. ### Date di pubblicazione e aggiornamento (datePublished / dateModified visibili e in markup) **Perché conta.** Esporre datePublished e dateModified (in pagina e in Article) aiuta Google a valutare la freschezza e a mostrare date corrette nello snippet, mentre per le AI fornisce un riferimento temporale per citare informazioni aggiornate; date incoerenti o gonfiate artificialmente minano il Trust. Collega freschezza dei contenuti e dati strutturati. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Mostra date di pubblicazione e ultimo aggiornamento veritiere, allineate ai campi datePublished/dateModified del markup Article; aggiorna dateModified solo a fronte di modifiche sostanziali, non cosmetiche. ``` {"@type":"Article","datePublished":"2026-01-10","dateModified":"2026-06-01"} ``` ### Accesso ai crawler bloccato da CSS/JS in robots.txt **Perché conta.** Bloccare in robots.txt le risorse CSS/JS necessarie al rendering impedisce a Google di renderizzare correttamente la pagina, con rischio di valutazione errata del layout, del mobile-friendliness e persino del contenuto caricato via JS. È un errore tecnico che danneggia indicizzazione e segnali di rendering/mobile. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Ranking — Priorità: Media_ **Best practice.** Consenti la scansione di CSS e JS essenziali al rendering (non fare Disallow su /assets, /css, /js critici); verifica il rendering con il test della pagina pubblicata in Search Console. ``` # evita di bloccare risorse di rendering User-agent: * Allow: /wp-content/themes/*.css Allow: /wp-includes/js/ ``` ### Markup di entità per AI/GEO: dichiarazione esplicita dell’entità principale (about / mentions / @id) **Perché conta.** Dichiarare l’entità principale della pagina (about) e le entità citate (mentions), collegandole al grafo via @id e sameAs, aiuta motori e AI a disambiguare il tema e ad associare il contenuto alle entità del Knowledge Graph, rafforzando la copertura entità e la citabilità generativa. Estende i dati strutturati verso il GEO. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Ranking — Priorità: Media_ **Best practice.** Usa about per l’entità centrale e mentions per quelle correlate, con sameAs verso fonti autorevoli (Wikipedia, Wikidata) e @id coerenti nel grafo del sito; mantieni l’entità dichiarata allineata al focus reale del contenuto. ``` {"@type":"Article","about":{"@type":"Thing","name":"SEO tecnico","sameAs":"https://it.wikipedia.org/wiki/Ottimizzazione_per_i_motori_di_ricerca"}} ``` ## Miti SEO da sfatare Credenze diffuse ma scorrette: evitarle ti fa risparmiare lavoro inutile. Il meta tag keywords NON è un fattore di ranking per Google: dichiarato non usato dal 2009; non inserirlo come tattica SEO (al massimo citarlo solo per spiegare che è ignorato/potenzialmente sfruttabile dai competitor per spiare le keyword). - Non esiste una ‘keyword density’ ottimale da rispettare: ripetere una percentuale prefissata di keyword è un mito; conta la pertinenza semantica e la copertura dell’intento, non un rapporto numerico, e lo stuffing è penalizzabile. - Google NON usa Google Analytics, il bounce rate o il ‘tempo sulla pagina’ di GA come fattore di ranking diretto: questi sono dati di terze parti non disponibili al ranking; non spacciare ‘metriche di engagement di GA’ come segnali SEO. - Non esiste un ‘Domain Authority’ ufficiale di Google: DA/DR sono metriche di tool di terze parti (Moz/Ahrefs), non punteggi usati da Google; evitare di presentarle come fattore di ranking. - Inviare la sitemap o usare lo strumento di indicizzazione NON garantisce l’indicizzazione né velocizza il ranking: la sitemap aiuta la scoperta, ma indicizzazione e posizionamento dipendono da qualità e altri segnali. - rel=canonical NON è un comando vincolante ma solo un suggerimento: Google può scegliere un canonical diverso; non trattarlo come garanzia, e non usarlo al posto di noindex o redirect quando serve escludere/spostare davvero una pagina. - noindex in robots.txt NON è supportato: la direttiva noindex va nel meta robots o nell’header X-Robots-Tag; un Disallow in robots.txt impedisce la scansione ma NON la deindicizzazione (l’URL può restare indicizzato senza snippet). - I Core Web Vitals sono un fattore di ranking minore e di ‘tie-break’, non un moltiplicatore magico: una pagina lenta ma molto pertinente può comunque posizionarsi; non promettere scalate di ranking solo migliorando i CWV. - HTTPS è un fattore di ranking molto leggero (tie-break), non un boost sostanziale: va adottato per sicurezza e fiducia, non aspettandosi salti di posizione. - Open Graph e Twitter Cards NON sono fattori di ranking diretti: servono all’anteprima social (CTR/condivisioni), non al posizionamento organico; vanno presentati come ottimizzazione di sharing. - I dati strutturati NON aumentano il ranking di per sé: abilitano i rich result (visibilità/CTR), ma non sono un fattore di posizionamento diretto; lo spam di markup non visibile o incoerente può causare azioni manuali. - Non esiste un ‘sandbox’ o un punteggio segreto che penalizza ogni sito nuovo per X mesi in modo deterministico: i siti nuovi semplicemente hanno meno segnali/storico; è un mito trattarlo come penalità garantita. - LSI keywords non sono un concetto usato da Google: ‘Latent Semantic Indexing’ è una tecnica datata e i ‘LSI keyword tool’ sono marketing; ciò che conta è la copertura semantica e delle entità, non liste di sinonimi LSI. - Più lungo NON significa automaticamente migliore: la lunghezza non è un fattore di ranking; la correlazione tra contenuti lunghi e ranking dipende dalla completezza nel soddisfare l’intento, non dal conteggio parole. - AMP non è (più) un requisito né un fattore di ranking per Top Stories: dal 2021 non è obbligatorio per i Top Stories e non dà boost; va considerato legacy e non raccomandato come pratica SEO attuale. - rel=prev/next NON è più usato da Google per la paginazione: il supporto è stato dismesso; non presentarlo come tecnica attiva, anche se altri motori/uso semantico possono ancora valerne la pena. - Il PageRank pubblico (toolbar) non esiste più dal 2016: non citare valori di PageRank visibili; il PageRank interno esiste come concetto di flusso del link juice, ma non come punteggio consultabile. - Aggiornare la data di ‘ultima modifica’ senza cambiare davvero il contenuto NON migliora la freschezza/ranking: il refresh cosmetico delle date è inefficace e può minare il Trust se ingannevole. - Submitting a Google/usare ‘crawl-delay’ su Googlebot non funziona: Google ignora la direttiva crawl-delay in robots.txt; la frequenza di scansione si gestisce con altri mezzi (server, Search Console), non con crawl-delay. ## Domande frequenti sulla checklist SEO ### Che cos’è una checklist SEO? È una lista strutturata di controlli tecnici, di struttura e di contenuto che rende una pagina leggibile dai motori di ricerca e dagli assistenti AI. Serve a non dimenticare nulla durante l’ottimizzazione e l’audit. ### Quanti elementi SEO bisogna controllare? Dipende dal sito, ma una checklist completa copre **oltre 180 elementi** su 9 aree (tag tecnici, struttura semantica, link, URL, media, dati strutturati, social, performance e GEO/AI). Non sono tutti ugualmente urgenti: si lavora per priorità. ### Da dove conviene iniziare? Dalle voci a priorità Alta: codifica e viewport, title e meta description, canonical e direttive robots, un solo H1 con gerarchia corretta, link interni e breadcrumb, URL puliti, HTTPS e Core Web Vitals. Poi si passa a dati strutturati, social meta e ottimizzazione GEO. ### Le breadcrumb sono importanti per la SEO? Sì: aiutano i crawler a capire la gerarchia del sito, migliorano la navigazione dell’utente e distribuiscono link juice verso le categorie superiori; con i dati strutturati BreadcrumbList possono comparire direttamente nei risultati di ricerca. ### Il meta keywords serve ancora? No: Google dichiara di non usarlo come fattore di ranking ed espone solo le tue keyword alla concorrenza. Nella maggior parte dei casi conviene ometterlo.

--- title: "Checklist SEO" url: https://www.conseolente.it/checklist-seo/ aggiornato: 2026-06-01 descrizione: "Checklist SEO costantemente aggiornata: oltre 180 controlli tecnici, di struttura, contenuto e GEO. Ogni voce, attività, compito SEO spiegato col perché e con…" topic: "checklist SEO · controlli · tecnici, strutturali e di contenuto" --- # Checklist SEO > Versione per assistenti AI. Pagina originale: [Checklist SEO](https://www.conseolente.it/checklist-seo/?via=md) **Una checklist SEO** è l’elenco ordinato dei controlli tecnici, strutturali e di contenuto da verificare su una pagina o un sito per renderlo comprensibile ai motori di ricerca e citabile dagli assistenti AI. Questa guida raccoglie **oltre 180 elementi** divisi in 9 aree e, per ciascuno, spiega _perché conta_, la best practice e un esempio di codice. Come usarla: parti dalle voci a **priorità Alta**, poi scendi verso quelle a priorità media e bassa. In fondo trovi i miti SEO da sfatare e le domande frequenti. ## 1. & meta tecnici ### **Perché conta.** Dichiara la versione del linguaggio (HTML5) e va come primissima riga del documento, prima di ; senza di essa il browser entra in ‘quirks mode’ interpretando il codice con regole legacy non standard, con il rischio di rotture di layout e box model diverso. Una dichiarazione corretta forza lo ‘standards mode’, previene errori di rendering e garantisce compatibilità cross-browser, riducendo anche bug che possono ostacolare l’esperienza utente e quindi indirettamente i segnali di qualità. _Motivazioni: Rendering/Compatibilità · Esperienza utente — Priorità: Media_ **Best practice.** Usa sempre il doctype HTML5 minimale come prima riga assoluta del file, senza spazi o commenti prima. ``` ``` ### **Perché conta.** L’attributo lang sull’elemento radice dichiara la lingua principale del documento: aiuta i motori di ricerca a capire per quale lingua/mercato la pagina è rilevante (utile insieme a hreflang per il targeting linguistico) ed è fondamentale per l’accessibilità, perché gli screen reader scelgono la pronuncia e la voce corretta in base a questo valore. Migliora inoltre funzioni del browser come la traduzione automatica e il controllo ortografico. _Motivazioni: Crawler/Indicizzazione · Accessibilità · Esperienza utente — Priorità: Media_ **Best practice.** Imposta lang con il codice lingua corretto (e regione se serve), coerente con il contenuto reale e con gli hreflang; non lasciarlo generico o errato. ``` ``` ### **Perché conta.** Specifica la codifica caratteri del documento e va il prima possibile nel , idealmente entro i primi 1024 byte; aiuta il browser a interpretare correttamente i caratteri ed evita testo corrotto (mojibake) su accenti e simboli. Una codifica esplicita previene anche un raro vettore di attacco XSS basato sull’auto-rilevamento dell’encoding, e garantisce che i crawler indicizzino il testo nella forma corretta. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Sicurezza · Crawler/Indicizzazione — Priorità: Alta_ **Best practice.** Dichiara come primissimo elemento dentro , prima di title e di qualsiasi contenuto, e salva i file effettivamente in UTF-8. ``` ``` ### **Perché conta.** Controlla come la pagina viene scalata e dimensionata sui dispositivi mobili: senza di esso i browser mobile renderizzano a larghezza desktop (es. 980px) e poi rimpiccioliscono, rendendo il testo illeggibile. Con l’indicizzazione mobile-first di Google la versione mobile è quella che conta per il ranking, quindi un viewport corretto è prerequisito per la mobile-friendliness, per una buona esperienza utente e per evitare penalizzazioni di usabilità. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Ranking · Crawler/Indicizzazione — Priorità: Alta_ **Best practice.** Usa width=device-width con initial-scale=1; evita di bloccare lo zoom (niente user-scalable=no o maximum-scale=1) per non danneggiare l’accessibilità. ``` ``` ### **Perché conta.** È uno dei segnali on-page più forti per capire l’argomento della pagina ed è ciò che (spesso) viene mostrato come link blu nella SERP, influenzando direttamente il CTR. Un title pertinente e unico aiuta i crawler a comprendere e differenziare le pagine, mentre title duplicati o generici confondono l’indicizzazione e fanno perdere clic; Google può comunque riscrivere il title se lo ritiene poco rappresentativo. _Motivazioni: Ranking · Crawler/Indicizzazione · Conversione · Esperienza utente — Priorità: Alta_ **Best practice.** Scrivi un title unico per pagina, ~50-60 caratteri, con la keyword principale verso l’inizio e il brand in coda; descrittivo e non keyword-stuffed. ``` Scarpe da Trail Running Impermeabili | NomeBrand ``` ### <meta name=’description’> **Perché conta.** Non è un fattore di ranking diretto, ma fornisce lo snippet che spesso appare sotto il title in SERP: una description chiara e invitante aumenta il CTR e quindi le visite e le conversioni. Se assente o duplicata, Google genera uno snippet dal contenuto, talvolta meno efficace; serve quindi a controllare il messaggio commerciale, non a posizionarsi. _Motivazioni: Conversione · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Scrivi una description unica per pagina di ~150-160 caratteri, con un riassunto persuasivo e una call to action, includendo naturalmente i termini chiave; non riempirla di keyword. ``` ``` ### <link rel=’canonical’> **Perché conta.** Indica ai motori l’URL preferito quando esistono più versioni della stessa pagina (parametri, http/https, www/non-www, ordinamenti, sessioni): consolida i segnali di ranking e il link juice su un solo URL evitando contenuti duplicati e cannibalizzazione, e ottimizza il crawl budget evitando che lo spider sprechi risorse su duplicati. È un suggerimento (hint) per Google, non un comando assoluto. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Usa un solo canonical per pagina, con URL assoluto e autoreferenziale di default; punta sempre a una pagina indicizzabile (200, non noindex/redirect) e mantieni coerenza con sitemap e link interni. ``` - ``` ### <meta name=’robots’> (index/noindex, follow/nofollow) **Perché conta.** Controlla a livello di pagina se i motori possono indicizzarla (index/noindex) e seguire i suoi link (follow/nofollow): è lo strumento corretto per tenere fuori dall’indice pagine di servizio, filtri o thank-you page senza bloccare il crawling. Attenzione: la direttiva va letta dal crawler, quindi la pagina NON deve essere bloccata in robots.txt, altrimenti il noindex non viene visto; noindex insieme a link interni rilevanti può anche disperdere link juice. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Usa noindex per escludere pagine dall’indice (e lasciale crawlabili, non in robots.txt); usa index,follow (o ometti il tag) per le pagine da posizionare; non mettere noindex sulle pagine importanti per errore. ``` ``` ### <meta name=’robots’> (max-snippet, max-image-preview, max-video-preview) **Perché conta.** Direttive granulari che regolano come Google mostra l’anteprima del contenuto in SERP: max-snippet limita la lunghezza dello snippet di testo, max-image-preview la dimensione dell’anteprima immagine, max-video-preview i secondi di anteprima video. Influiscono su appeal del risultato e CTR, e sono rilevanti anche per il modo in cui i contenuti vengono mostrati/usati da funzioni come Discover; impostazioni troppo restrittive possono ridurre la visibilità. _Motivazioni: Crawler/Indicizzazione · Conversione · Esperienza utente — Priorità: Media_ **Best practice.** Per massima visibilità usa max-image-preview:large e max-snippet:-1 (nessun limite); restringi solo se hai esigenze editoriali/licenze specifiche. ``` ``` ### <link rel=’alternate’ hreflang> **Perché conta.** Segnala ai motori le versioni della pagina destinate a lingue/regioni diverse, così Google mostra all’utente la variante corretta riducendo bounce e migliorando l’esperienza; aiuta inoltre a gestire contenuti quasi-duplicati tra mercati simili (es. it-IT e it-CH). Gli hreflang devono essere reciproci (ogni pagina linka tutte le altre e se stessa) e includere x-default per il fallback, altrimenti i segnali non vengono recepiti. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Implementa cluster hreflang bidirezionali con URL assoluti, codici ISO lingua (e regione) validi e un x-default; mantieni il canonical autoreferenziale su ciascuna variante e non far puntare il canonical di una lingua a un’altra. ``` ``` ### <link rel=’icon’> / favicon **Perché conta.** Definisce l’icona del sito mostrata nella scheda del browser, nei preferiti e, soprattutto, accanto al risultato nella SERP mobile: una favicon nitida e riconoscibile rafforza il brand e può aumentare il CTR. Google la usa nei risultati solo se è raggiungibile, di formato corretto e associata in modo coerente all’home; assente o rotta, peggiora la percezione di affidabilità. _Motivazioni: Conversione · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Fornisci una favicon quadrata (multipli di 48px, es. 48×48/96×96) in formato supportato, dichiarata nel <head> e stabile nel tempo; aggiungi anche le icone per dispositivi Apple e il manifest. ``` ``` ### <meta name=’theme-color’> **Perché conta.** Suggerisce ai browser supportati (soprattutto Chrome su Android e le PWA) il colore della barra dell’interfaccia, integrando la pagina con la chrome del browser: non è un fattore di ranking, ma migliora la coerenza visiva del brand e l’esperienza utente percepita, in particolare per i siti installabili. Supporta anche varianti per tema chiaro/scuro tramite media query. _Motivazioni: Esperienza utente · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Imposta un theme-color coerente con la palette del brand; valuta una versione per dark mode con l’attributo media. ``` ``` ### <base href> **Perché conta.** Definisce l’URL di base per risolvere tutti i link e le risorse relative della pagina: usato male è una fonte frequente di bug, perché altera silenziosamente la destinazione di ogni href/src relativo, può rompere ancore interne (#) e creare link errati o duplicati che confondono i crawler e disperdono link juice. Va usato con cognizione, non per abitudine. _Motivazioni: Rendering/Compatibilità · Crawler/Indicizzazione · Link juice/PageRank — Priorità: Bassa_ **Best practice.** Evita <base> se non strettamente necessario; preferisci URL assoluti. Se lo usi, dichiaralo una sola volta e prima di qualsiasi risorsa relativa nel <head>, verificando l’impatto su link e ancore. ``` ``` ### <meta http-equiv> (Content-Security-Policy, X-UA-Compatible, refresh) **Perché conta.** Emula header HTTP dal markup. Alcuni usi sono utili (es. una CSP minima a difesa contro XSS, anche se l’header HTTP reale è preferibile), altri sono obsoleti o dannosi per la SEO: X-UA-Compatible serviva per i vecchi IE e oggi è inutile, mentre http-equiv=’refresh’ per i redirect va evitato perché peggiora l’esperienza utente, non passa correttamente i segnali come un 301 e può essere visto come tecnica spam. _Motivazioni: Sicurezza · Rendering/Compatibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Per i redirect usa sempre 301/302 lato server, mai meta refresh. Imposta le policy di sicurezza via header HTTP; usa meta http-equiv solo quando l’header reale non è disponibile. ``` ``` ### X-Robots-Tag (header HTTP) **Perché conta.** È l’equivalente HTTP del meta robots, ma applicabile anche a risorse non-HTML (PDF, immagini, documenti) dove il meta tag non può essere inserito; permette di impostare noindex/nofollow a livello di server, per singolo file o pattern. Come per il meta robots, perché la direttiva noindex sia letta la risorsa NON deve essere bloccata in robots.txt, altrimenti il crawler non vede mai l’header. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank — Priorità: Media_ **Best practice.** Usa X-Robots-Tag per controllare l’indicizzazione di PDF e file non-HTML, mantenendoli crawlabili; verifica con un controllo header che la direttiva venga effettivamente inviata e non duplichi/contraddica il meta robots. ``` HTTP/1.1 200 OK Content-Type: application/pdf X-Robots-Tag: noindex, nofollow ``` ### Ordine degli elementi nel <head> **Perché conta.** L’ordine influisce su correttezza e performance: <meta charset> deve venire prima di qualsiasi contenuto/testo per evitare re-parsing e mojibake, mentre risorse render-blocking come CSS e gli hint di connessione (preconnect, dns-prefetch) posizionati in alto velocizzano il primo render migliorando i Core Web Vitals (LCP), che sono segnali di esperienza pagina. Un <head> ordinato riduce reflow e accelera la pagina per utenti e crawler. _Motivazioni: Performance · Rendering/Compatibilità · Ranking · Esperienza utente — Priorità: Media_ **Best practice.** Ordina il head così: charset → viewport → title → preconnect/dns-prefetch → CSS critico/preload → script/meta secondari; evita di anteporre tag che ritardano la lettura del charset. ``` ... ``` ### <meta name=’keywords’> **Perché conta.** Tag storico in cui si elencavano le parole chiave della pagina: oggi Google dichiara esplicitamente di NON usarlo come fattore di ranking (fu abusato con keyword stuffing) e va quindi considerato inutile per il posizionamento. Anzi, esporre l’elenco delle keyword target può solo dare informazioni gratuite alla concorrenza, quindi nella maggior parte dei casi è meglio ometterlo. _Motivazioni: Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Non inserire il meta keywords per scopi SEO su Google; ometterlo. Eventualmente mantienilo solo se richiesto da motori interni/legacy specifici. ``` ``` ### Resource hints (preconnect / dns-prefetch / preload) **Perché conta.** Sono direttive nel <head> che anticipano il caricamento di risorse o connessioni critiche: dns-prefetch e preconnect aprono in anticipo la connessione verso domini terzi (font, CDN, analytics), mentre preload forza il download prioritario di risorse chiave come font o l’immagine LCP. Usati con criterio migliorano i Core Web Vitals (LCP, riduzione del tempo a primo byte percepito), che impattano esperienza utente e segnali di ranking; usati in eccesso sprecano banda. _Motivazioni: Performance · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Usa preconnect per i 2-4 domini terzi più critici e preload solo per la risorsa LCP o i font above-the-fold; non abusarne per non saturare la banda iniziale. ``` ``` ## 2. Struttura semantica & HTML on-page ### Heading H1 (un solo H1 per pagina) **Perché conta.** L’H1 dichiara l’argomento principale della pagina ed è uno dei segnali più forti che crawler e modelli AI usano per capire di cosa tratta il contenuto, rafforzando la pertinenza in fase di ranking; per gli utenti (e per gli screen reader) è il titolo visivo che orienta la lettura. Un solo H1 evita ambiguità sul tema portante: anche se Google con HTML5 tollera più H1, mantenerne uno solo resta la pratica più pulita per gerarchia, accessibilità e GEO/AI. _Motivazioni: Crawler/Indicizzazione · Ranking · Accessibilità · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Usa un unico <h1> per pagina, coerente con il <title> ma non identico, che contenga la keyword principale in linguaggio naturale; tienilo descrittivo e collocato in alto nel <main>. ``` # Scarpe da trail running impermeabili: guida all'acquisto ``` ### Gerarchia heading H2-H6 (ordine logico, niente salti) **Perché conta.** I sottotitoli H2-H6 formano lo scheletro semantico del documento: i crawler li usano per segmentare il contenuto in argomenti e sotto-argomenti, i modelli AI per estrarre passaggi e generare risposte/featured snippet, gli utenti per scansionare la pagina. Saltare livelli (da H2 a H4) o usare gli heading solo per la dimensione del font rompe la struttura ad albero e peggiora l’accessibilità per chi naviga con screen reader saltando di intestazione in intestazione. _Motivazioni: Crawler/Indicizzazione · Accessibilità · Esperienza utente · GEO/AI · Ranking — Priorità: Alta_ **Best practice.** Annida gli heading in ordine sequenziale (H1 > H2 > H3…) senza saltare livelli; usa gli H per la struttura logica, mai per ottenere una certa grandezza del testo (per quello c’è il CSS). ``` # Guida ## Tipologie ### Trail leggere ### Trail tecniche ## Come scegliere ``` ### <header> (intestazione di pagina/sezione) **Perché conta.** Il tag <header> raggruppa il contenuto introduttivo (logo, titolo, navigazione, claim) e comunica ai crawler e alle tecnologie assistive il ruolo di quel blocco senza affidarsi a classi CSS generiche; espone implicitamente la landmark ARIA banner quando è figlio diretto del <body>, migliorando l’accessibilità e aiutando gli user agent a distinguere intestazione e contenuto principale. _Motivazioni: Crawler/Indicizzazione · Accessibilità · Rendering/Compatibilità · Esperienza utente — Priorità: Media_ **Best practice.** Usa <header> per l’intestazione del sito e, all’interno di article/section, per le intro locali; evita di usarlo come semplice contenitore stilistico al posto di un <div>. ``` [![Nome Brand](/logo.svg)](/) ... ``` ### <nav> (navigazione) **Perché conta.** Il <nav> marca esplicitamente i blocchi di link di navigazione: i crawler vi riconoscono i percorsi strutturali del sito (menu, breadcrumb) distinguendoli dai link contestuali del contenuto, contribuendo alla distribuzione del link juice; per l’accessibilità genera la landmark navigation, permettendo agli utenti di screen reader di saltare direttamente ai menu. Usare più <nav> richiede etichette per distinguerli. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Accessibilità · Esperienza utente — Priorità: Media_ **Best practice.** Racchiudi i menu principali e i breadcrumb in <nav> e, se ne hai più di uno, distinguili con aria-label; non avvolgere ogni singolo link in un <nav>. ``` 1. [Home](/) 2. Scarpe ``` ### <main> (contenuto principale) **Perché conta.** Il <main> isola il contenuto unico e centrale della pagina rispetto a boilerplate ripetuto (header, sidebar, footer): questo aiuta i crawler e i motori AI a identificare il blocco che porta valore informativo e meritevole di indicizzazione, riducendo il rumore del template. Espone la landmark main e, con il link ‘salta al contenuto’, migliora drasticamente la navigazione da tastiera e da screen reader. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Alta_ **Best practice.** Usa un solo <main> visibile per pagina, contenente esclusivamente il contenuto centrale; abbinalo a uno skip link iniziale (es. <a href=”#main”>Vai al contenuto</a>). ``` [Vai al contenuto](#main) ... # ... ``` ### <article> e <section> **Perché conta.** <article> identifica un’unità di contenuto autonoma e riutilizzabile (un post, una scheda prodotto, una recensione) mentre <section> raggruppa parti tematiche correlate: questa distinzione semantica aiuta i crawler e gli LLM a capire i confini dei contenuti e a estrarre blocchi citabili, e supporta l’accessibilità quando le sezioni hanno un’intestazione. Non vanno usati come <div> generici: ogni section dovrebbe avere un proprio heading. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Media_ **Best practice.** Usa <article> per contenuti che hanno senso da soli e <section> per raggruppamenti tematici dotati di heading; se serve solo un contenitore per il layout/CSS, usa <div>. ``` ## Recensione modello X ### Pro ... ``` ### <aside> (contenuto correlato/secondario) **Perché conta.** Il tag <aside> marca contenuti tangenziali (box correlati, approfondimenti, pubblicità, widget): comunica a crawler e modelli AI che si tratta di materiale complementare, non del corpo principale, aiutandoli a pesare correttamente cosa è core e cosa è contorno; per l’accessibilità genera la landmark complementary, facilitando l’esplorazione della pagina. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Usa <aside> per box di approfondimento, link correlati o promo affiancati al contenuto; evita di metterci dentro il contenuto principale solo perché è in colonna laterale nel layout. ``` ## Leggi anche ... ``` ### <footer> (piè di pagina) **Perché conta.** Il <footer> raccoglie informazioni di chiusura (contatti, copyright, link legali, mappa secondaria): segnala a crawler e tecnologie assistive il ruolo del blocco (landmark contentinfo se figlio diretto del body) e i link al suo interno partecipano comunque al flusso di link juice verso pagine utili come privacy, contatti e categorie principali. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Accessibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Usa <footer> per il piè di pagina del sito e per le chiusure di article/section; mantieni i link essenziali ed evita footer sovraccarichi di centinaia di link (keyword/link stuffing). ``` [Privacy](/privacy) © 2026 Brand ``` ### Paragrafi <p> **Perché conta.** Il <p> definisce l’unità di testo discorsivo: separare correttamente i paragrafi (invece di usare <br> o <div>) dà al contenuto una struttura che crawler e LLM possono spezzare in passaggi semanticamente coerenti per snippet e risposte; per gli utenti paragrafi brevi migliorano la leggibilità e la scansione, riducendo il carico cognitivo e il bounce. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente · Accessibilità — Priorità: Media_ **Best practice.** Racchiudi ogni blocco di testo in <p>; mantieni i paragrafi brevi (2-4 frasi) e non usare <br> ripetuti per simulare spaziatura tra paragrafi. ``` Le scarpe da trail impermeabili proteggono dalla pioggia leggera. Per il fango profondo conta di più il battistrada. ``` ### Liste <ul> e <ol> **Perché conta.** Le liste strutturano informazioni enumerabili (passaggi, caratteristiche, vantaggi) in modo che crawler e modelli AI le riconoscano come elenchi e le riusino per featured snippet a lista e risposte generative; gli utenti le scansionano molto più rapidamente del testo continuo. La distinzione è semantica: <ol> quando l’ordine conta (procedure), <ul> quando non conta (elenchi di pari livello). _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente · Accessibilità — Priorità: Media_ **Best practice.** Usa <ol> per sequenze ordinate (istruzioni step-by-step) e <ul> per elenchi non ordinati; metti ogni voce in un <li> e non costruire pseudo-liste con trattini dentro un singolo paragrafo. ``` 1. Allenta i lacci 2. Inserisci il piede 3. Stringi dall'alto ``` ### Tabelle <table> (con <th>, scope, <caption>) **Perché conta.** Le tabelle dati ben marcate permettono a crawler e LLM di interpretare relazioni riga/colonna (confronti, specifiche, prezzi) e sono candidate ideali per snippet comparativi e dati strutturati; le intestazioni <th> con scope e la <caption> rendono i dati comprensibili agli screen reader. Vanno usate solo per dati tabellari reali, mai per impaginare il layout (anti-pattern obsoleto che danneggia accessibilità e responsività). _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Usa <table> solo per dati relazionali, con <thead>/<tbody>, <th scope=”col|row”> per le intestazioni e una <caption> descrittiva; per il layout usa CSS Grid/Flexbox. ``` | Modello | Peso | | --- | --- | | X1 | 280g | ``` ### <strong> ed <em> (semantica) vs <b>/<i> (stile) **Perché conta.** <strong> ed <em> trasmettono importanza ed enfasi a livello semantico, informazione che gli screen reader possono vocalizzare e che aiuta crawler e LLM a cogliere i concetti enfatizzati; <b> e <i> sono puramente visivi e privi di significato. Usare quelli giusti migliora accessibilità e comprensione del contenuto, ma il grassetto eccessivo (keyword in bold ovunque) non porta vantaggi di ranking ed è solo rumore. _Motivazioni: Accessibilità · GEO/AI · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Usa <strong> per importanza ed <em> per enfasi reale; riserva <b>/<i> a casi puramente stilistici senza valore semantico (es. nomi di prodotto) e non abusare del grassetto sulle keyword. ``` **Attenzione:** il modello _non_ è impermeabile al 100%. ``` ### <blockquote> e <cite> (citazioni) **Perché conta.** Il <blockquote> marca citazioni testuali estese e <cite> il riferimento alla fonte: questo segnala a crawler e modelli generativi quali porzioni sono citazioni di terzi (utile per E-E-A-T e per evitare che il testo citato venga scambiato per contenuto originale), e migliora l’accessibilità con una struttura chiara. L’attributo cite con URL documenta la provenienza. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Accessibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Usa <blockquote cite=”URL”> per citazioni in blocco e <q> per quelle inline; indica la fonte con <cite> e non usare blockquote solo per ottenere un rientro grafico. ``` > Il 60% dei runner sceglie la traspirabilità. — Studio Esempio 2026 ``` ### Indice / sommario (TOC) con ancore **Perché conta.** Un sommario con link interni alle sezioni migliora la navigazione su contenuti lunghi, distribuisce link juice verso i blocchi interni e fornisce a Google segnali per i sitelink ‘jump to’ nei risultati; per crawler e LLM gli anchor con id mappano la struttura del documento e rendono i singoli passaggi indirizzabili e citabili. Aiuta anche l’accessibilità offrendo un accesso rapido alle parti. _Motivazioni: Esperienza utente · Link juice/PageRank · Crawler/Indicizzazione · GEO/AI · Accessibilità — Priorità: Media_ **Best practice.** Genera il TOC dai tuoi H2/H3 con link ad anchor (#id) coerenti; mettilo vicino all’inizio dei contenuti lunghi e assicurati che gli id siano stabili e descrittivi. ``` 1. [Come scegliere](#scelta) ... ## Come scegliere ``` ### Contenuto above-the-fold **Perché conta.** Ciò che è visibile senza scroll determina la prima impressione e influenza fortemente bounce rate e tempo di permanenza, segnali di esperienza utente; mostrare subito il contenuto principale (H1, risposta sintetica, valore) invece di banner, popup e annunci aiuta anche i crawler a trovare presto il testo rilevante e i modelli AI a estrarre una risposta immediata. Un above-the-fold ingombro di pubblicità è penalizzante (intrusive interstitials). _Motivazioni: Esperienza utente · Ranking · GEO/AI · Conversione — Priorità: Media_ **Best practice.** Posiziona H1 e una sintesi/risposta chiave entro il primo viewport; evita popup intrusivi e blocchi pubblicitari che spingono il contenuto sotto la piega, soprattutto su mobile. ### Rapporto contenuto vs boilerplate **Perché conta.** Crawler e sistemi AI estraggono il contenuto principale scartando il boilerplate (header, menu, sidebar, footer ripetuti su ogni pagina): se il template domina e il testo unico è scarso, la pagina rischia di sembrare thin content o duplicata, con impatto su indicizzazione e ranking. Marcare bene <main> e usare HTML5 semantico aiuta gli algoritmi a isolare il valore reale della pagina. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Ranking · Esperienza utente — Priorità: Media_ **Best practice.** Massimizza il contenuto unico nel <main> e riduci il peso del boilerplate ripetuto; evita pagine in cui il template supera nettamente il testo originale e usa la semantica HTML5 per delimitare le aree. ### Profondità e lunghezza del contenuto **Perché conta.** La lunghezza non è un fattore di ranking diretto, ma una copertura completa dell’intento (entità, sotto-domande, casi correlati) aumenta la pertinenza topica percepita da crawler e LLM e le chance di vincere snippet e citazioni in risposte generative; al contempo riempire la pagina di testo ridondante per allungarla danneggia leggibilità e qualità. Conta la profondità informativa, non il conteggio parole. _Motivazioni: Ranking · GEO/AI · Crawler/Indicizzazione · Esperienza utente — Priorità: Bassa_ **Best practice.** Copri l’intento di ricerca in modo esaustivo rispondendo alle domande correlate, senza padding; misura la qualità sulla completezza topica, non sul numero di parole. ### Leggibilità del testo **Perché conta.** Frasi brevi, paragrafi spezzati, sottotitoli frequenti e linguaggio chiaro riducono il carico cognitivo e tengono l’utente sulla pagina (segnale di esperienza positivo) e rendono il testo più facile da segmentare per gli LLM in passaggi citabili; una buona leggibilità migliora anche l’accessibilità per utenti con difficoltà di lettura. Un muro di testo denso aumenta l’abbandono e ostacola l’estrazione di risposte. _Motivazioni: Esperienza utente · GEO/AI · Accessibilità · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Scrivi frasi e paragrafi brevi, alterna heading, liste e grassetti semantici per spezzare il testo; punta a un linguaggio adeguato al pubblico e verifica con metriche di leggibilità. ## 3. Link interni, anchor & navigazione ### Link interni contestuali (<a href> nel corpo del testo) **Perché conta.** I link interni inseriti nel corpo del contenuto sono il principale veicolo con cui i crawler scoprono nuove URL e ne capiscono il rapporto semantico; trasmettono link juice/PageRank tra le pagine indirizzandolo verso quelle strategiche, aiutano gli utenti ad approfondire i temi correlati migliorando l’esperienza e il tempo sulla pagina, e rafforzano la pertinenza tematica (topical authority) che incide sul ranking. Per gli LLM/risposte AI un buon networking interno aiuta a ricostruire le entità e i loro collegamenti. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Inserisci link contestuali pertinenti verso pagine correlate dello stesso cluster tematico, dando priorità alle pagine importanti/da spingere; usa link veri in HTML (non solo JS) e mantieni un numero ragionevole, evitando di intasare il paragrafo. ``` Per approfondire vedi la nostra [guida alla SEO tecnica](/guida-seo-tecnica/). ``` ### Anchor text descrittiva **Perché conta.** L’anchor text dice a crawler e utenti di cosa parla la pagina di destinazione: un’ancora descrittiva e ricca di contesto migliora la comprensione semantica della pagina linkata (e quindi il suo ranking per i termini pertinenti), aiuta l’accessibilità per chi naviga con screen reader o salta di link in link, e migliora l’esperienza utente perché chiarisce cosa si trova al clic. Va evitato il generico ‘clicca qui’ / ‘leggi di più’ perché privo di valore informativo. _Motivazioni: Crawler/Indicizzazione · Ranking · Accessibilità · Esperienza utente — Priorità: Alta_ **Best practice.** Usa ancore brevi e descrittive che riflettono il contenuto di destinazione; varia naturalmente la formulazione invece di ripetere sempre la stessa keyword, e non usare ancore generiche tipo ‘qui’ o ‘clicca qui’. ``` [scarpe da running](/scarpe-running/) [clicca qui](/scarpe-running/) ``` ### Over-optimization dell’anchor text (anchor spam) **Perché conta.** Ripetere ossessivamente la stessa anchor a exact-match keyword su molti link (interni o, soprattutto, in entrata) crea un pattern innaturale che gli algoritmi anti-spam possono interpretare come manipolazione, con rischio di svalutazione o penalizzazione invece di beneficio sul ranking; peggiora anche l’esperienza utente rendendo il testo ripetitivo e poco naturale. _Motivazioni: Ranking · Crawler/Indicizzazione · Esperienza utente — Priorità: Media_ **Best practice.** Mantieni un profilo di ancore naturale e vario (brand, URL, frasi descrittive, sinonimi); evita di forzare la stessa exact-match keyword su tutti i link verso la stessa pagina. ### Breadcrumbs (briciole di pane) **Perché conta.** Le breadcrumbs devono esserci perché i crawler le usano (al pari di sitemap e menu) per capire la struttura gerarchica del sito, ma servono anche ad agevolare la navigazione degli utenti che capiscono dove si trovano e risalgono di livello, e contribuiscono a far sì che tutte le pagine ricevano juice distribuendo i link verso le categorie superiori. Con i dati strutturati BreadcrumbList Google può mostrare il percorso direttamente nella SERP. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Mostra breadcrumbs coerenti con la gerarchia reale del sito su tutte le pagine profonde e marcale con structured data BreadcrumbList; usa link reali e l’ultimo elemento (pagina corrente) senza link. ``` 1. [Home](/) 2. [Scarpe](/scarpe/) 3. Running ``` ### Menu di navigazione principale **Perché conta.** Il menu primario definisce le sezioni chiave del sito ed è uno dei primi elementi che i crawler seguono per mappare l’architettura e distribuire il PageRank verso le pagine più importanti; per l’utente è la bussola che orienta la navigazione e riduce i rimbalzi. È fondamentale che i link del menu siano in HTML nativo e non generati solo via JavaScript al clic, altrimenti i crawler potrebbero non seguirli. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente · Rendering/Compatibilità · Accessibilità — Priorità: Alta_ **Best practice.** Usa una navigazione con <nav> e link <a href> reali verso le pagine cardine; mantienila essenziale e gerarchica, accessibile da tastiera e indicizzabile senza dipendere dall’esecuzione JS. ``` [Prodotti](/prodotti/) - [Blog](/blog/) ``` ### Footer link **Perché conta.** I link nel footer aiutano a raggiungere pagine secondarie ma utili (privacy, contatti, hub tematici) e sono seguiti dai crawler, contribuendo alla copertura del sito e a evitare pagine orfane; danno anche supporto alla navigazione utente. Vanno però usati con criterio: un footer gonfio di centinaia di link a bassa pertinenza diluisce il link juice e può apparire spammoso, perché i link sitewide ricevono in genere meno peso di quelli contestuali. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente — Priorità: Media_ **Best practice.** Limita i link del footer a quelli realmente utili (legali, sezioni chiave, hub principali) evitando elenchi keyword-stuffed; non usare il footer come deposito di link a fini SEO. ### Link esterni / outbound **Perché conta.** Collegare a fonti esterne autorevoli e pertinenti rafforza la credibilità e l’esperienza dell’utente, fornisce contesto e segnali di qualità ed E-E-A-T del contenuto, e può aiutare crawler e modelli AI a comprendere l’ecosistema di entità a cui la pagina si riferisce. Linkare verso fonti scadenti o spam, invece, può associare il tuo contenuto a vicinati di bassa qualità. _Motivazioni: Esperienza utente · Ranking · Crawler/Indicizzazione · GEO/AI — Priorità: Media_ **Best practice.** Cita fonti esterne pertinenti e affidabili quando aggiungono valore; verifica che i link non siano rotti e valuta il target appropriato e gli attributi rel per i link non editoriali. ``` [studio di riferimento](https://esempio-autorevole.org/studio/) ``` ### rel=”nofollow” **Perché conta.** Indica ai motori che il link non è un endorsement editoriale: oggi Google lo tratta come un hint, non come una direttiva rigida, sia per il crawling sia per il passaggio di segnali di ranking. Usato correttamente serve a non trasmettere PageRank verso link non garantiti o di terzi e a mantenere pulito il profilo di link, evitando di sembrare coinvolti in scambi/manipolazioni. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Media_ **Best practice.** Applica nofollow ai link di cui non vuoi farti garante (es. contenuti non verificati); per i casi specifici preferisci gli attributi più precisi ugc e sponsored. ``` [link non garantito](https://sito-terzo.com/) ``` ### rel=”ugc” e rel=”sponsored” **Perché conta.** Sono le qualificazioni introdotte per distinguere la natura dei link non editoriali: ‘ugc’ marca i link generati dagli utenti (commenti, forum) e ‘sponsored’ i link a pagamento/affiliazione. Comunicano ai crawler il contesto corretto, riducono il rischio di violazioni delle policy sui link a pagamento e aiutano i motori a pesare in modo più accurato i segnali, proteggendo il sito da azioni manuali sugli schemi di link. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Media_ **Best practice.** Usa rel=”sponsored” per link pubblicitari/affiliati e rel=”ugc” per contenuti generati dagli utenti; puoi combinare più valori (es. ugc nofollow) quando appropriato. ``` [offerta partner](https://aff.example/?id=123/) ``` ### rel=”noopener” (e noreferrer) su target=”_blank” **Perché conta.** Quando un link apre una nuova scheda con target=”_blank”, la pagina di destinazione può accedere all’oggetto window.opener e potenzialmente manipolare la pagina d’origine (tabnabbing): rel=”noopener” recide questo legame proteggendo la sicurezza dell’utente, e impedisce inoltre cali di performance dovuti alla condivisione del processo. È quindi una pratica di sicurezza e robustezza, non un segnale SEO. _Motivazioni: Sicurezza · Performance · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Aggiungi rel=”noopener” (o noopener noreferrer) a tutti i link con target=”_blank”; i browser moderni lo applicano di default ma dichiararlo esplicitamente garantisce compatibilità. ``` [apri in nuova scheda](https://esterno.com/) ``` ### Link orfani vs pagine orfane **Perché conta.** Una pagina orfana è una URL a cui nessun link interno punta: i crawler faticano a scoprirla (spesso vi arrivano solo da sitemap o link esterni), non riceve link juice e tende a posizionarsi male o a non essere indicizzata, mentre l’utente non può raggiungerla navigando. È un classico spreco di contenuti di valore non collegati al resto del sito. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Verifica periodicamente (crawl + log + sitemap) che ogni pagina utile abbia almeno qualche link interno in entrata da pagine pertinenti; collega le orfane ai relativi hub/categorie. ### Profondità di click (click depth) **Perché conta.** Il numero di clic necessari per raggiungere una pagina dalla home indica quanto è ‘centrale’ nell’architettura: pagine troppo profonde vengono scoperte e ricrawlate meno spesso, ricevono meno PageRank e sono più difficili da trovare per l’utente, con effetto negativo su indicizzazione e ranking. Un’architettura piatta porta valore e crawler più velocemente alle pagine importanti. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Mantieni le pagine importanti a pochi clic dalla home (idealmente entro 3) usando hub, categorie e link contestuali; appiattisci la struttura dove le pagine chiave risultano troppo sepolte. ### Paginazione (rel=prev/next, storico) **Perché conta.** Le serie paginate vanno rese comprensibili ai crawler perché possano scoprire tutti gli elementi delle pagine successive e distribuire il juice. Attenzione a un mito comune: Google ha dichiarato di non usare più rel=”prev”/”next” come segnale (sebbene resti utile per accessibilità e altri motori); l’approccio attuale è basare la scoperta su normali link <a href> verso le pagine 2, 3, ecc. e su URL paginate indicizzabili. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Accessibilità — Priorità: Media_ **Best practice.** Esponi link <a href> reali alle pagine successive (non solo JS), usa URL paginate uniche e canoniche a se stesse; rel=prev/next puoi mantenerlo per accessibilità ma non aspettarti effetti da Google. ``` [Pagina successiva](/blog/page/2/) ``` ### Infinite scroll / caricamento lazy dei contenuti **Perché conta.** L’infinite scroll basato solo su eventi JS senza URL navigabili nasconde i contenuti ai crawler, che non scrollano: gli elementi caricati dinamicamente rischiano di non essere scoperti né indicizzati, e l’utente non può salvare o condividere uno stato preciso. È un caso in cui rendering e crawlability entrano in conflitto con l’esperienza. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Esperienza utente — Priorità: Media_ **Best practice.** Affianca all’infinite scroll una paginazione tradizionale con URL e link <a href> indicizzabili (progressive enhancement), così i crawler scoprono tutti gli elementi indipendentemente dallo scroll. ### Contenuti correlati / related links **Perché conta.** I blocchi di articoli o prodotti correlati creano collegamenti contestuali aggiuntivi che aumentano la profondità tematica del cluster, distribuiscono link juice verso pagine affini, riducono le pagine orfane e migliorano l’esperienza tenendo l’utente nel sito; aiutano inoltre crawler e modelli AI a comprendere le relazioni semantiche tra contenuti dello stesso argomento. _Motivazioni: Link juice/PageRank · Crawler/Indicizzazione · Esperienza utente · GEO/AI · Conversione — Priorità: Media_ **Best practice.** Genera i correlati per pertinenza tematica reale (stesso cluster/entità) e non in modo casuale; assicurati che siano link HTML reali e non solo widget JS non indicizzabili. ``` [Titolo correlato](/articolo-correlato/) ``` ### Distribuzione del link juice / PageRank interno **Perché conta.** Il PageRank si propaga lungo i link interni e ogni pagina ne ripartisce una quota tra i link che contiene: una struttura ben progettata convoglia il valore verso le pagine che devono posizionarsi (categorie, money page), mentre link sparsi verso pagine a basso valore (login, filtri, tag inutili) lo disperdono. Governare questo flusso è leva diretta su crawling prioritario e ranking. _Motivazioni: Link juice/PageRank · Ranking · Crawler/Indicizzazione — Priorità: Alta_ **Best practice.** Concentra i link interni verso le pagine prioritarie e limita o gestisci (canonical, noindex, parametri) quelli verso URL a basso valore; cura il flusso da home e hub ad alta autorità verso le pagine strategiche. ### Self-link e link a se stessa nella navigazione **Perché conta.** Un link che punta alla pagina su cui ci si trova (es. la voce di menu attiva o l’ultimo livello del breadcrumb) non aggiunge valore di navigazione, può confondere l’utente e spreca un link che potrebbe distribuire juice altrove; per accessibilità è meglio indicare lo stato corrente che linkarlo. _Motivazioni: Esperienza utente · Accessibilità · Link juice/PageRank — Priorità: Bassa_ **Best practice.** Rendi non cliccabile l’elemento corrispondente alla pagina attiva (menu/breadcrumb) marcandolo con aria-current=”page” anziché linkarlo a se stesso. ``` - Pagina attuale ``` ## 4. URL, redirect & crawlability ### URL parlanti / slug descrittivi **Perché conta.** Uno slug leggibile (parole reali separate da trattini) comunica a colpo d’occhio l’argomento della pagina sia ai crawler, che lo usano come segnale debole di pertinenza e per costruire l’anchor quando l’URL viene incollato nudo, sia agli utenti, che cliccano più volentieri risultati comprensibili in SERP e li condividono con più fiducia. URL puliti riducono inoltre il rischio di parametri inutili e duplicazioni, e migliorano la percezione di qualità del brand. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Usa slug brevi, in minuscolo, con parole chiave reali separate da trattini (-), niente underscore, spazi, accenti, maiuscole o stop-word inutili; mantieni lo slug stabile nel tempo per non rompere i link. ``` https://sito.it/scarpe-running-uomo (NON /prodotto?id=8493&cat=12) ``` ### Gerarchia e profondità di click (click depth) **Perché conta.** Una struttura a cartelle coerente (/categoria/sottocategoria/pagina) aiuta i crawler a capire la tassonomia del sito e distribuisce il link juice dall’alto verso il basso, mentre per l’utente rende la navigazione prevedibile. Le pagine raggiungibili in pochi click dalla home ricevono più PageRank interno e vengono crawlate più spesso; pagine sepolte a 5-6 livelli rischiano scarsa indicizzazione e crawl raro. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente — Priorità: Media_ **Best practice.** Tieni le pagine importanti entro 3 click dalla home, mantieni la gerarchia di cartelle allineata alla struttura logica e ai breadcrumb, ed evita silos troppo profondi o cartelle vuote di valore. ``` /blog/seo-tecnico/canonical-tag/ (3 livelli, non 6) ``` ### HTTPS / certificato TLS **Perché conta.** HTTPS è confermato da Google come fattore di ranking (leggero) ed è prerequisito per HTTP/2 e molte API browser; protegge i dati in transito da intercettazioni e manomissioni, rimuove il marchio ‘Non sicuro’ di Chrome che fa abbandonare gli utenti e preserva il referrer verso altri siti HTTPS. Un sito misto HTTP/HTTPS genera mixed content e perdita di fiducia. _Motivazioni: Sicurezza · Ranking · Esperienza utente · Performance — Priorità: Alta_ **Best practice.** Installa un certificato valido, forza HTTPS con redirect 301 da http a https, abilita HSTS e correggi ogni risorsa caricata in HTTP (mixed content); usa URL relativi o https:// per asset interni. ``` Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ``` ### Canonicalizzazione del dominio (www vs non-www, HTTP vs HTTPS) **Perché conta.** Lo stesso contenuto raggiungibile su http/https e www/non-www crea fino a quattro varianti duplicate che diluiscono i segnali di ranking e sprecano crawl budget. Scegliere una sola versione e reindirizzare le altre concentra il link juice su un unico URL e dà ai crawler un segnale univoco di quale host indicizzare. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Decidi una versione canonica (es. https://www.sito.it), reindirizza con 301 tutte le altre verso di essa in un solo hop, e mantieni coerenti canonical, sitemap e link interni sulla versione scelta. ``` http://sito.it/ , http://www.sito.it/ , https://sito.it/ → 301 → https://www.sito.it/ ``` ### Trailing slash (slash finale) **Perché conta.** /pagina e /pagina/ sono tecnicamente URL diversi: se entrambi rispondono 200 con lo stesso contenuto creano duplicazione e split dei segnali, mentre i link interni incoerenti generano hop di redirect superflui che bruciano crawl budget. Una regola unica e applicata ovunque mantiene chiara la versione canonica. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank — Priorità: Media_ **Best practice.** Scegli una convenzione (con o senza slash finale), applicala a livello server con 301 verso la forma scelta, e usa link interni e canonical sempre coerenti; nota che per i file (es. .html) lo slash finale non va aggiunto. ``` /servizi → 301 → /servizi/ (e canonical su /servizi/) ``` ### Redirect 301 (permanente) **Perché conta.** Il 301 dice ai crawler che una risorsa si è spostata definitivamente: trasferisce i segnali di ranking e l’equity di link verso la nuova URL, aggiorna l’indice e per l’utente garantisce di arrivare sempre alla pagina giusta evitando 404. È lo strumento corretto per migrazioni, cambio dominio, consolidamento di pagine e fix di URL duplicati. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Esperienza utente — Priorità: Alta_ **Best practice.** Usa il 301 per ogni spostamento definitivo, punta sempre alla destinazione finale (mai a un altro redirect) e aggiorna i link interni alla nuova URL invece di affidarti al solo redirect. ``` HTTP/1.1 301 Moved Permanently Location: https://www.sito.it/nuova-pagina/ ``` ### Redirect 302/307 (temporanei) **Perché conta.** 302 (HTTP/1.0) e 307 (HTTP/1.1, che preserva il metodo HTTP) segnalano uno spostamento temporaneo: i crawler mantengono indicizzata l’URL originale e in linea di principio non trasferiscono pienamente i segnali come il 301. Usarli per spostamenti permanenti rallenta o impedisce il passaggio di equity e tiene a indice l’URL sbagliato. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank — Priorità: Media_ **Best practice.** Riserva 302/307 a casi davvero temporanei (manutenzione, A/B test, geo/lingua provvisoria); per qualsiasi spostamento definitivo usa 301 (o 308 se devi preservare il metodo POST). ``` HTTP/1.1 307 Temporary Redirect (manutenzione) Location: /manutenzione/ ``` ### Redirect 308 (permanente che preserva il metodo) **Perché conta.** Il 308 è l’equivalente permanente del 307: come il 301 indica spostamento definitivo e consolida i segnali, ma a differenza del 301 garantisce che il metodo e il body della richiesta restino invariati (un POST resta POST). Conta soprattutto per API ed endpoint applicativi; per le pagine HTML tipiche il 301 resta lo standard più sicuro e universalmente compreso. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Link juice/PageRank — Priorità: Bassa_ **Best practice.** Usa il 308 quando devi reindirizzare in modo permanente preservando il metodo HTTP (es. endpoint POST/API); per redirect di pagine normali continua a usare il 301. ``` HTTP/1.1 308 Permanent Redirect Location: https://api.sito.it/v2/risorsa ``` ### Catene e loop di redirect **Perché conta.** Una catena (A→B→C) costringe crawler e browser a richieste multiple, ritarda il rendering, fa disperdere progressivamente i segnali di ranking a ogni hop e consuma crawl budget; un loop (A→B→A) blocca del tutto l’accesso restituendo errore al bot e all’utente. Entrambi degradano performance e indicizzazione. _Motivazioni: Crawler/Indicizzazione · Performance · Link juice/PageRank · Esperienza utente — Priorità: Alta_ **Best practice.** Appiattisci ogni catena facendo puntare la sorgente direttamente alla destinazione finale (un solo hop), elimina i loop e ricontrolla periodicamente le regole con un crawler per scovare hop accumulati nel tempo. ``` /a → /b → /c ✗ ⇒ /a → /c e /b → /c ✓ ``` ### robots.txt **Perché conta.** È il primo file che i crawler leggono: governa il crawling (non l’indicizzazione) indicando quali percorsi non scansionare e dove trovare la sitemap, aiutando a preservare crawl budget su aree inutili (carrelli, filtri, ricerche interne). Attenzione: un errore di sintassi o un Disallow troppo ampio può oscurare l’intero sito ai motori. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Alta_ **Best practice.** Blocca solo percorsi realmente inutili, NON usare Disallow per nascondere pagine dall’indice (vedi noindex), dichiara la sitemap e non bloccare CSS/JS necessari al rendering; testalo prima di pubblicare. ``` User-agent: * Disallow: /cart/ Disallow: /*?orderby= Sitemap: https://www.sito.it/sitemap_index.xml ``` ### noindex vs Disallow (differenza chiave) **Perché conta.** Sono cose diverse e spesso confuse: Disallow in robots.txt impedisce il crawling ma una URL bloccata può comunque finire indicizzata (senza snippet) se linkata altrove; noindex (meta robots o header X-Robots-Tag) impedisce l’indicizzazione ma richiede che la pagina sia crawlabile per essere letta. Bloccare in robots una pagina che vuoi de-indicizzare è l’errore classico: il bot non vedrà mai il noindex. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Alta_ **Best practice.** Per togliere una pagina dall’indice usa noindex e lasciala crawlabile (non metterla in Disallow); usa il Disallow solo per risparmiare crawl budget su risorse che non devono mai essere scansionate. ``` oppure X-Robots-Tag: noindex ``` ### sitemap.xml e sitemap index **Perché conta.** La sitemap fornisce ai crawler una lista pulita degli URL canonici da scoprire, accelerando l’indicizzazione di siti grandi, nuovi o con link interni deboli, e comunica con lastmod quando una pagina è cambiata. Il sitemap index permette di organizzare in più file (limite 50.000 URL / 50 MB ciascuno), utile per siti molto ampi. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Alta_ **Best practice.** Includi solo URL canonici, indicizzabili e che rispondono 200 (niente noindex, redirect, 404, parametri o pagine bloccate), aggiorna lastmod in modo veritiero, dichiarala in robots.txt e inviala in Search Console. ``` https://www.sito.it/pagina/2026-05-30 ``` ### Tag canonical (<link rel=”canonical”>) **Perché conta.** Indica ai motori l’URL preferita tra più varianti con contenuto identico o molto simile (parametri di tracking, ordinamenti, versioni stampa), consolidando i segnali di ranking su una sola pagina ed evitando che il duplicato competa o disperda equity. È un suggerimento, non un comando: Google può ignorarlo se incoerente con altri segnali. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Alta_ **Best practice.** Inserisci un canonical assoluto e self-referencing su ogni pagina, fai puntare i duplicati alla versione preferita, e mantieni canonical coerente con sitemap, link interni e redirect (no canonical verso pagine noindex o redirezionate). ``` - ``` ### Parametri URL e contenuti duplicati **Perché conta.** Parametri di sessione, tracking (utm), filtri e ordinamenti generano infinite URL diverse che servono lo stesso contenuto: questo crea duplicazione, frammenta i segnali di ranking e, su e-commerce con faccette, può intrappolare i crawler in spider trap che divorano il crawl budget senza indicizzare pagine utili. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Performance — Priorità: Media_ **Best practice.** Canonicalizza le varianti con parametro verso l’URL pulita, blocca in robots.txt i parametri di puro filtro/ordinamento che non devono essere crawlati, evita utm nei link interni e mantieni un ordine stabile dei parametri. ``` /scarpe?color=red&utm_source=fb → canonical: /scarpe ``` ### Paginazione (rel next/prev e canonical) **Perché conta.** Le serie paginate (?page=2,3…) devono essere gestite perché ogni pagina abbia un canonical self-referencing e resti crawlabile: così i motori scoprono e indicizzano i prodotti/articoli delle pagine profonde. Nota: Google ha dichiarato di non usare più rel=next/prev come segnale di indicizzazione, quindi NON canonicalizzare le pagine 2..N verso la pagina 1, perché ne nasconderesti i contenuti. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Media_ **Best practice.** Dai a ogni pagina paginata un canonical a se stessa (non alla pagina 1), tienile indicizzabili e ben linkate, e valuta una pagina ‘view-all’ canonica solo se carica velocemente. ``` Su /blog?page=2 → ``` ### Codici di stato HTTP corretti **Perché conta.** Lo status code è il modo in cui il server dichiara ai crawler lo stato reale di una risorsa: 200 = indicizzabile, 301/308 = spostata, 404 = inesistente, 410 = rimossa definitivamente, 5xx = errore server. Codici errati (es. una pagina mancante che risponde 200) confondono l’indice, e i 5xx ripetuti possono ridurre la frequenza di crawl perché Google interpreta il sito come instabile. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Performance — Priorità: Media_ **Best practice.** Restituisci sempre lo status veritiero: 404/410 per pagine rimosse, 301 per spostamenti, monitora i 5xx e correggili rapidamente; non servire mai contenuto reale con codici di errore né errori con codice 200. ``` Pagina cancellata definitivamente → HTTP/1.1 410 Gone ``` ### Soft 404 **Perché conta.** Un soft 404 è una pagina vuota o ‘non trovato’ che però risponde 200: il crawler la tratta come valida, sprecando crawl budget per scansionare e indicizzare contenuto inutile, e l’utente atterra su una pagina senza valore. Search Console li segnala perché diluiscono la qualità percepita del sito. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Performance — Priorità: Media_ **Best practice.** Fai restituire un vero 404 (o 410) alle pagine inesistenti/vuote; per prodotti esauriti o contenuti rimossi reindirizza con 301 a un’alternativa pertinente solo se sensato, altrimenti 404/410. ``` Risultato ricerca senza match: deve dare 404, non 200 con 'Nessun risultato' ``` ### Crawl budget **Perché conta.** È la quantità di URL che un motore è disposto a scansionare in un dato periodo, funzione di crawl rate (capacità del server) e crawl demand (interesse verso il sito). Su siti grandi, sprecarlo su duplicati, parametri, redirect e soft 404 significa che le pagine nuove o importanti vengono scoperte e aggiornate più lentamente. Server veloci e architettura pulita ne migliorano l’efficienza. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Media_ **Best practice.** Riduci gli sprechi (elimina catene di redirect, blocca/canonicalizza i parametri inutili, correggi soft 404, comprimi le sitemap a soli URL validi) e migliora velocità di risposta del server e link interni verso le pagine prioritarie. ### llms.txt **Perché conta.** Proposta emergente (non uno standard ufficiale dei motori) per offrire a LLM e motori di risposta AI una mappa curata in Markdown dei contenuti più rilevanti del sito, facilitando il recupero e la citazione in risposte generative (GEO). Va distinto da robots.txt e dai meccanismi di controllo crawler AI (es. blocco di GPTBot, CCBot via robots o header): llms.txt guida, non blocca. _Motivazioni: GEO/AI · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Pubblica /llms.txt con link Markdown alle pagine chiave e una breve descrizione; gestisci l’accesso dei crawler AI separatamente in robots.txt o via X-Robots-Tag, senza aspettarti che llms.txt influenzi il ranking sui motori tradizionali. ``` # Nome Sito > Descrizione breve ## Documentazione - [Guida SEO](https://www.sito.it/guida.md): panoramica ``` ## 5. Immagini, video & media ### Attributo alt (alt text) **Perché conta.** L’attributo alt descrive il contenuto dell’immagine in modo testuale: serve agli screen reader per descrivere l’immagine agli utenti non vedenti (accessibilita), viene letto dai crawler per capire il soggetto dell’immagine e indicizzarla in Google Immagini, e fornisce contesto semantico utile al ranking della pagina; inoltre funge da testo di fallback se l’immagine non si carica (rendering/compatibilita). Per i motori generativi/AI e un segnale chiave per capire cosa raffigura un’immagine non comprensibile altrimenti. _Motivazioni: Accessibilità · Crawler/Indicizzazione · GEO/AI · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Scrivi alt brevi ma descrittivi (circa 5-15 parole) che descrivono cosa si vede e il contesto, includendo keyword pertinenti solo se naturali; evita keyword stuffing e frasi come ‘immagine di’. ``` ![Scarpa da running rossa Nike Pegasus 41 vista laterale](scarpa-running-rossa.webp) ``` ### Decorative vs informative (alt=”” e role) **Perché conta.** Distinguere immagini decorative da quelle informative evita rumore per gli screen reader: un’immagine puramente estetica con alt vuoto (alt=””) viene saltata dagli assistive technology migliorando l’esperienza degli utenti non vedenti (accessibilita), mentre un’immagine informativa senza alt costringe lo screen reader a leggere il nome file. Per i crawler, segnalare correttamente le decorative evita di attribuire valore semantico a elementi irrilevanti (crawler/indicizzazione). _Motivazioni: Accessibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Usa alt=”” (vuoto, non assente) per immagini puramente decorative o spostale in CSS background; riserva l’alt descrittivo solo alle immagini che veicolano contenuto informativo. ``` ``` ### Attributi width e height (CLS) **Perché conta.** Specificare width e height permette al browser di riservare lo spazio corretto prima del download dell’immagine, evitando il Cumulative Layout Shift (CLS), una metrica dei Core Web Vitals che impatta sia il ranking sia l’esperienza utente (lo spostamento del layout durante il caricamento e frustrante e causa clic accidentali); il browser calcola l’aspect-ratio e mantiene il layout stabile (rendering/performance). _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Indica sempre width e height (o aspect-ratio in CSS) coerenti con le proporzioni reali del file; con immagini responsive usali insieme a CSS che imposta height:auto per non deformare. ``` ![...](foto.webp) ``` ### Lazy loading (loading=”lazy”) **Perché conta.** Il lazy loading rinvia il caricamento delle immagini fuori viewport finche l’utente non scrolla, riducendo il peso iniziale della pagina, accelerando il First Contentful Paint e risparmiando banda (performance ed esperienza utente); migliora indirettamente i Core Web Vitals e quindi il ranking. Va pero evitato sulle immagini above-the-fold per non penalizzare l’LCP. _Motivazioni: Performance · Esperienza utente · Ranking — Priorità: Alta_ **Best practice.** Applica loading=”lazy” solo alle immagini sotto la piega; NON usarlo sull’immagine LCP/hero, che anzi va caricata con priorita alta (eager + fetchpriority). ``` ![...](galleria-8.webp) ``` ### fetchpriority **Perché conta.** L’attributo fetchpriority indica al browser quali risorse scaricare per prime: impostarlo a ‘high’ sull’immagine LCP (es. hero) ne anticipa il download migliorando il Largest Contentful Paint, una metrica dei Core Web Vitals che incide su ranking ed esperienza utente; impostarlo a ‘low’ su immagini secondarie libera banda per cio che conta. E un fine-tuning della performance percepita. _Motivazioni: Performance · Ranking · Esperienza utente — Priorità: Media_ **Best practice.** Usa fetchpriority=”high” sull’immagine LCP (con loading=”eager”) e lascia il default o ‘low’ alle altre; non assegnarlo a piu immagini contemporaneamente o perde efficacia. ``` ![...](hero.webp) ``` ### Responsive images (srcset e sizes) **Perché conta.** srcset e sizes permettono al browser di scegliere la variante di immagine piu adatta a risoluzione e larghezza dello schermo (mobile, retina, desktop), evitando di scaricare un file enorme su uno smartphone: cio riduce peso e tempi di caricamento (performance) migliorando l’esperienza utente e i Core Web Vitals (ranking), e garantisce nitidezza sui display ad alta densita (rendering/compatibilita). _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Fornisci piu varianti dimensionali con srcset e descrivi gli slot di layout con sizes; per art direction (ritagli diversi per device) usa l’elemento <picture> con <source media>. ``` ![...](foto-800.webp) ``` ### Formati moderni (WebP, AVIF) **Perché conta.** WebP e AVIF offrono una compressione molto superiore a JPEG/PNG a parita di qualita visiva, riducendo drasticamente il peso dei file: questo accelera il caricamento e migliora i Core Web Vitals (performance, esperienza utente, ranking). Vanno serviti con fallback per i browser piu datati (rendering/compatibilita); Google li raccomanda esplicitamente in PageSpeed Insights. _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Servi AVIF/WebP con fallback JPEG/PNG tramite <picture> o content negotiation; AVIF per la massima compressione, WebP come compromesso ampiamente supportato. ``` ![...](img.jpg) ``` ### Compressione e peso del file **Perché conta.** Il peso delle immagini e spesso la prima causa di pagine lente: ottimizzare compressione e dimensioni reali (no immagini 4000px ridotte via CSS) riduce i tempi di download, migliora LCP e i Core Web Vitals (performance, ranking) e l’esperienza su connessioni mobili lente; immagini leggere riducono anche il consumo dati e il bounce rate (conversione). _Motivazioni: Performance · Esperienza utente · Ranking · Conversione — Priorità: Alta_ **Best practice.** Ridimensiona alla dimensione massima effettivamente visualizzata, comprimi con qualita 75-85% e rimuovi metadati EXIF superflui; punta a pochi centinaia di KB per immagine in pagina. ### Naming del file immagine **Perché conta.** Un nome file descrittivo e con parole chiave (separate da trattini) aiuta i crawler a comprendere il soggetto dell’immagine in Google Immagini e fornisce un debole segnale di rilevanza (crawler/indicizzazione, ranking); migliora anche l’organizzazione e l’accessibilita dell’URL. Nomi come IMG_0423.jpg non comunicano nulla ai motori. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Media_ **Best practice.** Usa nomi descrittivi minuscoli con trattini e senza spazi/accenti (es. torta-cioccolato-fatta-in-casa.webp); evita stringhe generiche e keyword stuffing. ``` scarpa-running-nike-pegasus-41.webp ``` ### Didascalie, figure e figcaption **Perché conta.** Il testo della didascalia e tra i contenuti piu letti vicino alle immagini e fornisce contesto semantico forte ai crawler (oltre all’alt); <figure>/<figcaption> associano semanticamente la didascalia all’immagine migliorando l’accessibilita e la comprensione del contenuto da parte dei motori e degli LLM (GEO/AI), e aiutano l’utente a interpretare cio che vede (esperienza utente). _Motivazioni: Crawler/Indicizzazione · Accessibilità · Esperienza utente · GEO/AI — Priorità: Media_ **Best practice.** Usa <figure> con <figcaption> per legare didascalia e immagine quando la didascalia aggiunge informazione; la didascalia integra l’alt, non lo duplica. ``` ![Andamento vendite 2025](grafico.webp) Vendite trimestrali 2025, in crescita del 12% ``` ### Image sitemap (sitemap immagini) **Perché conta.** Le immagini caricate via JavaScript, lazy loading o in gallerie complesse possono sfuggire al crawler; dichiararle in una sitemap XML (o con le estensioni image nella sitemap principale) aiuta Google a scoprirle e indicizzarle in Google Immagini (crawler/indicizzazione), aumentando la visibilita nella ricerca per immagini e il traffico potenziale. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Includi le immagini importanti con il tag image:image nella sitemap XML, soprattutto quelle caricate dinamicamente; non serve per immagini gia facilmente raggiungibili nel markup statico. ``` https://sito.it/paginahttps://sito.it/foto.webp ``` ### Open Graph image (og:image) **Perché conta.** og:image definisce l’immagine mostrata quando la pagina viene condivisa su social e app di messaggistica: una preview accattivante aumenta CTR e condivisioni (esperienza utente, conversione) e quindi il traffico social; pur non essendo un fattore di ranking diretto, influenza i segnali di engagement. Twitter/X usa anche twitter:image. Le anteprime corrette riducono il rischio di card vuote (rendering/compatibilita). _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Imposta og:image con URL assoluto, formato 1200x630px (ratio 1.91:1), peso contenuto e og:image:alt descrittivo; verifica con i debugger social. ``` ``` ### Video: VideoObject schema (dati strutturati) **Perché conta.** Il markup VideoObject in JSON-LD permette a Google di comprendere contenuto, durata, miniatura e data di un video, abilitando rich result, key moments e l’indicizzazione in Google Video (crawler/indicizzazione, ranking); migliora la visibilita nella SERP e fornisce dati strutturati che i motori AI possono citare (GEO/AI), aumentando CTR ed engagement. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Includi name, description, thumbnailUrl, uploadDate e contentUrl/embedUrl; aggiungi duration e hasPart con clip per i key moments quando rilevante. ``` ``` ### Video: transcript e sottotitoli **Perché conta.** Una trascrizione testuale e i sottotitoli rendono il contenuto del video indicizzabile e comprensibile ai crawler e agli LLM (i motori non ‘guardano’ davvero il video), arricchendo la pagina di testo rilevante (crawler/indicizzazione, ranking, GEO/AI); migliorano l’accessibilita per utenti sordi o in contesti senza audio (accessibilita) e l’esperienza utente, e aumentano il tempo sulla pagina. _Motivazioni: Accessibilità · Crawler/Indicizzazione · Ranking · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Pubblica la trascrizione completa nel testo della pagina e fornisci sottotitoli/closed caption (file VTT) sul player; evita di affidarti solo alle caption auto-generate non riviste. ``` ``` ### Decoding e async decoding (decoding=”async”) **Perché conta.** L’attributo decoding=”async” consente al browser di decodificare l’immagine fuori dal thread principale, evitando che la decodifica di immagini pesanti blocchi il rendering e la reattivita della pagina; contribuisce a una migliore performance percepita e fluidita di caricamento (performance, esperienza utente), con effetto indiretto positivo sui Core Web Vitals. _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Aggiungi decoding=”async” alle immagini non critiche; combinalo con loading=”lazy” per le immagini sotto la piega. ``` ![...](foto.webp) ``` ### Preload dell’immagine LCP **Perché conta.** Precaricare l’immagine LCP con <link rel=”preload”> (specie quando e referenziata in CSS o caricata tardi) anticipa il suo download, migliorando il Largest Contentful Paint e quindi i Core Web Vitals e l’esperienza utente percepita; e una leva diretta di performance che incide sul ranking. Va usato con imagesrcset per le immagini responsive. _Motivazioni: Performance · Ranking · Esperienza utente — Priorità: Bassa_ **Best practice.** Precarica solo l’immagine LCP critica con as=”image” e, se responsive, imagesrcset/imagesizes coerenti; non abusare del preload per non saturare la banda. ``` ``` ## 6. Dati strutturati (Schema.org / JSON-LD) ### JSON-LD (formato consigliato vs Microdata/RDFa) **Perché conta.** JSON-LD è il formato raccomandato ufficialmente da Google perché disaccoppia i dati strutturati dal markup visibile: lo inserisci come blocco <script> nel <head> o nel <body> senza intrecciarlo con l’HTML, riducendo errori di parsing e facilitando la manutenzione e l’iniezione lato server o tramite tag manager. I crawler lo interpretano in modo affidabile per costruire la propria comprensione dell’entità di pagina, mentre Microdata e RDFa, sparsi tra gli attributi dei tag, sono più fragili e soggetti a rotture quando cambi il template. Una migliore comprensione semantica alimenta l’eleggibilità ai rich results e, sempre più, l’estrazione di entità per risposte AI/GEO. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · GEO/AI — Priorità: Alta_ **Best practice.** Usa JSON-LD come formato unico, un blocco <script type=”application/ld+json”> per pagina (o più blocchi coerenti tra loro), e mantieni i valori allineati al contenuto realmente visibile. ``` ``` ### Organization (entità del sito/brand) **Perché conta.** Il markup Organization dichiara in modo esplicito chi è l’editore del sito (nome legale, logo, contatti, sedi) e funge da nodo centrale del knowledge graph del brand: aiuta i crawler a consolidare l’identità dell’entità, può alimentare il Knowledge Panel e fornisce ai motori e ai sistemi AI un riferimento autorevole su chi pubblica i contenuti, fattore che pesa nella valutazione di affidabilità (E-E-A-T). Il campo logo va a determinare quale immagine può comparire accanto al brand nei risultati e in alcune feature SERP. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Inserisci Organization una sola volta a livello di sito (tipicamente in home), con name, url, logo (ImageObject con dimensioni adeguate) e sameAs verso i profili ufficiali; usa @id stabile per referenziarla dalle altre entità. ``` { "@type": "Organization", "@id": "https://esempio.it/#org", "name": "Esempio SRL", "url": "https://esempio.it/", "logo": "https://esempio.it/logo.png", "sameAs": ["https://www.linkedin.com/company/esempio"] } ``` ### WebSite + SearchAction (Sitelinks Searchbox) **Perché conta.** Il markup WebSite identifica il sito come entità e, abbinato a potentialAction di tipo SearchAction, segnala a Google la presenza di una ricerca interna, abilitando in teoria la Sitelinks Searchbox direttamente in SERP: un beneficio sia di visibilità (occupa più spazio nel risultato) sia di esperienza utente (l’utente cerca dentro il sito senza passaggi intermedi). Va precisato che Google ha ridotto fortemente la comparsa di questa feature, quindi il valore principale oggi resta la chiara definizione dell’entità WebSite nel knowledge graph del sito più che la searchbox in sé. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · GEO/AI — Priorità: Media_ **Best practice.** Dichiara WebSite con name e url in home, e includi SearchAction solo se esiste davvero una ricerca interna funzionante con il parametro corretto in query-input. ``` { "@type": "WebSite", "url": "https://esempio.it/", "potentialAction": { "@type": "SearchAction", "target": "https://esempio.it/?s={search_term_string}", "query-input": "required name=search_term_string" } } ``` ### BreadcrumbList **Perché conta.** Lo schema BreadcrumbList esplicita la gerarchia di navigazione della pagina e permette a Google di sostituire l’URL grezzo in SERP con un percorso a briciole di pane leggibile, migliorando la comprensione della struttura del sito da parte dei crawler e il CTR percepito dagli utenti. Funziona in sinergia con i breadcrumb HTML visibili e con la distribuzione del link juice verso le pagine di categoria padre; deve riflettere esattamente il percorso mostrato nella pagina, altrimenti è considerato markup incoerente. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Link juice/PageRank — Priorità: Alta_ **Best practice.** Genera BreadcrumbList con itemListElement ordinati (position crescente), name e item (URL) per ogni livello tranne eventualmente l’ultimo (la pagina corrente), allineato al breadcrumb visibile. ``` { "@type": "BreadcrumbList", "itemListElement": [ {"@type":"ListItem","position":1,"name":"Home","item":"https://esempio.it/"}, {"@type":"ListItem","position":2,"name":"Blog","item":"https://esempio.it/blog/"} ] } ``` ### Article / BlogPosting / NewsArticle **Perché conta.** Il markup Article descrive un contenuto editoriale fornendo a crawler e sistemi AI segnali strutturati su titolo, autore, date di pubblicazione e modifica, editore e immagine principale: questo migliora la comprensione del documento, può abilitare feature come Top Stories e l’arricchimento del risultato, e i campi datePublished/dateModified aiutano i motori a valutare freschezza e cronologia del contenuto. Collegare author e publisher a entità Person/Organization rafforza i segnali E-E-A-T, sempre più rilevanti per il ranking dei contenuti informativi e per la citazione nelle risposte generative. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Scegli il sottotipo corretto (BlogPosting per blog, NewsArticle per notizie), valorizza headline, author (Person o Organization), publisher, datePublished, dateModified e image; mantieni headline coerente con l’H1. ``` { "@type": "BlogPosting", "headline": "Come ottimizzare i Core Web Vitals", "author": {"@type":"Person","name":"Mario Rossi"}, "datePublished": "2026-05-01", "dateModified": "2026-05-20" } ``` ### LocalBusiness **Perché conta.** LocalBusiness (e i suoi sottotipi come Restaurant o Dentist) struttura i dati dell’attività locale – nome, indirizzo (PostalAddress), coordinate geo, orari di apertura, telefono – permettendo ai crawler di associare il sito all’entità locale e supportando la coerenza NAP che è centrale per il ranking nella ricerca locale e nel pacchetto mappe. Migliora l’esperienza dell’utente che trova subito orari e contatti e fornisce ai sistemi AI dati affidabili per rispondere a query con intento locale. _Motivazioni: Crawler/Indicizzazione · Ranking · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Usa il sottotipo più specifico disponibile, mantieni name/address/telefono identici a Google Business Profile e altre citazioni, e aggiungi openingHoursSpecification, geo e priceRange dove pertinente. ``` { "@type": "Dentist", "name": "Studio Bianchi", "address": {"@type":"PostalAddress","streetAddress":"Via Roma 1","addressLocality":"Milano","postalCode":"20100"}, "telephone": "+390212345678" } ``` ### Product + Offer **Perché conta.** Il markup Product con il nodo Offer fornisce ai crawler prezzo, valuta, disponibilità e condizione del prodotto, dati necessari per l’eleggibilità ai rich results di e-commerce (prezzo e disponibilità in SERP) e per il Merchant listing: questo aumenta la visibilità e il CTR e fornisce informazioni che incidono direttamente sulla decisione d’acquisto. I valori devono rispecchiare quanto mostrato sulla pagina di prodotto, perché incongruenze di prezzo o disponibilità sono una violazione delle linee guida che può causare manual action. _Motivazioni: Crawler/Indicizzazione · Conversione · Ranking — Priorità: Alta_ **Best practice.** Includi name, image, description e offers con price, priceCurrency, availability e priceValidUntil; allinea i valori al front-end e aggiorna la disponibilità in tempo reale. ``` { "@type": "Product", "name": "Scarpa Running X", "offers": {"@type":"Offer","price":"89.90","priceCurrency":"EUR","availability":"https://schema.org/InStock"} } ``` ### Review / AggregateRating **Perché conta.** Le proprietà review e aggregateRating consentono di mostrare le stelle di valutazione nei rich results, un elemento che incrementa fortemente il CTR e la fiducia dell’utente fornendo prova sociale già in SERP. Google richiede che le recensioni siano genuine, di prima parte e riferite a un’entità idonea (Product, LocalBusiness, ecc.); l’auto-review o il markup di valutazioni non visibili in pagina viola le linee guida e può portare a penalizzazioni o alla perdita del rich result. _Motivazioni: Conversione · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Applica aggregateRating solo con recensioni reali e visibili sulla pagina, includendo ratingValue, reviewCount/ratingCount e bestRating; non marcare valutazioni sull’intera azienda nella home. ``` { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "128", "bestRating": "5" } ``` ### FAQPage **Perché conta.** FAQPage struttura coppie domanda/risposta presenti sulla pagina rendendole comprensibili ai crawler e potenzialmente espandibili nei risultati; va però precisato che dal 2023 Google limita il rich result FAQ a siti governativi e sanitari autorevoli, quindi per la maggior parte dei siti il rich result non compare più. Il valore residuo è la chiarezza semantica del contenuto, utile per l’estrazione di risposte da parte dei sistemi AI/GEO e per organizzare informazioni che rispondono a query specifiche degli utenti. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Usa FAQPage solo per vere FAQ visibili in pagina, con Question/acceptedAnswer; non abusarne su pagine commerciali e non aspettarti il rich result se il sito non rientra nelle categorie ammesse. ``` { "@type": "FAQPage", "mainEntity": [{"@type":"Question","name":"Quanto costa la spedizione?","acceptedAnswer":{"@type":"Answer","text":"La spedizione è gratuita sopra i 50 euro."}}] } ``` ### HowTo **Perché conta.** HowTo descrive una procedura passo-passo (step, strumenti, materiali, tempo) aiutando i crawler a interpretare guide e tutorial; come per le FAQ, Google ha deprecato il rich result HowTo nei risultati standard, quindi oggi serve soprattutto come struttura semantica leggibile dagli LLM e dai motori per estrarre istruzioni in risposte generative. Resta un modo pulito per modellare contenuti istruttivi quando il contenuto è realmente una sequenza di passaggi. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente — Priorità: Bassa_ **Best practice.** Applica HowTo solo a guide procedurali reali con step ordinati (HowToStep con name, text, eventuale image); evita di usarlo per articoli discorsivi e non aspettarti più il rich result classico. ``` { "@type": "HowTo", "name": "Come cambiare una gomma", "step": [{"@type":"HowToStep","text":"Allenta i bulloni."}] } ``` ### DefinedTerm / DefinedTermSet **Perché conta.** DefinedTerm e DefinedTermSet modellano voci di un glossario o tassonomia come entità definite, collegando un termine alla sua definizione e a uno schema concettuale: questo aiuta i crawler e soprattutto i sistemi AI/GEO a disambiguare il significato dei termini di settore e a riconoscere il sito come fonte autorevole su un dominio semantico. Pur non generando rich result, rafforza la mappatura entità-concetto utile per topical authority e per essere citati in risposte generative. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Usa DefinedTermSet per il glossario e DefinedTerm per ogni voce con name, description e inDefinedTermSet; collega i termini con @id stabili e, dove utile, sameAs verso fonti autorevoli (es. Wikidata). ``` { "@type": "DefinedTerm", "name": "Crawl budget", "description": "Numero di pagine che un crawler scansiona in un dato periodo.", "inDefinedTermSet": "https://esempio.it/glossario/#set" } ``` ### Person / author (E-E-A-T) **Perché conta.** Marcare l’autore come entità Person, con name, url alla pagina autore, jobTitle, sameAs verso profili e affiliazioni, fornisce ai motori e ai sistemi AI segnali strutturati su chi ha prodotto il contenuto, elemento chiave dell’E-E-A-T (esperienza, competenza, autorevolezza, affidabilità). Collegare l’autore tra articoli, bio e profili esterni aiuta a consolidare l’entità autore nel knowledge graph, rafforzando la credibilità percepita del contenuto, fattore che incide su come Google valuta e potenzialmente cita le pagine, soprattutto su temi YMYL. _Motivazioni: Ranking · GEO/AI · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Definisci Person con @id stabile, name, url (pagina autore reale), sameAs e knowsAbout; riusa lo stesso @id come author negli Article per consolidare l’entità. ``` { "@type": "Person", "@id": "https://esempio.it/autori/mario-rossi/#person", "name": "Mario Rossi", "jobTitle": "SEO Specialist", "sameAs": ["https://www.linkedin.com/in/mariorossi"] } ``` ### ImageObject **Perché conta.** ImageObject descrive un’immagine come entità (url, larghezza, altezza, didascalia) e va usato per i campi image di Article, Product, Organization (logo) e simili, perché Google preferisce dimensioni esplicite e immagini ad alta risoluzione per popolare rich result e anteprime. Fornire ImageObject strutturati migliora l’eleggibilità alle feature visive in SERP, la comprensione del contenuto multimediale da parte dei crawler e la qualità delle anteprime mostrate all’utente. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Per le immagini chiave usa ImageObject con url, width e height; fornisci immagini abbastanza grandi (lato lungo idealmente >=1200px) e in più aspect ratio quando richiesto dalla feature. ``` { "@type": "ImageObject", "url": "https://esempio.it/img/copertina.jpg", "width": 1200, "height": 675 } ``` ### sameAs **Perché conta.** La proprietà sameAs collega un’entità (Organization, Person, brand) ai suoi profili e riferimenti ufficiali su altri siti – social, Wikipedia, Wikidata, LinkedIn – fornendo ai motori prove di identità che aiutano la disambiguazione e il consolidamento dell’entità nel knowledge graph. È uno dei segnali più diretti per costruire l’autorevolezza dell’entità lato GEO/AI e per associare correttamente il brand o l’autore alle fonti note, riducendo confusione con omonimi. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Ranking — Priorità: Media_ **Best practice.** Inserisci in sameAs solo URL ufficiali e controllati dall’entità (profili social, scheda Wikidata/Wikipedia), evitando link irrilevanti o non posseduti. ``` "sameAs": [ "https://www.wikidata.org/wiki/Q12345", "https://www.linkedin.com/company/esempio", "https://twitter.com/esempio" ] ``` ### @id e collegamento tra entità (grafo) **Perché conta.** Assegnare un @id stabile a ciascuna entità e referenziarlo da altri nodi (es. l’Organization come publisher dell’Article, la Person come author) trasforma blocchi isolati di markup in un grafo coerente che i crawler e i sistemi AI possono attraversare per ricostruire le relazioni tra brand, autore, pagina e contenuto. Questo evita duplicazioni, riduce ambiguità e rafforza la comprensione semantica complessiva del sito, migliorando l’affidabilità dei segnali E-E-A-T e l’estrazione di entità per le risposte generative. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Ranking — Priorità: Media_ **Best practice.** Definisci ogni entità ricorrente una sola volta con @id assoluto e univoco, poi referenziala altrove con {“@id”:”…”} invece di ripetere i dati. ``` { "@type": "Article", "publisher": {"@id": "https://esempio.it/#org"}, "author": {"@id": "https://esempio.it/autori/mario-rossi/#person"} } ``` ### Eleggibilità ai rich results e validazione **Perché conta.** Avere dati strutturati validi è condizione necessaria ma non sufficiente per ottenere i rich results: Google decide se mostrarli e richiede che siano presenti le proprietà required, che il markup rispetti le linee guida e che il contenuto sia realmente sulla pagina. Validare con il Rich Results Test e monitorare il report Miglioramenti in Search Console intercetta errori e warning che bloccano l’eleggibilità, mentre il markup corretto ma su contenuto debole non garantisce comunque la feature. _Motivazioni: Crawler/Indicizzazione · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Testa ogni tipo con il Rich Results Test e lo Schema Validator, copri tutte le proprietà required/recommended e monitora gli errori nei report di Search Console dopo il deploy. ### Errori comuni: markup non visibile, spam e incoerenza **Perché conta.** L’errore più penalizzante è marcare informazioni non presenti o non visibili nella pagina (prezzi, recensioni, FAQ nascoste) o gonfiare le valutazioni: viola le linee guida sui dati strutturati e può causare manual action, perdita dei rich result o azioni anti-spam. Altri errori frequenti sono campi required mancanti, tipi errati, valori non coerenti tra markup e front-end e duplicazione della stessa entità senza @id; tutti riducono l’affidabilità dei segnali che crawler e sistemi AI usano per fidarsi del sito. _Motivazioni: Crawler/Indicizzazione · Ranking · Sicurezza — Priorità: Alta_ **Best practice.** Marca solo ciò che è visibile all’utente, evita auto-review e dati gonfiati, mantieni i valori coerenti col contenuto reale e correggi gli errori segnalati prima di affidarti alla feature. ## 7. Social / sharing meta ### <meta property=”og:title”> **Perché conta.** Definisce il titolo che appare quando la pagina viene condivisa su Facebook, LinkedIn, WhatsApp e altre piattaforme che leggono il protocollo Open Graph; non è un fattore di ranking diretto su Google, ma controlla l’anteprima social e quindi incide sul CTR e sulla propensione alla condivisione. Senza di esso la piattaforma fa fallback sul <title> o su euristiche, spesso troncate o poco accattivanti; un og:title curato e distinto dal <title> permette di ottimizzare separatamente il messaggio per i social rispetto a quello per i motori di ricerca. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Conversione — Priorità: Alta_ **Best practice.** Imposta sempre og:title in modo esplicito (anche se coincide spesso col title), mantienilo conciso (circa 60-70 caratteri per evitare troncamenti) e centrato sul contenuto della singola pagina; va dichiarato nel <head>. ``` ``` ### <meta property=”og:description”> **Perché conta.** Fornisce il testo descrittivo dell’anteprima nelle condivisioni social; come la meta description per la SERP, non è un segnale di ranking ma agisce sull’esperienza dell’utente e sul CTR perché spiega cosa troverà nella pagina prima del clic. In assenza di og:description le piattaforme ripiegano sulla meta description o su frammenti casuali del testo, con risultati spesso incoerenti; un valore esplicito garantisce un messaggio controllato e coerente con l’immagine e il titolo dell’anteprima. _Motivazioni: Esperienza utente · Conversione · Crawler/Indicizzazione — Priorità: Alta_ **Best practice.** Scrivi una descrizione persuasiva e pertinente alla pagina, idealmente entro circa 110 caratteri perché alcune piattaforme (es. mobile) troncano presto; evita keyword stuffing e rendila complementare al titolo. ``` ``` ### <meta property=”og:image”> **Perché conta.** Specifica l’immagine mostrata nell’anteprima quando la pagina viene condivisa; è l’elemento che più di ogni altro determina l’impatto visivo e quindi il CTR e la viralità della condivisione, pur non essendo un segnale di ranking organico. Una pagina senza og:image viene condivisa con un riquadro vuoto o con un’immagine scelta a caso dal crawler social, riducendo drasticamente l’attrattiva del post; definirla esplicitamente assicura che venga usata l’immagine giusta, ben renderizzata su tutte le piattaforme. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Usa un URL assoluto (con https), un’immagine dedicata e di alta qualità, e affianca og:image:width/height e og:image:alt per rendering affidabile e accessibilità; verifica l’anteprima con i debugger ufficiali delle piattaforme. ``` ``` ### Dimensioni e peso di og:image (1200×630, rapporto 1.91:1) **Perché conta.** Il rapporto e la risoluzione dell’immagine determinano se l’anteprima viene mostrata grande e nitida oppure ritagliata, compressa o relegata a thumbnail; 1200×630 px (rapporto 1.91:1) è lo standard che genera l’anteprima a immagine grande su Facebook/LinkedIn e si abbina alla Twitter Card summary_large_image. Dimensioni troppo piccole (sotto 600×315) o proporzioni errate compromettono il rendering cross-piattaforma e riducono l’efficacia visiva, con effetto diretto su CTR e percezione di qualità del brand. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Esporta l’immagine social a 1200×630 px (minimo 600×315, rapporto 1.91:1), tienila sotto i ~5-8 MB e in formato JPG/PNG/WebP supportato; centra gli elementi importanti per resistere a eventuali crop. ``` ``` ### <meta property=”og:url”> **Perché conta.** Indica l’URL canonico dell’oggetto condiviso: serve a consolidare le interazioni social (like, condivisioni, conteggi) sulla stessa risorsa anche quando la pagina è raggiunta con parametri di tracciamento (UTM) o varianti di URL, evitando frammentazione del ‘social juice’ e doppioni nelle cache delle piattaforme. Pur non essendo il canonical SEO, agisce con logica analoga lato social e mantiene coerente l’identità della pagina nelle anteprime e nei grafi delle piattaforme. _Motivazioni: Link juice/PageRank · Crawler/Indicizzazione · Esperienza utente — Priorità: Media_ **Best practice.** Imposta og:url all’URL canonico, assoluto e pulito (senza parametri di sessione/tracking), coerente con <link rel=”canonical”>. ``` ``` ### <meta property=”og:type”> **Perché conta.** Dichiara il tipo di oggetto (website, article, product, video, ecc.) e influenza come la piattaforma interpreta e arricchisce l’anteprima, abilitando proprietà aggiuntive specifiche (per esempio article:published_time o i campi product); un tipo corretto migliora il rendering e la coerenza semantica del contenuto condiviso. Un valore mancante o errato fa ripiegare le piattaforme sul tipo generico, perdendo metadati arricchiti utili a contesto ed esperienza utente. _Motivazioni: Rendering/Compatibilità · Crawler/Indicizzazione · Esperienza utente — Priorità: Media_ **Best practice.** Usa ‘website’ per pagine generiche e ‘article’ per contenuti editoriali (abbinando le proprietà article:* quando rilevanti); scegli ‘product’ per le schede prodotto e-commerce. ``` ``` ### <meta property=”og:site_name”> **Perché conta.** Indica il nome del sito/brand che compare nell’anteprima della condivisione, rafforzando il riconoscimento del brand e la fiducia dell’utente nel momento del clic; non incide sul ranking ma contribuisce alla coerenza dell’identità e indirettamente al CTR. È particolarmente utile quando lo stesso dominio ospita un brand riconoscibile, perché distingue la fonte rispetto al solo URL. _Motivazioni: Esperienza utente · Conversione — Priorità: Bassa_ **Best practice.** Imposta un og:site_name costante su tutte le pagine, uguale al nome ufficiale del brand/sito. ``` ``` ### <meta property=”og:locale”> **Perché conta.** Specifica la lingua e l’area geografica del contenuto (es. it_IT) aiutando le piattaforme a presentare l’anteprima in modo coerente con l’audience e a gestire correttamente versioni multilingua tramite og:locale:alternate; migliora l’esperienza per utenti in lingue diverse ed evita rendering incoerenti. Non è un fattore di ranking, ma supporta la corretta localizzazione delle condivisioni in siti internazionali. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Imposta og:locale nel formato lingua_PAESE (es. it_IT) e aggiungi og:locale:alternate per ogni versione linguistica disponibile, in linea con la strategia hreflang. ``` ``` ### <meta name=”twitter:card” content=”summary_large_image”> **Perché conta.** Definisce il formato della Twitter Card (anteprima su X/Twitter); ‘summary_large_image’ attiva l’anteprima con immagine grande, molto più visibile e performante in termini di CTR rispetto alla ‘summary’ a thumbnail. Non è un segnale di ranking, ma determina l’aspetto della condivisione sulla piattaforma; in assenza di tag twitter:*, X tende a fare fallback sui tag Open Graph, quindi spesso basta integrare il solo twitter:card con OG ben configurati. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Usa ‘summary_large_image’ per contenuti con un’immagine d’impatto e ‘summary’ per contenuti minimali; non serve duplicare tutti i campi OG, perché X ne fa fallback, ma dichiara almeno twitter:card. ``` ``` ### <meta name=”twitter:title”> **Perché conta.** Stabilisce il titolo specifico per l’anteprima su X/Twitter quando vuoi differenziarlo dall’og:title; in mancanza, X usa come fallback l’og:title, quindi è opzionale ma utile per ottimizzare il messaggio sul tono e i limiti della piattaforma. Incide su CTR e condivisione, non sul ranking organico. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Specifica twitter:title solo se serve un titolo diverso da og:title (es. più breve o più colloquiale); altrimenti affidati al fallback su Open Graph per evitare ridondanza. ``` ``` ### <meta name=”twitter:description”> **Perché conta.** Imposta la descrizione dell’anteprima su X/Twitter; se assente, viene usato l’og:description come fallback, perciò serve solo quando vuoi un testo dedicato alla piattaforma. Agisce sull’esperienza utente e sul CTR del tweet, non è un fattore di ranking; X tronca la descrizione, quindi conta la sintesi. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Mantieni la descrizione molto sintetica (circa 120-200 caratteri) e usala solo per differenziarti dall’og:description; in caso contrario lascia agire il fallback. ``` ``` ### <meta name=”twitter:image”> **Perché conta.** Indica l’immagine dell’anteprima su X/Twitter; se non presente, X fa fallback su og:image, quindi è opzionale ma utile quando vuoi un’immagine differente o ottimizzata per il formato della card. È l’elemento visivo che traina l’engagement del tweet e dunque il CTR, senza alcun effetto sul ranking organico. _Motivazioni: Esperienza utente · Conversione · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Usa un URL assoluto e, per summary_large_image, un’immagine in rapporto ~1.91:1 (es. 1200×630); aggiungi twitter:image:alt per l’accessibilità. Se identica a og:image, basta affidarsi al fallback. ``` ``` ### <meta name=”twitter:site” e twitter:creator”> **Perché conta.** Associano la card all’account X del sito (twitter:site) e all’autore del contenuto (twitter:creator), aggiungendo attribuzione e rafforzando il riconoscimento del brand e dell’autore nell’anteprima; favoriscono il follow e la fiducia, con un effetto indiretto su engagement e condivisioni. Non incidono sul ranking nei motori di ricerca. _Motivazioni: Esperienza utente · Conversione — Priorità: Bassa_ **Best practice.** Inserisci gli handle con la @ (es. @brand e @autore) quando esistono account ufficiali; lascia stare i tag se non hai profili da attribuire. ``` ``` ### Fallback al <title> e <meta name=”description”> in assenza di tag social **Perché conta.** Quando mancano i tag Open Graph/Twitter, le piattaforme ricostruiscono l’anteprima usando come fallback il <title>, la meta description e immagini individuate euristicamente nella pagina; il risultato è spesso povero, troncato o incoerente, con ricadute negative su CTR e percezione del brand. Capire questa catena di fallback evita di duplicare inutilmente i tag, ma chiarisce anche perché conviene dichiarare almeno og:title, og:description e og:image per non lasciare l’anteprima al caso. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Assicurati che <title> e meta description siano comunque ottimali (fungono da rete di sicurezza), ma definisci esplicitamente i tag OG essenziali per controllare l’anteprima invece di affidarti al fallback. ``` Guida completa al SEO tecnico 2026 ``` ### Open Graph / Twitter Cards e ranking (chiarimento) **Perché conta.** I meta social NON sono fattori di ranking diretto: Google non usa Open Graph né Twitter Cards per posizionare le pagine. Il loro valore è indiretto ma reale: migliorano l’anteprima nelle condivisioni, aumentano CTR ed engagement sui social, possono incrementare traffico e segnali di brand e talvolta favorire l’acquisizione di link naturali, con un effetto di secondo ordine su autorevolezza e visibilità. È un mito attribuire a questi tag un peso diretto nell’algoritmo organico. _Motivazioni: Conversione · Esperienza utente · Link juice/PageRank — Priorità: Media_ **Best practice.** Tratta i tag social come leva di marketing e CTR (non di ranking): implementali bene per massimizzare condivisioni e traffico, ma non aspettarti che da soli migliorino le posizioni in SERP. ### Coerenza e validazione delle anteprime (debugger ufficiali) **Perché conta.** Le piattaforme social mettono in cache i metadati, quindi un tag errato o un’immagine sbagliata può restare ‘incastrato’ nelle anteprime anche dopo la correzione; validare con i debugger ufficiali forza il re-scraping, mostra come la card verrà renderizzata e segnala tag mancanti o immagini non raggiungibili. Questo garantisce rendering corretto cross-piattaforma e protegge CTR ed esperienza utente al momento della condivisione. _Motivazioni: Rendering/Compatibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Dopo ogni modifica ai meta social, testa l’URL con i validatori ufficiali (Facebook Sharing Debugger, LinkedIn Post Inspector, X Card Validator) per forzare il refresh della cache e verificare l’anteprima. ## 8. Performance, Core Web Vitals & mobile ### LCP (Largest Contentful Paint) **Perché conta.** L’LCP misura il tempo di rendering dell’elemento di contenuto piu grande nel viewport (spesso l’hero image, un video poster o un blocco di testo): e una metrica di percezione della velocita centrale per l’esperienza utente, perche un utente considera la pagina ‘utile’ quando vede il contenuto principale. E un fattore di ranking confermato (Core Web Vital nel page experience signal) e, indirettamente, un buon LCP riduce la bounce rate e aumenta la conversione. Per i crawler/render di Google un caricamento lento puo penalizzare il crawl budget su siti grandi. _Motivazioni: Esperienza utente · Ranking · Performance · Conversione — Priorità: Alta_ **Best practice.** Tenere LCP sotto 2,5s al 75esimo percentile: ottimizzare e precaricare la risorsa LCP, servire immagini in formato moderno (AVIF/WebP) dimensionate correttamente, eliminare il render-blocking, usare un buon TTFB e CDN. Evitare lazy-loading sull’elemento LCP. ``` ``` ### CLS (Cumulative Layout Shift) **Perché conta.** Il CLS quantifica gli spostamenti inattesi del layout durante il caricamento: e una metrica di stabilita visiva fondamentale per l’esperienza utente, perche layout che ‘saltano’ causano click errati e frustrazione (es. si preme un bottone che si e spostato). E un Core Web Vital usato come segnale di ranking; un layout stabile migliora anche la conversione e riduce l’abbandono. Spesso causato da immagini/iframe/ads senza dimensioni, font che cambiano (FOIT/FOUT) e contenuti iniettati dinamicamente sopra il fold. _Motivazioni: Esperienza utente · Ranking · Rendering/Compatibilità · Conversione — Priorità: Alta_ **Best practice.** Tenere CLS sotto 0,1: riservare sempre lo spazio con width/height (o aspect-ratio) su immagini, video, iframe e annunci; non iniettare contenuti sopra contenuti esistenti; usare font-display ben gestito e transform invece di proprieta che ricalcolano il layout. ``` img { aspect-ratio: 16 / 9; width: 100%; height: auto; } ``` ### INP (Interaction to Next Paint, ex FID) **Perché conta.** L’INP ha sostituito FID a marzo 2024 come Core Web Vital di reattivita: misura la latenza di tutte le interazioni dell’utente (click, tap, input da tastiera) lungo l’intera visita, riportando il valore peggiore. A differenza di FID, che valutava solo il primo input, INP cattura la reattivita reale durante l’uso. Influisce direttamente sull’esperienza utente (una UI che ‘non risponde’ frustra), e un segnale di ranking ed e tipicamente degradato da JavaScript pesante che blocca il main thread. _Motivazioni: Esperienza utente · Ranking · Performance — Priorità: Alta_ **Best practice.** Tenere INP sotto 200ms: spezzare i long task, fare yield al main thread, ridurre/posticipare il JS di terze parti, usare web worker per calcoli pesanti e debouncing sugli handler. Evitare di eseguire lavoro sincrono costoso negli event handler. ``` button.addEventListener('click', () => { showSpinner(); requestIdleCallback(doHeavyWork); }); ``` ### TTFB (Time To First Byte) **Perché conta.** Il TTFB misura il tempo tra la richiesta e la ricezione del primo byte di risposta dal server: e un prerequisito a monte di tutte le altre metriche, perche un TTFB alto ritarda inevitabilmente LCP e FCP. Dipende da latenza di rete, tempo di elaborazione server, query al database e configurazione di caching/CDN. Un TTFB lento peggiora l’esperienza utente percepita, puo erodere il crawl budget (Googlebot rallenta su server lenti) e indebolisce i Core Web Vitals a valle. _Motivazioni: Performance · Crawler/Indicizzazione · Esperienza utente — Priorità: Alta_ **Best practice.** Puntare a TTFB sotto 800ms: usare caching server-side e a livello di pagina, CDN con edge caching, connessioni keep-alive/HTTP-2, ottimizzare query e backend, e ridurre i redirect. Servire HTML statico o cache-warmed quando possibile. ``` Cache-Control: public, max-age=3600, s-maxage=86400, stale-while-revalidate=600 ``` ### Render-blocking CSS/JS **Perché conta.** Risorse CSS e JS bloccanti nel <head> impediscono al browser di renderizzare la pagina finche non sono scaricate, parsate ed eseguite: questo ritarda First Paint e LCP, peggiorando velocita percepita ed esperienza utente. Il CSS e bloccante per costruzione (necessario al CSSOM); il JS sincrono blocca il parser HTML. Ridurre il render-blocking e una delle leve piu efficaci su LCP/FCP e quindi sul page experience signal usato nel ranking. _Motivazioni: Performance · Esperienza utente · Ranking · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Inlinare il CSS critico ed estrarre il resto in caricamento differito; aggiungere defer o async agli script non essenziali e spostarli prima di </body>; rimuovere CSS/JS inutilizzato e suddividere il codice (code splitting). ``` ``` ### Minificazione e tree-shaking (CSS/JS/HTML) **Perché conta.** La minificazione rimuove spazi, commenti e caratteri superflui e accorcia i nomi delle variabili, riducendo il peso dei file trasferiti: meno byte significano download piu rapidi, parsing/esecuzione piu veloci e migliore LCP/INP, con beneficio diretto su performance ed esperienza utente, soprattutto su mobile e reti lente. Il tree-shaking elimina codice morto dai bundle. E un’ottimizzazione a basso rischio e alto impatto, soprattutto combinata con la compressione. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Automatizzare la minificazione in fase di build (Terser, esbuild, cssnano) e abilitare il tree-shaking; servire i file minificati in produzione mantenendo i source map separati per il debug. ``` // build: esbuild app.js --minify --tree-shaking=true --bundle ``` ### Compressione gzip / Brotli **Perché conta.** La compressione testuale a livello di trasporto riduce drasticamente i byte trasferiti per HTML, CSS, JS, SVG e JSON: Brotli supera generalmente gzip (10-20% in meno sul testo) ed e supportato da tutti i browser moderni. Meno byte sulla rete equivalgono a download piu rapidi, miglior LCP/FCP e minor consumo dati su mobile, con impatto diretto su performance ed esperienza utente. E complementare alla minificazione (si minifica e poi si comprime). _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Abilitare Brotli (livello 4-6 dinamico, max per asset statici) con fallback gzip via Accept-Encoding; comprimere solo risorse testuali (non immagini/video gia compressi) e pre-comprimere gli asset statici. ``` Content-Encoding: br Vary: Accept-Encoding ``` ### Caching del browser (Cache-Control / ETag) **Perché conta.** Le intestazioni di caching dicono al browser per quanto e come riutilizzare le risorse senza riscaricarle: un caching corretto rende quasi istantanee le visite ripetute e la navigazione tra pagine, migliorando esperienza utente e performance e riducendo carico server e banda. Asset versionati (fingerprint nel nome) possono avere cache lunghissima e immutabile, mentre l’HTML resta a revalidate per restare fresco. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Cache lunga e immutable per asset versionati (CSS/JS/font/immagini con hash nel nome), short cache o no-cache con revalidate per HTML; usare ETag/Last-Modified per la validazione condizionale. ``` Cache-Control: public, max-age=31536000, immutable # /app.4f2a.js ``` ### CDN (Content Delivery Network) **Perché conta.** Una CDN distribuisce gli asset (e spesso l’HTML cache-warmed) su server edge geograficamente vicini all’utente: riduce la latenza e quindi il TTFB e i tempi di download, migliorando LCP ed esperienza utente soprattutto per audience internazionali. Offre inoltre offload del traffico, terminazione TLS rapida, HTTP/2-3, compressione e protezione DDoS, e puo migliorare anche l’efficienza di crawling servendo risposte veloci a Googlebot. _Motivazioni: Performance · Esperienza utente · Crawler/Indicizzazione · Sicurezza — Priorità: Media_ **Best practice.** Servire tutti gli asset statici (e idealmente l’HTML cacheable) tramite CDN con edge caching, HTTP/2-3, Brotli e TLS moderno; configurare regole di cache coerenti con il versioning degli asset. ### Resource hints: preload, preconnect, dns-prefetch **Perché conta.** I resource hint anticipano al browser quali risorse e connessioni serviranno, ottimizzando la coda di rete: preload forza il download anticipato di risorse critiche (font, immagine LCP, CSS critico); preconnect apre in anticipo connessione + DNS + TLS verso origini terze (es. CDN, Google Fonts); dns-prefetch risolve solo il DNS come fallback piu leggero. Usati bene riducono i tempi di scoperta delle risorse e migliorano LCP; usati male (troppi preload) competono per la banda e peggiorano la performance. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Precaricare solo le risorse veramente critiche e above-the-fold con as corretto; preconnect alle origini di terze parti essenziali (max 3-4) e dns-prefetch per quelle secondarie. Non abusare di preload. ``` ``` ### Lazy loading (immagini e iframe) **Perché conta.** Il lazy loading rinvia il caricamento delle risorse fuori dal viewport finche l’utente non vi si avvicina scrollando: riduce i byte iniziali e il lavoro del browser, accelerando LCP/FCP e risparmiando banda su mobile, con beneficio su performance ed esperienza utente. L’attributo loading=lazy nativo evita JS aggiuntivo. Attenzione: non va applicato all’immagine LCP/above-the-fold, perche ne ritarderebbe il rendering e peggiorerebbe proprio l’LCP. _Motivazioni: Performance · Esperienza utente — Priorità: Media_ **Best practice.** Usare loading=lazy su immagini e iframe sotto il fold; mantenere eager (o nessun lazy) e fetchpriority=high sull’immagine LCP; specificare sempre width/height per evitare CLS. ``` ![...](/foto.avif) ``` ### font-display: swap (e ottimizzazione web font) **Perché conta.** font-display controlla come il browser gestisce il testo mentre il web font carica: il valore swap mostra subito il testo con un font di fallback e lo sostituisce poi col font definitivo, evitando il FOIT (testo invisibile) e migliorando la velocita percepita. Va bilanciato perche lo swap puo causare un piccolo layout shift (CLS) se i font hanno metriche diverse; per questo si abbinano font-fallback con size-adjust o si precarica il font. _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Usare font-display: swap (od optional per evitare shift), servire WOFF2, sottoinsiemizzare i glifi, precaricare i font critici e definire fallback con size-adjust/ascent-override per minimizzare il CLS. ``` @font-face { font-family:'Inter'; src:url(/inter.woff2) format('woff2'); font-display:swap; } ``` ### Immagini dimensionate, responsive e formati moderni **Perché conta.** Immagini senza dimensioni esplicite causano layout shift (CLS), mentre immagini sovradimensionate sprecano banda e rallentano LCP: specificare width/height (o aspect-ratio) e servire la risoluzione giusta per il dispositivo via srcset/sizes evita entrambi i problemi. I formati moderni AVIF/WebP riducono molto il peso a parita di qualita rispetto a JPEG/PNG. Insieme migliorano stabilita visiva, performance, esperienza utente e consumo dati su mobile. _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità · Conversione — Priorità: Alta_ **Best practice.** Indicare sempre width/height; usare srcset+sizes (o <picture>) per servire dimensioni e formati adatti; preferire AVIF/WebP con fallback; comprimere e usare lazy loading sotto il fold. ``` ![...](foto.jpg) ``` ### Mobile-first / responsive design **Perché conta.** Google usa l’indicizzazione mobile-first: indicizza e valuta principalmente la versione mobile del sito, quindi contenuti, link e dati strutturati devono essere presenti e accessibili anche su mobile, pena perdita di ranking. Un design responsive (un solo HTML che si adatta) garantisce parita di contenuto, evita problemi di URL separati e offre una buona esperienza su qualsiasi schermo, riducendo bounce rate e favorendo la conversione. E anche piu efficiente da crawlare rispetto a versioni mobile/desktop separate. _Motivazioni: Crawler/Indicizzazione · Ranking · Esperienza utente · Conversione — Priorità: Alta_ **Best practice.** Adottare un design responsive con CSS fluido e media query (mobile-first), assicurando contenuto e markup identici tra desktop e mobile; testare con il test di compatibilita mobile e con rendering di Googlebot. ``` @media (min-width: 768px) { .grid { grid-template-columns: repeat(3,1fr); } } ``` ### <meta name=”viewport”> **Perché conta.** Il meta viewport indica al browser mobile come scalare e dimensionare la pagina rispetto alla larghezza del dispositivo: senza di esso i dispositivi assumono un viewport desktop e mostrano la pagina rimpicciolita/da zoomare, rovinando l’esperienza mobile e segnalando una pagina non mobile-friendly (con impatto su usabilita e ranking mobile-first). E un requisito di base per qualsiasi layout responsive e per l’accessibilita su mobile. _Motivazioni: Esperienza utente · Rendering/Compatibilità · Ranking · Accessibilità — Priorità: Alta_ **Best practice.** Inserire nel <head> width=device-width, initial-scale=1; non disabilitare lo zoom utente (evitare user-scalable=no e maximum-scale=1) per non danneggiare l’accessibilita. ``` ``` ### Tap target adeguati (dimensione e spaziatura) **Perché conta.** Su mobile gli elementi interattivi (link, bottoni) devono essere abbastanza grandi e distanziati per essere toccati con il dito senza errori: target troppo piccoli o ravvicinati causano tap errati, frustrazione e abbandono, e vengono segnalati come problema di usabilita mobile. Tap target corretti migliorano esperienza utente, accessibilita (utenti con mobilita ridotta) e tasso di conversione su mobile. _Motivazioni: Esperienza utente · Accessibilità · Conversione — Priorità: Media_ **Best practice.** Dimensionare i tap target ad almeno ~48x48px (CSS) con spaziatura adeguata (~8px) tra elementi cliccabili; ampliare l’area cliccabile con padding piuttosto che con margini. ``` .btn { min-height: 48px; min-width: 48px; padding: 12px 16px; } ``` ### Critical CSS (CSS critico inline) **Perché conta.** Estrarre e inlinare nel <head> solo il CSS necessario a renderizzare l’above-the-fold elimina la dipendenza da un foglio di stile esterno bloccante per il primo paint: cosi il browser disegna subito il contenuto visibile, migliorando FCP/LCP e velocita percepita, mentre il CSS completo viene caricato in modo asincrono. E una tecnica avanzata e potente contro il render-blocking, da gestire con cura per evitare CSS critico troppo pesante (gonfia l’HTML). _Motivazioni: Performance · Esperienza utente · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Generare automaticamente il critical CSS dell’above-the-fold e inlinarlo nel <head>, caricando il resto in modo non bloccante; mantenere l’inline ridotto e rigenerarlo quando cambia il design. ``` ``` ### HTTP/2 e HTTP/3 (QUIC) **Perché conta.** I protocolli moderni eliminano colli di bottiglia di HTTP/1.1: HTTP/2 introduce multiplexing (molte richieste su una sola connessione, senza head-of-line blocking applicativo), compressione degli header e prioritizzazione, mentre HTTP/3 sposta tutto su QUIC/UDP riducendo la latenza di handshake ed eliminando l’head-of-line blocking a livello di trasporto, con grandi vantaggi su reti mobili instabili. Il risultato e un caricamento di molte risorse piu veloce, migliorando performance ed esperienza utente. _Motivazioni: Performance · Esperienza utente — Priorità: Bassa_ **Best practice.** Abilitare HTTP/2 (e HTTP/3 dove supportato dal CDN/server) con TLS moderno; con HTTP/2+ evitare lo sharding dei domini e la concatenazione eccessiva, perche il multiplexing rende controproducenti questi vecchi workaround. ``` Alt-Svc: h3=":443"; ma=86400 ``` ## 9. GEO/AI, E-E-A-T, Local & contenuto ### Passaggi answer-ready / auto-conclusivi (citabili dalle AI) **Perché conta.** I sistemi generativi (AI Overview, ChatGPT, Perplexity) non leggono la pagina intera: estraggono e citano singoli passaggi che rispondono in modo autosufficiente alla query. Un paragrafo che apre con la risposta diretta (40-60 parole), senza dipendere dal contesto precedente, ha molte più probabilita di essere selezionato come grounding citato; questo si traduce in visibilita nelle risposte AI e, di riflesso, in autorita topica e traffico referral qualificato verso il dominio. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Apri ogni sezione con una risposta diretta e autoconclusiva (chi/cosa/quando in 1-3 frasi), poi approfondisci; usa un’entita o un dato verificabile per frase così che il passaggio resti citabile estratto dal contesto. ``` ## Quanto costa un sito WordPress? Un sito WordPress costa in media 800-3.000 euro per una vetrina aziendale nel 2026, esclusi hosting (50-200 euro/anno) e manutenzione. Il prezzo dipende da numero di pagine, e-commerce e personalizzazione del tema. ``` ### FAQ strutturate per AI Overview e featured snippet **Perché conta.** Coppie domanda/risposta esplicite mappano direttamente sul formato con cui i motori generativi e gli snippet costruiscono le risposte: i crawler le associano alle query a coda lunga e in forma di domanda, le AI le riusano come blocchi citabili e migliorano l’esperienza utente offrendo la risposta a colpo d’occhio. Attenzione pero: dal 2023 Google mostra FAQ rich result quasi solo per siti governativi/sanitari, quindi il valore principale oggi è il contenuto citabile, non il rich snippet. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Scrivi FAQ con domande reali (prese da ‘People Also Ask’ / reverse-prompt) e risposte brevi e complete; marca con schema FAQPage solo se le domande sono visibili in pagina e non duplicate, senza aspettarti il rich result al di fuori delle nicchie ammesse. ``` ``` ### llms.txt e versioni testuali/markdown per crawler AI **Perché conta.** I crawler AI (GPTBot, PerplexityBot, ClaudeBot, Google-Extended) digeriscono meglio testo pulito che HTML pieno di markup, script e UI. Esporre una versione markdown/testuale dei contenuti chiave (o un indice llms.txt) riduce il rumore di parsing, aumenta la probabilita di estrazione/citazione corretta e dà controllo su cosa offrire agli LLM; va inteso come proposta emergente (non standard ufficiale Google) complementare, non sostitutiva, di un buon HTML semantico. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Performance — Priorità: Media_ **Best practice.** Pubblica /llms.txt con titolo, descrizione e link agli URL prioritari; offri per gli articoli chiave un endpoint testuale (es. .md) con solo contenuto, e decidi consapevolmente in robots.txt quali bot AI ammettere (GPTBot, Google-Extended). ``` # /llms.txt # Nome Sito — guida per LLM > Sintesi del sito in una riga. ## Pagine chiave - [Servizi](https://esempio.it/servizi): cosa offriamo - [Guida prezzi](https://esempio.it/prezzi.md): listino in testo ``` ### Controllo accesso crawler AI (robots.txt: GPTBot, Google-Extended, PerplexityBot) **Perché conta.** Bloccare o ammettere i bot AI è una scelta strategica: ammetterli aumenta la probabilita di essere citati nelle risposte generative (visibilita GEO) ma cede i contenuti all’addestramento; bloccarli protegge l’IP editoriale ma esce dalle citazioni. Va deciso in modo esplicito perché impatta crawl budget, visibilita nelle AI e tutela del contenuto, e perché alcuni bot (PerplexityBot live) servono risposte in tempo reale citando la fonte. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Sicurezza — Priorità: Media_ **Best practice.** Distingui i bot in robots.txt: tieni aperti i bot ‘live/RAG’ che citano la fonte (PerplexityBot) e valuta Google-Extended/GPTBot caso per caso; ricorda che robots.txt è un’indicazione, non un blocco tecnico. ``` User-agent: GPTBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: PerplexityBot Allow: / ``` ### Copertura entita e topical authority (cluster tematici) **Perché conta.** I motori e i sistemi generativi valutano la competenza non sulla singola keyword ma sulla copertura completa di un’entita e dei suoi sotto-temi (clustering semantico dei passaggi attorno a un centroide, come nei brevetti di thematic search). Coprire in modo esaustivo entita correlate consolida l’autorita topica del dominio, aiuta i crawler a capire di cosa tratta il sito e migliora il ranking sull’intero cluster anziché su singole URL isolate. _Motivazioni: GEO/AI · Ranking · Crawler/Indicizzazione · Link juice/PageRank — Priorità: Alta_ **Best practice.** Costruisci topic cluster pillar+supporto coprendo tutte le entita e domande del tema; usa un’analisi vettoriale per individuare i gap di copertura e collega internamente i contenuti dello stesso cluster. ``` Pillar: "Guida al marketing locale" ├─ Cluster: Google Business Profile ├─ Cluster: recensioni e reputazione └─ Cluster: SEO local on-page (tutti i supporti linkano al pillar e tra loro) ``` ### Allineamento all’intento di ricerca (search intent) **Perché conta.** Un contenuto che non rispetta l’intento dominante della query (informazionale, commerciale, transazionale, navigazionale) non posiziona, per quanto sia ottimizzato: i motori imparano dal comportamento sulla SERP quale formato soddisfa l’utente. Allineare formato e profondita all’intento riduce pogo-sticking, migliora i segnali di soddisfazione e aumenta sia ranking che conversione; per le AI, un intento chiaro rende il passaggio più facilmente abbinabile alla domanda. _Motivazioni: Ranking · Esperienza utente · Conversione · GEO/AI — Priorità: Alta_ **Best practice.** Prima di scrivere, analizza la SERP attuale della keyword: replica il tipo di contenuto che già posiziona (guida vs scheda prodotto vs lista) e assicurati che la pagina soddisfa l’intento prevalente, non quello che immagini. ``` Query "miglior CRM" → intento commerciale-comparativo → tabella comparativa + pro/contro, NON una scheda di vendita di un singolo CRM. ``` ### Freschezza e aggiornamento dei contenuti (content decay) **Perché conta.** La freschezza è un segnale di qualita sia per i ranking (query ‘query deserves freshness’, dati e prezzi datati) sia per la selezione delle fonti da parte delle AI (i sistemi di generative summaries pesano la freschezza tra i segnali di scelta della fonte). Contenuti obsoleti perdono posizioni, citazioni e fiducia; un audit periodico del decadimento intercetta le pagine in calo prima che svaniscano e mantiene viva l’autorita. _Motivazioni: Ranking · GEO/AI · Esperienza utente — Priorità: Media_ **Best practice.** Mostra date di pubblicazione e ultimo aggiornamento reali; rivedi periodicamente i contenuti che calano (content decay audit), aggiorna dati/anno/esempi e aggiorna dateModified solo a fronte di una revisione sostanziale, non cosmetica. ``` Aggiornato il 20 maggio 2026 ``` ### Segnale Author: autore identificato con byline e bio **Perché conta.** L’autorialita è un pilastro E-E-A-T: attribuire il contenuto a una persona reale con competenza dimostrabile aumenta la fiducia di utenti e motori, è cruciale nelle nicchie YMYL (salute, finanza, legale) e aiuta le AI a valutare l’affidabilita della fonte da citare. Una byline cliccabile verso una bio ricca collega esperienza ed expertise all’entita-autore riconoscibile. _Motivazioni: GEO/AI · Ranking · Esperienza utente — Priorità: Alta_ **Best practice.** Firma ogni articolo con un autore reale collegato a una pagina autore con bio, credenziali, foto e link ai profili; per i temi YMYL evidenzia esperienza diretta ed eventuale revisione di un esperto. ``` [Mario Rossi](/autori/mario-rossi) ``` ### Fonti, citazioni e link esterni autorevoli (Trust) **Perché conta.** Citare fonti primarie e autorevoli con link in uscita è un segnale di trustworthiness e di esperienza: dimostra che le affermazioni sono verificabili (lo stesso principio di grounding/verifica dei brevetti sulle generative summaries) e dà all’utente e ai motori il modo di controllare i dati. Aumenta la credibilita del contenuto, riduce il rischio percepito di disinformazione e rafforza l’E-E-A-T complessivo della pagina. _Motivazioni: GEO/AI · Ranking · Esperienza utente · Accessibilità — Priorità: Media_ **Best practice.** Supporta affermazioni e dati con link a fonti primarie autorevoli (studi, enti, documentazione ufficiale); cita la fonte e l’anno nel testo e collega il dato al riferimento esatto. ``` Secondo l'[ISTAT (2025)](https://www.istat.it/.../), il fatturato del settore è cresciuto del 4,2%. ``` ### Pagine About e Contact (trust di sito) **Perché conta.** Le pagine Chi siamo e Contatti sono tra i primi segnali di trust valutati: dimostrano che dietro il sito c’è un’entita reale, raggiungibile e responsabile, requisito esplicito per i siti YMYL e per la fiducia generale. Forniscono ai motori e alle AI l’entita-organizzazione da disambiguare e collegano il brand al Knowledge Graph, migliorando reputazione e conversione. _Motivazioni: GEO/AI · Ranking · Esperienza utente · Conversione — Priorità: Media_ **Best practice.** Pubblica una pagina About con storia, persone e missione e una pagina Contact con indirizzo fisico, telefono ed email reali; marca l’organizzazione con schema Organization e collega i profili ufficiali via sameAs. ``` ``` ### NAP consistente (Name, Address, Phone) **Perché conta.** Per la SEO local la coerenza di nome, indirizzo e telefono su sito, Google Business Profile e directory è un segnale di affidabilita usato per validare l’esistenza e la posizione dell’attivita: incongruenze (abbreviazioni, vecchi numeri) confondono i crawler, frammentano i segnali di citazione e indeboliscono il ranking locale. Un NAP identico ovunque consolida l’entita-attivita e migliora la fiducia dell’utente che ti contatta. _Motivazioni: Ranking · Crawler/Indicizzazione · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Usa esattamente la stessa stringa NAP (stesso formato, stessa via, stesso prefisso) su tutto il sito e in ogni directory; replicala nel footer e marcala con schema LocalBusiness/PostalAddress. ``` Via Roma 10, Napoli +39 081 1234567 ``` ### Google Business Profile ottimizzato **Perché conta.** Il profilo Google Business è il fulcro della visibilita nel local pack e su Maps: categoria, orari, foto, post e prossimita determinano in larga parte il ranking locale, spesso più della pagina web stessa. Un profilo completo e attivo intercetta utenti ad alto intento transazionale (chiamate, indicazioni, visite) e alimenta le AI con dati strutturati sull’attivita, incidendo direttamente su conversione e fiducia. _Motivazioni: Ranking · Conversione · Esperienza utente · GEO/AI — Priorità: Alta_ **Best practice.** Compila ogni campo (categoria primaria precisa, servizi, orari, area servita), aggiungi foto reali e aggiornate, pubblica post e rispondi a tutte le recensioni; mantieni il NAP identico a quello del sito. ### Schema LocalBusiness (dati strutturati attivita locale) **Perché conta.** Il markup LocalBusiness comunica ai crawler in modo esplicito nome, indirizzo, coordinate, orari e tipologia dell’attivita, riducendo l’ambiguita di interpretazione e abilitando rich result e knowledge panel. Rafforza il collegamento tra sito e profilo locale, aiuta le AI a recuperare dati affidabili sull’attivita e supporta il ranking nel local pack quando coerente con GBP e NAP. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Implementa LocalBusiness (o sottotipo specifico es. Restaurant) con address, geo, openingHoursSpecification e telephone coerenti col sito; usa JSON-LD e valida con il Rich Results Test. ``` ``` ### Recensioni e gestione reputazione **Perché conta.** Volume, freschezza, valutazione media e risposte alle recensioni sono segnali di reputazione e trust che incidono sul ranking locale e, soprattutto, sulla decisione dell’utente di scegliere l’attivita (conversione). Le recensioni alimentano contenuto fresco e ricco di entita/linguaggio naturale che le AI possono sintetizzare; rispondere a tutte, incluse le negative, dimostra cura e affidabilita. _Motivazioni: Ranking · Conversione · Esperienza utente · GEO/AI — Priorità: Media_ **Best practice.** Sollecita recensioni reali in modo continuo e conforme alle policy, rispondi a ognuna in modo professionale; non usare schema Review auto-attribuito sul tuo sito per stelle nei risultati (Google lo ignora/penalizza per le self-serving reviews). ### Contenuto duplicato e thin content **Perché conta.** Pagine duplicate o di scarso valore diluiscono il crawl budget, frammentano i segnali di ranking tra URL concorrenti e abbassano la qualita percepita del dominio; le AI tendono a ignorarle come fonti. Consolidare il duplicato (canonical/redirect) e arricchire o rimuovere il thin content concentra link juice e autorita sulle pagine giuste e migliora l’esperienza dell’utente che trova risposte complete. _Motivazioni: Crawler/Indicizzazione · Ranking · Link juice/PageRank · Esperienza utente — Priorità: Alta_ **Best practice.** Identifica duplicati e pagine sottili; consolida con canonical o 301 verso la versione migliore, espandi le pagine recuperabili e applica noindex o rimozione a quelle senza valore. ``` ``` ### Internal linking tematico (cluster e flusso di juice) **Perché conta.** I link interni a tema collegano i contenuti dello stesso cluster, distribuiscono il PageRank verso le pagine prioritarie e comunicano ai crawler la struttura semantica e le relazioni tra entita; per le AI, i link interni con anchor descrittiva creano un grafo di contesto che aiuta a capire la rilevanza di ogni passaggio. Una rete interna tematica rafforza l’autorita topica e fa sì che ogni pagina riceva juice, non solo la home. _Motivazioni: Link juice/PageRank · Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Alta_ **Best practice.** Collega i contenuti per affinita semantica (verificata su vettori/embedding, non solo per keyword) con anchor text descrittiva e varia; fai puntare i supporti al pillar e i pillar alle pagine di conversione. ``` Per impostare la scheda locale, vedi la [guida al Google Business Profile](/guida-google-business-profile). ``` ### Keyword cannibalization **Perché conta.** Quando più pagine competono per la stessa query, i motori non sanno quale premiare: i segnali (link, click, autorita) si dividono, le posizioni oscillano e nessuna pagina raggiunge il potenziale. La cannibalizzazione spreca link juice e crawl budget e confonde anche le AI nella scelta della fonte; risolverla consolida i segnali su un’unica URL e ne stabilizza/migliora il ranking. _Motivazioni: Ranking · Link juice/PageRank · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Mappa keyword→URL una a una; in caso di sovrapposizione consolida (merge + 301), differenzia l’intento delle pagine o scegli la pagina canonica e reindirizza/declassa le altre. ``` site:esempio.it "scarpe da corsa" → se compaiono 3 URL per la stessa intent, unisci in una sola guida e 301 le altre. ``` ## 10. Altri controlli importanti ### <meta http-equiv=”refresh”> (redirect/refresh lato client) — da evitare **Perché conta.** Il meta refresh sposta o ricarica la pagina lato client invece di usare un redirect HTTP: i crawler lo interpretano in modo inaffidabile (Google lo tratta come redirect “debole” e ne sconsiglia l’uso), spezza il pulsante Indietro del browser danneggiando l’esperienza utente, e trasferisce link juice in modo incerto rispetto a un 301 server-side. È anche un problema di accessibilità (un refresh a tempo disorienta gli utenti). _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Link juice/PageRank · Accessibilità — Priorità: Media_ **Best practice.** Non usare il meta refresh per redirezionare: implementa redirect 301 (permanenti) o 302 (temporanei) a livello server. Riserva il refresh solo a casi limite documentati e, se inevitabile, evita ritardi a tempo. ``` HTTP/1.1 301 Moved Permanently Location: https://esempio.it/nuova ``` ### Relazione tra og:url e <link rel=”canonical”> (coerenza dei segnali URL) **Perché conta.** og:url indica ai social/scraper l’URL canonico per il social graph, mentre il canonical indica ai motori la versione preferita per l’indicizzazione: se i due divergono (es. canonical senza parametri ma og:url con parametri di tracking) si inviano segnali contraddittori che confondono crawler e consolidamento dei segnali, e possono frammentare condivisioni e metriche. La coerenza tra i due rafforza il consolidamento del link juice sull’URL giusto. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Rendering/Compatibilità — Priorità: Media_ **Best practice.** Fai puntare og:url e rel=canonical alla stessa URL assoluta, pulita e auto-referenziale (senza parametri di sessione/tracking), coerente con il dominio canonicalizzato. ``` ``` ### hreflang x-default **Perché conta.** Senza x-default i motori non sanno quale versione servire a utenti la cui lingua/regione non rientra in nessun hreflang dichiarato, generando selezioni errate nei risultati internazionali e una peggiore esperienza per il pubblico non mappato. È il fallback che completa un set hreflang e ne previene errori di reciprocità. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Aggiungi sempre un <link rel=”alternate” hreflang=”x-default”> che punti alla pagina di selezione lingua o alla versione internazionale/di default; assicura che ogni URL del cluster elenchi tutte le alternative (incluso x-default) in modo reciproco e con URL assoluti. ``` ``` ### HSTS (Strict-Transport-Security header) **Perché conta.** HSTS forza il browser a usare solo HTTPS per il dominio, eliminando il redirect HTTP→HTTPS iniziale (più veloce, meno catene di redirect da seguire per i crawler) e proteggendo da attacchi di downgrade/man-in-the-middle. È un segnale di sito sicuro e ben configurato che supporta l’affidabilità (Trust) percepita. _Motivazioni: Sicurezza · Performance · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Imposta l’header Strict-Transport-Security con max-age elevato e includeSubDomains solo dopo aver verificato che tutto il sito (sottodomini compresi) sia raggiungibile in HTTPS; valuta l’inserimento nella preload list solo a configurazione stabile. ``` Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ``` ### Security headers (CSP, X-Content-Type-Options, Referrer-Policy) **Perché conta.** Header di sicurezza ben configurati proteggono gli utenti da XSS/sniffing e migliorano il Trust del sito; una Referrer-Policy corretta preserva il passaggio del referrer per analytics e attribuzione, mentre X-Content-Type-Options: nosniff evita interpretazioni errate dei tipi MIME che possono rompere il rendering o creare vulnerabilità. Non sono fattori di ranking diretti ma supportano sicurezza, affidabilità ed esperienza. _Motivazioni: Sicurezza · Rendering/Compatibilità · Esperienza utente — Priorità: Bassa_ **Best practice.** Aggiungi via header HTTP almeno X-Content-Type-Options: nosniff, una Referrer-Policy ragionevole (es. strict-origin-when-cross-origin) e una CSP testata in report-only prima dell’enforcement per non bloccare risorse legittime. ``` X-Content-Type-Options: nosniff Referrer-Policy: strict-origin-when-cross-origin Content-Security-Policy: default-src 'self' ``` ### Pagina 404 personalizzata (utile + stato corretto) **Perché conta.** Una 404 personalizzata trattiene l’utente offrendo ricerca, link alle pagine principali e percorsi di recupero (esperienza e conversione), mentre il codice di stato 404/410 corretto comunica ai crawler che la risorsa non esiste evitando l’indicizzazione di pagine vuote. Distribuire link utili dalla 404 aiuta anche il flusso interno verso pagine valide. _Motivazioni: Esperienza utente · Crawler/Indicizzazione · Conversione · Link juice/PageRank — Priorità: Media_ **Best practice.** Servi un template 404 con messaggio chiaro, barra di ricerca e link alle sezioni chiave, restituendo realmente HTTP 404 (o 410 per contenuti rimossi definitivamente); non reindirizzare massivamente le 404 alla home (genera soft 404). ``` HTTP/1.1 404 Not Found ``` ### Link interni e contenuto generati via JavaScript (crawlabilità del JS) **Perché conta.** I link inseriti solo in onclick/JS o i contenuti renderizzati lato client possono non essere scoperti finché Google non esegue il rendering (seconda ondata, con ritardo), e altri crawler/AI spesso non eseguono JS affatto: i link non in <a href> non passano PageRank in modo affidabile e i contenuti JS-only rischiano di restare fuori dall’indice. Impatta scoperta, indicizzazione e distribuzione del juice. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Rendering/Compatibilità · GEO/AI — Priorità: Alta_ **Best practice.** Usa veri <a href=”…”> per ogni link importante (no navigazione solo via onclick), e rendi disponibile il contenuto critico nell’HTML iniziale tramite SSR/SSG o idratazione progressiva; evita di dipendere dall’esecuzione JS per testo e link indicizzabili. ``` [Scarpe](/categoria/scarpe) Scarpe ``` ### Rendering: SSR / SSG / prerendering per siti JavaScript **Perché conta.** Per SPA e siti JS-heavy, fornire HTML già renderizzato lato server riduce la dipendenza dal rendering differito di Googlebot e abilita i crawler AI/social (che spesso non eseguono JS) a leggere contenuti e meta: migliora velocità di indicizzazione, LCP/TTFB percepiti e la citabilità da parte di motori generativi. Riguarda indicizzazione, performance e GEO/AI. _Motivazioni: Crawler/Indicizzazione · Performance · GEO/AI · Rendering/Compatibilità — Priorità: Alta_ **Best practice.** Adotta SSR o pre-rendering (statico/dinamico) per le pagine indicizzabili, assicurando che HTML, meta tag, canonical e dati strutturati siano presenti nella risposta iniziale senza richiedere esecuzione JS; verifica con il test “HTML reso” e con cURL/disattivando il JS. ### Contenuto in <iframe> e <embed> **Perché conta.** Il contenuto in un iframe appartiene a un documento separato e generalmente non viene attribuito alla pagina che lo ospita ai fini dell’indicizzazione: testo e link dentro l’iframe non contano come contenuto/link della pagina padre. Affidare contenuto principale a iframe rischia di renderlo invisibile per ranking e per i crawler AI. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Bassa_ **Best practice.** Non inserire contenuto principale o link SEO-critici in iframe; usa l’iframe solo per embed esterni (mappe, video) e fornisci titolo/contesto in pagina. Se necessario, esponi gli stessi contenuti anche come HTML nativo della pagina. ``` ``` ### Dati strutturati Event **Perché conta.** Lo schema Event abilita rich result per eventi (date, luogo, modalità online/offline, biglietti) in Ricerca e in superfici dedicate, aumentando visibilità e CTR e fornendo a motori e AI dati machine-readable per rispondere a query su eventi. Senza markup, queste informazioni restano solo testo non strutturato. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI · Conversione — Priorità: Bassa_ **Best practice.** Marca gli eventi con Event (name, startDate/endDate con fuso, eventStatus, eventAttendanceMode, location/VirtualLocation, offers); mantieni i dati strutturati coerenti col contenuto visibile e aggiorna stato/date in caso di rinvio o annullamento. ``` {"@context":"https://schema.org","@type":"Event","name":"Webinar SEO","startDate":"2026-07-10T18:00+02:00","eventAttendanceMode":"https://schema.org/OnlineEventAttendanceMode","location":{"@type":"VirtualLocation","url":"https://esempio.it/live"}} ``` ### Speakable (SpeakableSpecification) per ricerca vocale **Perché conta.** Speakable indica quali parti della pagina sono adatte alla lettura vocale (assistenti/TTS), aiutando le superfici voice e potenzialmente le risposte generative a identificare i passaggi sintetizzabili. È un segnale di struttura answer-ready che si integra con i contenuti auto-conclusivi citabili dalle AI. _Motivazioni: GEO/AI · Accessibilità · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Applica Speakable (tramite cssSelector o xpath) solo a sezioni brevi e auto-conclusive (es. sintesi/risposta diretta) di contenuti tipo news; non marcare l’intero articolo e mantieni coerenza col testo visibile. ``` {"@context":"https://schema.org","@type":"WebPage","speakable":{"@type":"SpeakableSpecification","cssSelector":[".risposta-sintetica"]}} ``` ### Landmark ARIA e accessibilità (ruoli, aria-label, skip link) **Perché conta.** Ruoli/landmark coerenti con i tag semantici, etichette ARIA e skip link migliorano la navigazione per screen reader (accessibilità) e rafforzano la chiarezza strutturale che i crawler usano per capire le aree della pagina; un sito accessibile riduce frizioni, amplia il pubblico e sostiene indirettamente engagement e conversioni. Da usare a complemento, non in sostituzione, dell’HTML semantico. _Motivazioni: Accessibilità · Esperienza utente · Crawler/Indicizzazione — Priorità: Media_ **Best practice.** Preferisci sempre l’HTML semantico nativo (<nav>, <main>, <header>); aggiungi ARIA solo dove serve (es. aria-label per più <nav>, aria-current sul link attivo, skip link a inizio pagina). Non duplicare ruoli già impliciti nei tag. ``` [Salta al contenuto](#main) … … ``` ### Sitemap video (video sitemap / markup VideoObject in sitemap) **Perché conta.** Una sitemap video (o le estensioni video nella sitemap) segnala a Google contenuti video con metadati (titolo, descrizione, thumbnail, durata, URL del player/contenuto), favorendone scoperta e indicizzazione e l’eleggibilità a risultati video. Complementa il VideoObject on-page accelerando la crawlabilità dei media. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Includi i video in una sitemap con i campi obbligatori (thumbnail_loc, title, description e content_loc o player_loc); mantieni i metadati coerenti col VideoObject in pagina e aggiorna alla rimozione/scadenza dei video. ``` https://esempio.it/video …/thumb.jpg Titolo… …/video.mp4 ``` ### Sitemap news (Google News) e markup NewsArticle **Perché conta.** Per siti editoriali, la sitemap news comunica gli articoli pubblicati nelle ultime 48 ore con data e testata, accelerando la scoperta e l’idoneità a Google News/Top Stories dove la velocità di indicizzazione è critica. Si integra con NewsArticle e con la freschezza dei contenuti. _Motivazioni: Crawler/Indicizzazione · Ranking — Priorità: Bassa_ **Best practice.** Genera una news sitemap separata con solo articoli recenti (max 48h, fino a 1000 URL), includendo news:publication (name, language) e news:publication_date; rimuovi gli articoli più vecchi di 2 giorni e abbinala a markup NewsArticle. ``` https://esempio.it/notizia Testata it 2026-06-01 Titolo ``` ### Last-Modified / If-Modified-Since e <lastmod> in sitemap **Perché conta.** Un Last-Modified accurato (e il supporto a If-Modified-Since con risposta 304) permette ai crawler di rilevare se una pagina è cambiata senza riscaricarla, risparmiando crawl budget e velocizzando il refresh dei contenuti aggiornati; un <lastmod> affidabile in sitemap guida le ri-visite verso le pagine effettivamente modificate. Tocca crawlabilità, performance e freschezza. _Motivazioni: Crawler/Indicizzazione · Performance — Priorità: Media_ **Best practice.** Imposta Last-Modified coerente con l’effettiva modifica del contenuto e gestisci correttamente le richieste condizionali (304 Not Modified); popola <lastmod> in sitemap solo con date veritiere di aggiornamento sostanziale, non a ogni rigenerazione. ``` Last-Modified: Mon, 01 Jun 2026 10:00:00 GMT …2026-06-01 ``` ### QAPage e Q&A markup (vs FAQPage) **Perché conta.** Per pagine di domande e risposte generate dagli utenti (forum, community), QAPage è il tipo corretto e distinto da FAQPage (riservato alle FAQ redatte dall’editore): usare il markup giusto evita azioni manuali per uso improprio dei dati strutturati e abilita l’eleggibilità ai relativi rich result. È una questione di correttezza e conformità delle linee guida. _Motivazioni: Crawler/Indicizzazione · Ranking · GEO/AI — Priorità: Bassa_ **Best practice.** Usa QAPage solo dove c’è una singola domanda con risposte multiple proposte dagli utenti (mainEntity di tipo Question con acceptedAnswer/suggestedAnswer); usa FAQPage solo per FAQ ufficiali del sito, mai per contenuti pubblicitari o di vendita. ``` {"@context":"https://schema.org","@type":"QAPage","mainEntity":{"@type":"Question","name":"Come...?","acceptedAnswer":{"@type":"Answer","text":"..."}}} ``` ### BreadcrumbList in JSON-LD allineato alle breadcrumb visibili **Perché conta.** Il markup BreadcrumbList consente a Google di mostrare il percorso a briciole nello snippet al posto dell’URL grezzo, migliorando comprensione della gerarchia da parte dei crawler e CTR per gli utenti; deve rispecchiare le breadcrumb visibili in pagina per non incorrere in incoerenza dei dati strutturati. Si lega sia ai dati strutturati sia alla navigazione interna. _Motivazioni: Crawler/Indicizzazione · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Genera BreadcrumbList con itemListElement ordinati (position, name, item URL) coerenti al 100% con la breadcrumb HTML visibile; non includere passi inesistenti né la pagina corrente come link. ``` {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://esempio.it/"}]} ``` ### Dimensione e contenuto del DOM / peso della pagina (page weight, # nodi) **Perché conta.** Un DOM eccessivamente grande e pagine molto pesanti rallentano rendering e Core Web Vitals (LCP/INP), aumentano l’uso di memoria su mobile e possono ostacolare il rendering completo da parte dei crawler; pagine più leggere costano meno crawl budget e offrono un’esperienza migliore. Impatta performance, esperienza e indicizzazione. _Motivazioni: Performance · Esperienza utente · Crawler/Indicizzazione — Priorità: Bassa_ **Best practice.** Mantieni il DOM contenuto (linea guida indicativa: evitare migliaia di nodi e nesting profondo), limita il peso totale, usa paginazione/virtualizzazione per liste enormi e rimuovi markup superfluo; monitora con Lighthouse. ### PWA / Web App Manifest e installabilità **Perché conta.** Il manifest (con name, icone, theme_color, display) abilita l’installazione come app e una migliore integrazione mobile, rafforzando engagement e ritorni; pur non essendo un fattore di ranking diretto, supporta esperienza utente mobile e coerenza del branding insieme a theme-color e favicon. Va distinto dai segnali di ranking veri e propri. _Motivazioni: Esperienza utente · Performance · Rendering/Compatibilità — Priorità: Bassa_ **Best practice.** Fornisci un manifest valido referenziato nel <head>, con icone in più dimensioni e theme_color coerente; non aspettarti benefici diretti di ranking, ma migliori metriche di engagement su mobile. ``` ``` ### Gestione dei contenuti duplicati cross-domain e scraping/syndication **Perché conta.** Quando lo stesso contenuto è ripubblicato su altri domini (syndication) o copiato da scraper, senza un canonical cross-domain o un accordo di attribuzione il motore può attribuire ranking e link juice alla copia invece che all’originale, cannibalizzando visibilità e autorità. È un tema di indicizzazione, consolidamento dei segnali e Trust. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking — Priorità: Media_ **Best practice.** Per i contenuti dati in syndication, chiedi un rel=canonical cross-domain verso l’originale (o almeno un link attribuito); pubblica per primo sull’originale e usa la Search Console per monitorare la corretta attribuzione. ``` ``` ### Internazionalizzazione: struttura ccTLD / sottodominio / sottocartella + geotargeting **Perché conta.** La scelta tra ccTLD (.it, .fr), sottodomini o sottocartelle determina come i motori associano il sito a un Paese e come si distribuisce l’autorità: le sottocartelle concentrano il link juice su un unico dominio, i ccTLD danno un forte segnale geografico ma frammentano l’autorità. Va coordinata con hreflang per servire la versione giusta agli utenti corretti. _Motivazioni: Crawler/Indicizzazione · Link juice/PageRank · Ranking · Esperienza utente — Priorità: Bassa_ **Best practice.** Scegli una struttura coerente (spesso sottocartelle per lingua su un dominio principale per consolidare l’autorità), abbinala a hreflang reciproci con x-default ed evita redirect automatici basati solo su IP che bloccano i crawler. ``` esempio.com/it/ esempio.com/en/ (sottocartelle) vs esempio.it / esempio.fr (ccTLD) ``` ### Markup prezzo/disponibilità avanzato (shippingDetails, MerchantReturnPolicy, priceValidUntil) **Perché conta.** Per l’e-commerce, arricchire Offer con disponibilità, validità prezzo, spese di spedizione e politica di reso abilita rich result più completi (anche nelle schede prodotto e in superfici shopping) e fornisce a motori e AI dati accurati, riducendo discrepanze che generano warning in Search Console. Migliora visibilità, fiducia e conversione. _Motivazioni: Crawler/Indicizzazione · Ranking · Conversione · GEO/AI — Priorità: Media_ **Best practice.** In Offer specifica price, priceCurrency, availability e priceValidUntil; aggiungi shippingDetails e hasMerchantReturnPolicy quando disponibili, mantenendo i valori sincronizzati col prezzo/stock reali mostrati in pagina. ``` {"@type":"Offer","price":"49.90","priceCurrency":"EUR","availability":"https://schema.org/InStock","priceValidUntil":"2026-12-31"} ``` ### Profile/Author bio collegata (Person + knowsAbout, E-E-A-T) **Perché conta.** Collegare l’autore a una vera pagina profilo con Person (sameAs ai profili ufficiali, knowsAbout, credenziali) rafforza i segnali di esperienza/autorevolezza che alimentano E-E-A-T e la fiducia di utenti e motori, e fornisce alle AI un’entità autore identificabile e citabile. Va oltre la semplice byline collegandola al grafo delle entità. _Motivazioni: Ranking · GEO/AI · Esperienza utente · Link juice/PageRank — Priorità: Media_ **Best practice.** Crea pagine autore reali con bio, foto, sameAs ai profili autorevoli e markup Person collegato via @id all’author dell’Article; mantieni coerenza tra byline visibile, pagina profilo e dati strutturati. ``` {"@type":"Person","@id":"https://esempio.it/autori/mario#person","name":"Mario Rossi","knowsAbout":["SEO"],"sameAs":["https://www.linkedin.com/in/mariorossi"]} ``` ### Cookie banner / interstitial e contenuti intrusivi **Perché conta.** Banner cookie a tutto schermo, pop-up e interstitial intrusivi che coprono il contenuto principale subito dopo l’arrivo da ricerca degradano l’esperienza mobile e sono esplicitamente scoraggiati da Google (intrusive interstitials); possono inoltre peggiorare CLS/INP e frenare le conversioni. Riguarda esperienza, performance e, indirettamente, ranking mobile. _Motivazioni: Esperienza utente · Performance · Ranking · Conversione — Priorità: Media_ **Best practice.** Usa cookie banner non intrusivi (barra/box che non oscura il contenuto), evita interstitial a tutto schermo subito dopo il click dalla SERP, e assicura che il consenso non blocchi crawl/rendering dei contenuti indicizzabili né causi layout shift. ### Coerenza tra contenuto per i crawler e per gli utenti (no cloaking) **Perché conta.** Mostrare a Googlebot un contenuto diverso da quello servito agli utenti (cloaking) viola le linee guida e può portare ad azioni manuali e deindicizzazione; tecniche di personalizzazione/A-B test devono restare neutre verso i crawler. È un tema di conformità, Trust e sicurezza dell’indicizzazione, particolarmente rilevante con rendering JS e geo/user-agent detection. _Motivazioni: Crawler/Indicizzazione · Ranking · Sicurezza — Priorità: Media_ **Best practice.** Servi a crawler e utenti lo stesso contenuto sostanziale; per A/B test usa redirect 302 e rel=canonical verso l’originale e non discriminare per user-agent Googlebot; evita reindirizzamenti o contenuti differenziati basati su geolocalizzazione che nascondano contenuto ai crawler. ### Date di pubblicazione e aggiornamento (datePublished / dateModified visibili e in markup) **Perché conta.** Esporre datePublished e dateModified (in pagina e in Article) aiuta Google a valutare la freschezza e a mostrare date corrette nello snippet, mentre per le AI fornisce un riferimento temporale per citare informazioni aggiornate; date incoerenti o gonfiate artificialmente minano il Trust. Collega freschezza dei contenuti e dati strutturati. _Motivazioni: Crawler/Indicizzazione · GEO/AI · Esperienza utente · Ranking — Priorità: Media_ **Best practice.** Mostra date di pubblicazione e ultimo aggiornamento veritiere, allineate ai campi datePublished/dateModified del markup Article; aggiorna dateModified solo a fronte di modifiche sostanziali, non cosmetiche. ``` {"@type":"Article","datePublished":"2026-01-10","dateModified":"2026-06-01"} ``` ### Accesso ai crawler bloccato da CSS/JS in robots.txt **Perché conta.** Bloccare in robots.txt le risorse CSS/JS necessarie al rendering impedisce a Google di renderizzare correttamente la pagina, con rischio di valutazione errata del layout, del mobile-friendliness e persino del contenuto caricato via JS. È un errore tecnico che danneggia indicizzazione e segnali di rendering/mobile. _Motivazioni: Crawler/Indicizzazione · Rendering/Compatibilità · Ranking — Priorità: Media_ **Best practice.** Consenti la scansione di CSS e JS essenziali al rendering (non fare Disallow su /assets, /css, /js critici); verifica il rendering con il test della pagina pubblicata in Search Console. ``` # evita di bloccare risorse di rendering User-agent: * Allow: /wp-content/themes/*.css Allow: /wp-includes/js/ ``` ### Markup di entità per AI/GEO: dichiarazione esplicita dell’entità principale (about / mentions / @id) **Perché conta.** Dichiarare l’entità principale della pagina (about) e le entità citate (mentions), collegandole al grafo via @id e sameAs, aiuta motori e AI a disambiguare il tema e ad associare il contenuto alle entità del Knowledge Graph, rafforzando la copertura entità e la citabilità generativa. Estende i dati strutturati verso il GEO. _Motivazioni: GEO/AI · Crawler/Indicizzazione · Ranking — Priorità: Media_ **Best practice.** Usa about per l’entità centrale e mentions per quelle correlate, con sameAs verso fonti autorevoli (Wikipedia, Wikidata) e @id coerenti nel grafo del sito; mantieni l’entità dichiarata allineata al focus reale del contenuto. ``` {"@type":"Article","about":{"@type":"Thing","name":"SEO tecnico","sameAs":"https://it.wikipedia.org/wiki/Ottimizzazione_per_i_motori_di_ricerca"}} ``` ## Miti SEO da sfatare Credenze diffuse ma scorrette: evitarle ti fa risparmiare lavoro inutile. Il meta tag keywords NON è un fattore di ranking per Google: dichiarato non usato dal 2009; non inserirlo come tattica SEO (al massimo citarlo solo per spiegare che è ignorato/potenzialmente sfruttabile dai competitor per spiare le keyword). - Non esiste una ‘keyword density’ ottimale da rispettare: ripetere una percentuale prefissata di keyword è un mito; conta la pertinenza semantica e la copertura dell’intento, non un rapporto numerico, e lo stuffing è penalizzabile. - Google NON usa Google Analytics, il bounce rate o il ‘tempo sulla pagina’ di GA come fattore di ranking diretto: questi sono dati di terze parti non disponibili al ranking; non spacciare ‘metriche di engagement di GA’ come segnali SEO. - Non esiste un ‘Domain Authority’ ufficiale di Google: DA/DR sono metriche di tool di terze parti (Moz/Ahrefs), non punteggi usati da Google; evitare di presentarle come fattore di ranking. - Inviare la sitemap o usare lo strumento di indicizzazione NON garantisce l’indicizzazione né velocizza il ranking: la sitemap aiuta la scoperta, ma indicizzazione e posizionamento dipendono da qualità e altri segnali. - rel=canonical NON è un comando vincolante ma solo un suggerimento: Google può scegliere un canonical diverso; non trattarlo come garanzia, e non usarlo al posto di noindex o redirect quando serve escludere/spostare davvero una pagina. - noindex in robots.txt NON è supportato: la direttiva noindex va nel meta robots o nell’header X-Robots-Tag; un Disallow in robots.txt impedisce la scansione ma NON la deindicizzazione (l’URL può restare indicizzato senza snippet). - I Core Web Vitals sono un fattore di ranking minore e di ‘tie-break’, non un moltiplicatore magico: una pagina lenta ma molto pertinente può comunque posizionarsi; non promettere scalate di ranking solo migliorando i CWV. - HTTPS è un fattore di ranking molto leggero (tie-break), non un boost sostanziale: va adottato per sicurezza e fiducia, non aspettandosi salti di posizione. - Open Graph e Twitter Cards NON sono fattori di ranking diretti: servono all’anteprima social (CTR/condivisioni), non al posizionamento organico; vanno presentati come ottimizzazione di sharing. - I dati strutturati NON aumentano il ranking di per sé: abilitano i rich result (visibilità/CTR), ma non sono un fattore di posizionamento diretto; lo spam di markup non visibile o incoerente può causare azioni manuali. - Non esiste un ‘sandbox’ o un punteggio segreto che penalizza ogni sito nuovo per X mesi in modo deterministico: i siti nuovi semplicemente hanno meno segnali/storico; è un mito trattarlo come penalità garantita. - LSI keywords non sono un concetto usato da Google: ‘Latent Semantic Indexing’ è una tecnica datata e i ‘LSI keyword tool’ sono marketing; ciò che conta è la copertura semantica e delle entità, non liste di sinonimi LSI. - Più lungo NON significa automaticamente migliore: la lunghezza non è un fattore di ranking; la correlazione tra contenuti lunghi e ranking dipende dalla completezza nel soddisfare l’intento, non dal conteggio parole. - AMP non è (più) un requisito né un fattore di ranking per Top Stories: dal 2021 non è obbligatorio per i Top Stories e non dà boost; va considerato legacy e non raccomandato come pratica SEO attuale. - rel=prev/next NON è più usato da Google per la paginazione: il supporto è stato dismesso; non presentarlo come tecnica attiva, anche se altri motori/uso semantico possono ancora valerne la pena. - Il PageRank pubblico (toolbar) non esiste più dal 2016: non citare valori di PageRank visibili; il PageRank interno esiste come concetto di flusso del link juice, ma non come punteggio consultabile. - Aggiornare la data di ‘ultima modifica’ senza cambiare davvero il contenuto NON migliora la freschezza/ranking: il refresh cosmetico delle date è inefficace e può minare il Trust se ingannevole. - Submitting a Google/usare ‘crawl-delay’ su Googlebot non funziona: Google ignora la direttiva crawl-delay in robots.txt; la frequenza di scansione si gestisce con altri mezzi (server, Search Console), non con crawl-delay. ## Domande frequenti sulla checklist SEO ### Che cos’è una checklist SEO? È una lista strutturata di controlli tecnici, di struttura e di contenuto che rende una pagina leggibile dai motori di ricerca e dagli assistenti AI. Serve a non dimenticare nulla durante l’ottimizzazione e l’audit. ### Quanti elementi SEO bisogna controllare? Dipende dal sito, ma una checklist completa copre **oltre 180 elementi** su 9 aree (tag tecnici, struttura semantica, link, URL, media, dati strutturati, social, performance e GEO/AI). Non sono tutti ugualmente urgenti: si lavora per priorità. ### Da dove conviene iniziare? Dalle voci a priorità Alta: codifica e viewport, title e meta description, canonical e direttive robots, un solo H1 con gerarchia corretta, link interni e breadcrumb, URL puliti, HTTPS e Core Web Vitals. Poi si passa a dati strutturati, social meta e ottimizzazione GEO. ### Le breadcrumb sono importanti per la SEO? Sì: aiutano i crawler a capire la gerarchia del sito, migliorano la navigazione dell’utente e distribuiscono link juice verso le categorie superiori; con i dati strutturati BreadcrumbList possono comparire direttamente nei risultati di ricerca. ### Il meta keywords serve ancora? No: Google dichiara di non usarlo come fattore di ranking ed espone solo le tue keyword alla concorrenza. Nella maggior parte dei casi conviene ometterlo.