La sitemap non è un rel=canonical

Il 2 novembre 2026 una URL messa in sitemap e un rel="canonical" non pesano allo stesso modo. La guida di Google li elenca in ordine di influenza: il reindirizzamento è un indicatore forte, l’annotazione rel="canonical" è un indicatore forte, l’inclusione in sitemap è un indicatore debole. Non ho impostato tag su un sito.

In breve: ho letto Come specificare un URL canonico, ultimo aggiornamento 2026-07-15 UTC. Quale codice di stato usare nel redirect è un altro gesto, nel pezzo sul 301. Questa pagina è nel cluster Web Agency.

Tre pesi, non un interruttore

La pagina dice che i metodi si possono sovrapporre e che due o più insieme aumentano la possibilità che la URL preferita compaia nei risultati. Nessuno è obbligatorio. Se non si indica una preferenza, Google sceglie la versione che ritiene obiettivamente migliore da mostrare.

La sitemap, nella tabella di confronto, è facile da gestire sui siti grandi. Lo svantaggio scritto sotto è che Google deve comunque identificare le pagine duplicate per ogni URL dichiarata canonica nella sitemap, e che il segnale è meno efficace della mappatura con rel="canonical". Elencare una URL non chiude la scelta.

Il reindirizzamento, sulla stessa pagina, si usa quando si vuole eliminare una duplicata esistente. Tutti i metodi di reindirizzamento permanente hanno, scrive Google, lo stesso effetto sulla Ricerca, ma i motori hanno bisogno di tempo prima di notare che i vari metodi possono essere diversi. Per un effetto più rapido la guida chiede i reindirizzamenti HTTP, detti lato server. L’esempio sono https://example.com/home, https://home.example.com e https://www.example.com: se ne sceglie uno e gli altri ci mandano il traffico. Il confronto fra 301 e 302 non sta in questa scheda.

Il link HTML non vale per un PDF

Google scrive di supportare le annotazioni esplicite come nella RFC 6596. I due modi sono l’elemento link nel codice HTML e l’intestazione HTTP Link. La guida consiglia di sceglierne uno. Usarli insieme è supportato, ma è più facile sbagliare: un URL nell’header e un altro nell’elemento.

L’elemento sta nella sezione head, e almeno quella sezione deve essere HTML valido. Fuori dal head non è accettato. La pagina consiglia anche il canonico autoreferenziale, lo stesso elemento sulla pagina canonica. I percorsi assoluti sono quelli consigliati. I relativi sono supportati e sconsigliati, perché a lungo andare possono far scansionare un sito di test. L’esempio corretto è https://www.example.com/dresses/green/green-dress.html. L’esempio errato è /dresses/green/green-dress.html.

Nella definizione italiana dell’elemento, il 2 novembre 2026, la frase stampa «un’altra pagina è e rappresentativa dei contenuti». Manca una parola. Non l’ho ricostruita.

La tabella dice che l’elemento funziona solo per le pagine HTML, non per i file, e porta l’esempio del PDF. Per quelli indica l’intestazione HTTP, definita nel richiamo alla RFC 5988. Google supporta questo metodo solo per i risultati di ricerca web. L’esempio sulla pagina: la versione .docx risponde con Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical", così il PDF è il canonico. Anche nell’header gli URL vanno assoluti.

Un rel="canonical" che propone una versione alternativa viene ignorato. In particolare gli attributi hreflang, lang, media e type su quell’annotazione non servono alla canonicalizzazione. Per lingua e paese la guida indica link rel="alternate".

Due metodi che non devono litigare

La best practice vieta di indicare URL diversi come canonici con tecniche diverse. L’esempio è proprio questo: un URL in sitemap e un altro, per la stessa pagina, con rel="canonical".

Non va indicato un frammento di URL: in genere Google non li supporta. Non va usato robots.txt per scegliere il canonico: una URL non consentita può restare indicizzata senza i contenuti. Lo strumento di rimozione URL non è un metodo di canonicalizzazione, perché nasconde tutte le versioni. noindex non serve a impedire la scelta di un canonico dentro lo stesso sito: la pagina viene bloccata del tutto. La soluzione preferita, sulla guida, è l’annotazione rel="canonical".

Con JavaScript il modo migliore, scrive la pagina, è il canonico nel codice sorgente HTML, senza che lo script modifichi l’elemento. Se non si può metterlo nel sorgente, la guida chiede di lasciarlo fuori dall’HTML e impostarlo solo con JavaScript. WordPress, Wix e Blogger possono non far toccare l’HTML: in quel caso si cerca l’impostazione del motore di ricerca del CMS.

Oltre ai metodi espliciti, Google preferisce HTTPS a HTTP, salvo quattro contrasti: certificato SSL non valido, dipendenze non protette diverse dalle immagini, un HTTPS che reindirizza a o attraverso una pagina HTTP, un rel="canonical" sulla pagina HTTPS che punta all’HTTP. Certificati non validi e reindirizzamenti da HTTPS a HTTP portano Google a preferire HTTP in modo netto. L’HSTS non sostituisce quella preferenza. Non va messa in sitemap, né nelle annotazioni hreflang, la versione HTTP al posto della HTTPS. Il certificato deve corrispondere all’URL completo del sito, o essere un certificato jolly: l’esempio da evitare è example.com che serve il certificato di subdomain.example.com.

Nei cluster hreflang Google preferisce le URL che ne fanno parte. Se https://example.com/de-de/cats e https://example.com/de-ch/cats si puntano e non puntano https://example.com/de-at/cats, de-de e de-ch sono preferite a /de-at/, che nel cluster non c’è.

Errori da evitare

• Credere che la presenza in sitemap chiuda il canonico. La guida la chiama indicatore debole.

• Mettere un URL nel rel="canonical" e un altro in sitemap. La pagina lo vieta.

• Usare l’elemento HTML su un PDF. Per i file l’esempio è l’header, con white-paper.pdf.

• Scrivere il percorso relativo /dresses/green/green-dress.html. L’esempio corretto è assoluto.

• Aggiungere hreflang o media sul rel="canonical". Quelle annotazioni, per la canonicalizzazione, vengono ignorate.

• Usare noindex per scegliere quale copia tenere. La guida dice che la pagina esce dalla Ricerca.

• Contare sull’HSTS se il certificato non è valido o se l’HTTPS manda a una pagina HTTP. La preferenza per HTTP, in quei casi, resta netta.

In sintesi

Il 2 novembre 2026 la guida tiene tre leve e non le pareggia. Il redirect e il rel="canonical" sono forti. La sitemap aiuta e non decide. Il link HTML e l’header HTTP non sono intercambiabili sul PDF, e non vanno puntati a due URL diverse. Non ho chiesto a Google quale URL avrebbe scelto su un sito reale.

Foto di copertina: Jaggery, «No Entry signs, St John's Street, Monmouth», Wikimedia Commons, CC BY-SA 2.0. Sono cartelli a Monmouth. Non sono un rel="canonical" e non sono una sitemap.