Lingue

Canonicalizzazione

Come i motori di ricerca scelgono un URL canonical tra duplicati, vi consolidano i segnali e allineano tutti i segnali, sapendo che rel=canonical è un suggerimento, non una regola.

Prima pubblicazione: 23 giu 2026 · Ultimo aggiornamento: 9 ago 2026 · Advanced
Lingue
AIScritto daAI v2
1 segnale di evidenza in questa pagina

La canonicalizzazione è il modo in cui un motore di ricerca sceglie un URL rappresentativo quando più URL servono contenuti uguali o quasi uguali e vi consolida i segnali di ranking (link, PageRank, anchor text). rel=canonical è un suggerimento, non una regola: Google raggruppa i duplicati, pesa segnali come annotazione, redirect, sitemap, link interni, HTTPS e formato dell’URL e può scegliere un canonical diverso. Canonical non è un 301 né una direttiva di indicizzazione come noindex. Fai puntare tutti i segnali allo stesso URL e verifica la scelta in Search Console.

TL;DR — La canonicalizzazione è raggruppamento + selezione + consolidamento: Google rileva i duplicati (checksum/impronte del contenuto), li raggruppa, sceglie un canonical e vi consolida i segnali di ranking (link, PageRank, anchor text). rel="canonical" è un suggerimento forte, non una direttiva: Google può ignorarlo e lo fa, mostrando in GSC “Duplicate, Google chose different canonical than user”. Usa un insieme crescente di segnali (circa 20 secondo Illyes nel 2020, circa 40 secondo Allan Scott di Google nel 2025): annotazione rel=canonical, redirect, presenza nella sitemap, link interni, HTTPS rispetto a HTTP e URL più corti rispetto a quelli più lunghi; alcuni prevalgono su altri (un redirect pesa più del segnale HTTPS). Canonical non significa 301 e non è una direttiva di indicizzazione come noindex. Fai puntare tutti i segnali a un URL, usa canonical autoreferenziali e verifica il canonical scelto con lo strumento Controllo URL di Search Console.

Che cos’è davvero la canonicalizzazione

Canonicalization sits between duplicate URLs and the index — deciding which one URL represents the group. Fonte: /technical-seo/how-search-works/indexing/canonicalization/

Three reachable duplicate URL variants feed a canonicalization decision. A separate bundle of signals also feeds the decision: rel=canonical, redirects, sitemap inclusion, internal links, and HTTPS. The decision selects one representative canonical URL, which may be indexed and shown in search while cluster signals consolidate onto it. The other duplicate URLs remain reachable rather than being deleted.

© Patrick Stox LLC · CC BY 4.0 ·

La definizione di Google è precisa: “Canonicalization is the process of selecting the representative –canonical– URL of a piece of content,” (traduzione) e “a canonical URL is the URL of a page that Google chose as the most representative from a set of duplicate pages.” (traduzione) La canonicalizzazione è il processo di selezione dell’URL rappresentativo, cioè canonical, di un contenuto; un URL canonical è l’URL della pagina che Google ha scelto come più rappresentativo tra una serie di pagine duplicate. Evidence for this claim Google groups similar pages and selects a representative canonical URL for the cluster. Scope: Google Search canonical selection for duplicate or very similar content. Confidence: high · Verified: Google Search Central: In-depth guide to how Google Search works Ho scritto la guida alla canonicalizzazione di Ahrefs e la mia impostazione è che in realtà avvengano due lavori: “Clustering creates a cluster of duplicate pages, and canonicalization chooses which version signals consolidate to and what page will be shown in search results.” (traduzione) Il clustering crea un gruppo di pagine duplicate e la canonicalizzazione sceglie la versione verso cui si consolidano i segnali e quale pagina verrà mostrata nei risultati di ricerca.

Quindi succedono tre cose, in quest’ordine:

  1. Rilevamento e raggruppamento degli URL duplicati (o quasi duplicati).
  2. Selezione di uno di essi come canonical.
  3. Consolidamento dei segnali di ranking sull’URL scelto.

Chiariti questi tre passaggi, la maggior parte della confusione sulla canonicalizzazione scompare.

Perché conta

