L'analisi SEO tecnica verifica come gli spider dei motori di ricerca scansionano il sito. I fattori che influenzano il posizionamento si dividono in:

• On-site — codice, struttura URL, meta tag, canonical, hreflang, tag semantici HTML, microdati, FAQ, E-E-A-T, llms.txt, ecc.
• Performance — Core Web Vitals, ottimizzazione asset.
• Contenuti e consigli — E-E-A-T, testimonianze, FAQ, trust signals e-commerce, profilo backlink, segnali social.

Entity

L'entity è la rappresentazione che Google costruisce del brand incrociando Open Graph, social, Google Business Profile e correlati delle ricerche. Se l'entity è ambigua o incoerente, il posizionamento ne risente.

Cosa verificare

• Nome, categoria e descrizione del brand coerenti su tutti i canali
• Open Graph compilato correttamente su tutte le pagine principali
• Google Business Profile aggiornato e allineato ai servizi erogati
• Nessun profilo/pagina secondario che crea ambiguità nell'entity

Struttura URL

L'autorità si trasferisce dalla home alle pagine interne tramite link. URL più lunghe diluiscono questa autorità. Google premia le URL parlanti e penalizza quelle con codici o parametri tecnici esposti.

Best practice

• URL parlanti: /categoria/sottocategoria/pagina
• Separatore: trattino (-), non underscore (_)
• Gerarchia esplicita nella URL anche per schede prodotto/annuncio
• Parametri tecnici gestiti via canonical o robots.txt, non esposti come URL canoniche
• Verificare che site:dominio.it restituisca la home in prima posizione

Contenuto duplicato

Stesso contenuto su URL diverse genera contenuto duplicato, con rischio di cannibalizzazione e dispersione del link equity. Cause tipiche: parametri URL (filtri, ordinamento, paginazione), versioni www/non-www, http/https entrambe accessibili.

Soluzione: rel canonical

Ogni pagina con parametri deve avere un canonical che punta alla versione pulita. Per le paginazioni con filtri, usare un self-referencing canonical che mantiene solo page:

<!-- URL reale: /categoria?filtro=valore&page=5 -->
<link rel="canonical" href="https://www.dominio.it/categoria?page=5" />

Da implementare programmaticamente per coprire tutte le pagine con parametri.

Soft 404

URL che restituisce HTTP 200 ma senza contenuto utile. Google la tratta come pagina di bassa qualità e spreca crawl budget su di essa.

Cause tipiche

• Archivi/categorie con zero risultati che rendono comunque il template
• Paginazioni oltre l'ultimo elemento disponibile
• Ricerche interne senza risultati, indicizzabili

Soluzione

• Archivio vuoto → restituire HTTP 404
• In alternativa: <meta name="robots" content="noindex">

Robots.txt

Presente all'indirizzo /robots.txt, indica agli spider cosa indicizzare. Parametrizzazioni non escluse generano duplicati nell'indice.

Struttura base

