Lingue

Tag canonical

Come implementare correttamente rel=canonical: elemento link HTML, header HTTP Link per i PDF, URL assoluti, un solo canonical per pagina e principali errori da evitare.

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

Un tag canonical (rel=canonical) dice ai motori di ricerca quale URL è la versione preferita di un contenuto duplicato. È un segnale forte ma non una direttiva: Google può superarlo. I metodi validi sono il link HTML nel head (mai nel body), l'header HTTP Link per PDF e altri documenti non HTML e la sitemap come segnale più debole. Dichiara una sola relazione canonical non ambigua per pagina, usa URL assoluti e autoreferenziali per le pagine preferite. Non canonicalizzare pagine paginate verso pagina 1 e non combinare canonical con noindex o blocco robots.txt. Testa risposta grezza, DOM renderizzato, header e confronto tra canonical dichiarato dall'utente e scelto da Google in Search Console.

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”. È un suggerimento forte — come spiego nel mio approfondimento sulla canonicalizzazione, il canonical è “considered a strong signal” e “Google ignores it if other signals are stronger” — ma 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 “Duplicate, Google chose a different canonical than user”. Evidence for this claim Canonicalization methods communicate a preferred URL, but Google can choose a different canonical when signals conflict. Scope: Google Search canonical selection; applies to duplicate or very similar pages. Confidence: high · Verified: 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: Evidence for this claim Alongside redirects, Google documents three non-redirect ways to indicate a canonical: an HTML link element, an HTTP Link header, and sitemap inclusion. Scope: The three non-redirect canonical declaration approaches covered in this article; Google also documents redirects as a canonicalization method. Confidence: high · Verified: Google: Specify a canonical URL

  • HTML <link rel="canonical"> nel <head> — “A strong signal that the specified URL should become canonical.” È 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 “Only works for HTML pages, not for files such as PDF”; per questi casi usa l’header HTTP rel=“canonical”. È la risposta alla domanda “come canonicalizzare un PDF”.
  • Presenza nella sitemap — “A weak signal that helps the URLs that are included in a sitemap become canonical.” È reale, ma è il più debole dei tre.

Due aspetti da ricordare sul loro rapporto:

  • Si sommano. Google dice che “these methods can stack and thus become more effective when combined”. Un <link> autoreferenziale, una sitemap pulita e link interni coerenti verso lo stesso URL sono molto più forti di un solo segnale.
  • Nessuno è obbligatorio. “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.” 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).

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: “The rel=“canonical” link element is only accepted if it appears in the <head> section of the HTML, so make sure at least the <head> section is valid HTML.” E dal post del 2013 sui “5 errori comuni”, ancora la formulazione più chiara: “When we encounter a rel=canonical designation in the <body>, it’s disregarded.” La regola finale è: “rel=canonical designations in the <head> are processed, not the <body>.” Evidence for this claim Google accepts an HTML rel=canonical link element only in a valid head section and disregards a canonical placed in the body. Scope: HTML link-element canonicals in Google Search; HTTP-header canonicals are a separate method. Confidence: high · Verified: 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: elementi come “unclosed tags, JavaScript injected” possono terminare prima il <head> e spingere il canonical nel <body> renderizzato, “where it will not be respected”.

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.” 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 pattern nel mio approfondimento sulla canonicalizzazione: più tag rel=canonical probabilmente vengono ignorati e “in many cases this happens because tags are inserted into a system at different points such as by the CMS, the theme, and plugin(s).” Se stai eseguendo il debug di un canonical che “non funziona”, conta prima i tag nel DOM renderizzato.

Usa URL assoluti, non relativi

Google dice: “Use absolute paths rather than relative paths with the rel=“canonical” link element. Even though relative paths are supported by Google, they can cause problems in the long run.” 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: “Google generally doesn’t support URL fragments.”

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. “Specifying a rel=canonical from page 2 (or any later page) to page 1 is not correct use of rel=canonical.” La pagina 2 non è un duplicato della pagina 1: ha contenuto diverso. Usa invece “self-referencing canonicals … on all paginated pages”: 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 Disallow il duplicato, Google non può eseguirne il crawling e non vede il canonical: non può consolidare. Google aggiunge che un URL bloccato da robots “may still index URLs that are disallowed in robots.txt without their content.” 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: “Don’t specify different URLs as canonical for the same page using different canonicalization techniques”, 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: “specify a canonical page in the same language, or the best possible substitute language if a canonical page doesn’t exist for the same language.”

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.

La preferenza di Google per i duplicati interni è il canonical: “We don’t recommend using noindex to prevent selection of a canonical page within a single site, because it will completely block the page from Search. rel=“canonical” link annotations are the preferred solution.” Evidence for this claim Google recommends rel=canonical rather than noindex when the goal is selecting a canonical within one site, because noindex removes the page from Search. Scope: Google Search guidance for duplicate pages within a single site. Confidence: high · Verified: 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: “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.” Se Google non vede il contenuto unico, 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: la guida Google corrente dice che “the canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different.” Evidence for this claim 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. Scope: Google Search guidance for syndicated-content duplication; canonical remains valid where the syndicated copy is a genuine duplicate or superset of the original. Confidence: high · Verified: 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, “Canonical tags, redirects, hreflang, noindex, and IndexNow all support this clarity, but the foundation is a streamlined site that avoids unnecessary duplication.” 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.

Add an expert note

Pin an expert quote

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