Google ammette apertamente che i duplicati sono soprattutto un problema di usabilità e reporting, non una colpa morale: “having the same content accessible through many different URLs can be a bad user experience… and it may make it harder for you to track how your content performs in search results.” (traduzione) avere lo stesso contenuto accessibile tramite molti URL diversi può creare una cattiva esperienza utente e rendere più difficile monitorare il rendimento del contenuto nei risultati di ricerca. La maggior parte dei duplicati non è dannosa: sono normali incidenti tecnici (parametri, navigazione a facet, varianti di protocollo/host, ID di sessione).

Il vero vantaggio si manifesta su quattro superfici; vale la pena essere precisi su ciascuna invece di trattare “la canonicalizzazione aiuta la SEO” come un beneficio indistinto:

  • Appartenenza al gruppo. Gli URL duplicati vengono riuniti in un cluster; il canonical è il rappresentante designato di quel cluster.
  • Frequenza relativa di crawling. Google dice che la pagina canonical viene sottoposta a crawling con maggiore regolarità e i duplicati meno spesso: è un effetto relativo che riduce il crawling ridondante. Non promette che canonicalizzare una pagina liberi immediatamente budget altrove o acceleri l’indicizzazione di pagine non correlate.
  • Valutazione di contenuto e qualità. Di norma Google usa il canonical come fonte principale per valutare qualità e pertinenza del contenuto.
  • Che cosa viene servito. I risultati di ricerca collegano di solito al canonical, ma non sempre. Google può servire un duplicato quando è più adatto all’utente, per esempio una versione specifica per dispositivo.

La documentazione di Google descrive chiaramente il lato dei segnali: dichiarare un canonical “helps search engines to be able to consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL.” (traduzione) aiuta i motori di ricerca a consolidare in un unico URL preferito i segnali che possiedono per i singoli URL, come i link che vi puntano. Questo vale solo se la destinazione diventa davvero canonical: non garantisce che ogni canonical dichiarato assorba automaticamente tutto il PageRank, l’anchor text o il valore di ranking di un duplicato. Se i segnali non concordano e Google sceglie altro, nulla si consolida nel modo previsto.

E una parte dei duplicati è semplicemente normale: da sola non costituisce una violazione delle norme antispam. I motivi pratici per canonicalizzare sono chiarezza per gli utenti, report più puliti, un URL di ricerca coerente, consolidamento dei segnali e riduzione del crawling duplicato, non il timore di una penalizzazione. La duplicazione incontrollata va comunque risolta alla fonte: riguarda più il crawl budget e la navigazione a facet che la canonicalizzazione, anche se gli argomenti sono collegati.

Come Google sceglie un canonical

Canonicalization is three jobs, not one: cluster, select, consolidate. Fonte: /technical-seo/how-search-works/indexing/canonicalization/

Step one fingerprints duplicate URLs and groups them into a cluster. Step two selects one URL as canonical while the others remain reachable alternates. Step three consolidates links, PageRank, and anchor text from the cluster onto the selected canonical.

© Patrick Stox LLC · CC BY 4.0 ·

È la parte che la maggior parte delle guide tratta in modo superficiale, quindi vale la pena affrontarla correttamente.

Passaggio 1 — rilevamento dei duplicati

Google crea un’impronta del contenuto della pagina per trovare i duplicati. Gary Illyes ha descritto il meccanismo in l’episodio del podcast di Google: “A checksum is basically a hash of the content. Basically a fingerprint.” (traduzione) Nella citazione riportata più sotto, un checksum è un hash del contenuto: una sorta di impronta. Le pagine con impronte uguali o quasi uguali (gli elementi standard come navigazione e footer vengono in gran parte scontati) sono candidate a essere trattate come duplicati.

La documentazione attuale di Google esprime la stessa idea in termini più semplici, senza entrare nella meccanica dei checksum: durante l’indicizzazione confronta il contenuto principale di ogni pagina e raggruppa le pagine uguali o molto simili. Google non pubblica il funzionamento preciso delle impronte né quanto markup standard venga scontato; considera quindi l’impostazione dei checksum di Illyes un’interpretazione orientativa di una conversazione del 2020, non un algoritmo documentato.

Passaggio 2 — raggruppamento

