Cos'è un URL canonical, e quando usarne uno

Cosa fa davvero rel=canonical

Lo stesso contenuto è di solito raggiungibile su più di un URL. Parametri di tracciamento, identificatori di sessione, uno slash finale, http accanto a https, www accanto al dominio nudo, una vista di stampa, un elenco ordinato: ognuno di questi è un URL separato che serve le stesse parole. Se lasciato correre da solo, un motore di ricerca ne sceglie uno per conto proprio, e potrebbe non scegliere quello che sceglieresti tu.

Un canonical è il modo in cui rendi esplicita quella scelta:

<link rel="canonical" href="https://example.com/shoes">
Link: <https://example.com/shoes>; rel="canonical"

Vale la pena interiorizzare due proprietà. Primo, è un suggerimento, non un'istruzione. Google lo pesa insieme a redirect, link interni, voci della sitemap e il contenuto stesso, e può scegliere, e a volte lo fa, un canonical diverso da quello che hai dichiarato. Secondo, consolida invece di eliminare. I segnali dal duplicato confluiscono nel canonical, ed è questa la differenza rispetto al noindex, dove il duplicato smette semplicemente di esistere per quanto riguarda la ricerca.

Canonical auto-referenziati

Ogni pagina indicizzabile dovrebbe dichiarare se stessa come proprio canonical. Suona ridondante ed è invece la riga più utile delle tre, perché è ciò che neutralizza i parametri che non avevi previsto. Quando /shoes?utm_source=newsletter dichiara https://example.com/shoes, l'URL della campagna confluisce automaticamente in quello pulito invece di competere con esso.

Tre regole per farli bene: usa URL assoluti incluso lo schema, emetti esattamente un elemento canonical per pagina (una pagina con due canonical in conflitto li vede ignorati entrambi), e mantieni il canonical coerente con il resto dei tuoi segnali. Un canonical che punta a un URL che reindirizza altrove, o che restituisce 404, o che porta un noindex, invia istruzioni contraddittorie e viene scontato.

Canonical cross-domain

Un canonical può puntare a un altro dominio. È il meccanismo corretto quando sindachi un articolo verso un sito partner o un aggregatore di notizie: la copia sul loro dominio dichiara il tuo URL come canonical, così i posizionamenti di ricerca confluiscono verso il tuo originale invece che verso la loro ripubblicazione.

È anche ciò che rende pericolosi i canonical. Niente impedisce a una pagina di nominare un URL su un host con cui non ha alcun rapporto, e niente nella sintassi fa sembrare sbagliato un canonical cross-domain accidentale. È da qui che nasce il fallimento dello staging.

Il fallimento del canonical di staging

La maggior parte dei framework e dei sistemi di gestione dei contenuti costruisce il canonical concatenando un URL base configurato con il percorso corrente. Quell'URL base vive in una variabile d'ambiente, in una riga di opzione del database o in un file di configurazione, ed è diverso in ogni ambiente. Quando il valore di staging raggiunge la produzione, ogni pagina sul sito live dichiara che la versione reale vive su https://staging.example.com/....

Ciò che segue è silenzioso e lento. Le pagine live continuano a restituire 200 e continuano a servire il contenuto giusto. Ma ciascuna di esse sta dicendo a Google che la copia autorevole si trova altrove, e quell'altrove è irraggiungibile, protetto da password o noindexato. Le pagine iniziano a uscire dai risultati una recrawl alla volta, e poiché non c'è alcun errore su cui scattare un avviso, il primo segnale è di solito un grafico del traffico una settimana dopo. La riparazione è trattata in correggere un canonical che punta allo staging.

Canonical, redirect o noindex

I tre vengono usati in modo intercambiabile e non sono intercambiabili:

• Redirect 301 quando il duplicato non dovrebbe essere raggiungibile affatto. Il segnale più forte disponibile, e la risposta giusta per un URL ritirato o uno spostamento di dominio.
• rel=canonical quando entrambi gli URL devono restare raggiungibili ma solo uno dovrebbe posizionarsi. Parametri, viste di stampa, copie sindacate, elenchi filtrati.
• noindex quando la pagina deve restare raggiungibile e non deve posizionarsi, e non c'è una pagina equivalente in cui consolidarla. Risultati di ricerca interna, pagine di ringraziamento, aree dell'account.

Non sovrapporli. Un canonical su una pagina noindexata è contraddittorio, dato che stai chiedendo il consolidamento in una pagina e allo stesso tempo chiedendo che quel rapporto venga ignorato.

Verifica cosa servi davvero

Leggere il template non è verifica, perché edge worker, plugin e logica lato server iniettano tutti canonical che non compaiono mai nel tuo repository. Leggi invece la risposta: curl -s https://example.com/ | grep -i 'rel="canonical"'. Per una pagina, il controllo canonical gratuito risolve il tag e dice se punta alla pagina stessa, a un altro URL sullo stesso host, alla versione http o a un altro host. Per controllare l'intero sito, lo strumento gratuito di crawl del sito riporta uno stato del canonical per URL, segnando le pagine dove manca e le pagine dove punta altrove. Sorvegliare le tue pagine chiave per il giorno in cui il valore cambia è ciò che fa l'opzione Indexability su un monitor HTTP di HostTracker - vedi il monitoraggio SEO.