Tag canonical

TL;DR — Un tag canonical indica ai motori di ricerca quale URL è quello “principale” quando lo stesso contenuto vive a più indirizzi. Aggiungi una riga <link rel="canonical" href="..."> nel <head> della pagina, puntando alla versione che vuoi indicizzare. È un segnale, non un comando: Google di solito lo segue, ma può scegliere una pagina diversa se gli altri segnali non concordano.

Che cos’è un tag canonical

Quando lo stesso contenuto (o quasi) è raggiungibile da più URL — per esempio example.com/page, example.com/page?ref=newsletter e la versione http:// — i motori di ricerca devono decidere quale mostrare davvero nei risultati. Un tag canonical è il modo per indicare la tua preferenza.

È una singola riga HTML che va nel <head> della pagina:

<link rel="canonical" href="https://www.example.com/page/">

Dice: “Se trovi questo contenuto a più URL, tratta questo come la versione reale”. I motori di ricerca consolidano così segnali di ranking — come i link — sull’URL preferito invece di dividerli tra i duplicati.

La prima cosa da capire

Un tag canonical è un segnale, non una direttiva. Google lo considera un suggerimento forte, ma lo pesa contro gli altri segnali e può scegliere un URL diverso. Prova a sostegno di questa affermazione Canonicalization methods communicate a preferred URL, but Google can choose a different canonical when signals conflict. Ambito: Google Search canonical selection; applies to duplicate or very similar pages. Attendibilità: alta · Verificato: 2026-07-14 Google: URL canonicalization Quindi il tag non forza l’altra versione fuori da Google. Se vuoi che una pagina sparisca davvero dalla ricerca, serve un altro strumento (noindex), non un canonical.

Qui nasce la maggior parte della confusione. Si aggiunge un canonical e si presume che l’altro URL venga eliminato da Google. Non succede: il canonical dice soltanto quale versione preferire e su cui consolidare i segnali.

Come aggiungerne uno (versione semplice)

• HTML grezzo: inserisci la riga <link rel="canonical" href="..."> nel <head>.
• WordPress: un plugin SEO (Yoast o Rank Math) aggiunge automaticamente un canonical autoreferenziale e consente di impostarne uno personalizzato per pagina.
• Shopify: il tema aggiunge i canonical per impostazione predefinita; puoi modificarli in theme.liquid/nei template.

Tre regole coprono la maggior parte degli errori: usa l’URL completo https://... (non un percorso breve /page/), tienilo nel <head> e usane uno solo per pagina.

A cosa serve

• Contenuto duplicato dovuto a parametri di tracciamento, versioni per la stampa o allo stesso prodotto raggiungibile da categorie diverse.
• Consolidare i link, così l’autorevolezza dei link diretti a più URL arriva a quello che vuoi far posizionare.
• Autoreferenziale: va bene (ed è consigliato) che una pagina indichi se stessa come canonical: rende esplicita la preferenza.

Vuoi i dettagli d’implementazione — metodo tramite header HTTP per i PDF, modi in cui può fallire senza segnalazioni e test — passa alla scheda Advanced.

TL;DR — rel=canonical è un segnale, non una regola: un’indicazione forte che Google può e talvolta supera. Metodi validi: elemento HTML <link rel="canonical"> nel <head> (nel <body> viene ignorato), header HTTP Link: rel="canonical" (l’unico modo per canonicalizzare PDF e altri documenti non HTML) e presenza nella sitemap come segnale più debole. Usa esattamente un canonical non ambiguo per pagina: dichiarazioni multiple o in conflitto possono produrre risultati inattesi. Usa URL assoluti, preferisci l’autoreferenziale per le pagine, non canonicalizzare una serie paginata alla pagina 1 e non combinare canonical con noindex, blocco robots.txt o 4XX: ciascuno impedisce a Google di leggere o rispettare il tag. Testa con view-source e DOM renderizzato, curl -I per l’header e Controllo URL di GSC (canonical dichiarato dall’utente contro quello scelto da Google).

Un canonical è una dichiarazione, non una decisione

Tieni separate due idee. La canonicalizzazione è il processo con cui Google sceglie un URL rappresentativo tra i duplicati: pesa molti segnali. Il tag canonical è solo uno di quei segnali, cioè la tua preferenza dichiarata. Questa pagina spiega come dichiararla correttamente; la scelta in sé vive nell’hub sulla canonicalizzazione.

Questa distinzione è la spina dorsale dell’accuratezza, perché Google dice esplicitamente che “indicating a canonical preference is a hint, not a rule.” (traduzione) «Indicare una preferenza canonical è un suggerimento, non una regola.» È un suggerimento forte — come spiego nel mio approfondimento sulla canonicalizzazione, il canonical è considerato un segnale forte, ma Google lo ignora se altri segnali prevalgono — e non è mai una direttiva. Se dichiari A mentre link interni, sitemap e redirect puntano tutti a B, Google può scegliere B. È lo stato di Search Console «Duplicato: Google ha scelto una pagina canonica diversa da quella indicata dall’utente». Prova a sostegno di questa affermazione Canonicalization methods communicate a preferred URL, but Google can choose a different canonical when signals conflict. Ambito: Google Search canonical selection; applies to duplicate or very similar pages. Attendibilità: alta · Verificato: 2026-07-14 Google: URL canonicalization

Tre modi senza redirect per dichiarare un canonical

Oltre ai redirect, Google documenta tre modi non basati su redirect per indicare un canonical, con pesi diversi: Prova a sostegno di questa affermazione Alongside redirects, Google documents three non-redirect ways to indicate a canonical: an HTML link element, an HTTP Link header, and sitemap inclusion. Ambito: The three non-redirect canonical declaration approaches covered in this article; Google also documents redirects as a canonicalization method. Attendibilità: alta · Verificato: 2026-07-14 Google: Specify a canonical URL

• HTML <link rel="canonical"> nel <head> — “A strong signal that the specified URL should become canonical.” (traduzione) «Un segnale forte affinché l’URL specificato diventi canonico.» È il metodo ordinario per le pagine HTML.
• Header di risposta HTTP Link: rel="canonical" — per documenti in cui non puoi inserire un elemento <link>. Google dice che puoi usare un header di risposta HTTP con attributo target rel=“canonical” definito da RFC5988 invece di un elemento HTML, anche per documenti non HTML come i PDF. Il metodo HTML funziona solo per le pagine HTML, non per file come i PDF; per questi casi usa l’header HTTP rel=“canonical”. È la risposta alla domanda «come canonicalizzare un PDF».
• Presenza nella sitemap — è un segnale debole che aiuta gli URL inclusi nella sitemap a diventare canonici. È reale, ma è il più debole dei tre.