User-agent: *
Disallow: /*?*sort=
Disallow: /*?*filtro=
Disallow: /cerca?*
Disallow: /service/*

Sitemap: https://www.dominio.it/sitemap.xml

Note

• Il Disallow non rimuove dall'indice le pagine già indicizzate — usare prima noindex, poi Disallow
• Il percorso della Sitemap nel robots.txt deve corrispondere esattamente a quello inviato in Search Console

File llms.txt

Standard proposto nel 2024 (Jeremy Howard / fast.ai) analogo al robots.txt ma rivolto ai crawler AI (ChatGPT, Claude, Gemini, Perplexity, ecc.). Permette di indicare come i modelli linguistici devono trattare e citare i contenuti del sito. Non ancora standardizzato, ma adottato da molti siti tecnici e documentazioni.

Struttura base

# Nome Sito
> Breve descrizione del sito e del suo scopo.

## Sezioni principali

- [Homepage](https://www.dominio.it/): descrizione della home
- [Documentazione](https://www.dominio.it/docs/): guide tecniche
- [Blog](https://www.dominio.it/blog/): articoli di approfondimento

## Note per i modelli AI

- Citare sempre la fonte con URL completa
- I contenuti sono aggiornati mensilmente

Posizionamento e varianti

• File testuale (text/plain) nella root: https://www.dominio.it/llms.txt
• Variante llms-full.txt: versione estesa con contenuto completo delle pagine principali per RAG
• Alcuni siti espongono anche /llms.xml o endpoint JSON per i modelli che supportano la struttura dati

Riferimento: llmstxt.org

Rel Canonical

Indica al motore quale è la pagina "principale" tra versioni simili. Un solo canonical per pagina, deve puntare a una URL che risponde HTTP 200.

Regole

1. Pagine di paginazione → canonical alla prima pagina della categoria
2. Pagine con filtri/parametri → canonical alla pagina senza filtri
3. Schede prodotto/annuncio → self-referencing (canonical a se stesse)

Errore comune

<!-- ERRATO: canonical include il parametro -->
<link rel="canonical" href="https://www.dominio.it/categoria?filtro=valore" />

<!-- CORRETTO -->
<link rel="canonical" href="https://www.dominio.it/categoria" />

Meta tag

Title

• Unico per ogni pagina, 50–60 caratteri
• Deve riflettere il contenuto specifico della pagina
• Una translation key non risolta (es. front::controller.title) nel title è un errore critico

Meta Description

• Non influenza direttamente il ranking, ma determina il CTR — che è un segnale indiretto
• Unica per pagina, 120–160 caratteri

Meta Robots

<meta name="robots" content="noindex, nofollow">

Tag H1

• Un solo H1 per pagina
• Nei siti multilingua: l'H1 della versione alternativa deve essere tradotto — un H1 identico in due lingue è un duplicato
• Includere la keyword primaria

Tag HTML semantici

I tag semantici descrivono il significato del contenuto — non solo la sua presentazione. Permettono ai motori di ricerca di identificare con precisione le parti della pagina (navigazione, contenuto principale, articolo, contatti ecc.) e contribuiscono alla comprensione dell'entità del brand.

Principali tag e utilizzo corretto

Esempio: struttura articolo

<article>
  <header>
    <h1>Come ottimizzare le immagini per il web</h1>
    <address>
      Di <a rel="author" href="/autori/mario-rossi">Mario Rossi</a>
    </address>
    &mdash; Pubblicato il <time datetime="2026-03-26">26 marzo 2026</time>
  </header>

  <section>
    <h2>Formati consigliati</h2>
    <figure>
      <img src="confronto-formati.webp" alt="Confronto visivo tra WebP, AVIF e JPG">
      <figcaption>Confronto dimensione file a parità di qualità visiva</figcaption>
    </figure>
    <p>Il formato WebP riduce il peso del 30–50% rispetto al JPG...</p>
  </section>
</article>

Errori comuni

• Usare <div> per tutto — perdita completa del contesto semantico per il crawler
• <address> per indirizzi fisici generici non correlati all'autore/organizzazione del documento
• Più <main> nella stessa pagina — valido solo con hidden sugli alternativi
• <article> annidati senza relazione logica (es. commenti dentro l'articolo padre vanno bene, sezioni di navigazione no)
• <section> senza heading — equivale a un <div> senza valore aggiunto

Alt text immagini

• Ogni immagine significativa deve avere alt compilato
• Immagini decorative: alt=""
• Controllare anche: logo, icone SVG usate come immagini, bandiere nei selettori lingua, immagini iniettate via JS/template

Sitemap XML

• Includere solo URL HTTP 200 e indicizzabili — niente noindex, 404 o parametrizzazioni
• Per siti grandi: index sitemap + sotto-sitemap per sezione
• Per siti multilingua: sitemap separate per lingua oppure hreflang nella sitemap
• Aggiornare <lastmod> ad ogni modifica del contenuto
• Il percorso nel robots.txt deve corrispondere esattamente a quello registrato in Search Console

Hreflang

Indica lingua e localizzazione geografica delle pagine. Fondamentale nei siti multilingua per evitare duplicati cross-lingua e garantire che Google mostri la versione corretta.

Struttura corretta

<link rel="alternate" hreflang="it" href="https://www.dominio.it/pagina-it" />
<link rel="alternate" hreflang="en" href="https://www.dominio.it/en/pagina-en" />
<!-- x-default: versione da mostrare quando la lingua non è determinabile -->
<link rel="alternate" hreflang="x-default" href="https://www.dominio.it/en/pagina-en" />

Errori comuni

• x-default sempre alla homepage — deve puntare alla relativa pagina in lingua alternativa, non sempre alla home:

  <!-- ERRATO -->
  <link rel="alternate" hreflang="x-default" href="https://www.dominio.it" />
  
  <!-- CORRETTO -->
  <link rel="alternate" hreflang="x-default" href="https://www.dominio.it/en/pagina-en" />

• Paginazioni con hreflang che punta alla pagina 1 — l'hreflang deve includere il parametro page:

  <!-- ERRATO: it punta alla pagina 1 invece che alla paginazione corrente -->
  <link rel="alternate" hreflang="it" href="https://www.dominio.it/categoria" />
  <link rel="alternate" hreflang="en" href="https://www.dominio.it/en/category?page=5" />
  
  <!-- CORRETTO -->
  <link rel="alternate" hreflang="it" href="https://www.dominio.it/categoria?page=5" />
  <link rel="alternate" hreflang="en" href="https://www.dominio.it/en/category?page=5" />

• hreflang che punta a URL inesistente (404) — se la pagina non esiste nella lingua alternativa, omettere il tag. Lato codice: verificare l'esistenza prima di generare il tag.

Crawling e indicizzazione

Errori 404

Link rotti peggiorano l'UX, disperdono il crawl budget e indeboliscono il PageRank interno. Monitorare con Search Console o tool di crawling (Screaming Frog, SeoZoom). Per i link generati automaticamente (es. link alla versione in altra lingua): se la pagina non esiste, non generare il link.

Errori 500

A differenza dei 404, gli errori 500 non sono uno stato "atteso" per i motori di ricerca. La loro presenza continuativa incide sull'affidabilità del sito. Priorità alta: allineare il comportamento di tutte le versioni linguistiche (es. annuncio scaduto → 404 su tutte le lingue, non 404 in italiano e 500 in inglese).

Microdati (Schema.org)

I microdati descrivono i contenuti alle pagine facilitando la comprensione del motore. Google può usarli per i rich snippet in SERP. Riferimento: schema.org.

Errori comuni

• Caratteri non ASCII nel JSON-LD — apostrofi tipografici ' e virgolette tipografiche " causano errori di parsing. Sostituire con i corrispondenti ASCII (', ").
• Campo obbligatorio vuoto — se un campo (es. description, brand) arriva vuoto dal CMS/utente, il microdato viene generato con valore vuoto. Inserire un fallback programmatico.
• Lunghezza stringa non valida — alcuni campi hanno limiti min/max. Troncare o integrare il valore lato codice prima di includerlo nel markup.
• Proprietà url con parametri — deve corrispondere alla URL canonica, non alla URL con filtri/parametri.

Workflow correzione

1. Individuare gli errori con Google Rich Results Test
2. Correggere il codice
3. Search Console → Miglioramenti → Convalida correzione

Core Web Vitals

Google usa le CWV come fattore di ranking. I target sono indicativi — contano solo in caso di parità tra siti con caratteristiche simili.

• LCP (Largest Contentful Paint) — elemento più grande above-the-fold. Target: < 2.5s
• FCP (First Contentful Paint) — primo contenuto visibile. Target: < 1.8s
• CLS (Cumulative Layout Shift) — stabilità visiva. Target: < 0.1
• INP (Interaction to Next Paint) — reattività agli input. Target: < 200ms

Strumenti: PageSpeed Insights, Search Console → Core Web Vitals, Chrome DevTools → Lighthouse.

Ottimizzazione immagini

Le immagini sono quasi sempre il responsabile principale di un LCP elevato — in particolare l'immagine hero above-the-fold.

Peso e formato

• Formato WebP con fallback JPG via <picture>
• Compressione prima dell'upload: recompressor.com (fino al 74% senza perdita visibile)
• Dimensioni reali: non caricare 2000px se l'immagine viene mostrata a 400px
• srcset per servire risoluzioni diverse

Priorità di caricamento

L'immagine LCP deve essere caricata con priorità massima:

<img src="hero.jpg" fetchpriority="high" alt="...">

Lazy load (immagini below-the-fold)

<!-- Nativo -->
<img src="immagine.jpg" loading="lazy" alt="...">

<!-- Con data-srcset per lazy load custom via JS -->
<picture>
  <source type="image/webp" data-srcset="immagine.webp">
  <img data-srcset="immagine.jpg" alt="...">
</picture>

CSS critico e non bloccante

I CSS nel <head> bloccano il rendering finché non sono scaricati e processati, ritardando FCP e LCP.

Strategia

• CSS critico (header, menu, hero) → inline nel <head>
• CSS completo → preload non bloccante

<head>
  <style>
    /* CSS critico: header, menu, primo blocco visibile */
    .site-header { display: flex; align-items: center; height: 64px; }
  </style>

  <link rel="preload" href="/css/style.min.css" as="style" onload="this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/style.min.css"></noscript>