Gli URL duplicati vengono riuniti in un cluster. Ogni elemento del cluster è candidato a diventare canonical; alla fine ne vincerà esattamente uno.

Passaggio 3 — selezione dal cluster

A questo punto Google sceglie. Usa un insieme di segnali, e il numero pubblicato è cresciuto nel tempo. Nel 2020 Illyes disse: “we employ, I think, over twenty signals, we use over twenty signals, to decide which page to pick as canonical.” (traduzione) impieghiamo, credo, più di venti segnali per decidere quale pagina scegliere come canonical. Nel 2025 il numero di cui parla Google è più alto: come ho osservato nella mia guida alla canonicalizzazione di Ahrefs, “According to Google’s Allan Scott, there are ~40 different canonical selection signals.” (traduzione) secondo Allan Scott di Google esistono circa 40 segnali diversi di selezione del canonical. Consideralo come una maggiore trasparenza pubblica nel tempo: più di 20 nel 2020, circa 40 nel 2025, non come una contraddizione.

La documentazione di Google elenca esplicitamente alcuni fattori: “There are a handful of factors that play a role in canonicalization: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations.” (traduzione) «La documentazione elenca alcuni fattori: la pagina può essere servita via HTTP o HTTPS, possono esserci redirect, l’URL può comparire in una sitemap e possono essere presenti annotazioni di link rel="canonical"». La mia lista più completa aggiunge ciò che viene citato di frequente: duplicati, elementi link canonical, URL nella sitemap, link interni, link esterni, redirect, hreflang, hreflang x-default, PageRank, pagine HTTPS rispetto a HTTP e URL più corti rispetto a quelli più lunghi.

Quali segnali prevalgono

Non hanno tutti lo stesso peso. Illyes è stato esplicito: “301 redirect, or any sort of redirect actually, should be much higher weight… than whether the page is on an http URL or https.” (traduzione) un redirect 301, o in realtà qualsiasi tipo di redirect, dovrebbe avere un peso molto maggiore del fatto che la pagina sia su un URL http o https. Ha definito il tag canonical stesso “quite a strong signal”. (traduzione) un segnale piuttosto forte, ma che può perdere. Come scrivo nella mia guida alla canonicalizzazione, il tag canonical “is sometimes referred to as a hint because it’s just one canonicalization signal, but it is considered a strong signal. Google ignores it if other signals are stronger.” (traduzione) a volte viene chiamato suggerimento perché è solo uno dei segnali di canonicalizzazione, ma è considerato un segnale forte. Google lo ignora se gli altri segnali sono più forti.

Perché è un suggerimento, non una direttiva

È la struttura portante dell’accuratezza su tutto l’argomento. Google dice: “You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.” (traduzione) puoi indicare la tua preferenza a Google con queste tecniche, ma per vari motivi Google può scegliere come canonical una pagina diversa da quella scelta da te: indicare una preferenza canonical è un suggerimento, non una regola. Evidence for this claim Canonical declarations express a preference; Google can select a different canonical based on its signals. Scope: Google Search canonicalization; redirects and rel=canonical are strong signals while sitemap inclusion is weaker. Confidence: high · Verified: Google Search Central: How to specify a canonical URL Quando il canonical dichiarato perde, in Search Console vedrai “Duplicate, Google chose different canonical than user”, che, come lo descrivo io, “means that Google chose a different URL to index than the one the user selected.” (traduzione) significa che Google ha scelto per l’indicizzazione un URL diverso da quello selezionato dall’utente. La soluzione quasi mai è “add a stronger tag” (traduzione) «aggiungere un tag più forte»: è allineare i segnali in conflitto.

Modi per specificare un canonical