Due aspetti da ricordare sul loro rapporto:

• Si sommano. Google dice che questi metodi possono accumularsi e diventare più efficaci quando vengono combinati. Un <link> autoreferenziale, una sitemap pulita e link interni coerenti verso lo stesso URL sono molto più forti di un solo segnale.
• Nessuno è obbligatorio. Google incoraggia a usarli, ma precisa che nessuno è obbligatorio e che il sito probabilmente funzionerà bene anche senza dichiarare una preferenza canonical. Dichiararne uno elimina ambiguità; non dichiararlo non è un errore.

Separatamente, un redirect 301 è un segnale di consolidamento ancora più forte di rel=canonical, ma è uno strumento diverso (ne parlo più avanti nel confronto canonical/301/noindex).

L’header HTTP Link (e perché serve per i PDF)

Un PDF non ha un <head>, quindi non c’è posto per un elemento <link>. La soluzione è inviare il canonical nell’header di risposta HTTP a livello di server. La forma è:

Link: <https://www.example.com/downloads/whitepaper.pdf>; rel="canonical"

Lo configuri sul server (Apache .htaccess, Nginx) o sulla CDN/edge; guarda la scheda Scripts per snippet Apache e Nginx funzionanti e per il comando curl -I che conferma l’invio dell’header. Il metodo header funziona anche per HTML, ma su HTML l’elemento <link> è più semplice; usa l’header quando non puoi modificare il markup (PDF, immagini e altri documenti non HTML).

Deve stare nel <head> — la trappola del body-placement

È il problema che brucia più persone, quasi sempre per errore. Google dice che l’elemento rel=canonical viene accettato solo se appare nella sezione <head> di un HTML valido. Il post del 2013 sui «5 errori comuni» ribadisce che una dichiarazione trovata nel <body> viene ignorata. In breve, le dichiarazioni nel <head> vengono elaborate, quelle nel <body> no. Prova a sostegno di questa affermazione Google accepts an HTML rel=canonical link element only in a valid head section and disregards a canonical placed in the body. Ambito: HTML link-element canonicals in Google Search; HTTP-header canonicals are a separate method. Attendibilità: alta · Verificato: 2026-07-14 Google: Common rel=canonical mistakes

Ecco la trappola. Hai scritto il canonical nel <head> della sorgente. Ma quando il browser o il motore di ricerca costruisce la pagina, il <head> può chiudersi prima: tag non chiusi, JavaScript iniettato nel head o un <iframe> nel head possono chiuderlo prematuramente. Il canonical finisce così nel <body> renderizzato, dove viene ignorato. L’ho descritto nella mia guida alla SEO JavaScript: tag non chiusi o JavaScript iniettato possono terminare prima il <head> e spingere il canonical nel <body> renderizzato, dove non verrà rispettato.

Il problema è invisibile in view-source: l’HTML grezzo sembra corretto. Devi confrontarlo con il DOM renderizzato (pannello Elements di DevTools o HTML renderizzato di Controllo URL GSC) per vedere dove è finito davvero il canonical.

Sul JavaScript, la guida Google invita a scegliere un metodo e non a contraddirsi: “If you can’t set the canonical URL in the HTML source code, leave it out and only set it with JavaScript.” (traduzione) «Se non puoi impostare l’URL canonico nel codice sorgente HTML, omettilo e impostalo soltanto con JavaScript.» Se JS inietta il canonical, assicurati che lo inserisca correttamente nel <head>: non renderizzarne anche uno diverso lato server.

Dichiarare una sola relazione canonical per pagina

Ogni pagina dovrebbe avere una relazione canonical non ambigua. L’attuale guida Google sui metodi canonical avverte che combinare metodi può causare errori e risultati inattesi; non definisce un vincitore primo tag/ultimo tag. Un post Google Search Central del 2013 diceva che dichiarazioni multiple sarebbero probabilmente state ignorate. Trattalo come contesto storico, non come contratto deterministico del parser: la conclusione prudente oggi è segnalare il conflitto, esporre ogni dichiarazione HTML e HTTP e correggere il template.

La causa di solito non è un refuso, ma la sovrapposizione di sistemi. Il CMS ne inietta uno, il tema uno e un plugin SEO uno: tre dichiarazioni in conflitto. Ho segnalato direttamente questo schema nel mio approfondimento sulla canonicalizzazione: più tag rel=canonical probabilmente vengono ignorati e, in molti casi, il problema nasce perché CMS, tema e plugin inseriscono tag in punti diversi. Se stai eseguendo il debug di un canonical che «non funziona», conta prima i tag nel DOM renderizzato.

Usa URL assoluti, non relativi

Google consiglia di usare percorsi assoluti anziché relativi con l’elemento rel=canonical: anche se supportati, i percorsi relativi possono causare problemi nel tempo. Il motivo è meccanico: un <link> accetta URL relativi e assoluti e un href relativo come /page/ si risolve rispetto all’URL corrente. Con una base malformata o un percorso imprevisto può risolversi dove non volevi. Scrivi sempre l’URL completo:

<!-- Good -->
<link rel="canonical" href="https://www.example.com/dresses/green/green-dress.html">

<!-- Bad: relative path -->
<link rel="canonical" href="/dresses/green/green-dress.html">