</head>

JavaScript in defer

Script nel <head> senza attributi bloccano il parsing HTML. Con defer vengono scaricati in parallelo ed eseguiti solo dopo il parsing completo, nell'ordine dichiarato.

<script src="/js/jquery.min.js" defer></script>
<script src="/js/bootstrap.bundle.min.js" defer></script>
<script src="/js/scripts.min.js" defer></script>

defer vs async

• defer — eseguito dopo il parsing, rispetta l'ordine. Per script che dipendono dal DOM o da altri script.
• async — eseguito appena scaricato, ignora l'ordine. Per script indipendenti (es. analytics).

E-E-A-T

Google valuta i contenuti attraverso il framework E-E-A-T: Experience, Expertise, Authoritativeness, Trustworthiness. Non è un fattore tecnico diretto, ma influenza come i quality rater giudicano il sito e, di riflesso, il ranking. Ha peso maggiore nelle verticalità YMYL (finanza, salute, legale, e-commerce).

Segnali che rafforzano l'E-E-A-T

• Pagina Chi siamo con biografia degli autori, credenziali, contatti verificabili
• Firma autore negli articoli con data di pubblicazione e ultima modifica
• Fonti citate esplicitamente (link a studi, normative, fonti primarie)
• Recensioni reali su Google Business Profile, Trustpilot o piattaforme di settore
• Presenza mediatica: menzioni autorevoli, interviste, guest post su siti tematici
• HTTPS attivo, policy privacy e cookie aggiornate, contatti facilmente raggiungibili

