Un tag canonical dice a un motore di ricerca quale URL preferiresti che trattasse come copia principale - un suggerimento che di solito segue ma che può ignorare. Un redirect 301 elimina del tutto la scelta: invia ogni visitatore e ogni crawler a un unico URL, e quello vecchio smette di rispondere. Questa è l'intera decisione in una frase. Usa un tag canonical quando entrambi gli URL devono continuare a funzionare per gli esseri umani. Usa un redirect 301 quando dovrebbe esisterne solo uno.
I due si confondono perché combattono lo stesso problema - i contenuti duplicati che dividono il segnale di ranking tra URL quasi identici - con meccanismi diversi. Un canonical è un suggerimento lasciato nell'head della pagina. Un redirect è una risposta HTTP che il browser non ha altra scelta che obbedire. Scambiali e finirai per uccidere un URL che ti serviva vivo, oppure per lasciare diverse versioni della stessa pagina a competere tra loro nell'indice.
L'ho spiegato più spesso della domanda 301 contro 302, quindi questa è la versione che avrei voluto esistesse la prima volta che qualcuno me lo ha chiesto, e se sei qui per la domanda sul codice di stato, redirect 301 vs 302 la copre per intero; questo articolo riguarda un bivio diverso.
Tag canonical vs redirect 301: un suggerimento contro un'istruzione
Un tag rel=canonical vive dentro l'<head> di una pagina: <link rel="canonical" href="https://example.com/preferred-url" />. È uno dei diversi segnali usati per selezionare un URL canonical - forte, ma uno che un motore di ricerca può ignorare quando altre prove non sono d'accordo. Entrambi gli URL restano attivi, una persona può visitare l'uno o l'altro e ottenere una risposta 200 in entrambi i casi, e il tag cambia solo cosa compare nei risultati di ricerca, non cosa un browser può raggiungere.
Un redirect 301 non è un suggerimento. Risponde direttamente alla richiesta: chiedi il vecchio URL, vieni mandato a quello nuovo, punto. Non resta nessuna versione della vecchia pagina da visitare. I browser smettono di provarci, e i motori di ricerca la eliminano dall'indice perché non risolve più verso un contenuto proprio.
Il test pratico si riduce a due condizioni:
- Se entrambi gli URL devono continuare a risolvere per visitatori reali, usa un canonical.
- Se d'ora in avanti dovrebbe esisterne solo uno, usa un redirect - e tipi di redirect è il riferimento per capire quale codice si adatta a quale tipo di permanenza.
Entrambi gli strumenti combattono lo stesso problema da direzioni opposte: un redirect è per un URL su cui nessun essere umano dovrebbe più atterrare, un canonical è per uno su cui una persona potrebbe legittimamente farlo.
Le quattro situazioni in cui i contenuti duplicati richiedono una correzione diversa
Quattro situazioni si presentano di continuo, e ognuna ha esattamente un segnale corretto. Inverti la mappatura e finirai per bloccare un flusso di lavoro attivo, oppure per lasciare un'esca seduta nell'indice.
URL parametrizzati
Un URL con un parametro di tracciamento o un ID di sessione allegato - ?ref=partner o ?sessionid=abc123 - è funzionalmente la stessa pagina della versione pulita, solo con un bagaglio in più. Reindirizzarlo altrove è di solito sbagliato, perché il parametro spesso deve sopravvivere alla richiesta: un codice di referral, un bucket A/B, un passaggio di sessione. La correzione è un canonical auto-referenziale sull'URL pulito, così la versione parametrizzata resta raggiungibile mentre il tag dice ai motori di ricerca di indicizzare la versione senza il rumore.
URL taggati per campagna
Questo è il caso in cui i team marketing si imbattono ogni giorno. Un link come elido.app/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=august-launch deve continuare a funzionare esattamente come taggato, perché i parametri UTM sono il modo in cui l'analytics attribuisce la visita a quella newsletter, tra campagne e canali. Nessuna eccezione, mai. Reindirizzarlo al semplice URL /pricing butterebbe via l'attribuzione prima ancora che venga registrata.
Il tag canonical va sulla pagina di destinazione, non sul link: /pricing dichiara <link rel="canonical" href="https://elido.app/pricing" />, e ogni variante taggata con UTM eredita lo stesso target. I motori di ricerca indicizzano un unico URL /pricing pulito, mentre l'analytics continua a vedere ogni variante di campagna separatamente, dato che il tag non tocca mai ciò che il browser richiede. Un avvertimento: alcuni browser oggi eliminano i parametri UTM o bloccano gli script che li leggono prima che l'attribuzione arrivi a destinazione - vedi come Firefox e Brave rompono l'attribuzione UTM se i numeri delle tue campagne sembrano scarsi. Quello è un problema di tracciamento, non di canonical.
Pagine paginate o sfaccettate
La risposta onesta dipende dal fatto che la combinazione abbia o meno un contenuto che una query di ricerca potrebbe davvero volere. La pagina 2 di un archivio è un contenuto genuinamente diverso dalla pagina 1, quindi fare il canonical di ogni pagina paginata verso la pagina 1 tende a ritorcersi contro nella pratica. Un filtro sfaccettato che si limita a riordinare lo stesso catalogo è il caso opposto - fare il canonical verso la pagina di categoria non filtrata è corretto, dato che su quell'URL non c'è nulla che valga la pena indicizzare separatamente. Nessuna regola universale, solo lo stesso test.
Consolidare una pagina ritirata
Qui un tag canonical è lo strumento sbagliato e un redirect è l'unico corretto. Quando una pagina viene ritirata per sempre - unita a un articolo più recente, eliminata dopo una modifica al catalogo - non c'è motivo perché il vecchio URL continui a risolvere verso qualcosa. Un redirect 301 trasferisce in modo pulito il suo segnale di ranking e rimuove la pagina morta dalla circolazione. Un tag canonical su una pagina che intendi cancellare lascia solo un URL orfano che continua a zoppicare, ancora scansionabile, ancora capace di decadere - esattamente la modalità di fallimento che la prevenzione del link rot esiste per intercettare. Se la vecchia pagina è davvero sparita, reindirizzala. Non fare il canonical di un cadavere.
Quando canonical e redirect non sono d'accordo
A volte un URL porta entrambi i segnali contemporaneamente, e non sono d'accordo. La pagina A reindirizza alla pagina B con un redirect 301, ma la pagina B dichiara il proprio canonical puntando alla pagina C - diversi salti lontano da dove è partito il primo clic.
Le linee guida di Google sono inequivocabili: un redirect è un segnale più forte e più letterale di un tag canonical, perché ha già rimosso l'alternativa - non resta nessuna pagina A da riconsiderare. Quando i due non sono d'accordo, vince la destinazione del redirect come destinazione effettiva, e il tag canonical su quella destinazione diventa il vero segnale che i motori di ricerca valutano. Tutto ciò che sta a monte è rumore nel momento in cui un crawler raggiunge la fine della catena.
Il fallimento pratico è raramente filosofico - di solito è una catena che nessuno ha mai controllato, dove il canonical della destinazione finale era stato impostato per una migrazione diversa anni fa e mai più rivisto. Districarla significa seguire ogni salto finché non raggiungi un URL che restituisce 200 e fa canonical su se stesso, per poi correggere qualunque link sia obsoleto. Un salto pulito, un tag canonical d'accordo con dove sei atterrato: questo è l'intero stato obiettivo.
Perché ogni pagina ha bisogno di un canonical auto-referenziale
Un canonical auto-referenziale è una pagina il cui tag canonical punta a se stessa: /pricing che dichiara <link rel="canonical" href="https://elido.app/pricing" /> invece di restare in silenzio, e la maggior parte delle pagine ben gestite ne porta uno esattamente per questo motivo. Niente di misterioso. Sembra ridondante - perché una pagina dovrebbe aver bisogno di confermare di essere se stessa? È un'assicurazione economica contro ogni modo in cui un URL si duplica per caso: una barra finale, un percorso con maiuscole e minuscole miste, una query string vagante aggiunta da un plugin, una versione http residua accanto a https. Ognuno di questi casi può finire indicizzato come un URL separato, quasi identico, se nulla dice quale copia sia quella vera.
Senza uno di questi, la scelta viene lasciata alla ponderazione dei segnali di Google, che per lo più la azzecca e occasionalmente no - e te ne accorgi notando l'URL sbagliato che si posiziona, il che è un pessimo modo per scoprirlo. Impostalo esplicitamente su ogni pagina indicizzabile e l'ambiguità non avrà mai la possibilità di contare.
Se stai taggando una pagina per una dozzina di canali e non riesci a capire se il canonical è d'accordo con ciò che i tuoi report stanno contando, l'analytics di Elido raggruppa ogni variante taggata verso l'URL che sta davvero misurando, così un parametro vagante non biforca silenziosamente il tuo traffico in due.
Dove si collocano i link brevi rispetto all'URL canonical
Un link breve solleva una domanda che sembra appartenere a questo discorso e per lo più non è così: elido.app/abc123 ha bisogno di un tag canonical che punti alla sua destinazione? No. Un dominio di redirect non è un duplicato della pagina verso cui manda i visitatori - è un indirizzo senza contenuto proprio, nulla che un tag canonical debba disambiguare. La canonicalizzazione è per le pagine che potrebbero plausibilmente essere indicizzate; un link breve non è mai stato un candidato per questo.
Il tag canonical che conta appartiene alla pagina di destinazione, esattamente come se il visitatore fosse arrivato per qualsiasi altra strada. Se elido.app/summer-sale manda le persone verso yoursite.com/sale?utm_source=twitter, il lavoro sul canonical è comunque il caso dell'URL taggato per campagna visto prima, non diverso da qualsiasi link di campagna che taggheresti allo stesso modo. Succede su yoursite.com/sale, non sul link breve. Diramare lo stesso link breve verso destinazioni diverse per campagna o regione non cambia la risposta: gli smart link instradano il clic, ma il lavoro sul canonical avviene comunque ovunque il visitatore atterri. La domanda sulla correttezza del redirect in sé è coperta da redirect 301 vs 302 e come reindirizzare un URL.
Questo è il motivo per cui la paura SEO attorno ai link accorciati è per lo più infondata una volta che i due segnali vengono tenuti separati: il redirect trasferisce il proprio segnale, il canonical della destinazione gestisce il proprio, e nessuno dei due contamina l'altro. Gli URL shortener danneggiano la SEO? copre il resto di questa domanda.
Come controllare quale segnale sta davvero inviando una pagina
Non dare nulla per scontato. Controlla entrambi i segnali direttamente, iniziando dal redirect:
curl -sI "https://example.com/old-page"
Un 301 con un header Location significa che l'URL è sparito per sempre; l'assenza di uno status 3xx significa che non c'è redirect, e qualunque tag canonical è l'unico segnale in gioco. Per vedere il tag canonical stesso, recupera la pagina e cerca nel sorgente:
curl -s "https://example.com/page" | grep -i 'rel="canonical"'
Se un URL invia entrambi i segnali, ripercorri l'intera catena prima di supporre quale sia la vera destinazione. Quando i due sono d'accordo - il redirect atterra su un URL il cui canonical punta a se stesso - il segnale è inequivocabile, ed è lo stato in cui dovrebbe trovarsi ogni URL che conta per il tuo posizionamento.
Correlati nel blog
Domande frequenti
Qual è la differenza tra un tag canonical e un redirect 301?
Un tag canonical è un suggerimento nell'head di una pagina che dice ai motori di ricerca quale URL preferire mentre entrambi restano attivi e raggiungibili; un redirect 301 è un codice di stato HTTP che invia ogni visitatore e ogni crawler al nuovo URL e mette fuori servizio quello vecchio. Google tratta un canonical come un segnale forte che può comunque ignorare se altre prove non sono d'accordo, mentre un redirect non lascia nessuna alternativa da valutare, dato che non resta più una vecchia pagina da riconsiderare. Usa un canonical quando entrambi gli URL devono continuare a rispondere alle richieste; usa un redirect quando dovrebbe esisterne solo uno.
Devo usare un tag canonical o un redirect 301 per i contenuti duplicati?
Usa un redirect se l'URL duplicato deve smettere di esistere del tutto - una pagina ritirata, un vecchio dominio, un trasferimento permanente - perché un redirect consolida il segnale di ranking e allo stesso tempo rimuove dalla circolazione l'URL morto. Usa un tag canonical se il duplicato deve restare raggiungibile per un motivo reale, come un link di campagna taggato con UTM, un parametro di sessione, o una pagina filtrata quasi duplicata. La domanda decisiva è se una persona ha un motivo legittimo per continuare a visitare l'URL che non stai scegliendo come canonical.
Cosa succede quando un tag canonical e un redirect non sono d'accordo?
Vince il redirect, perché ha già rimosso dall'equazione l'URL alternativo - a quel punto della catena non resta più nulla che un tag canonical possa contraddire. Google segue prima il redirect fino alla sua destinazione, poi legge qualunque tag canonical quella destinazione dichiari come segnale operativo. La correzione per un disallineamento è ripercorrere ogni salto finché non atterri su un URL che restituisce 200 e fa canonical su se stesso.
Gli URL con parametri UTM hanno bisogno di un tag canonical?
Sì, il tag canonical appartiene alla pagina di destinazione e dovrebbe puntare all'URL pulito, senza i parametri di tracciamento allegati. Una pagina come /pricing dovrebbe dichiarare se stessa come proprio canonical, indipendentemente da quante varianti taggate con UTM puntino a essa, così i motori di ricerca indicizzano un unico URL pulito mentre l'analytics continua a registrare separatamente ogni variante taggata. Reindirizzare invece un URL taggato con UTM eliminerebbe i parametri prima che il tuo strumento di analytics possa attribuire la visita.
Perché mettere un tag canonical auto-referenziale su ogni pagina?
Un canonical auto-referenziale, una pagina che dichiara se stessa come proprio URL preferito, chiude ogni via accidentale attraverso cui una pagina può duplicarsi, dalle barre finali ai parametri di query vaganti fino a una versione http residua accanto a https. Senza uno di questi, Google sceglie l'URL canonical usando i propri segnali, il che di solito è corretto ma occasionalmente sceglie la variante sbagliata. Impostarlo esplicitamente su ogni pagina indicizzabile rimuove quell'ambiguità gratis.
Un link breve ha bisogno di un tag canonical?
No. Un link breve è un puro redirect HTTP senza contenuto proprio, quindi su quell'URL non c'è nulla che un tag canonical debba disambiguare, e la canonicalizzazione conta solo per le pagine che potrebbero plausibilmente essere indicizzate come contenuto. Il tag canonical che conta si trova sulla pagina di destinazione verso cui il link breve reindirizza, esattamente come sarebbe se un visitatore arrivasse per qualsiasi altra strada.
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Gratis, nessuna registrazione richiesta · 2 al giorno