La stessa logica vale per host e protocollo: punta alla versione finale reale (https:// invece di http://, con il tuo host canonico). Non usare un frammento URL come canonical: in generale Google non supporta i frammenti URL.

Canonical autoreferenziali e paginazione

Che una pagina nomini se stessa come canonical va bene ed è consigliato per la versione preferita: rende l’intento chiaro quando gli altri segnali non sono perfettamente allineati. Se un controllo dice “no different canonical”, un canonical autoreferenziale soddisfa quella condizione: è una dichiarazione consentita dello stesso URL, non un target concorrente.

La paginazione è il caso in cui l’autoreferenziale conta di più e in cui si sbaglia spesso. Non canonicalizzare la pagina 2, 3, 4… di una serie verso la pagina 1: specificare un rel=canonical da una pagina successiva alla prima non è un uso corretto. La pagina 2 non è un duplicato della pagina 1, perché ha contenuto diverso. Usa invece canonical autoreferenziali su tutte le pagine della serie: ogni pagina ha il proprio canonical.

Un errore correlato di sovra-canonicalizzazione: una pagina categoria o landing che canonicalizza verso un singolo articolo in evidenza. La categoria e l’articolo non hanno lo stesso contenuto, quindi anche questo uso è scorretto.

Non rompere la visibilità del canonical — e non puntare a un target rotto

Un canonical funziona solo se Google può eseguire il crawling della pagina, leggere il tag e non riceve un’istruzione contraddittoria. È un problema di salute lato sorgente: riguarda la possibilità di vedere il tag sull’URL duplicato. Tre modi in cui ci si sabota:

• Bloccare l’URL canonicalizzato in robots.txt. Se applichi Disallow al duplicato, Google non può eseguirne il crawling e non vede il canonical: non può consolidare. Un URL escluso tramite robots.txt può comunque essere indicizzato senza che Google ne conosca il contenuto. Non usare robots.txt per canonicalizzare.
• Impostare noindex sull’URL canonicalizzato. Sono istruzioni contraddittorie: noindex dice “rimuovi questa pagina”, canonical dice “consolida questa pagina”. Non mischiarle: scegli in base all’intento.
• Restituire un 4XX sull’URL canonicalizzato. Effetto simile a noindex: Google non può leggere il tag e non può trasferire il consolidamento.

Non dichiarare neppure canonical in conflitto tra metodi diversi: non specificare URL canonici differenti per la stessa pagina mediante tecniche diverse, per esempio un URL nella sitemap e uno diverso in rel=canonical.

Esiste un problema separato, lato target, che spesso sfugge perché è nella direzione opposta: l’URL verso cui punti deve essere una destinazione pulita. RFC 6596 invita a non designare un target che è a sua volta sorgente di un redirect, che rimanda a un altro canonical o che restituisce un codice di errore; la checklist di verifica Google aggiunge di controllare che il target non abbia noindex. Puntare a un target che reindirizza, concatena, è noindexed o restituisce errore significa chiedere a Google di consolidare su un URL che non può rappresentare davvero la pagina: verifica separatamente che il target restituisca un 200 pulito, senza redirect, noindex o un altro canonical.

Se usi hreflang, il canonical deve puntare a una pagina nella stessa lingua oppure alla migliore lingua sostitutiva disponibile quando non esiste una pagina canonica nella stessa lingua.

Canonical, redirect 301 o noindex

Questi strumenti vengono trattati come intercambiabili. Non lo sono: guarda la tabella decisionale nella scheda Cheat Sheets. In breve:

• rel=canonical — entrambi gli URL restano live e sottoposti a crawling; esprimi una preferenza e Google consolida i segnali su quello scelto. È un segnale. Usalo quando entrambi gli URL devono restare accessibili e sono duplicati o quasi duplicati (parametri, versioni per la stampa), non come rimedio generale per contenuti in syndication.
• Redirect 301 — utenti e bot vengono spostati al target; è il segnale di consolidamento più forte. Usalo quando il duplicato non deve essere raggiungibile.
• noindex — una direttiva che rimuove una pagina dalla ricerca (la pagina deve restare raggiungibile per permettere a Google di vedere il tag). Usalo per rimuovere, non per consolidare.

Per i duplicati interni Google preferisce il canonical: sconsiglia noindex, perché blocca completamente la pagina dalla Ricerca, e indica le annotazioni rel=canonical come soluzione preferita. Prova a sostegno di questa affermazione Google recommends rel=canonical rather than noindex when the goal is selecting a canonical within one site, because noindex removes the page from Search. Ambito: Google Search guidance for duplicate pages within a single site. Attendibilità: alta · Verificato: 2026-07-14 Google: Specify a canonical URL

Perché un canonical viene ignorato

Quando Google sceglie un canonical diverso da quello dichiarato, quasi sempre accade per uno di questi motivi: i due URL non hanno davvero lo stesso contenuto; esistono più canonical o canonical in conflitto; il tag è nel body; è relativo o rotto; l’URL è bloccato da robots o restituisce 4XX; oppure segnali più forti (link interni, sitemap, redirect) puntano altrove.

Il caso «contenuto non realmente uguale» colpisce soprattutto i siti renderizzati in JavaScript. John Mueller spiega che, nelle SPA il cui HTML statico è quasi identico, l’esecuzione non corretta di JavaScript può impedire a Google di vedere il contenuto unico e far apparire uguali le pagine. In quel caso Google non distingue i duplicati e può consolidare o separare gli URL in modi indesiderati.

Bing tratta rel=canonical allo stesso modo — un segnale di chiarezza, non una cura universale — e lo raccomanda esplicitamente per i contenuti in syndication (chiedi al partner di puntare il canonical all’originale). È una divergenza reale da Google: “the canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different.” (traduzione) «L’elemento link canonical non è consigliato a chi vuole evitare duplicazioni da partner di syndication, perché le pagine sono spesso molto diverse.» Prova a sostegno di questa affermazione Google's current troubleshooting guidance does not recommend rel=canonical as the general fix for duplication by syndication partners, because syndicated pages are often materially different from the original. Ambito: Google Search guidance for syndicated-content duplication; canonical remains valid where the syndicated copy is a genuine duplicate or superset of the original. Attendibilità: alta · Verificato: 2026-07-17 Google: Fix canonicalization issues Per quel problema Google consiglia di chiedere al partner di impedire l’indicizzazione della copia sul proprio sito, non di usare un canonical: funziona solo quando il target è davvero lo stesso contenuto, mentre le copie syndicated spesso non sono abbastanza simili. Nel toolkit Bing, tag canonical, redirect, hreflang, noindex e IndexNow sostengono questa chiarezza, ma la base resta un sito lineare che eviti duplicazioni inutili. Un’altra divergenza: per duplicazione da parametri Bing offre URL Normalization in Bing Webmaster Tools come soluzione preferita.

Come testarlo

Il flusso numerato è nella scheda Checklists; i comandi sono in Scripts. I passaggi fondamentali:

1. View-source della pagina: esiste esattamente un <link rel="canonical">, nel <head>, con URL assoluto?
2. Confronta il DOM renderizzato (DevTools / HTML renderizzato da GSC): è rimasto nel <head> ed è ancora l’unico dopo il rendering?
3. curl -I sull’URL per cercare l’header HTTP Link: rel="canonical" (così controlli PDF e documenti non HTML).
4. Controllo URL GSC: confronta il canonical dichiarato dall’utente con il canonical scelto da Google. Una differenza è un segnale da indagare. Due cautele: il risultato indicizzato può essere in ritardo di ore e il live test conferma solo che l’URL è recuperabile in questo momento, non quale URL Google sceglierà.
5. Crawling del sito (Ahrefs Site Audit, gratuito tramite Ahrefs Webmaster Tools per siti verificati, oppure Screaming Frog) per intercettare problemi canonical su larga scala.

Per il quadro più ampio — come Google sceglie un canonical tra circa 40 segnali — consulta l’hub sulla canonicalizzazione. Problemi vicini, come contenuti duplicati e parametri URL, sono di solito il motivo per cui si introduce un canonical.

Riepilogo IA

Una sintesi della versione Advanced:

• rel=canonical è un segnale, non una regola. Google lo definisce un segnale forte, ma può superarlo quando altri segnali non concordano. Dichiara la tua preferenza, non forza l’altro URL fuori dalla ricerca.
• Tre metodi validi: <link rel="canonical"> HTML nel <head> (forte), header HTTP Link: rel="canonical" (l’unico per PDF/non HTML) e presenza nella sitemap (debole). Si sommano; nessuno è obbligatorio. Un redirect 301 è un segnale distinto e più forte.
• Solo <head>. Nel <body> viene ignorato. La causa comune è accidentale: tag non chiusi, JS iniettato o iframe chiudono prima il head durante il rendering e spingono il canonical nel body. Confronta HTML grezzo e DOM renderizzato.
• Una dichiarazione non ambigua per pagina. Dichiarazioni multiple sono un conflitto, non un caso con regola documentata primo-vince o ultimo-vince. La causa tipica è CMS + tema + plugin che iniettano ciascuno un tag.
• URL assoluti, host e protocollo corretti, nessun frammento. I percorsi relativi si risolvono rispetto all’URL corrente e possono puntare nel posto sbagliato.
• Autoreferenziale per le pagine preferite. Non canonicalizzare una serie paginata alla pagina 1: ogni pagina deve indicare se stessa. Non canonicalizzare una categoria verso un articolo in evidenza.
• Non ostacolarlo: niente noindex insieme al canonical con lo stesso intento, niente blocco robots.txt sull’URL canonicalizzato, niente 4XX: ciascuno impedisce a Google di leggere o rispettare il tag. Non dichiarare canonical diversi tra i metodi.
• Canonical contro 301 contro noindex: canonical mantiene entrambi gli URL live (segnale); 301 sposta tutto (più forte); noindex rimuove una pagina (direttiva). Per duplicati interni Google preferisce canonical a noindex.
• Perché viene ignorato: contenuto non equivalente (comune sui siti JS/SPA), tag multipli o in conflitto, posizione nel body, robots/4XX o segnali più forti altrove.
• Testa con view-source e DOM renderizzato, curl -I per l’header e Controllo URL GSC (dichiarato dall’utente contro scelto da Google).

Documentazione ufficiale

Documentazione primaria dei motori di ricerca.

Google

• Come specificare un URL canonical con rel=canonical e altri metodi — documento d’implementazione: metodi supportati e loro forza, requisito del <head>, URL assoluti, header HTTP Link per i PDF e regole da evitare.
• Che cos’è la canonicalizzazione degli URL — concetto, compresa la frase portante “segnale, non regola” e i segnali che Google pesa.
• 5 errori comuni con rel=canonical (Search Central Blog, 2013) — fonte originale per “uno solo per pagina → tutti ignorati” e “nel <body> viene ignorato”.
• Correggere i problemi di canonicalizzazione (troubleshooting) — interpretazione degli stati Search Console come “Duplicate, Google chose a different canonical than user”.
• Bloccare l’indicizzazione della ricerca (noindex) — quando vuoi rimuovere una pagina (noindex), non consolidarla (canonical).

Bing / Microsoft

• I contenuti duplicati danneggiano la visibilità nella SEO e nella ricerca AI? (Canel e Madhavan, dicembre 2025) — posizione corrente di Bing, compresa la raccomandazione di rel=canonical per la syndication.
• Better than canonical; URL Normalization (Canel, 2012) — soluzione preferita da Bing per i duplicati da parametri: URL Normalization in Bing Webmaster Tools.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google e Bing. Ogni link è profondo e porta al passaggio citato nella pagina sorgente.

Google — è un segnale, non una regola

• “indicating a canonical preference is a hint, not a rule.” (traduzione) «Indicare una preferenza canonical è un suggerimento, non una regola.» — documentazione Google Search Central. Vai alla citazione
• “Canonicalization is the process of selecting the representative –canonical– URL of a piece of content.” (traduzione) «La canonicalizzazione è il processo di selezione dell’URL rappresentativo, cioè canonico, di un contenuto.» Vai alla citazione

Google — metodi supportati e loro forza

• “A strong signal that the specified URL should become canonical.” (traduzione) «Un segnale forte affinché l’URL specificato diventi canonico.» (rel=canonical) — documentazione Google Search Central. Vai alla citazione
• “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 canonici.» (sitemap) Vai alla citazione
• “While we encourage you to use these methods, none of them are required; your site will likely do just fine without specifying a canonical preference.” (traduzione) «Sebbene ne incoraggiamo l’uso, nessuno di questi metodi è obbligatorio; il sito probabilmente funzionerà bene anche senza specificare una preferenza canonical.» Vai alla citazione

Google — posizione, URL assoluti e header HTTP

• L’espressione originale “is only accepted if it appears in the” (traduzione) «viene accettato solo se appare nella» introduce questa regola: «L’elemento link rel=canonical viene accettato solo se appare nella sezione <head> dell’HTML; assicurati quindi che almeno quella sezione sia HTML valido.» Vai alla citazione
• La documentazione dice “Use absolute paths rather than relative paths” (traduzione) «Usa percorsi assoluti anziché relativi»: «Usa percorsi assoluti anziché relativi con l’elemento link rel=canonical. Anche se Google supporta i percorsi relativi, nel tempo possono causare problemi.» Vai alla citazione
• La fonte comprende l’espressione “non-HTML documents such as PDF files” (traduzione) «documenti non HTML come i file PDF»: «Per indicare l’URL canonico di un documento supportato dalla Ricerca, inclusi file non HTML come i PDF, puoi usare un header HTTP Link con attributo target rel=canonical definito da RFC5988 anziché un elemento HTML.» Vai alla citazione
• «Funziona solo per pagine HTML, non per file come i PDF. In questi casi puoi usare l’header HTTP rel=canonical.» Vai alla citazione

Guida storica di Google — uno per pagina (i “5 errori comuni” del 2013)

• “When more than one is specified, all rel=canonical links will be ignored.” (traduzione) «Quando ne viene specificato più di uno, tutti i link rel=canonical vengono ignorati.» — Google Webmaster Central Blog (2013). È un contesto cronologico utile; la documentazione corrente avverte di errori e risultati inattesi senza definire un esito deterministico dei tag duplicati. Vai alla citazione
• “When we encounter a rel=canonical designation in the <body>, it’s disregarded.” (traduzione) «Quando troviamo una dichiarazione rel=canonical nel <body>, la ignoriamo.» Vai alla citazione
• “Specifying a rel=canonical from page 2 (or any later page) to page 1 is not correct use of rel=canonical.” (traduzione) «Specificare un rel=canonical dalla pagina 2, o da una pagina successiva, alla pagina 1 non è un uso corretto di rel=canonical.» Vai alla citazione

Google — canonical preferito a noindex; metodi in conflitto

• «Sconsigliamo di usare noindex per impedire la selezione di una pagina canonica nello stesso sito, perché bloccherebbe completamente la pagina dalla Ricerca. Le annotazioni rel=canonical sono la soluzione preferita.» Vai alla citazione
• “Don’t specify different URLs as canonical for the same page using different canonicalization techniques…” (traduzione) «Non specificare URL canonici diversi per la stessa pagina usando tecniche di canonicalizzazione differenti…» Vai alla citazione

John Mueller, Google — perché un canonical viene ignorato sui siti JS

• “With JavaScript based sites, the content side is a common reason for this: for example, if you’re using a SPA-type setup where the static HTML is mostly the same, and JavaScript has to be run in order to see any of the unique content, then if that JS can’t be executed properly, then the content ends up looking the same.” (traduzione) «Nei siti basati su JavaScript il contenuto è una causa comune: per esempio, in una SPA con HTML statico quasi identico, JavaScript deve essere eseguito per mostrare il contenuto unico; se non viene eseguito correttamente, i contenuti finiscono per sembrare uguali.» (Riportato da Search Engine Journal, 2019.) Vai alla citazione

Fabrice Canel e Krishna Madhavan, Microsoft Bing

• “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 contribuiscono tutti a questa chiarezza, ma la base è un sito lineare che eviti duplicazioni inutili.» Leggi l’articolo

Checklist d’implementazione e QA del canonical

Eseguila su qualunque pagina (o template) per cui stai impostando un canonical:

• Esiste esattamente un <link rel="canonical"> nella pagina, contato nel DOM renderizzato, non solo in view-source (CMS, tema e plugin possono aggiungerne uno ciascuno).
• Il tag è nel <head>, il più presto possibile, e vi resta nel <head> dopo il rendering (nessun tag non chiuso, JS o iframe che lo spinga fuori).
• href è un URL assoluto e completo (https://www.example.com/page/), non un percorso relativo /page/ e non un frammento.
• Punta all’host e protocollo corretti (https:// invece di http://, con il tuo host canonico) e l’URL restituisce davvero 200.
• Il target è una destinazione pulita: non reindirizza, non concatena un altro canonical e non è noindex. (È un controllo separato dalla crawlability della sorgente.)
• Le pagine preferite si riferiscono a se stesse.
• Le pagine paginate si riferiscono a se stesse, non alla pagina 1.
• L’URL canonicalizzato (duplicato) non è bloccato in robots.txt, non è noindex e non restituisce 4XX: Google deve poter leggere il tag.
• Nessun canonical in conflitto tra i metodi (URL sitemap, <link> e header concordano).
• Per PDF/non HTML, il canonical viene inviato nell’header HTTP Link (verificato con curl -I).
• Se usi hreflang, il canonical punta a una pagina nella stessa lingua.
• Controllo URL GSC mostra il canonical scelto da Google uguale a quello dichiarato dall’utente (indaga ogni differenza).

Cheat sheet canonical

Canonical contro redirect 301 contro noindex — quale usare

Preferenza Google per i duplicati interni: rel=canonical invece di noindex.

Posizionamento canonical valido e non valido

Mappa delle correzioni

Testare e implementare i canonical

Testare il canonical HTML (macOS / Linux)

Recupera l’HTML grezzo e cerca il tag: così vedi che cosa invia la sorgente, prima del rendering JavaScript:

# Show every rel=canonical the server sends in the raw HTML
curl -sL https://www.example.com/page/ | grep -i 'rel=["'"'"']\?canonical'

Se restituisce più di una riga, hai un problema di canonical multipli: non presumere che vinca il primo o l’ultimo e neppure che tutti vengano certamente ignorati. Se non restituisce nulla ma la pagina “ha” un canonical, probabilmente viene iniettato da JavaScript: controlla invece il DOM renderizzato (pannello Elements di DevTools o Controllo URL GSC → “Visualizza pagina sottoposta a crawling” / HTML renderizzato). La trappola del body-placement è visibile solo nel DOM renderizzato, quindi verifica sempre entrambe le versioni.

Testare l’header HTTP Link (per PDF/non HTML)

# -I = headers only; look for a Link: ...; rel="canonical" line
curl -sI https://www.example.com/downloads/whitepaper.pdf | grep -i '^link:'
# Expected:
# link: <https://www.example.com/downloads/whitepaper.pdf>; rel="canonical"

Inviare l’header HTTP Link — Apache (.htaccess)

# Canonical header for a specific PDF
<Files "whitepaper.pdf">
  Header set Link '<https://www.example.com/downloads/whitepaper.pdf>; rel="canonical"'
</Files>

Inviare l’header HTTP Link — Nginx

location = /downloads/whitepaper.pdf {
    add_header Link '<https://www.example.com/downloads/whitepaper.pdf>; rel="canonical"';
}

Note sulle piattaforme

• WordPress + Yoast (o Rank Math): un canonical autoreferenziale viene aggiunto automaticamente; impostane uno personalizzato nelle impostazioni SEO Advanced del post. Se anche il tema o un altro plugin emette un canonical, avrai duplicati: controlla il DOM renderizzato e disattiva la sorgente extra.
• Shopify: i temi producono di default un canonical in theme.liquid/nei template (spesso {{ canonical_url }}). Per sovrascriverlo per template, modifica Liquid; per asset non HTML, in cui non puoi modificare un <head>, usa un’app o una regola edge/CDN che aggiunga l’header HTTP Link.
• Next.js / SPA: renderizza il canonical lato server (API metadata del framework / output <head>). Non affidarti a JS lato client: se non viene eseguito durante il rendering o inserisce il tag nel body, il canonical scompare. È il caso di contenuto JS descritto da Mueller.

Modelli mentali

1. Dichiarare contro decidere. Tu dichiari una preferenza con il tag canonical; Google decide durante la canonicalizzazione, pesando circa 40 segnali — una cifra che Allan Scott di Google ha dichiarato pubblicamente. Il tag è un input forte, mai l’ultima parola. Se canonical dichiarato e scelto non concordano, il problema è nel contenuto o negli altri segnali, non nella formulazione del tag.

2. Segnale, non direttiva: scegli lo strumento giusto per l’obiettivo.

• Mantieni entrambi gli URL live e consolida → canonical (segnale).
• Rimuovi il duplicato dall’esistenza → 301 (più forte, cambia il comportamento).
• Rimuovi una pagina dall’indice → noindex (direttiva). Non usare canonical quando in realtà intendi “elimina questa pagina dalla ricerca”.

3. Prima la visibilità. Un canonical conta solo se Google può eseguire il crawling della pagina, leggere il tag nel <head> e trovarne esattamente uno. Tutto ciò che rompe la visibilità — blocco robots.txt, 4XX, noindex, posizione nel body, tag multipli — lo neutralizza senza segnalarlo chiaramente. Esegui il debug della visibilità prima dell’intento.

4. Grezzo contro renderizzato. Ogni pagina ha due viste: HTML grezzo inviato dal server e DOM dopo che browser/renderer lo costruiscono. Un canonical può superare la prima e fallire la seconda (spinto nel body o con un secondo tag iniettato). Controllale sempre entrambe.

5. L’uguaglianza è la precondizione. Il canonical consolida duplicati veri o quasi duplicati. Se i due URL non hanno davvero lo stesso contenuto (frequente quando JS deve rivelare la parte unica), Google può decidere che c’è un errore e indicizzare comunque l’URL “non canonical”.

Risorse che meritano il tuo tempo

I miei contenuti correlati

• Tag canonical: spiegazione e importanza per la SEO — la guida d’implementazione Ahrefs che recensisco (a cura di Joshua Hardwick): regole d’oro, errori comuni e metodo di test.
• Google Uses ~40 Canonicalization Signals — il mio approfondimento sul lato della scelta: inventario dei segnali e distinzione tra suggerimento e segnale forte.
• The Beginner’s Guide to Technical SEO — il posto della canonicalizzazione nel quadro più ampio.
• JavaScript SEO Issues & Best Practices — il lato rendering dietro gli errori di posizionamento nel body e di contenuto apparentemente uguale.

Ufficiali

• Come specificare un URL canonical (Google) — documento d’implementazione.
• 5 errori comuni con rel=canonical (Google, 2013) — ancora la fonte più chiara sui modi in cui può fallire.

Da altri

• Yoast — rel=canonical: la guida definitiva — forte sul concetto e sulla configurazione WordPress/Yoast.
• John Mueller di Google spiega perché rel=canonical a volte viene ignorato (Search Engine Journal, 2019) — spiegazione testuale di Mueller sul motivo per cui i siti SPA/JS ricevono spesso il canonical sbagliato.
• Google Clarifies Simultaneous Use of Canonical & Noindex (Search Engine Journal, 2024) — problema delle istruzioni in conflitto quando entrambi i tag sono sulla pagina.
• Google: Having Rel Canonical Doesn’t Guarantee Google Picks Up That Page As Canonical (Search Engine Roundtable) — Mueller sul canonical come segnale, non garanzia.
• Semrush — URL canonici: buone pratiche SEO, problemi comuni e soluzioni — utile per interpretare gli errori canonical di GSC.
• r/TechSEO — comunità per il debug di canonical e indicizzazione.

Citazioni degne di nota

Le frasi a cui torno quando spiego i canonical — ciascuna è un link profondo al passaggio della fonte.

• È un segnale. “indicating a canonical preference is a hint, not a rule.” (traduzione) «Indicare una preferenza canonical è un suggerimento, non una regola.» — Google. Vai alla citazione
• Guida storica sui duplicati. “When more than one is specified, all rel=canonical links will be ignored.” (traduzione) «Quando ne viene specificato più di uno, tutti i link rel=canonical vengono ignorati.» — Google (2013); i documenti attuali definiscono i metodi in conflitto inclini a errori, senza specificare l’esito del parser. Vai alla citazione
• Solo <head>. “When we encounter a rel=canonical designation in the <body>, it’s disregarded.” (traduzione) «Quando troviamo una dichiarazione rel=canonical nel <body>, la ignoriamo.» — Google (2013). Vai alla citazione
• Per i PDF si usa l’header. “Only works for HTML pages, not for files such as PDF. In such cases, you can use the rel=“canonical” HTTP header.” (traduzione) «Funziona solo per pagine HTML, non per file come i PDF; in questi casi puoi usare l’header HTTP rel=canonical.» — Google. Vai alla citazione
• Canonical invece di noindex. “rel=“canonical” link annotations are the preferred solution.” (traduzione) «Le annotazioni link rel=canonical sono la soluzione preferita.» — Google. Vai alla citazione
• Perché viene ignorato sui siti JS. “…if that JS can’t be executed properly, then the content ends up looking the same.” (traduzione) «Se JavaScript non viene eseguito correttamente, i contenuti finiscono per sembrare uguali.» — John Mueller, Google. (Riportato da Search Engine Journal, 2019.) Vai alla citazione

Errori d’implementazione canonical da evitare

Sono i modi specifici in cui si rompe un tag canonical mentre lo si configura. Ogni caso è reale e comune, non ipotetico.

• Accumulo di più tag rel=canonical nella stessa pagina. Perché è sbagliato: le dichiarazioni sono in conflitto e la guida corrente non offre un esito affidabile primo/ultimo. La causa tipica è CMS, tema e plugin SEO che iniettano ciascuno il proprio tag. Fai invece: conta i tag <link rel="canonical"> nel DOM renderizzato (non solo view-source) e assicurati che li emetta una sola sorgente.
• Lasciare che il canonical finisca nel <body>. Perché è sbagliato: Google ignora le dichiarazioni rel=canonical trovate nel <body>. Di solito non è un refuso: tag non chiusi, JavaScript iniettato nel head o un <iframe> nel <head> possono chiuderlo prima durante il rendering. Fai invece: confronta HTML grezzo e DOM renderizzato (Elements di DevTools o HTML renderizzato GSC); il problema è invisibile in view-source da solo.
• Scrivere un href relativo invece di un URL assoluto. Perché è sbagliato: un percorso /page/ si risolve rispetto all’URL corrente e con una base malformata può portare altrove. I percorsi relativi sono supportati ma possono causare problemi nel tempo. Fai invece: usa sempre https://www.example.com/page/ completo.
• Canonicalizzare pagina 2, 3, 4… alla pagina 1. Perché è sbagliato: le pagine successive non sono duplicati della prima e puntarle alla pagina 1 non è un uso corretto di rel=canonical. Fai invece: ogni pagina paginata deve riferirsi al proprio canonical.
• Canonicalizzare una categoria o landing verso un singolo articolo in evidenza. Perché è sbagliato: categoria e articolo non sono lo stesso contenuto: è sovra-canonicalizzazione. Fai invece: la categoria deve riferirsi a se stessa; usa il canonical solo per duplicati reali o quasi duplicati.
• Affiancare canonical e noindex sull’URL che vuoi consolidare. Perché è sbagliato: le istruzioni si contraddicono: noindex dice “rimuovi”, canonical “consolida”. Fai invece: consolidare → solo canonical; rimuovere → solo noindex.
• Bloccare l’URL canonicalizzato in robots.txt. Perché è sbagliato: se Google non può eseguire il crawling del duplicato, non vede il canonical e non può consolidare; un URL bloccato può comunque essere indicizzato senza che Google ne conosca il contenuto. Fai invece: lascia il duplicato scansionabile e fai consolidare al canonical.
• Restituire un 4XX sull’URL canonicalizzato. Perché è sbagliato: stesso fallimento del blocco robots: Google non può leggere il tag su una pagina che non riesce a recuperare. Fai invece: mantieni l’URL live con stato 200 se vuoi consolidarne i segnali.

Canonical, redirect 301 o noindex — quale mi serve?

Parti da ciò che vuoi che accada all’URL duplicato, non dal tag che suona più “tecnico”.

La versione in una riga: entrambi live e vuoi solo esprimere una preferenza → canonical. Vuoi spostare tutto a un URL → 301. Vuoi mantenere la pagina ma fuori dalla ricerca → noindex. Non usare canonical quando intendi davvero “elimina questa pagina dalla ricerca”: quello è il lavoro di noindex, non del canonical.

Prompt IA pronti all’uso

Punti di partenza da copiare per controllare o diagnosticare tag canonical con un LLM. Verifica sempre l’output sulla pagina renderizzata e in GSC: sono aiuti per la bozza, non sostituti del controllo HTML reale.

Controllare l’implementazione canonical di una pagina

Ecco l’HTML grezzo del <head> e il <head> del DOM renderizzato per questo URL: [incolla entrambi]. Controlla: (1) esiste esattamente un <link rel="canonical">, (2) è un URL assoluto e non un percorso relativo, (3) dopo il rendering è rimasto nel <head> invece di essere spinto nel <body>, (4) non canonicalizza una pagina paginata alla pagina 1 o una categoria verso un singolo articolo. Elenca ogni regola fallita e cita la riga esatta errata.

Spiegare una differenza canonical in Search Console

Controllo URL di Google Search Console mostra un canonical dichiarato dall’utente [URL A] e un canonical scelto da Google [URL B] per questa pagina. Dato che rel=canonical è un segnale che Google può superare, elenca in ordine di priorità le cause più probabili di questa differenza (contenuto non davvero equivalente, link interni/sitemap/redirect in conflitto, più tag canonical, posizione nel body) e che cosa controllare per ciascuna.

Preparare l’header HTTP Link per un file non HTML

Devo canonicalizzare questo PDF (o altro file non HTML) a [URL] usando l’header di risposta HTTP Link: rel="canonical" invece di un elemento HTML <link>, perché i PDF non hanno un <head>. Il mio server è [Apache / Nginx / altro]. Dammi lo snippet di configurazione esatto e il comando curl -I da eseguire dopo per confermare che l’header venga davvero inviato.

Controllare una decisione canonical contro 301 contro noindex

Ho un URL duplicato a [URL] e un URL preferito a [URL]. Attualmente entrambi [restano live / uno deve sparire — descrivi]. In base alla regola per cui canonical è un segnale per URL che devono restare raggiungibili entrambi, 301 è l’opzione più forte quando il duplicato non dovrebbe esistere affatto e noindex rimuove una pagina dalla ricerca, dimmi quale si adatta al mio caso e perché gli altri due no.

Strumenti per controllare i tag canonical

Il walkthrough completo del Canonicalization Checker nella lente Advanced copre il controllo primario su una singola pagina. Questi strumenti sono utili insieme:

• Redirect Checker — utile insieme al checker canonical quando devi scegliere tra canonical e 301: mostra ogni passaggio e lo stato finale dell’URL.
• Controllo URL GSC — confronto di Google tra canonical dichiarato dall’utente e canonical scelto da Google; il modo più rapido per vedere se Google concorda col tag.
• curl -I — il modo più rapido per verificare che un header HTTP Link: rel="canonical" venga davvero inviato per un PDF o altro file non HTML.
• Ahrefs Site Audit (gratuito tramite Ahrefs Webmaster Tools per siti verificati) o Screaming Frog — esegui il crawling dell’intero sito per trovare problemi canonical (multipli, URL relativi, differenze) su larga scala invece di una pagina alla volta.

Problemi comuni

GSC mostra “Duplicate, Google chose a different canonical than user”

Causa: il canonical dichiarato non concorda con quello scelto da Google: di solito i due URL non hanno davvero lo stesso contenuto oppure link interni, sitemap o redirect puntano tutti all’altro URL e superano il tag. Correzione: conferma che il contenuto sia davvero equivalente (è il fallimento JS/SPA più comune: se il contenuto unico appare solo dopo l’esecuzione JavaScript e quel JS non viene eseguito, Google vede le pagine più simili di quanto siano); poi allinea link interni e sitemap verso lo stesso URL dichiarato.

Il tag sembra corretto in view-source ma non viene rispettato

Causa: durante il rendering il canonical viene spinto fuori dal <head>: un tag non chiuso, JavaScript iniettato o un <iframe> nel head lo chiude prima e il tag finisce nel <body>, dove viene ignorato. Correzione: confronta HTML grezzo e DOM renderizzato (pannello Elements di DevTools o HTML renderizzato in Controllo URL GSC): il fallimento è invisibile in view-source, quindi controllali sempre entrambi.

Una pagina sembra avere un canonical, ma non viene consolidato nulla

Causa: ci sono più tag rel=canonical (CMS + tema + plugin ne aggiungono uno ciascuno, quindi vengono ignorati) oppure l’URL canonicalizzato è bloccato in robots.txt o restituisce 4XX, perciò Google non legge mai il tag. Correzione: usa curl -sL sulla pagina e conta le righe canonical nell’HTML grezzo; se sono più di una, rimuovi le sorgenti extra. Separatamente, verifica che l’URL canonicalizzato sia scansionabile e restituisca 200.

Un PDF o altro file non HTML non si consolida

Causa: un PDF non ha <head>, quindi non c’è posto per un elemento <link rel="canonical">; inoltre non è stato configurato un header che trasporti il segnale. Correzione: invia il canonical tramite l’header di risposta HTTP Link: rel="canonical" a livello di server o CDN, poi conferma che sia presente con curl -sI <url> | grep -i '^link:'.

Il canonical punta a un URL che reindirizza, concatena o è noindexed

Causa: il target — l’URL verso cui punti — non è una destinazione pulita. RFC 6596 sconsiglia un target che è sorgente di un redirect, concatena un altro canonical o restituisce un codice di errore; un target con noindex è lo stesso problema in pratica. È diverso dalla crawlability lato sorgente (robots.txt, noindex o 4XX sull’URL duplicato): qui il duplicato è corretto, ma la destinazione non è valida per il consolidamento. Correzione: punta direttamente all’URL finale, live, con stato 200 e senza noindex; mai a un URL che reindirizza o che ha a sua volta un canonical diverso.

Il canonical continua a essere ignorato anche dopo aver corretto posizione e duplicati

Causa: qualcosa continua a dire a Google che le pagine non sono equivalenti oppure esiste un segnale conflittuale altrove: un URL diverso nella sitemap o noindex sull’URL che vuoi consolidare. Correzione: controlla sitemap e tag noindex per conflitti con il canonical dichiarato e riesegui Controllo URL GSC dopo ogni modifica per vedere se il canonical scelto da Google si avvicina a quello dichiarato.

Dimostrare che il canonical funziona davvero

Hai aggiunto o corretto un tag canonical. Questi controlli separano “il tag esiste nel mio codice sorgente” da “Google sta davvero consolidando verso di esso”.

Test 1 — Esattamente un canonical nel head renderizzato

• Test da eseguire — usa view-source e poi ispeziona separatamente il DOM renderizzato (Elements di DevTools oppure il Canonicalization Checker).
• Risultato atteso — esattamente un <link rel="canonical">, ancora dentro il <head> dopo il rendering e con URL assoluto.
• Interpretazione del fallimento — più tag nell’HTML grezzo significa che tutti verranno ignorati (CMS + tema + plugin ne aggiungono uno ciascuno). Un tag presente in view-source ma assente dal <head> renderizzato è stato spinto nel <body>: cerca tag non chiusi, JS iniettato o un <iframe> nel head.
• Finestra di monitoraggio — immediata: è un controllo statico della pagina corrente.
• Trigger di rollback — se il <head> renderizzato non porta mai il tag, qualunque correzione tu faccia, smetti di modificare il canonical e controlla prima ciò che chiude prematuramente il <head>.

Test 2 — L’header HTTP è inviato (PDF/non HTML)

• Test da eseguire — curl -sI https://example.com/file.pdf | grep -i '^link:'.
• Risultato atteso — una riga link: <url>; rel="canonical" negli header di risposta.
• Interpretazione del fallimento — nessun header link: significa che la configurazione server/CDN non lo invia: controlla .htaccess, configurazione Nginx o regola edge che dovrebbe aggiungerlo.
• Finestra di monitoraggio — immediata.
• Trigger di rollback — N/A: è un controllo di configurazione, non un cambiamento da ripristinare.

Test 3 — Il canonical scelto da Google corrisponde a quello dichiarato

• Test da eseguire — esegui Controllo URL in Google Search Console sull’URL canonicalizzato (duplicato).
• Risultato atteso — canonical dichiarato dall’utente e canonical scelto da Google coincidono con l’URL voluto.
• Interpretazione del fallimento — una differenza (per esempio “Duplicate, Google chose a different canonical than user”) di solito significa che i contenuti non sono davvero equivalenti oppure che un segnale più forte — link interni, sitemap, redirect — porta Google altrove. Ricorda che è un segnale, non una regola: Google può continuare a non concordare anche con un tag corretto. I campi del canonical indicizzato possono inoltre essere in ritardo di ore e il live test non predice la scelta: conferma solo che l’URL è recuperabile.
• Finestra di monitoraggio — da giorni fino al limite dichiarato da Google: la guida di troubleshooting dice che “might hold pages in a duplicate cluster for up to two weeks” dopo la correzione del problema di contenuto. È specifico della rivalutazione di un cluster corretto, non una tempistica universale per un tag canonical, la pulizia di un rapporto o il ranking.
• Trigger di rollback — non continuare a irrigidire il tag canonical se la differenza persiste per settimane: controlla prima se i due URL sono davvero duplicati, perché è più spesso la causa principale rispetto alla formulazione del tag.

Mettiti alla prova: il tag canonical

Cinque domande rapide sul funzionamento di rel=canonical. Scegli una risposta per ciascuna, poi controlla il risultato.

Cronologia modifiche