YMYL — standard elevati

Per siti in ambito medico, finanziario, legale o e-commerce Google applica standard E-E-A-T più stringenti. In questi casi: referenze professionali, certificazioni, politiche reso/rimborso chiare e informazioni di contatto complete sono requisiti minimi, non opzionali.

Testimonianze e recensioni

Testimonianze di clienti reali rafforzano l'E-E-A-T (trust) e possono generare rich snippet tramite Review e AggregateRating schema. Una valutazione aggregata visibile in SERP migliora sensibilmente il CTR.

Best practice

• Raccogliere recensioni su Google Business Profile — le stelle appaiono direttamente in SERP per le ricerche brand
• Integrare widget Trustpilot, Tripadvisor o piattaforme di settore nella landing page
• Le testimonianze testuali devono includere nome, ruolo/contesto e (se possibile) foto — le citazioni generiche non hanno valore SEO
• Non usare recensioni false o incentivate: Google le individua e penalizza

Schema AggregateRating

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nome prodotto/servizio",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "142",
    "bestRating": "5",
    "worstRating": "1"
  }
}
</script>

FAQ

Una sezione FAQ strutturata con FAQPage schema può generare rich snippet in SERP: le domande si espandono direttamente nel risultato, aumentando la visibilità e il CTR senza necessariamente guadagnare posizioni.