Google chiarisce subito che “none of them are required; your site will likely do just fine without specifying a canonical preference,” (traduzione) nessuno di questi metodi è obbligatorio; probabilmente il sito funzionerà bene anche senza specificare una preferenza canonical, ma nella pratica conviene essere intenzionali. La documentazione attuale di Google nota anche che questi metodi possono sommarsi: usare diversi segnali forti e allineati aumenta la probabilità che Google scelga l’URL desiderato, anche se nessuno da solo lo garantisce. I metodi principali sono:

  • Elemento link rel="canonical" — la riga nel <head>. È il metodo più comune; Google lo definisce “a strong signal that the specified URL should become canonical.” (traduzione) un segnale forte che l’URL specificato dovrebbe diventare canonical. Deve stare nel <head>: un tag non chiuso o JavaScript che lo spinge nel <body> fa sì che Google lo ignori. Dichiarane uno solo per pagina; se ne dichiari più di uno, Google li ignora tutti.
  • Header HTTP rel="canonical" — per file non HTML, come i PDF, dove non c’è un <head> in cui inserire un tag, imposta il canonical nell’header della risposta HTTP.
  • Redirect — “a strong signal that the target of the redirect should become canonical.” (traduzione) un segnale forte che la destinazione del redirect dovrebbe diventare canonical. Usa un 301 quando stai davvero spostando il contenuto.
  • Presenza nella sitemap — “a weak signal that helps the URLs that are included in a sitemap become canonical.” (traduzione) un segnale debole che aiuta gli URL inclusi in una sitemap a diventare canonical. Inserisci nella sitemap solo URL canonical.
  • Link interni — collega in modo coerente la versione desiderata. I link interni incoerenti sono uno dei motivi più comuni per cui i segnali entrano in conflitto.

Canonical autoreferenziali e cross-domain

Un canonical autoreferenziale, cioè una pagina indicizzabile il cui canonical punta a se stessa, è una best practice per ogni pagina che vuoi indicizzare. Rende esplicita la preferenza anche quando gli altri segnali sono ambigui e neutralizza le copie con parametri che altrimenti sembrerebbero duplicati.

I canonical cross-domain sono supportati: puoi puntare il canonical di una pagina a un URL su un altro dominio che controlli per consolidarlo (caso comune nella syndication). Il rischio da considerare è il dirottamento: come avverto nella mia guida alla canonicalizzazione, “In some really bad scenarios, a page on the wrong domain may be shown. This is referred to as hijacking.” (traduzione) in alcuni scenari davvero negativi può essere mostrata una pagina sul dominio sbagliato. Questo viene definito hijacking. È raro, ma è il motivo per cui i canonical cross-domain richiedono attenzione.

Casi limite: che cosa conta davvero come duplicato

Cinque situazioni ricevono l’etichetta “duplicato” più spesso del dovuto. Lo schema è sempre lo stesso: non decidere in base a una caratteristica dell’URL (un ?, il numero di pagina, una cartella della lingua, un tag script), ma in base a ciò che è davvero il contenuto principale renderizzato.

SituazioneTrattarla come duplicato?Perché
Parametri di tracking o sessione (?utm_source=, ?sessionid=)Di solito sìStesso contenuto principale: è sicuro canonicalizzare verso l’URL pulito.
Parametri di filtro, ordinamento o facet (?color=red, ?sort=price)Non automaticamentePossono produrre contenuti o intenti materialmente diversi dalla pagina di base: controlla il contenuto renderizzato prima di eliminarli con un canonical.
Pagine paginate (/page/2/)NoGoogle tratta ogni pagina della serie separatamente, con un proprio contenuto principale: dai a ciascuna un URL unico e un canonical autoreferenziale, mai un canonical verso la pagina 1.
Pagine completamente tradotteNoIl contenuto in un’altra lingua non è un duplicato dell’originale anche quando il template coincide: collegale con hreflang, non con canonical.
Varianti regionali nella stessa lingua (per esempio pagine quasi identiche en-US ed en-GB)A voltePossono essere raggruppate come normali duplicati. Mantieni la preferenza canonical nella stessa lingua e abbinala a hreflang reciproci, così l’URL regionale corretto conserva la possibilità di emergere.

Due dettagli di implementazione causano abbastanza spesso errori silenziosi da meritare una nota separata:

  • Canonical generati da JavaScript. La guida di Google consiste nello scegliere una fonte chiara per il valore: inseriscilo nell’HTML iniziale e non sovrascriverlo con JavaScript oppure, se non è possibile, lascialo fuori dall’HTML e impostalo solo tramite JavaScript. Dichiarare un canonical nel sorgente e poi cambiarlo con uno script è il vero errore: Google finisce con due segnali in conflitto dalla stessa pagina.
  • File non HTML. L’header HTTP rel="canonical" (per PDF, documenti Word e simili) è supportato specificamente per i risultati della Ricerca Google web, non è un segnale universale in ogni superficie Google. Usa un URL assoluto e non lasciare che i metadati del file dichiarino un canonical in conflitto.

