Valuta se gli URL sono effettivamente duplicati
Un URL canonico è l’indirizzo rappresentativo per pagine duplicate o quasi-duplicate. La relazione di link canonical è appropriata quando il target contiene contenuto duplicato o un superset del contenuto della pagina riferente. Non è un modo per nascondere prodotti diversi, filtri utili, articoli distinti o localizzazioni.
Chiediti se un visitatore perderei contenuti importanti, scelte o la possibilità di completare un’attività se questo URL fosse rappresentato dall’URL candidato. Se la risposta è sì, mantienilo distinto e migliora il suo contenuto o la localizzazione. Se no, scegli un URL stabile e documentane protocollo, host, path, regole sul trailing-slash e sui parametri.
Aggiungi un canonical autoreferenziale a ogni pagina HTML indicizzabile preferita, anche quando non è evidente alcun duplicato oggi.
Indirizza un duplicato necessario, come una route con parametri di analytics, verso l’URL preferito solo se entrambe le pagine restituiscono lo stesso contenuto principale.
Usa un redirect quando l’URL vecchio dovrebbe sparire
Usa un redirect permanente lato server quando un percorso obsoleto, un host ritirato o una versione HTTP non dovrebbero più essere una destinazione per visitatori o crawler. Google considera i redirect un forte segnale di canonicalizzazione e li raccomanda quando si depreca un duplicato.
Usa rel=canonical quando entrambi gli URL devono rispondere con contenuto ma uno dovrebbe rappresentare il cluster nella ricerca. Il tag non cambia l’indirizzo del visitatore né rimuove l’altra route. Il target dovrebbe rispondere con successo e non dovrebbe ridirigere o canonicalizzare altrove.
Invia un URL legacy HTTP direttamente all’URL finale HTTPS e usa quell’URL HTTPS ovunque altrove.
Robots.txt, rimozioni di URL e noindex non esprimono un duplicato preferito. Noindex invece blocca una pagina dalla Ricerca.
Pubblica un’unica annotazione chiara
Per l’HTML, inserisci un’unica annotazione rel=canonical assoluta nella head. Controlla il sorgente consegnato, non solo l’impostazione del CMS: un tema, plugin, regola edge o JavaScript può sostituire il valore. Google consiglia di fornirla nel sorgente HTML e di assicurarsi che JavaScript non la modifichi.
Per un documento non-HTML come un PDF, usa un header di risposta HTTP Link con canonical quando appropriato. Evita valori contrastanti tra HTML e header. Il target deve essere accessibile, non deve restituire un errore 4xx e non deve essere un URL che ridirige o che è concatenato.
Pubblica un singolo target canonical per risorsa; target multipli rendono la preferenza poco chiara.
Effettua il fetch di pagine campione e header dopo modifiche a template, CDN, CMS o routing e conferma il target finale.
Fai concordare i segnali di supporto
Collega internamente all’URL preferito nella navigazione, nei breadcrumb, nei link nel corpo e nei feed generati. Metti in sitemap solo gli URL che vuoi appaiano nella ricerca. L’inclusione in sitemap è un segnale più debole, ma rinforza la scelta quando concorda con redirect e annotazioni.
Genera URL sitemap completamente qualificati con lo stesso host, protocollo e stile di slash del canonical. Rimuovi duplicati con redirect e parametrici. Testa le sitemap generate automaticamente dopo modifiche a permalink, dominio, lingua o ecommerce.
Sostituisci i link a URL tracciati, legacy o di host alternativi con il canonical selezionato.
Mantieni coerenti redirect HTTPS, target canonical, sitemap e link; problemi di certificato e fault da HTTPS a HTTP inviati segnali contrastanti.
Tratta parametri, paginazione e lingue in base allo scopo
I parametri non sono automaticamente duplicati. I parametri di analytics possono lasciare il contenuto invariato, mentre filtri e ordinamenti possono cambiare il set di risultati. Testa combinazioni rappresentative. Conserva qualsiasi parametro necessario per carrello, login, consenso o configurazione; un canonical non deve rompere un flusso visitatore.
Non canonicalizzare tutta la serie paginata alla pagina uno: le pagine successive di solito contengono contenuti che la pagina uno non ha. Per gli URL per lingua o paese, nomina come canonical la pagina nella stessa lingua quando esiste e usa hreflang per gli alternativi. La canonicalizzazione non sostituisce il design per la localizzazione.
Documenta quali filtri sono landing page distinte e quali sono riordinamenti duplicati in modo che prodotto e ingegneria rimangano allineati.
Usane una sola quando è un superset di contenuto effettivamente utilizzabile; testa il suo caricamento e la navigazione prima di selezionarla.
Debugga conflitti con evidenze indicizzate e live
In Search Console, ispeziona l’URL interessato e confronta il canonical selezionato da Google con il valore dichiarato dall’utente. Ispeziona anche il target candidato. Il report indicizzato riflette ciò che Google ha elaborato l’ultima volta; un test live è utile per il fetch attuale, la pagina renderizzata, gli header e le risorse, ma non può prevedere la selezione finale del canonical.
Se i valori differiscono, valuta se Google ha scelto il rappresentante migliore. Altrimenti traccia redirect, annotazioni in HTML e header HTTP, output renderizzato, link, voci di sitemap, hreflang e somiglianza dei contenuti. Risolvi la discrepanza, registra la modifica e lascia il tempo per la rivalutazione.
Controlla template, header, routing host e cambi di sicurezza. Un canonical o un redirect cross-domain inspiegabile richiede un’indagine di sicurezza.
Confronta sorgente consegnato ed header con le impostazioni del CMS; un plugin o una regola della piattaforma può emettere un valore diverso.
Aggiungi controlli canonical all’hardening di release SIU
Prima di release su dominio, HTTPS, CDN, CMS, template o catalogo, campiona la homepage, pagine di contenuto e prodotto, una route con parametri, una locale, un URL legacy e documenti pubblicati. Registra stato, URL finale, target canonical, inclusione in sitemap e un esempio di link interno.
Mantieni le correzioni revertibili: cattura la mappatura corrente, cambia un set di regole, verifica le route interessate e conserva un piano di rollback. Questo supporta l’ottimizzazione proattiva dell’uptime proteggendo percorsi pubblici stabili durante il cambiamento; non fornisce rilevamento di outage né garantisce l’indicizzazione.
Assegna regole canonical tra marketing e ingegneria e registra il template, redirect, sitemap o modifica di piattaforma dietro ogni aggiornamento.
Allega un piccolo campione di URL e header prima-e-dopo al ticket di release per una remediation più rapida.