Schema FAQPage

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Come posso tracciare il mio ordine?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Dopo la spedizione ricevi un'email con il codice tracking."
      }
    }
  ]
}
</script>

Note

• Google mostra tipicamente 2-3 FAQ per risultato — inserire le domande più rilevanti per prime
• Le risposte vengono troncate in SERP intorno ai 300 caratteri: rispondere in modo diretto senza intro ridondanti
• Le FAQ devono essere reali e utili — keyword stuffing viene ignorato o penalizzato
• Lato HTML: strutturare con <details>/<summary> o accordion accessibile, non solo nel JSON-LD

Spedizioni, resi e pagamenti (e-commerce)

Per gli shop online, le policy di spedizione, reso e pagamento sono un segnale di trust diretto per Google (E-E-A-T) e influenzano il tasso di conversione. Google Merchant Center richiede queste informazioni per approvare i prodotti su Shopping.

Best practice

• Pagine dedicate con URL parlanti: /spedizioni, /resi, /pagamenti — raggiungibili dal footer
• Indicare chiaramente: costi di spedizione, tempi di consegna, corrieri, zone coperte, spedizione gratuita (soglia)
• Politica reso: tempi (es. 14 o 30 giorni), modalità, rimborso o cambio, chi paga la spedizione di reso
• Metodi di pagamento accettati con loghi visibili in footer e checkout

Schema ShippingDetails e MerchantReturnPolicy

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Offer",
  "shippingDetails": {
    "@type": "OfferShippingDetails",
    "shippingRate": {
      "@type": "MonetaryAmount",
      "value": "4.90",
      "currency": "EUR"
    },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "handlingTime": { "@type": "QuantitativeValue", "minValue": 1, "maxValue": 2, "unitCode": "DAY" },
      "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 5, "unitCode": "DAY" }
    }
  },
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn"
  }
}
</script>

Profilo link

Google analizza i backlink e il loro anchor text per valutare se arrivano in modo naturale o artificioso. Link da siti non tematici, directory o palesemente acquistati danneggiano la reputazione del sito.

Cosa evitare

• Directory e liste generiche
• Link acquistati su siti a bassa autorità
• Anchor text identici e ripetitivi su molti domini

Link building efficace

• Guest post su siti tematici di settore
• Contenuti linkabili (ricerche, infografiche, tool)
• PR digitali e comunicati stampa

Strumenti: Ahrefs, Search Console. Per link tossici: Disavow Tool.

Segnali social

Canali social attivi generano segnali di engagement, distribuiscono rapidamente nuovi contenuti (accelerando l'indicizzazione) e rafforzano la coerenza dell'entity. Canali abbandonati sono un segnale negativo.

• Mantenere nome, bio e URL del sito coerenti su tutti i profili
• Usare i social per distribuire nuovi contenuti del blog

• Google Search Console
• Google PageSpeed Insights
• Google Rich Results Test
• Schema.org
• Ahrefs
• Recompressor
• Google — Guida robots.txt
• Google — Guida hreflang
• Google — E-E-A-T e contenuti utili
• llmstxt.org — Specifiche standard llms.txt
• Google Rich Results Test (FAQ, Review, Shipping)
• Schema.org — FAQPage
• Schema.org — MerchantReturnPolicy
• Schema.org — OfferShippingDetails
• MDN — Semantica in HTML
• MDN — Elemento <address>