Come controllare il canonical scelto da Google

Non dare per scontato che il tuo HTML sia la fonte autorevole: lo è la scelta di Google. Come dico spesso: “Your main source of truth for what Google chose as the canonical will be the URL Inspection tool in Google Search Console. Enter the URL, and it will show what the declared canonical is and what Google chose as the canonical.” (traduzione) la fonte principale per sapere quale canonical ha scelto Google è lo strumento Controllo URL in Google Search Console. Inserisci l’URL e vedrai quale canonical è stato dichiarato e quale ha scelto Google. Se i due valori non coincidono, è il segnale che devi allineare tutto.

Ecco alcuni limiti da conoscere prima di trattare quel campo come una verità assoluta:

  • Riflette lo stato indicizzato, non un controllo live. Il canonical scelto da Google in Controllo URL proviene da ciò che Google ha già indicizzato. Il Live Test dello stesso strumento può mostrare i segnali attuali, ma non può prevedere che cosa sceglierà Google: tratta il campo indicizzato come storico, non in tempo reale.
  • La visibilità è limitata alle proprietà che possiedi. Puoi vedere le informazioni canonical solo per gli URL dentro proprietà Search Console a cui hai accesso, non per pagine arbitrarie di terze parti.
  • Uno strumento di audit osserva gli input, non la decisione di Google. Uno strumento come il Canonicalization Checker qui sopra mostra i segnali che stai inviando: HTML, header e redirect. Non può dirti che cosa abbia scelto davvero Google; solo Controllo URL può farlo.
  • Nessuna garanzia di inclusione, tempi o ranking. Far scegliere a Google l’URL desiderato come canonical non garantisce che venga indicizzato, non avviene secondo una tempistica fissa e non garantisce traffico o ranking: la canonicalizzazione decide la rappresentazione, non questi risultati.

Errori comuni nella canonicalizzazione

Quelli che vedo ricorrere (diversi dalla mia lista personale degli errori comuni):

  • Usare un canonical di produzione come protezione del sito di staging. Una pagina di staging su https://staging.example.com/pricing/ può puntare con il canonical a https://example.com/pricing/ e continuare a essere sottoposta a crawling, raggruppata o persino mostrata mentre Google riconcilia i segnali. Il canonical indica quale duplicato preferisci: non rende privato l’URL di staging e non ordina a Google di rimuoverlo. Se l’host di staging finisce nella ricerca, mantienilo sottoponibile a crawling con noindex finché Google elabora la direttiva oppure reindirizzalo se l’URL ha un sostituto permanente in produzione. Per un ambiente che non dovrebbe mai essere pubblico, richiedi autenticazione.
  • Canonicalizzare verso una pagina non duplicata. Puntare il canonical di una pagina a una pagina non correlata comunica a Google che sono lo stesso contenuto; può far sparire il “duplicato” dai risultati. I canonical servono per duplicati autentici.
  • Canonical + noindex sullo stesso URL. Sono istruzioni contraddittorie. La guida di John Mueller sull’unione di segnali in conflitto dice: “I’d just pick one (noindex or followed links). Links on a noindexed page can be picked up, but it’s not guaranteed.” (traduzione) Nella citazione riportata più sotto, conviene scegliere uno dei due (noindex o link seguiti). Su una pagina con noindex, i link possono essere rilevati anche dopo un tentativo di scansione, ma non è garantito.
  • Bloccare in robots.txt l’URL canonicalizzato. Google dice: “Don’t use the robots.txt file for canonicalization purposes. Google may still index URLs that are disallowed in robots.txt without their content.” (traduzione) non usare il file robots.txt per la canonicalizzazione. Google potrebbe comunque trovare e indicizzare URL vietati in robots.txt senza il loro contenuto. Una pagina bloccata non può nemmeno essere letta per vedere il suo tag canonical.
  • Restituire un 4XX per l’URL canonicalizzato — se il duplicato genera un errore, il consolidamento si interrompe.
  • Canonicalizzare tutte le pagine paginate verso la pagina 1. Ogni pagina della serie ha contenuto distinto: non collassarle sulla radice.
  • Catene di canonical / redirect in conflitto — un canonical che punta a un URL che poi reindirizza altrove obbliga Google a sciogliere una contraddizione. Fai puntare il canonical senza passaggi intermedi alla destinazione finale.
  • Più canonical o un canonical nel <body> — la posizione nel body non è accettata; più dichiarazioni creano un conflitto senza un esito affidabile basato sul primo o sull’ultimo.

