Cos’è il rel canonical: definizione diretta
Il rel canonical è un tag HTML che indica ai motori di ricerca quale versione di una pagina web considerare come quella ufficiale e preferita. Si inserisce nel <head> del documento o negli HTTP header, e serve a consolidare i segnali SEO — link equity, dati di engagement, segnali di ranking — su un’unica URL, evitando la dispersione causata da contenuti duplicati o quasi-duplicati.
Immagina di avere la stessa pagina prodotto raggiungibile da tre URL distinte: con www, senza www, e con un parametro di sessione aggiunto automaticamente dal server. Per Google si tratta di tre pagine diverse che competono tra loro. Il rel canonical dice esattamente quale delle tre conta.
La sintassi HTML di base è questa:
<link rel="canonical" href="https://www.esempio.it/pagina-preferita/" />
L’attributo rel="canonical" definisce il tipo di relazione tra la pagina corrente e quella referenziata. L’attributo href contiene l’URL assoluto della versione preferita. Una svista frequente è usare URL relative al posto di assolute: href="/pagina/" invece di href="https://www.esempio.it/pagina/". Tecnicamente accettato, ma sconsigliato perché aumenta il rischio di errori in contesti di migrazione o cambio di dominio.
È fondamentale distinguere tra canonical dichiarato (quello che inserisci tu) e canonical selezionato da Google (quello che Google sceglie autonomamente). Il tag è un segnale, non un’istruzione imperativa: Google lo rispetta nella maggioranza dei casi, ma si riserva il diritto di ignorarlo se i segnali presenti sulla pagina contraddicono la tua dichiarazione.
Perché il rel canonical è fondamentale per la SEO
Il rel canonical è fondamentale per la SEO perché protegge la link equity accumulata da una pagina, evitando che venga dispersa tra varianti URL equivalenti che Google potrebbe trattare come contenuti separati e in competizione tra loro.
Il problema della dispersione dei segnali SEO
Senza canonical, ogni URL che punta allo stesso contenuto accumula separatamente i propri segnali: backlink ricevuti, dati di comportamento utente, autorità interna. Il risultato è che nessuna delle versioni raggiunge la massa critica necessaria per posizionarsi bene, mentre con il canonical tutti questi segnali confluiscono sulla versione dichiarata come preferita.
Il canonical link element — come documentato anche su Wikipedia — è stato introdotto nel febbraio 2009 da Google, Yahoo e Bing in modo coordinato, un evento raro nella storia della SEO tecnica: tre motori di ricerca concorrenti che adottano simultaneamente lo stesso standard per risolvere un problema comune. Da quel momento è diventato uno degli strumenti più utilizzati nella SEO tecnica a livello globale.
L’impatto sul crawl budget è spesso sottovalutato. Nei siti di grandi dimensioni — ecommerce con migliaia di SKU, portali con archivi profondi, siti con molte varianti di filtro — Googlebot dedica risorse limitate al crawling. Se il bot spreca cicli su URL duplicate invece di scoprire contenuti nuovi, l’intero sito ne risente in termini di frequenza di indicizzazione.
Un caso concreto: un ecommerce di abbigliamento con 500 prodotti e filtri per colore, taglia e ordinamento può generare decine di migliaia di URL uniche. Senza canonical su tutte le varianti, il crawl budget viene consumato da pagine che non aggiungono valore, rallentando l’indicizzazione delle nuove schede prodotto. Con il canonical implementato correttamente, il crawler riconosce subito le varianti e le scarta.
Canonical autoreferenziale: perché metterlo anche sulle pagine uniche
Il canonical self-referencing è una best practice difensiva raccomandata da Google per ogni pagina del sito, anche quelle senza duplicati apparenti. La logica è semplice: un canonical autoreferenziale dice esplicitamente a Google “questa è la versione ufficiale di questa pagina”, proteggendola da varianti accidentali generate da parametri UTM, ID di sessione, token di tracciamento o semplicemente dalla presenza o assenza del trailing slash.
Considera questo scenario: un link condiviso su una newsletter arriva con ?utm_source=email&utm_campaign=maggio appeso all’URL. Senza canonical, Google potrebbe vedere questa variante come una pagina separata. Con il canonical self-referencing che punta all’URL pulita, il segnale è chiaro indipendentemente dai parametri aggiuntivi.
Per la gestione dei parametri URL, il canonical è anche più elegante dell’alternativa — configurare Google Search Console per ignorare specifici parametri — perché opera direttamente sulla pagina e non richiede accesso a strumenti esterni.
Come implementare il tag rel canonical: sintassi e metodi
Il tag rel canonical si implementa in tre modi distinti: via tag HTML nel <head>, via HTTP header per documenti non-HTML, o indirettamente attraverso la sitemap XML. La scelta del metodo dipende dal tipo di contenuto e dall’accesso che hai all’infrastruttura del sito.
Metodo 1 — Tag HTML nel <head>
È il metodo principale e più diffuso. Il tag va inserito nella sezione <head> della pagina, preferibilmente il più in alto possibile per essere letto dal crawler prima di eventuali JavaScript che potrebbero modificare il DOM:
<!DOCTYPE html>
<html lang="it">
<head>
<meta charset="UTF-8">
<link rel="canonical" href="https://www.esempio.it/categoria/prodotto-principale/" />
<title>Titolo della pagina</title>
</head>
Errori di sintassi frequenti da evitare:
- Inserire il tag nel
<body>invece del<head>(alcuni CMS mal configurati lo fanno) - Usare URL con HTTP invece di HTTPS se il sito è già su HTTPS
- Omettere il trailing slash quando tutte le altre URL del sito lo includono (o viceversa)
- Inserire più tag canonical sulla stessa pagina — Google legge il primo e ignora gli altri, ma la situazione è ambigua
Metodo 2 — HTTP header per documenti non-HTML
Per file come PDF, Word o CSV non puoi inserire un tag HTML. In questo caso puoi dichiarare il canonical tramite l’intestazione HTTP Link:
Link: <https://www.esempio.it/documento-originale.pdf>; rel="canonical"
Questa configurazione si imposta tipicamente nel file .htaccess (Apache) o nella configurazione Nginx. Il metodo è funzionalmente equivalente al tag HTML e riconosciuto da Google, ma richiede accesso al server.
Metodo 3 — Sitemap XML come segnale debole
Includere solo gli URL canonici nella sitemap XML è un segnale di canonicalità, ma debole. Google tratta la sitemap come un suggerimento su quali pagine vuoi vengano indicizzate, non come una dichiarazione vincolante. Questo metodo va usato in combinazione con gli altri, non come sostituto.
Rel canonical su WordPress: Yoast SEO e RankMath
Su WordPress, sia Yoast SEO che RankMath gestiscono il canonical automaticamente per ogni tipo di contenuto: post, pagine, custom post type, tassonomie.
Con Yoast SEO:
- Accedi alla pagina o al post da modificare
- Scorri fino al metabox di Yoast SEO
- Vai alla scheda Avanzate
- Nel campo “URL canonico” trovi l’URL generata automaticamente — modificala solo se necessario
Con RankMath:
- Nel metabox di RankMath, seleziona la scheda Avanzate
- Il campo “URL canonica” mostra il valore attuale
- Sovrascrivilo manualmente solo in caso di necessità specifica
Per verificare che il plugin stia emettendo correttamente il tag, visualizza il sorgente della pagina (Ctrl+U) e cerca rel="canonical". Dovresti trovare un solo tag, con l’URL corretta. Se ne trovi due — situazione possibile quando si usano più plugin SEO contemporaneamente — è un problema critico da risolvere immediatamente disattivando o configurando correttamente il plugin secondario.
Quando sovrascrivere il canonical automatico? Nei casi in cui la pagina è intenzionalmente una copia di un’altra (una versione stampabile, una variante di landing page per una campagna specifica), oppure quando stai publicando un contenuto sindicato e vuoi che il canonical punti alla fonte originale esterna.
Canonical in HTTP header per file PDF e documenti
Il caso d’uso più comune per il canonical via HTTP header è la gestione di PDF scaricabili che hanno un URL proprio e ricevono backlink. Se il PDF è una versione stampabile di una pagina HTML esistente, dichiara il canonical sul PDF che punta alla pagina HTML:
Link: <https://www.esempio.it/guida-completa/>; rel="canonical"
Questo consolida eventuali link che puntano al PDF verso la pagina HTML principale, che è quella che vuoi venga indicizzata e posizionata.
Quando usare il rel canonical: flow decisionale per ogni scenario
Il rel canonical va applicato ogni volta che la stessa informazione — o una sua variante sostanzialmente identica — è accessibile da più URL diverse. Ecco come orientarsi nei casi più comuni.
Guida rapida ai principali scenari:
- URL con parametri di tracking (UTM, fbclid, gclid) → Canonical self-referencing sull’URL pulita. I parametri di campagna non cambiano il contenuto, ma moltiplicano le URL che Google può scansionare.
- HTTP vs HTTPS, www vs non-www → Scegli una versione come principale, implementa il canonical su tutte le altre che puntano a quella, e aggiungi un redirect 301 come rinforzo. Il canonical da solo non è sufficiente — il redirect è necessario.
- Schede prodotto raggiungibili da più categorie eCommerce → Canonical sulla versione URL che considera “principale” (di solito quella della categoria principale), su tutte le varianti generate dai breadcrumb alternativi.
- Contenuti sindicati su altri domini → Il sito che ripubblica il contenuto inserisce un canonical che punta alla fonte originale sul dominio esterno. Tutti i link ricevuti dalla versione ripubblicata passano così alla fonte.
- Versioni stampabili di una pagina → Canonical sulla pagina di stampa che punta alla versione standard. Le versioni print-friendly sono spesso indistinguibili per contenuto, ma hanno URL separata.
- Filtri e ordinamenti nei listing eCommerce → Canonical self-referencing su ciascuna pagina filtrata che punta all’URL del listing principale (senza filtri applicati), oppure canonical sulla pagina senza filtri se il contenuto filtrato non aggiunge valore indicizzabile autonomo.
- URL con e senza trailing slash → Scegli una convenzione e applicala ovunque. Il canonical rinforza la scelta, ma il redirect è il meccanismo corretto per evitare che entrambe le versioni siano accessibili.
Canonical e paginazione: come gestire archivi e categorie
La gestione della paginazione ha subito un cambio significativo nel 2019, quando Google ha deprecato i tag rel="prev" e rel="next". Dopo quella decisione, molti SEO hanno commesso l’errore opposto: usare il canonical di tutte le pagine paginate che puntano alla pagina 1 della serie.
Questa è una pratica da evitare. Se la pagina 2 di una categoria eCommerce contiene prodotti diversi dalla pagina 1, canonicalizzarla verso pagina 1 dice a Google di ignorare quei prodotti. Il risultato è che le pagine 2, 3, 4 e oltre smettono di essere indicizzate, e i prodotti presenti solo in quelle pagine spariscono dai risultati di ricerca.
La best practice attuale è usare il canonical self-referencing su ciascuna pagina paginata: ogni pagina è canonica rispetto a sé stessa. Questo permette a Google di indicizzare ogni pagina come entità autonoma e di capire che fa parte di una serie, senza segnali contraddittori.
L’unica eccezione ammissibile è quando le pagine paginate oltre la prima hanno contenuto talmente scarso o generico da non meritare indicizzazione autonoma — situazione più comune negli archivi blog che negli ecommerce.
Rel canonical vs redirect 301 vs noindex: tabella comparativa
Tre tecniche diverse per tre problemi diversi. Confonderle o usarle in modo intercambiabile è uno degli errori più costosi nella SEO tecnica.
| Tecnica | Caso d’uso principale | Effetto sull’indicizzazione | Effetto sul link equity | Impatto sull’utente | Quando preferirla |
|---|---|---|---|---|---|
| rel canonical | URL duplicate con contenuto identico o quasi-identico che devono restare accessibili | La variante non-canonica non viene indicizzata (in genere) | Trasferito all’URL canonica | Nessuno: l’utente vede la pagina normalmente | URL duplicate necessarie per motivi tecnici o UX |
| Redirect 301 | Pagina rimossa, rinominata, o migrata definitivamente | L’URL vecchia smette di essere indicizzata, l’URL nuova la sostituisce | Trasferito quasi integralmente all’URL di destinazione | L’utente viene inviato automaticamente alla nuova URL | Quando la vecchia URL non deve più essere accessibile |
| noindex | Pagina tecnica da mantenere accessibile agli utenti ma non indicizzabile | La pagina viene rimossa dall’indice di Google | Non consolidato: il link equity ricevuto si disperde | Nessuno: la pagina è accessibile normalmente | Pagine di login, carrello, conferma ordine, ricerca interna |
Tre casi ibridi che generano confusione:
Redirect 301 invece di canonical (pagina rimossa definitivamente): Se una pagina non esiste più e non hai motivo di mantenerla accessibile, il redirect 301 è la scelta corretta. Il canonical presuppone che entrambe le URL restino accessibili — se la vecchia URL risponde 200 ma il contenuto è sparito, stai creando un segnale incoerente.
noindex invece di canonical (pagina tecnica non indicizzabile): Il canonical non rimuove una pagina dall’indice, la associa a un’altra. Se hai una pagina che non vuoi venga mai indicizzata — come una pagina di conferma ordine o una pagina di filtraggio interno — noindex è lo strumento corretto, non il canonical.
Redirect 301 + canonical sulla destinazione: In una migrazione di sito, il pattern ideale è implementare il redirect 301 sulle vecchie URL e assicurarsi che le nuove URL di destinazione abbiano un canonical self-referencing corretto. Questo garantisce che i segnali accumulati sulle vecchie URL vengano trasferiti e che le nuove URL siano identificate chiaramente come canoniche.
Per un approfondimento sui redirect, consulta la guida completa su redirect e reindirizzamenti.
Canonical cross-domain per contenuti sindicati
Il canonical cross-domain permette a un sito che ripubblica un contenuto di dichiarare esplicitamente che la versione originale si trova su un dominio diverso. Sintassi identica al canonical standard, ma con URL che punta a un dominio esterno:
<link rel="canonical" href="https://www.sito-originale.it/articolo-originale/" />
Per il sito che pubblica il contenuto: riceve il traffico diretto degli utenti che atterrano sulla pagina, ma cede il credito SEO alla fonte. È una scelta editoriale consapevole, non un errore.
Per il sito originale: riceve tutti i segnali di ranking accumulati dalla versione ripubblicata — backlink, condivisioni, engagement — senza che la versione sindicata competa nella SERP.
La differenza rispetto al guest post è sostanziale: il guest post è un contenuto originale scritto per un altro sito, senza canonical cross-domain, e genera un backlink verso il tuo sito. La sindicazione con canonical è la republication di un contenuto già esistente, con trasferimento esplicito del credito SEO.
L’accordo editoriale minimo necessario prima di sindicare un contenuto: il sito che ripubblica deve impegnarsi esplicitamente a inserire il canonical cross-domain. Senza questa garanzia, il contenuto sindicato rischia di competere con l’originale o, peggio, di venire scelto da Google come versione canonica se il sito ripubblicante ha più autorità.
Errori critici di implementazione del rel canonical
Gli errori di canonical sono tra i più insidiosi nella SEO tecnica perché spesso non generano errori visibili, ma semplicemente rendono il tag inefficace o controproducente. Ecco gli otto errori più frequenti, con impatto concreto e soluzione operativa.
Errore 1 — Canonical che punta a una pagina 404
Se il canonical punta a un URL che risponde con un errore 404, Google ignora il segnale e tratta la pagina come se non avesse canonical. Peggio: potrebbe indicizzare la pagina con il canonical rotto al posto della versione che intendevi promuovere. Soluzione: audit periodico dei canonical con Screaming Frog per rilevare destinazioni che restituiscono codici non-200.
Errore 2 — Canonical chain (A → B → C)
Quando la pagina A ha un canonical che punta a B, e B ha un canonical che punta a C, si crea una catena. Google può risolvere la catena, ma non è garantito — e nei casi complessi può semplicemente ignorare i segnali. La best practice di Google è che ogni pagina dichiari il canonical direttamente all’URL finale della catena. Controlla con Screaming Frog esportando tutti i canonical e verificando che nessuno punti a una pagina che a sua volta ha un canonical diverso da sé stessa.
Errore 3 — Canonical in conflitto con noindex
Se una pagina ha sia rel="canonical" che punta a un’altra pagina, sia un tag noindex, stai inviando segnali contraddittori. Il noindex dice “non mettere questa pagina nell’indice”, il canonical dice “considera questa pagina come versione di quella”. Google ha dichiarato che in questo caso noindex ha generalmente la precedenza sul canonical per l’indicizzazione, ma il comportamento non è sempre prevedibile. Regola: una pagina con noindex non ha bisogno di canonical — sono mutuamente esclusivi nella maggior parte dei casi pratici.
Errore 4 — Canonical loop (A → B e B → A)
La pagina A dichiara come canonical la pagina B, e la pagina B dichiara come canonical la pagina A. Google non può risolvere il loop e ignora entrambi i segnali. Come rilevarlo: con Screaming Frog, esporta il report “Canonicals” e incrocia le colonne “URL” e “Canonical Link Element 1” cercando coppie circolari.
Errore 5 — Canonical su pagina in redirect
Se l’URL che hai indicato come destinazione del canonical fa un redirect verso un’altra pagina, Google seguirà il redirect ma potrebbe non attribuire correttamente il segnale canonico. Il canonical deve sempre puntare all’URL finale, quella che risponde 200, non a URL intermedie che reindirizzano.
Errore 6 — URL relativa invece di assoluta
<!-- Sconsigliato -->
<link rel="canonical" href="/categoria/prodotto/" />
<!-- Corretto -->
<link rel="canonical" href="https://www.esempio.it/categoria/prodotto/" />
Tecnicamente i browser e i crawler risolvono le URL relative, ma in contesti di migrazione, cambio di dominio o configurazione di CDN, un canonical relativo può essere interpretato rispetto a un base URL errato, generando canonical che puntano a domini sbagliati.
Errore 7 — Più tag canonical sulla stessa pagina
Può succedere quando si usano due plugin SEO contemporaneamente, o quando il tema WordPress emette un canonical di base e il plugin ne aggiunge un secondo. Google legge il primo e ignora il resto, ma la situazione è ambigua e difficile da debuggare. Verifica sempre il sorgente della pagina e assicurati di avere un solo <link rel="canonical"> nel <head>.
Errore 8 — Canonical con URL non pulita come destinazione
<!-- Sbagliato: il canonical punta a un URL con parametri -->
<link rel="canonical" href="https://www.esempio.it/prodotto/?sort=price&color=rosso" />
<!-- Corretto: il canonical punta all'URL pulita -->
<link rel="canonical" href="https://www.esempio.it/prodotto/" />
Il canonical deve sempre puntare alla versione più pulita e stabile dell’URL, non a una variante con parametri. Altrimenti stai canonicalizzando verso una URL che a sua volta potrebbe avere problemi.
Pagina alternativa con tag canonical appropriato in Search Console: cosa significa e come risolverla
Lo stato “Pagina alternativa con tag canonical appropriato” in Google Search Console indica che Google ha escluso quella URL dall’indice perché ha riconosciuto e rispettato il canonical dichiarato, che punta a un’altra pagina. In parole semplici: il tuo tag funziona, e Google ha indicizzato la versione canonica invece di questa.
Quando questo stato è corretto
Questo stato è il comportamento atteso per tutte le URL che hai intenzionalmente canonicalizzato verso un’altra versione: varianti con parametri UTM, pagine di prodotto raggiungibili da categorie secondarie, versioni HTTP di pagine HTTPS. Vedere centinaia di URL con questo stato nel report Pagine non indicizzate non è un problema — è la conferma che il tuo lavoro SEO tecnico funziona.
Quando è un segnale d’allarme
Il problema si presenta quando vedi questo stato su URL che non hai intenzionalmente canonicalizzato, o quando la versione canonica che Google ha scelto non coincide con quella che ti aspettavi.
Come accedere al report e interpretarlo
- Apri Google Search Console
- Vai a Indicizzazione > Pagine
- Seleziona la scheda Pagine non indicizzate
- Filtra per “Pagina alternativa con tag canonical appropriato”
- Clicca su un URL specifico per vedere i dettagli
Per ogni URL in questo stato, usa lo strumento Ispezione URL (icona lente sulla riga dell’URL) per vedere due informazioni chiave:
- URL canonica dichiarata: quella che il tag nel tuo codice indica
- URL canonica selezionata da Google: quella che Google ha effettivamente scelto
Se le due coincidono → tutto corretto.
Se le due differiscono → Google sta ignorando il tuo canonical.
Scenario A: canonical corretto, nessuna azione richiesta
Se la pagina in stato “alternativa” è una variante URL che hai canonicalizzato intenzionalmente (es. ?ref=banner verso l’URL pulita), non fare nulla. Il sistema funziona come previsto.
Scenario B: canonical punta alla pagina sbagliata
Se la versione canonicalizzata non è quella che volevi, le cause più comuni sono:
- Errore nel codice: controlla manualmente il sorgente della pagina (Ctrl+U) e cerca
rel="canonical" - Plugin che sovrascrive il canonical: se usi più plugin SEO, potrebbero emettere canonical in conflitto
- HTTP header in conflitto: se il server emette un canonical via header che contraddice il tag HTML, Google può preferire l’header. Verifica con
curl -I https://www.tuodominio.it/pagina/e controlla la rigaLink:nella risposta
Scenario C: Google ha scelto un canonical diverso da quello dichiarato
Questo è il caso più complesso e frequente nei siti con architettura problematica.
Come Google sceglie il canonical: quando ignora il tuo tag
Google seleziona autonomamente il canonical preferito basandosi su un insieme di segnali che valuta in modo aggregato. Secondo la documentazione ufficiale di Google Search Central, i fattori principali sono:
- Frequenza di link interni: l’URL più linkata internamente nel sito è un forte segnale di preferenza
- Presenza nella sitemap XML: gli URL nella sitemap ricevono un segnale canonico aggiuntivo
- HTTPS vs HTTP: la versione HTTPS è preferita quando entrambe esistono
- URL senza parametri: le URL pulite sono preferite rispetto a quelle con query string
- Redirect: se l’URL A fa redirect a B, B è considerata più canonica
Per allineare i tuoi segnali e “forzare” la scelta di Google verso l’URL che vuoi:
- Linka internamente solo alla versione canonica preferita
- Includi solo quella versione nella sitemap
- Implementa redirect 301 sulle varianti non canoniche
- Assicurati che HTTPS sia l’unica versione accessibile
- Usa il canonical self-referencing sull’URL preferita
Puoi approfondire questi concetti nella guida dedicata all’URL canonico e alla sua importanza SEO.
Canonical e hreflang nei siti multilingua: come evitare i conflitti
Nei siti multilingua, il tag canonical e il tag hreflang svolgono funzioni diverse e complementari che non devono mai sovrapporsi: il canonical indica la versione preferita di una pagina all’interno della stessa lingua, mentre hreflang indica le varianti per lingua o regione geografica.
La regola fondamentale, spesso ignorata, è questa: ogni pagina che partecipa a un set hreflang deve avere un canonical self-referencing che punta a sé stessa. Se la pagina in italiano ha un canonical che punta alla pagina in inglese, Google interpreta che la pagina italiana è un duplicato di quella inglese e potrebbe ignorare completamente l’hreflang.
L’errore più comune: canonical cross-lingua
<!-- SBAGLIATO: pagina italiana con canonical verso la versione inglese -->
<!-- File: /it/prodotto/ -->
<link rel="canonical" href="https://www.esempio.com/en/product/" />
<link rel="alternate" hreflang="it" href="https://www.esempio.com/it/prodotto/" />
<link rel="alternate" hreflang="en" href="https://www.esempio.com/en/product/" />
Questo codice dice a Google due cose contraddittorie: “questa pagina è un duplicato dell’inglese” (canonical) e “questa pagina è la versione italiana” (hreflang). Google non può rispettare entrambi i segnali.
Implementazione corretta per un sito IT/EN/DE
<!-- Pagina italiana: /it/prodotto/ -->
<link rel="canonical" href="https://www.esempio.com/it/prodotto/" />
<link rel="alternate" hreflang="it" href="https://www.esempio.com/it/prodotto/" />
<link rel="alternate" hreflang="en" href="https://www.esempio.com/en/product/" />
<link rel="alternate" hreflang="de" href="https://www.esempio.com/de/produkt/" />
<link rel="alternate" hreflang="x-default" href="https://www.esempio.com/en/product/" />
Ogni pagina dichiara come canonica sé stessa e lista tutte le varianti linguistiche del set hreflang. Il tag x-default indica la versione di fallback per utenti in lingue non esplicitamente mappate.
Come verificare la coerenza tra canonical e hreflang
Con Screaming Frog:
- Esegui il crawl del sito con l’opzione “Store HTML” abilitata
- Esporta il report “Hreflang” e il report “Canonicals”
- Incrocia i dati: per ogni URL nel set hreflang, verifica che il canonical corrisponda all’URL stessa (self-referencing)
- Qualsiasi pagina hreflang con canonical che punta a un’altra URL è un errore da correggere
L’ordine di priorità quando i segnali sono in conflitto: Google tende a rispettare il canonical prima dell’hreflang. Questo significa che un canonical sbagliato può annullare l’intero lavoro di internazionalizzazione del sito, rendendo le pagine tradotte invisibili nelle SERP locali.
Rel canonical nelle SPA e applicazioni JavaScript (React, Vue, Angular)
Nelle applicazioni a pagina singola (SPA), il tag rel canonical presenta una sfida tecnica specifica: il DOM viene costruito lato client tramite JavaScript, quindi il canonical potrebbe non essere presente nell’HTML inviato dal server durante il primo crawl di Googlebot.
Il problema del two-wave rendering
Googlebot esegue il crawling in due fasi distinte: nella prima fase legge l’HTML grezzo restituito dal server (la risposta HTTP), nella seconda fase — che può avvenire con ritardi anche di settimane — renderizza il JavaScript ed elabora il DOM costruito lato client. Se il canonical è inserito solo via JavaScript (es. tramite document.querySelector('head').innerHTML +=), Googlebot potrebbe non vederlo nella prima fase e indicizzare la pagina senza canonical, o con il canonical sbagliato.
Soluzione 1: Server-Side Rendering (SSR)
Il metodo più efficace e raccomandato è implementare il SSR per le pagine SEO-critiche. Con SSR, l’HTML inviato dal server include già il tag canonical corretto prima che qualsiasi JavaScript venga eseguito. Framework come Next.js (React), Nuxt.js (Vue) e Angular Universal supportano nativamente il SSR e offrono API specifiche per la gestione dei meta tag nell’HTML iniziale.
Esempio con Next.js:
import Head from 'next/head';
export default function Prodotto({ url }) {
return (
<>
<Head>
<link rel="canonical" href={`https://www.esempio.it${url}`} />
</Head>
{/* contenuto della pagina */}
</>
);
}
Soluzione 2: Prerendering statico
Per siti con struttura URL prevedibile e contenuto relativamente stabile, il prerendering statico con strumenti come Gatsby o Next.js in modalità Static Site Generation (SSG) genera HTML pre-renderizzato che include tutti i meta tag, compresi i canonical, già nell’HTML servito al crawler.
Soluzione 3: Librerie di gestione meta tag
Se il SSR non è un’opzione, usa librerie specifiche che garantiscono l’inserimento del canonical nell’HTML iniziale:
- React:
react-helmetoreact-helmet-async - Vue:
vue-metao il composableuseHeaddi VueUse - Angular: il servizio
MetaeTitleintegrato nel framework
Queste librerie modificano il <head> durante l’esecuzione JavaScript, ma in molte configurazioni di hosting moderno (con SSR parziale o edge rendering) riescono a iniettare i tag prima della risposta HTTP.
Come verificare il canonical in una SPA
- Apri Google Search Console e usa lo strumento Ispezione URL sull’URL da verificare
- Clicca su “Visualizza pagina indicizzata” per vedere la versione renderizzata da Google
- Nel codice sorgente renderizzato, cerca
rel="canonical"e verifica che sia presente con il valore corretto - In alternativa, usa il comando
curl -A "Googlebot" https://www.tuodominio.it/pagina/e verifica se il canonical è presente nell’HTML grezzo restituito
Se il canonical è assente nell’HTML grezzo ma presente nell’HTML renderizzato, Googlebot lo vedrà solo nella seconda fase di rendering — accettabile, ma non ottimale per pagine ad alta priorità SEO. Per queste, il SSR rimane la soluzione più affidabile.
La gestione del canonical nelle SPA si inserisce nel quadro più ampio dell’ottimizzazione SEO on-page, dove ogni elemento tecnico contribuisce alla corretta comprensione della struttura del sito da parte dei motori di ricerca.
Domande frequenti
Clicca sulla domanda per visualizzare la risposta
Cos’è il rel canonical?
Il rel canonical è un tag HTML inserito nel <head> di una pagina web che indica ai motori di ricerca quale versione di un URL considerare come quella ufficiale e preferita. Viene usato quando lo stesso contenuto è accessibile da più URL diverse. Serve a consolidare i segnali SEO — link equity, autorità, dati di engagement — su un’unica versione, evitando dispersione e competizione interna tra varianti della stessa pagina.
Cos’è il tag canonical e a cosa serve nella pratica?
Il tag canonical è l’elemento HTML <link rel="canonical" href="URL"> che si inserisce nel <head> di una pagina. Nella pratica serve a gestire URL duplicate generate da filtri eCommerce, parametri di tracking, varianti HTTP/HTTPS, o contenuti sindicati su più domini. Dice a Google su quale versione concentrare gli sforzi di indicizzazione e su quale accumulare il valore dei link in entrata.
Cosa significa ‘pagina alternativa con tag canonical appropriato’ in Search Console?
Questo stato in Google Search Console indica che la pagina è stata esclusa dall’indice perché Google ha riconosciuto e rispettato il tag canonical dichiarato, che punta a un’altra URL. Se il canonical è corretto, questo stato è atteso e non richiede azioni. Se vedi questo stato su pagine che non hai intenzionalmente canonicalizzato, o se il canonical scelto da Google differisce da quello dichiarato, è necessario investigare e correggere il tag.
Google può ignorare il tag canonical che ho impostato?
Sì. Il rel canonical è un suggerimento, non un’istruzione vincolante. Google può ignorarlo quando i segnali interni al sito contraddicono la dichiarazione: se l’URL non-canonica riceve più link interni di quella canonica, se è presente nella sitemap mentre quella canonica non lo è, o se il canonical punta a una pagina con errori (404, redirect, noindex). Per forzare la scelta di Google, allinea tutti i segnali — link interni, sitemap, redirect — verso l’URL preferita.
Qual è la differenza tra rel canonical e redirect 301?
Il rel canonical mantiene entrambe le URL accessibili agli utenti ma consolida i segnali SEO verso quella dichiarata come preferita. Il redirect 301 invia sia gli utenti che i motori di ricerca automaticamente alla nuova URL, rendendo la vecchia inaccessibile. Il canonical è preferibile quando la duplicazione è tecnica ma l’URL deve restare accessibile; il redirect 301 è obbligatorio quando una pagina viene rimossa, rinominata o migrata definitivamente.
Il canonical self-referencing è davvero necessario su ogni pagina?
Sì, è una best practice raccomandata da Google. Un canonical autoreferenziale — che punta alla pagina stessa — protegge ogni URL da varianti accidentali generate da parametri UTM, token di sessione, ID di campagna o semplicemente dalla presenza o assenza del trailing slash. Senza canonical self-referencing, un link condiviso con parametri di tracking potrebbe far sì che Google indicizzi una variante sporca invece della versione pulita che preferisci.
Come verifico che il canonical sia implementato correttamente?
Tre metodi pratici: 1) Visualizza il sorgente della pagina (Ctrl+U) e cerca rel="canonical" — verifica che esista un solo tag con l’URL corretta. 2) Usa lo strumento Ispezione URL in Google Search Console per vedere sia il canonical dichiarato che quello selezionato da Google. 3) Esegui un crawl con Screaming Frog e analizza il report “Canonicals” per rilevare canonical mancanti, catene, loop, o destinazioni che restituiscono errori.
Il rel canonical nella tua strategia SEO: sintesi operativa
Il rel canonical non è uno strumento difensivo da applicare solo in caso di problemi: è un elemento strutturale dell’architettura SEO di qualsiasi sito con più di poche decine di pagine. Un eCommerce senza canonical rischia di sprecare budget di crawl su migliaia di URL parametrizzate. Un sito multilingua senza canonical self-referencing su ogni pagina hreflang rischia di vanificare mesi di lavoro di internazionalizzazione. Una SPA senza SSR rischia che i canonical inseriti via JavaScript non vengano letti durante la prima fase di crawl.
I punti chiave da ricordare:
- Il canonical è un suggerimento, non un comando: rinforza sempre con segnali coerenti (link interni, sitemap, redirect)
- Ogni pagina dovrebbe avere un canonical, anche self-referencing, come misura difensiva preventiva
- Gli errori più costosi sono i canonical loop, le catene, e i canonical che puntano a pagine con errori 404
- In Search Console, “pagina alternativa con tag canonical appropriato” è positivo se l’hai intenzionalmente impostato, problematico se compare su pagine che non avresti canonicalizzato
- Nei siti multilingua, canonical e hreflang devono coesistere senza conflitti: ogni pagina hreflang è canonica rispetto a sé stessa
Per chi gestisce siti con architetture complesse, l’audit periodico dei canonical — almeno ogni sei mesi o dopo ogni migrazione significativa — è parte integrante di una strategia di link building e ottimizzazione tecnica efficace. I segnali consolidati su URL canoniche corrette amplificano l’impatto di ogni backlink acquisito.
