Il rel canonical, cioè il rel="canonical", è un elemento che sta nell’<head> di una pagina e dice a Google quale URL mostrare quando lo stesso contenuto è raggiungibile da più indirizzi. È un suggerimento, non una direttiva: Google lo legge, lo pesa insieme agli altri segnali e può decidere diversamente.
Il tag si può mettere in tre posti (elemento link, intestazione HTTP, sitemap) e i tre non pesano uguale: Google li ordina per forza, e la sitemap è l’ultimo. Quale URL abbia scelto davvero si legge in un solo punto di Search Console, nei dati indicizzati e non nel test in tempo reale. In mezzo, l’audit dei canonical di questo sito fatto con curl il 31 agosto 2026, comandi inclusi, con dentro un problema che non avevo previsto.
Cos’è un URL canonico, in tre righe
Un URL canonico è «l’URL di una pagina che Google ha scelto come più rappresentativo tra un insieme di pagine duplicate», e la canonicalizzazione è «il processo di selezione dell’URL canonico rappresentativo di un contenuto». Le due definizioni stanno una accanto all’altra nella pagina di Google sulla canonicalizzazione, aggiornata al 15 luglio 2026.
Dentro quelle due righe c’è la distinzione che regge tutto il resto: il canonical che scrivi tu e il canonico che sceglie Google sono due cose diverse. Il primo è un tag nel tuo HTML. Il secondo è una decisione presa altrove, su una macchina che non hai, e può non coincidere con la tua.
I motivi per cui un sito si ritrova con contenuti duplicati sono molti, dice Google, e ne elenca cinque a titolo di esempio: varianti regionali, varianti per dispositivo, varianti di protocollo (http e https), funzionalità del sito come ordinamento e filtri, varianti accidentali, tipo la versione demo del sito lasciata accessibile ai crawler.
Prima che parta l’ansia, la stessa pagina la sgonfia in una riga: «la presenza di alcuni contenuti duplicati su un sito è normale e non costituisce una violazione delle norme di Google relative allo spam». Non stai per essere punito. Stai per essere frainteso.
Come si scrive il rel canonical: l’elemento link nella head
Una riga sola, dentro la <head>, con l’URL scritto per intero:
<link rel="canonical" href="https://donatopirolo.dev/rel-canonical/">Le prime due regole le scrive la guida ufficiale sui metodi di canonicalizzazione, anche lei aggiornata al 15 luglio 2026. La terza sta altrove, nel post del 2013 sui cinque errori, che trovi più avanti.
URL assoluto, mai relativo. «Utilizza percorsi assoluti anziché percorsi relativi con l’elemento link rel="canonical". Anche se i percorsi relativi sono supportati da Google, possono causare problemi a lungo termine (ad esempio, se consenti involontariamente la scansione del tuo sito di test).» Il motivo che porta Google capita a chiunque abbia uno staging: un href="/pagina/" su staging.tuosito.it punta a sé stesso, e il giorno che quel dominio finisce nell’indice ti ritrovi due siti che si dichiarano canonici a vicenda.
Solo nella <head>. «link element rel="canonical" è accettato solo se compare nella sezione <head> dell’HTML…»: la pagina italiana lascia link element in inglese perché nel sorgente quel pezzo è marcato translate="no", e la localizzazione non lo tocca. Nel body diventa HTML che Google non guarda nemmeno.
Uno solo per pagina. Questa Google la mette per iscritto nel post sugli errori di rel=canonical, ed è una sanzione più cattiva di quanto sembri: «In caso di più dichiarazioni dell’elemento rel=canonical, Google probabilmente ignorerà tutti i suggerimenti di rel=canonical». Si perdono tutti, compreso quello giusto, e la pagina torna a essere canonicalizzata come se il tag non l’avessi mai messo.
Ultima nota di igiene, che vale mezza riga: il tag lo trovi scritto sia come <link ... > sia come <link ... />. Per il parser sono la stessa cosa, e sul mio sito la differenza fra le due forme la fa il minificatore, non il generatore.
Gli altri due posti dove si può mettere: intestazione HTTP e sitemap
L’intestazione HTTP serve per i file che non sono HTML, la sitemap è un segnale, e nessuno dei due sostituisce l’elemento link.
Un PDF non ha una <head>, quindi il canonical va nell’header della risposta. L’esempio della documentazione:
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"Google lo definisce un’alternativa piena all’elemento HTML, con una condizione: «Google supporta questo metodo solo per i risultati di ricerca web». Fuori dalla ricerca web (Immagini, Discover, il resto) quell’header non lo stai usando per niente.
La sitemap funziona in modo diverso: tutti gli URL che ci metti dentro li stai suggerendo come canonici, ma il peso è quello che è. Google la classifica come indicatore debole, cioè un voto in più che da solo non decide niente. Come si costruisce e si invia è materia di un altro pezzo, come si costruisce una sitemap.
La regola operativa la scrive la guida ai metodi di canonicalizzazione: scegline uno e restaci. Usare insieme l’elemento link e l’intestazione HTTP è supportato, ma «è più soggetto a errori». È una riga che sa di prudenza da manuale, e sotto c’è dell’esperienza: due sistemi che scrivono lo stesso tag in due posti diversi prima o poi divergono, e chi li ha configurati se ne accorge sei mesi dopo.
I segnali di canonicalizzazione, in ordine di forza
Google li ordina lui, per iscritto, e l’ordine è questo:
| metodo | forza dichiarata | cosa dice Google |
|---|---|---|
| reindirizzamento | forte | «un indicatore forte che la destinazione del reindirizzamento dovrebbe diventare canonica» |
rel="canonical" | forte | «un indicatore forte che l’URL specificato dovrebbe diventare canonico» |
| inclusione in sitemap | debole | «un indicatore debole che aiuta gli URL inclusi in una Sitemap a diventare canonici» |
A questi tre, che dichiari tu, se ne aggiungono due che Google ricava da come è fatto il sito: «la preferenza di HTTPS rispetto ad HTTP e l’utilizzo di URL nei cluster hreflang». La preferenza per l’HTTPS non è incondizionata, e le eccezioni sono quattro: certificato non valido, dipendenze non protette dentro la pagina, redirect che riporta a HTTP, canonical che dalla versione HTTPS punta a quella HTTP. In quei quattro casi Google la HTTPS la lascia stare.
I segnali si sommano: «l’utilizzo di due o più metodi aumenterà la possibilità che l’URL canonico preferito venga visualizzato nei risultati di ricerca». Redirect più canonical più sitemap coerenti fra loro valgono più di uno dei tre da solo.
Da qui esce l’unica conseguenza operativa che conta, e che di solito si perde perché la gerarchia viene trascritta e poi abbandonata. Se puoi normalizzare con un 301, il canonical è la seconda scelta. Il redirect chiude la questione lato server, l’URL sbagliato smette di esistere e non c’è niente da suggerire a nessuno; il canonical lascia la variante viva, raggiungibile e in cache, e affida a Google il compito di capirsi. Ogni punto in cui stai usando il canonical al posto di un redirect è debito tecnico che hai deciso di tenere. La meccanica sta in come si imposta un redirect 301.
«Un suggerimento, non una regola»: cosa vuol dire davvero
Vuol dire che Google può ignorarlo, e che quando lo fa di solito ha un motivo. La frase esatta è: «Ciò significa che indicare una preferenza canonica è un suggerimento, non una regola».
Il meccanismo dietro è descritto nella stessa pagina. Google raggruppa le pagine che considera simili in un cluster, e dentro al cluster sceglie quella che «risulta oggettivamente la più completa e utile». Poi la tratta diversamente dalle altre: «la pagina canonica viene sottoposta a scansione con maggiore regolarità rispetto alle pagine duplicate». Le duplicate non spariscono, passano in secondo piano.
Il canonical ignorato è quindi una valutazione che ha dato un risultato diverso dal tuo, e la pagina ufficiale di troubleshooting suggerisce di partire proprio da lì: «valuta se, per gli utenti provenienti dalla Ricerca Google, la versione canonica scelta da Google ha più senso rispetto al tuo URL canonico preferito». Prima di aprire un ticket con te stesso, guarda le due pagine e chiediti quale apriresti tu.
C’è una conseguenza sui numeri che spaventa più del dovuto. In Search Console le prestazioni vengono raggruppate sull’URL canonico, e Google lo aveva già scritto in un post del febbraio 2019: se la tua pagina preferita risulta a zero clic mentre un’altra variante ne ha, il traffico c’è ancora, raggruppato sotto l’URL che Google ha scelto.
Ho guardato i canonical del mio sito, e ogni articolo esiste in centinaia di copie
Il mio server risponde 200 a tutte le combinazioni di maiuscole e minuscole che ho provato, e su ognuna di quelle copie il canonical punta alla versione minuscola. Tre righe, riproducibili adesso:
curl -s -o /dev/null -w '%{http_code}\n' https://donatopirolo.dev/Hreflang/ # 200
curl -s -o /dev/null -w '%{http_code}\n' https://donatopirolo.dev/HREFLANG/ # 200
curl -s -o /dev/null -w '%{http_code}\n' https://donatopirolo.dev/hReFlAnG/ # 200
curl -s https://donatopirolo.dev/hReFlAnG/ | grep -o 'rel="canonical" href="[^"]*"'
# -> rel="canonical" href="https://donatopirolo.dev/hreflang/"Quel 200 serve l’articolo intero: stesso H1, stesso testo, stessa impaginazione. L’ho verificato su sette slug diversi (hreflang, noindex, redirect-301, sitemap-xml, robots-txt, schema-markup, core-web-vitals e le loro varianti) e il risultato è identico ogni volta.
Il conto delle copie va fatto sullo slug, non a occhio. hreflang ha otto lettere, quindi 2⁸ = 256 combinazioni di maiuscole e minuscole, e fra quelle che ho chiesto il server non ha fatto differenza. sitemap-xml ha dieci lettere alfabetiche, quindi 1.024. Di quelle 256 versioni di /hreflang/, 255 sono varianti che il sito dichiara non canoniche con un suggerimento che Google può ignorare. Poi però ho chiesto a Search Console cosa ne sappia, e la risposta ridimensiona sia l’allarme sia il merito del canonical: delle due varianti che ho controllato, /HREFLANG/ e /hReFlAnG/, dice «L’URL è sconosciuto a Google». Non le tiene fuori il canonical: Google non ci è proprio mai arrivato, e perché non ci sia arrivato lo strumento non lo dice. Il tag lì è un’assicurazione che finora non è mai stata chiamata a pagare.
Gli header raccontano la coda della storia:
curl -sI https://donatopirolo.dev/Hreflang/ | grep -i 'x-breeze\|x-cache\|cache-provider'
# x-breeze-cache-write: SUCCESS
# cache-provider: CLOUDWAYS-CACHE-DC
# x-cache: HITLa variante sbagliata viene servita e poi anche scritta in cache. Ogni forma diversa dello stesso URL si prende il suo posto sul disco, e il canonical sta facendo bene il lavoro di un altro: qui la normalizzazione andrebbe chiusa lato server, con un reindirizzamento alla minuscola, che è un indicatore forte dove il canonical è un suggerimento. È la gerarchia della sezione qui sopra, applicata al contrario.
Per onestà di quadro, le normalizzazioni classiche sul sito sono chiuse come si deve, con un 301 e non con il canonical:
| variante | risposta |
|---|---|
http://donatopirolo.dev/hreflang/ | 301 verso la versione HTTPS |
https://donatopirolo.dev/hreflang (senza slash) | 301 |
https://donatopirolo.dev/?p=450 | 301 |
https://donatopirolo.dev/index.php/hreflang/ | 301 |
https://donatopirolo.dev/blog/page/1/ | 301 verso /blog/ |
E due comportamenti da guardare, perché sono i più frequenti su un blog. ?utm_source=test&utm_medium=curl risponde 200 e il canonical punta all’URL pulito, che è il caso d’uso numero uno del tag e l’unico che qui il canonical risolve davvero da solo. E /blog/page/2/ ha un canonical su sé stessa, non sulla pagina 1: è quello che Google chiede dal 2013, e il contrario è il primo dei cinque errori del suo post ufficiale.
Il caso peggiore: due pagine identiche, ognuna canonica di sé stessa
Sul mio sito /blog/ e /category/seo/ servono lo stesso identico elenco di articoli, e nessuna delle due rinuncia a favore dell’altra. Il diff non ha niente da dire:
diff <(curl -s https://donatopirolo.dev/blog/ | grep -o 'href="https://donatopirolo.dev/[a-z0-9-]*/"' | sort -u) \
<(curl -s https://donatopirolo.dev/category/seo/ | grep -o 'href="https://donatopirolo.dev/[a-z0-9-]*/"' | sort -u)
# nessuna differenzaPrima di gridare al falso positivo: quel grep cattura tredici URL, tre dei quali non sono articoli (sono pagine del sito che stanno nel template), quindi i post in comune sono dieci. Su /blog/page/2/ e /category/seo/page/2/ la stessa cosa, con gli altri otto, e diciotto è il totale degli articoli online. Le due liste combaciano riga per riga.
Fuori dall’elenco cambia solo il title («Blog SEO & AI | Donato Pirolo» contro «SEO – Donato Pirolo»). Entrambe rispondono index, follow. Entrambe hanno un canonical su sé stesse.
Il segnale che tira dalla parte opposta è la sitemap: /blog/ c’è, /category/seo/ no, perché il sitemap_index.xml contiene solo post-sitemap.xml e page-sitemap.xml e le categorie non hanno la loro. Il sito quindi dichiara che le due pagine sono entrambe canoniche, e poi ne suggerisce una sola.
Qui il canonical non risolve niente, perché nessuna delle due pagine cede: la scelta la fa Google, con i suoi criteri. Ed è la domanda vera di questo pezzo, quella a cui i metodi più a portata di mano non rispondono.
Allora l’ho aperta, la Search Console, sui due URL. La risposta non è quella che mi aspettavo: /blog/ risulta «Inviata e indicizzata», con la pagina canonica selezionata da Google uguale a quella dichiarata da me. /category/seo/ risulta «Pagina scansionata, ma attualmente non indicizzata», pur essendo index, follow e canonica di sé stessa, e pur essendo stata scansionata il 30 agosto 2026.
Vale la pena fermarsi su cosa dicono davvero quei due stati. Su entrambe il canonico scelto da Google coincide con quello che dichiaro io, e nessuna delle due porta un’etichetta di duplicazione: il conflitto di canonicalizzazione che stavo cercando nel mio HTML lì dentro non c’è. Perché /category/seo/ resti fuori dall’indice Search Console non lo dice: «Pagina scansionata, ma attualmente non indicizzata» è uno stato, non una motivazione, e attribuirlo al duplicato sarebbe una mia ipotesi. Resta il fatto operativo: qui il canonical non ha deciso niente, e la differenza fra le due pagine si è giocata altrove.
Come si scopre quale URL Google ha davvero scelto
Search Console, Controllo URL, incolli l’URL, apri la sezione Indicizzazione delle pagine. Lì dentro ci sono due campi, e in italiano si chiamano esattamente così.
«Contenuto canonico dichiarato dall’utente» è quello che hai scritto tu. La guida allo strumento Controllo URL lo descrive senza girarci intorno: «L’URL canonico eventualmente dichiarato dalla tua pagina in modo esplicito verrà mostrato qui… Non possiamo garantire che Google scelga l’URL che hai indicato come canonico, ma solo che verrà preso in considerazione».
«Contenuto canonico selezionato da Google» è quello che conta: «la pagina scelta da Google come URL canonico (ufficiale) nel caso in cui siano state trovate pagine simili sul sito».
Le letture possibili sono tre. I due campi coincidono, e il tuo suggerimento è passato. I due campi non coincidono, e Google ha raggruppato la tua pagina sotto un’altra: qui si va a leggere l’etichetta nel rapporto, che è la sezione dopo. Il campo dichiarato è vuoto, e allora il canonical o non c’è, o Google non l’ha visto, o ce n’erano due e sono saltati tutti e due.
I due limiti che fanno perdere il pomeriggio sono scritti sulla stessa pagina, e nelle guide italiane non li ho trovati. Il primo: «puoi determinare la versione canonica solo nei dati indicizzati; il test in tempo reale non può prevedere se la versione testata verrà considerata canonica». Il secondo è ancora più esplicito: «in particolare, le condizioni duplicate o canoniche non vengono testate nel test in tempo reale». In pratica: se clicchi «Testa l’URL pubblicato» e vai a cercare i due campi, non li trovi, e la conclusione naturale (sbagliata) è che il tag non funzioni. I dati sulla canonicalizzazione stanno nella scheda dei dati indicizzati, quella che ti si apre per prima e che di solito si scavalca perché sembra vecchia.
Un dettaglio del 2019 che conta ancora: da quell’anno il Controllo URL mostra «tutte le pagine canoniche selezionate da Google per un URL, non solo quelle per le proprietà che gestite in Search Console». Vale anche su URL che non sono tuoi, il che lo rende lo strumento più onesto che ci sia rimasto per capire come Google raggruppa un sito.
Il resto del rapporto, con tutti e quindici gli stati di mancata indicizzazione e i loro nomi italiani, sta nel pezzo sul rapporto Indicizzazione delle pagine.
Quello che site:, inurl: e info: non ti dicono
Non ti dicono quale URL Google ha scelto come canonico. È uno dei metodi più a portata di mano, e non risponde alla domanda per cui lo si apre.
Lo scrive Google nel post del 26 marzo 2019, firmato John Mueller: «se eseguite una ricerca utilizzando i comandi site: o inurl:, verrà visualizzato il dominio che avete specificato lì, anche se non sono gli URL canonici selezionati da Google; ciò accade perché stiamo rispondendo alla richiesta esatta specificata». E subito dopo: «dietro le quinte utilizziamo ancora la versione canonica scelta da Google».
Tradotto: gli chiedi tutte le pagine di esempio.it e lui ti restituisce pagine di esempio.it, perché è quello che gli hai chiesto. Non è una verifica, è un’eco. È un filtro sul dominio, e si ferma lì.
Del comando info: Google ha annunciato il ritiro il 26 marzo 2019, nello stesso post in cui il Controllo URL ha iniziato a mostrare il canonico scelto: «Con questa modifica ritireremo anche il comando info:». Era l’unica alternativa comoda, e la sostituzione dichiarata è lo strumento della sezione precedente.
Le tre etichette di Search Console che parlano di canonical
Nel rapporto Indicizzazione delle pagine ci sono quindici stati di mancata indicizzazione, e tre parlano di canonical. Questi, con i nomi italiani esatti presi dalla guida al report Indicizzazione delle pagine.
«Pagina alternativa con tag canonical appropriato». Tutto in ordine, e la guida lo mette per iscritto: la pagina «è contrassegnata come alternativa a un’altra pagina (ovvero una pagina AMP con una versione canonica per computer, una versione mobile di una canonica per computer o la versione per computer di una versione canonica mobile)», e «rimanda correttamente alla pagina canonica, che è indicizzata, quindi non devi fare nulla». È lo stato delle alternative dichiarate, e non dice altro: le pagine che ci finiscono dentro sono il sistema che funziona.
«Pagina duplicata senza URL canonico selezionato dall’utente». Google ha trovato dei duplicati, tu non hai dichiarato niente, lui ha scelto per conto suo. La guida ci tiene a chiarire che «non si tratta di un errore, ma funziona come previsto, perché Google non pubblica pagine duplicate». Cosa farci dipende da chi ha vinto: se la scelta di Google ti va bene, è finita lì; se ti va male, il canonical serve proprio a dire la tua.
«Pagina duplicata, Google ha scelto una pagina canonica diversa da quella specificata dall’utente». Questo è il caso serio, e la spiegazione ufficiale è brutale: «se il contenuto canonico dichiarato dall’utente non è simile alla pagina corrente, Google non sceglierà mai quell’URL come canonico». Il problema quindi sta nelle due pagine, che non si somigliano abbastanza. Stai chiedendo a Google di raggruppare due pagine che lui non considera la stessa cosa, e quella richiesta non passa per quanto tu la ripeta. Si lavora sul contenuto, o si sceglie un altro strumento.
Mezza riga di onestà sulle etichette, che nelle guide italiane non ho visto da nessuna parte. In fondo alla guida italiana di Search Console Google avverte che la pagina «potrebbe includere contenuti tradotti usando la tecnologia AI» e che «le traduzioni con l’AI potrebbero contenere errori». Le stringhe qui sopra le ho prese da lì, ma vanno confrontate con quello che vedi a schermo nella tua proprietà: se una differisce, vince lo schermo. Gli altri stati stanno nel pezzo sul rapporto Indicizzazione delle pagine.
Canonical, 301 o noindex: la tabella
Tre strumenti, tre effetti diversi sulla pagina di partenza, e si scambiano molto più spesso di quanto dovrebbero.
| cosa fa | cosa non fa | quando si usa | |
|---|---|---|---|
| 301 | la pagina vecchia sparisce, il traffico e i segnali vanno sulla nuova; indicatore forte | non lascia la vecchia raggiungibile | quando rendi obsoleta una pagina duplicata e non ti serve più |
| canonical | entrambe restano raggiungibili, i segnali si raggruppano su quella dichiarata | non garantisce niente: la scelta finale resta a Google | quando le due versioni devono restare entrambe online |
| noindex | la pagina esce dalla Ricerca | non raggruppa niente, non trasferisce niente | quando quella pagina non deve stare nell’indice, punto |
Il caso dubbio lo decide una riga della documentazione, con la sua condizione: «non è consigliabile utilizzare noindex per impedire la selezione di una pagina canonica all’interno di un singolo sito, perché la pagina verrà completamente bloccata dalla Ricerca. Le annotazioni link rel="canonical" sono la soluzione preferita». La condizione è «all’interno di un singolo sito»: fra domini diversi il discorso cambia, e quella frase non lo copre.
Il noindex ha poi un prerequisito suo, che sta nella pagina di Google sul noindex, aggiornata al 31 dicembre 2025: funziona solo se la pagina è scansionabile, perché «se la pagina è bloccata da un file robots.txt oppure non è possibile accedervi, il crawler non rileverà mai la regola». La tabella decisionale completa sta in la tabella decisionale del noindex.
Sui template che ho controllato i due segnali non si incrociano, per una scelta del plugin: dove Rank Math mette noindex, il canonical lo toglie del tutto. Succede sulla pagina autore, sulla ricerca interna ?s=, sugli URL con ?replytocom=. Curioso il seguito: sulla pagina autore Search Console riporta «Esclusa in base al tag noindex» e insieme una pagina canonica selezionata da Google, che è la pagina stessa. Quel canonico non gliel’ho dichiarato io, il template non lo scrive: se l’è calcolato Google per conto suo. Le due cose convivono senza contraddirsi, perché il canonico indicato è l’URL stesso e non manda da nessun’altra parte: dice qual è l’indirizzo rappresentativo di quel contenuto, il noindex dice di tenerlo fuori dai risultati. Se il canonico avesse indicato un altro URL, allora sì che le istruzioni sarebbero state due e opposte, ed è il caso che la documentazione sconsiglia.
Una parola sul 302. Googlebot lo segue, ma «la pipeline di indicizzazione non lo utilizza come un indicatore del fatto che la destinazione del reindirizzamento dovrebbe essere canonica. La pagina di destinazione potrebbe comunque essere indicizzata se sono presenti altri indicatori di canonicalizzazione». La frase è nella documentazione sui reindirizzamenti, aggiornata al 17 aprile 2026, e il senso è che un 302 non canonicalizza da solo. La meccanica dei redirect sta nel pezzo sul redirect 301.
Canonical e hreflang
Due regole ufficiali, e stanno in due righe. Se usi hreflang, il canonical di ogni pagina va «nella stessa lingua o nella migliore lingua sostitutiva»: la versione italiana punta a sé stessa, non alla versione inglese. E le annotazioni rel="canonical" che portano attributi hreflang, lang, media o type «non vengono utilizzati per la canonicalizzazione», quindi un canonical con dentro un hreflang è un canonical che non esiste.
Autoreferenza, reciprocità, cluster e x-default sono un mestiere a parte, e stanno in hreflang e canonical.
I cinque errori che Google elenca, e i due prerequisiti sul target
L’elenco ufficiale è vecchio e regge ancora. Sta nel post «Cinque errori comuni con rel=canonical», e sono questi.
- Canonical dalla pagina 2 alla pagina 1 di una serie impaginata. Google lo mette per primo perché il danno è totale: «dato che non sono pagine duplicate… i contenuti della pagina 2 e di quelle successive non verranno indicizzati». Una paginazione così canonicalizzata cancella tutto quello che non sta nella prima schermata.
- URL assoluti scritti per sbaglio come relativi. L’errore da un carattere:
href="pagina/"invece dihref="https://sito.it/pagina/", e il canonical punta a un indirizzo che non esiste. - Dichiarazioni multiple o non intenzionali. Google indica anche da dove arrivano: il caso nasce «spesso in combinazione con plug-in SEO che spesso inseriscono un link
rel=canonicalpredefinito, probabilmente all’insaputa del webmaster». Tema più plugin, o due plugin, e la pagina si ritrova due tag. - Canonical da una pagina di categoria all’articolo in evidenza. La pagina di categoria non viene più mostrata nei risultati, che è esattamente il contrario di quello che volevi.
- Canonical fuori dalla
<head>. Nel body non viene letto.
Prima ancora dei cinque errori, in cima al post, ci sono due prerequisiti sul target del canonical: la pagina che indichi non deve essere un soft 404, e non deve avere un noindex. Sono i due controlli che si saltano più facilmente, perché si dà per scontato che l’URL di destinazione stia bene.
Una nota sulla datazione. Quel post è del 2013, e l’URL lo dice (/search/blog/2013/04/). La versione inglese riporta «Monday, April 08, 2013». La versione italiana della stessa pagina riporta «Lunedì 8 aprile 2023», dieci anni dopo, e la data italiana non regge nemmeno da sola: l’8 aprile 2023 era un sabato. Si verifica in dieci secondi alternando ?hl=en e ?hl=it sullo stesso URL. La portata è quella e va detta: non è un difetto sistematico della localizzazione italiana, perché gli altri due post ufficiali sul tema, quelli del 2019, in italiano hanno la data giusta. È sbagliata proprio quella.
Il perché conta a chi legge: un italiano che apre quella pagina crede di avere davanti un documento di tre anni fa mentre ne sta leggendo uno di tredici, scritto quando rel="prev" e rel="next" erano ancora supportati. Il post lo ammette da solo, in cima: «è passato un po’ di tempo da quando abbiamo pubblicato questo post del blog. Determinate informazioni potrebbero essere obsolete… rel="prev" e rel="next" non sono più supportati».
Il canonical autoreferenziale: perché va messo anche dove non serve
Sì, va messo, anche su una pagina che non ha nessun duplicato. Sta fra le best practice ufficiali, scritto così: «includi un link rel="canonical" nella pagina canonica stessa (noto anche come canonico autoreferenziale)».
Il motivo pratico è che le varianti non le decidi tu. Arrivano dai parametri di campagna che qualcuno appiccica al link, dagli ID di sessione, da chi condivide l’URL con dentro un ?fbclid, dal server che risponde 200 a una maiuscola. Nessuna di queste passa dal tuo editor, e per ognuna il canonical autoreferenziale è già lì che aspetta, con l’URL giusto dentro.
Sul mio sito è esattamente quello che succede, con una precisazione che ho potuto misurare. Il canonical autoreferenziale è la sola cosa che dichiara non canoniche le versioni con ?utm_source=, /HREFLANG/ e le altre 254 varianti di capitalizzazione. A chiederlo a Search Console, di tutte e tre le varianti che ho controllato la risposta è «L’URL è sconosciuto a Google»: la difesa c’è, non è mai stata messa alla prova, e questo è il caso migliore. Vale contro un elenco di URL che nessuno ha scritto, e che basta un link sbagliato da fuori per far esistere.
Sui parametri di ordinamento e filtro il discorso è diverso e più lungo, perché lì le combinazioni si moltiplicano e il canonical da solo non basta: sta in i parametri dei filtri.
Il tag canonical che ti mette il CMS (e su WordPress il plugin)
Tre comandi, trenta secondi, e sai cosa sta generando il tuo sito senza aprire nessun pannello.
# 1. quanti canonical ci sono nella pagina? se ne esce più di uno, sono tutti persi
curl -s https://tuosito.it/pagina/ | grep -o 'rel="canonical"[^>]*'
# 2. il canonical nell'header, per i file non HTML
curl -sI https://tuosito.it/file.pdf | grep -i '^link:'
# 3. la variante di controllo: lo stesso URL con una maiuscola dentro
curl -s -o /dev/null -w '%{http_code}\n' https://tuosito.it/Pagina/Il primo è il controllo che conta di più, perché su WordPress il doppio tag ha una causa strutturale: il tema ne mette uno, il plugin SEO ne mette un altro, e nessuno dei due sa dell’altro. Il terzo dice se la tua normalizzazione sta lato server (301) o è appesa al canonical (200), che è il caso mio.
Google mette i CMS mal configurati nell’elenco ufficiale delle cause di canonicalizzazione sbagliata, con questa formulazione: «Alcuni sistemi di gestione dei contenuti (CMS) o plug-in CMS potrebbero utilizzare in modo errato le tecniche di canonicalizzazione per reindirizzare a URL indesiderati». Nello stesso elenco, e in nessuna delle guide italiane che ho letto, sta un caso che vale la pena conoscere: la compromissione dannosa. Un canonical che punta a un dominio esterno che non hai mai visto è un sintomo di un sito bucato, e va trattato come tale. Se il primo comando qui sopra ti restituisce un href verso un dominio che non conosci, il problema non è SEO.
Sugli shop il capitolo si allarga a taglie, colori e varianti di prodotto, e sta in gli errori di canonical sugli shop.
L’ho messo, quando si vede?
Fino a due settimane. È l’unica aspettativa temporale che Google mette per iscritto sul tema, e sta nella pagina di troubleshooting: «anche dopo aver risolto i problemi relativi ai contenuti, Google potrebbe mantenere le pagine in un cluster duplicato per un massimo di due settimane».
La stessa pagina dice anche da cosa dipende la velocità: «le pagine vengono generalmente suddivise più rapidamente se la differenza tra i nuovi contenuti e le altre pagine raggruppate è chiara e significativa». Una modifica cosmetica lascia il cluster dov’è, una riscrittura vera lo apre.
La «Richiesta di indicizzazione» del Controllo URL (nell’interfaccia il bottone si chiama «Richiedi indicizzazione») accelera, ma «è soggetta a quote», quindi va spesa sugli URL che contano davvero e non su tutta la lista.
La checklist
Nell’ordine in cui si fanno, che è anche l’ordine in cui pesano.
- Normalizza a monte con un 301 dove puoi: maiuscole, slash finale, protocollo,
www. Il canonical viene dopo, non al posto. - Metti il canonical autoreferenziale su ogni pagina indicizzabile, anche su quelle senza duplicati.
- URL assoluto, dentro la
<head>, uno solo. Se ne trovi due, non ne sopravvive nessuno. - Scegli un metodo e restaci: elemento
linkoppure intestazione HTTP, non tutti e due sulla stessa risorsa. - Fai puntare i link interni all’URL canonico, non alla variante con i parametri attaccati.
- Controlla il target: la pagina che dichiari canonica non deve essere un soft 404 né avere un
noindex. - Apri il Controllo URL sui dati indicizzati, non in tempo reale, e confronta «Contenuto canonico dichiarato dall’utente» con «Contenuto canonico selezionato da Google».
- Aspetta due settimane prima di concludere qualcosa, perché è il tempo che Google si dà.
- Rifai il giro fra sei mesi. Il CMS si aggiorna da solo, i plugin pure, e il tag cambia senza avvisare.
Domande frequenti
Il canonical è un obbligo o un suggerimento?+
Un suggerimento. Google lo scrive con queste parole: «indicare una preferenza canonica è un suggerimento, non una regola». Viene pesato insieme a redirect, sitemap, preferenza HTTPS e cluster hreflang, e il verdetto finale è di Google.
Cosa succede se in una pagina ci sono due tag canonical diversi?+
Si perdono tutti e due. «In caso di più dichiarazioni dell’elemento rel=canonical, Google probabilmente ignorerà tutti i suggerimenti di rel=canonical.» Non vince il primo, non vince quello più in alto nella <head>: la pagina viene canonicalizzata come se il tag non ci fosse. Su WordPress il caso classico è tema e plugin SEO che ne generano uno a testa.
Meglio il canonical o un redirect 301?+
Il 301, quando puoi permettertelo. Il redirect è un indicatore forte e chiude la questione lato server; il canonical è un indicatore altrettanto forte, ma resta un suggerimento e lascia viva la pagina duplicata. Il canonical serve quando entrambe le versioni devono restare raggiungibili, il 301 quando la vecchia non ti serve più.
Posso usare il robots.txt per gestire i contenuti duplicati?+
No. È una delle best practice esplicite di Google: «non utilizzare il file robots.txt per la canonicalizzazione». Bloccando la scansione impedisci a Google di vedere le pagine e quindi di capire che sono duplicate, e il tag canonical dentro quelle pagine non lo leggerà mai nessuno.
Il canonical funziona anche su un PDF?+
Sì, ma non con un tag. Un PDF non ha una <head>, quindi il canonical va nell’intestazione HTTP della risposta, nella forma Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical". La condizione da tenere: Google «supporta questo metodo solo per i risultati di ricerca web».
Posso verificare il canonico con site: o con il comando info:?+
No. Con site: e inurl: «verrà visualizzato il dominio che avete specificato lì, anche se non sono gli URL canonici selezionati da Google», perché Google sta rispondendo alla richiesta esatta che gli hai fatto. Del comando info: Google ha annunciato il ritiro il 26 marzo 2019, nello stesso post in cui il Controllo URL ha iniziato a mostrare il canonico scelto. L’unico posto dove si legge il canonico di Google è il Controllo URL, sui dati indicizzati.
Se lo stesso URL risponde 200 con maiuscole e minuscole, basta il canonical?+
No, e sul mio sito è la voce aperta della lista. Il canonical è la rete di sicurezza: le varianti continuano a esistere, a rispondere 200 e a occupare spazio in cache, e restano appese a un segnale che Google può ignorare. Nel mio caso, delle due varianti maiuscole che ho controllato Search Console dice che non le conosce nemmeno: la prova che finora il tag non ha dovuto fare niente, non che funzioni. Un redirect alla versione minuscola le fa sparire davvero. Il curl della sezione sull’audit lo mostra in tre righe.
Il canonical della pagina 2 di una paginazione va sulla pagina 1?+
No. È il primo dei cinque errori del post ufficiale, e la conseguenza è scritta: «dato che non sono pagine duplicate… i contenuti della pagina 2 e di quelle successive non verranno indicizzati». Ogni pagina di una serie impaginata va canonicalizzata su sé stessa.