Miti sfatati

  • “Un tag canonical garantisce quale URL si posiziona o viene indicizzato.” No: è un suggerimento e Google può sceglierne un altro (è esattamente ciò che segnala lo stato GSC “Duplicate, Google chose different canonical than user”).
  • “rel=canonical is the same as a 301 redirect.” (traduzione) «rel=canonical è la stessa cosa di un redirect 301.» No. Un 301 è la direttiva per spostare una pagina; un canonical è un suggerimento di consolidamento e entrambi gli URL restano raggiungibili. La posizione storica di Bing è che quando sposti un contenuto devi usare un 301, non un canonical, perché il redirect è l’istruzione non ambigua. Se stai ritirando un URL, reindirizzalo.
  • “Un canonical blocca o consente l’indicizzazione come noindex.” No: il canonical non è affatto una direttiva di indicizzazione. Abbinarlo a noindex invia segnali in conflitto; usa l’uno o l’altro.
  • “Più tag canonical = segnale più forte.” È il contrario: dichiarane più di uno e Google li ignora tutti.

Bing e gli altri motori

Bing usa gli stessi strumenti di base. Nella sua impostazione del dicembre 2025, “Duplicate content doesn’t trigger search penalties on its own, but it does reduce visibility by diluting authority, confusing intent, and slowing how updates reach both search engines and AI-powered discovery systems,” (traduzione) il contenuto duplicato da solo non attiva penalizzazioni nella ricerca, ma riduce la visibilità diluendo l’autorevolezza, confondendo l’intento e rallentando il modo in cui gli aggiornamenti raggiungono sia i motori di ricerca sia i sistemi di scoperta basati sull’IA. E: “Canonical tags, redirects, hreflang, noindex, and IndexNow all support this clarity, but the foundation is a streamlined site that avoids unnecessary duplication.” (traduzione) tag canonical, redirect, hreflang, noindex e IndexNow sostengono questa chiarezza, ma la base è un sito snello che evita duplicazioni non necessarie. Bing offre anche una funzione URL Normalization in Bing Webmaster Tools per consolidare le varianti con parametri senza modificare il codice, utile quando i duplicati derivano dai parametri URL.

Dove andare dopo

Questa pagina è il centro concettuale della canonicalizzazione, l’argomento principale. Si trova nella fase più ampia di indicizzazione del funzionamento della ricerca: la canonicalizzazione decide quale URL di un cluster duplicato viene effettivamente indicizzato. I tre approfondimenti sotto sviluppano ciascuno un elemento:

  • Tag canonical (rel=canonical) — il tag in sé: sintassi esatta, implementazione nel <head> rispetto all’header HTTP, schemi autoreferenziali e tutti i modi in cui può essere ignorato.
  • Contenuto duplicato — che cosa conta davvero come duplicato, perché non è una penalizzazione e come prevenirlo alla fonte invece di correggerlo con i tag.
  • Parametri URL — il principale produttore di duplicati: tracking, ordinamento, filtri e parametri di sessione, e come impedire che frammentino una pagina in infinite varianti.

La canonicalizzazione tocca anche i temi fratelli di questo cluster: duplicati e proliferazione dei parametri sprecano esattamente crawl budget, la navigazione a facet è una fonte primaria di URL quasi duplicati e le spider trap possono generare gli spazi URL infiniti che fanno esplodere la duplicazione. Per l’intera pipeline — scoperta, crawling, rendering, indicizzazione e distribuzione — vedi il cluster How Search Works.

Add an expert note

Pin an expert quote

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