Il canonical non è più solo un suggerimento SEO
Per anni abbiamo spiegato il canonical come un segnale. Non una direttiva assoluta. Non un redirect. Non un blocco. Un’indicazione.
Con rel="canonical" dici a Google, Bing e agli altri sistemi automatici: “tra queste URL simili o duplicate, considera questa come versione preferita”. Poi il motore decide se rispettarla, ignorarla o sostituirla con la propria scelta algoritmica.
Cloudflare, con Redirects for AI Training, sposta il problema su un altro piano: per i crawler AI verificati destinati al training, il canonical può diventare un redirect HTTP 301 effettivo.
Non per gli utenti. Non per Googlebot. Non per gli AI assistant che recuperano pagine su richiesta dell’utente.
Solo per una classe specifica di bot AI: quelli classificati da Cloudflare come AI Crawler, cioè crawler che raccolgono contenuti per l’addestramento dei modelli.
Questa è la novità vera. Il canonical non serve più solo a consolidare segnali SEO: diventa una regola di distribuzione del contenuto verso i sistemi di training AI. E questo, per chi lavora su SEO tecnica, crawling, documentazione, editoria, e-commerce e GEO, non è un dettaglio. È un cambio di postura.
Cosa ha lanciato Cloudflare
Il 17 aprile 2026 Cloudflare ha annunciato Redirects for AI Training, una funzione di AI Crawl Control che trasforma i canonical tag già presenti nelle pagine HTML in redirect 301 Moved Permanently per crawler AI verificati.
Il comportamento è questo:
<link rel="canonical" href="https://www.example.com/pagina-canonica/" />Se un crawler AI verificato richiede una pagina non canonica, e quella pagina dichiara una canonical diversa ma sullo stesso origin, Cloudflare può rispondere con:
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/pagina-canonica/Cloudflare documenta che la funzione si attiva da AI Crawl Control > Quick Actions ed è disponibile sui piani Pro, Business ed Enterprise senza costo aggiuntivo. Può essere attivata anche via API o tramite Configuration Rules per limitarla a specifici host, sottodomini o path.
Il punto importante è che il sito non deve per forza cambiare la propria architettura lato origin: Cloudflare legge la risposta HTML, estrae il canonical dal <head> e, se le condizioni sono rispettate, applica il redirect all’edge.
Perché questa funzione nasce ora
Il problema è semplice: molti segnali SEO sono segnali “educati”.
Funzionano bene quando l’interlocutore è un motore di ricerca che ha interesse a mantenere un indice pulito. Ma i crawler AI non sempre hanno lo stesso obiettivo, la stessa frequenza di aggiornamento o lo stesso rispetto dei segnali storicamente usati nella SEO.
Cloudflare porta un caso molto concreto: nella propria documentazione aveva vecchie versioni di Wrangler ancora accessibili, con banner di deprecazione, meta noindex e canonical verso le pagine aggiornate. Tutti i segnali dicevano: “questo contenuto è vecchio, usa la versione nuova”. Eppure Cloudflare dichiara che, su developers.cloudflare.com, i bot nella categoria AI Crawler hanno generato 4,8 milioni di visite negli ultimi 30 giorni e hanno consumato contenuti deprecati allo stesso ritmo dei contenuti aggiornati.
Questo è il punto SEO/GEO più interessante: se un crawler AI ingerisce documentazione obsoleta, il problema non è solo che spreca crawl budget. Il problema è che quella versione può entrare nei dati usati per addestramento o aggiornamento del modello.
Quindi, domani, un assistente AI potrebbe spiegare il tuo prodotto, la tua API, il tuo listino o la tua policy usando una pagina vecchia.
Non perché la pagina nuova non esista.
Ma perché il crawler ha visto anche quella sbagliata.
Canonical classico vs canonical enforced
Nel modello SEO classico, il canonical è una relazione dichiarativa.
Secondo RFC 6596, la relazione canonical specifica la versione preferita di una risorsa quando esistono contenuti duplicati o sovrapposti; le applicazioni, come i motori di ricerca, possono concentrare l’elaborazione sulla risorsa canonica e consolidare proprietà come segnali e riferimenti.
Google supporta rel="canonical" nell’HTML o via header HTTP, ma continua a trattarlo come parte di un sistema di canonicalizzazione, non come un redirect automatico universale. Google raccomanda inoltre di usare URL assolute e di posizionare il canonical nel <head> valido della pagina.
Cloudflare aggiunge una cosa diversa:
| Scenario | Utente umano | Googlebot / crawler search | AI Assistant / AI Search bot | AI Crawler training |
|---|---|---|---|---|
| Pagina con canonical self-referencing | vede la pagina | vede la pagina | vede la pagina | vede la pagina |
| Pagina con canonical verso URL same-origin diversa | vede la pagina | vede la pagina | vede la pagina | riceve 301 verso canonical |
| Pagina con canonical cross-origin | vede la pagina | vede la pagina | vede la pagina | vede la pagina, perché Cloudflare ignora canonical cross-origin |
| Pagina non HTML | vede la risorsa | vede la risorsa | vede la risorsa | nessun redirect automatico |
Questo significa che il canonical resta un segnale per la SEO tradizionale, ma diventa un enforcement selettivo per i crawler AI di training.
È qui che entra la GEO.
Perché c’entra la GEO
La GEO, o Generative Engine Optimization, non è solo “farsi citare da ChatGPT”.
È anche controllare quali versioni del tuo contenuto sono più facilmente recuperabili, leggibili, riutilizzabili e ingeribili dai sistemi AI.
Nella SEO tradizionale ci siamo abituati a ragionare così:
URL duplicate → canonical → consolidamento ranking/indexingNella GEO il flusso diventa:
URL duplicate o obsolete → canonical enforced → riduzione del rischio che i modelli apprendano contenuti sbagliatiAttenzione: questo non significa che attivando Redirects for AI Training “correggi” immediatamente le risposte dei modelli.
Cloudflare stessa parla di aspettativa e ipotesi: reindirizzare i crawler verso contenuti aggiornati dovrebbe migliorare nel tempo le risposte AI su strumenti legacy, ma l’effetto dipende da pipeline di training chiuse, tempi di recrawl e aggiornamento dei modelli. Quello che migliora subito è il contenuto servito al crawler nel momento dell’accesso.
Questo è il modo corretto di leggerla.
Non è una bacchetta magica GEO.
È un controllo tecnico sul dato che esce dal tuo sito.
Come funziona tecnicamente
Cloudflare usa due input principali:
- la classificazione del bot tramite i campi di verified bot / bot category;
- il tag
<link rel="canonical">presente nella risposta HTML.
Il flusso è:
1. Arriva una richiesta da un bot verificato.
2. Cloudflare verifica se il bot è nella categoria AI Crawler.
3. Cloudflare richiede la pagina all’origin.
4. Legge lo stream HTML, in particolare il <head>.
5. Cerca <link rel="canonical" href="...">.
6. Risolve eventuali URL relative.
7. Verifica che la canonical sia same-origin e diversa dall’URL richiesta.
8. Se tutto torna, restituisce 301 verso la canonical.La documentazione Cloudflare specifica che, se non trova un canonical, se il canonical è self-referencing, se è cross-origin o se non è valido per la regola, la risposta passa invariata.
Questo è fondamentale: Cloudflare non “sceglie” la canonical al posto tuo. Esegue quello che hai già dichiarato.
Se la tua canonicalizzazione è sporca, la stai rendendo più pericolosa.
Quali bot vengono coinvolti
Cloudflare distingue tra categorie diverse di bot AI.
Esempi:
- AI Crawler: crawler che raccolgono contenuti per training, come GPTBot, ClaudeBot, Bytespider, CCBot, Meta-ExternalAgent.
- AI Assistant: bot attivati da un’azione utente, come ChatGPT-User, Claude-User, Perplexity-User.
- AI Search: bot usati per esperienze di ricerca AI, come OAI-SearchBot, Claude-SearchBot, PerplexityBot.
Redirects for AI Training riguarda solo i bot verificati nella categoria AI Crawler. Non coinvolge AI Assistant e AI Search bot. Cloudflare lo dichiara esplicitamente nella documentazione della funzione e nella documentazione sulle categorie di bot.
Questa distinzione è strategica.
Perché non tutti i bot AI hanno lo stesso valore.
Bloccare o reindirizzare un training crawler può avere senso se vuoi evitare che pagine obsolete finiscano nei dataset. Bloccare un bot di AI Search o un assistant user-triggered, invece, può ridurre la possibilità di essere letto, citato o recuperato in un contesto conversazionale.
La GEO seria parte da qui: non trattare “i bot AI” come una massa indistinta.
Casi pratici
1. Documentazione tecnica versionata
Scenario tipico:
/docs/v1/installazione/
canonical → /docs/current/installazione/La vecchia documentazione deve restare online perché alcuni utenti usano ancora vecchie versioni del prodotto. Per Google puoi decidere di mantenerla noindex o canonicalizzata. Per gli utenti umani resta utile.
Ma per un crawler AI di training è rumore.
Se il modello ingerisce la guida vecchia, domani potrebbe suggerire comandi non più validi, endpoint deprecati o parametri rimossi.
Qui Redirects for AI Training ha molto senso.
Non cancelli la vecchia pagina.
Non rompi l’esperienza dell’utente legacy.
Non cambi il comportamento di Googlebot.
Ma dici ai training crawler: “questa è la versione che devi vedere”.
È probabilmente il caso d’uso migliore.
2. Knowledge base con articoli obsoleti
Molte aziende hanno centinaia di articoli help center:
/help/vecchia-dashboard-creazione-report/
canonical → /help/report-dashboard/L’articolo vecchio resta accessibile perché linkato da ticket storici, forum, email o onboarding passati. Ma non vuoi che un modello AI lo tratti come documento valido.
Con il redirect selettivo puoi mantenere la pagina per gli umani e forzare i training crawler verso l’articolo aggiornato.
Qui il valore non è solo SEO. È customer care.
Un assistente AI che consiglia procedure vecchie aumenta ticket, frizione e sfiducia.
3. E-commerce con varianti e parametri
Caso classico:
/prodotto/scarpa-x?color=nero&size=42
canonical → /prodotto/scarpa-x/Per Google il canonical serve a consolidare varianti, parametri e duplicazioni.
Per i crawler AI di training il problema è diverso: se ogni variante viene ingerita come contenuto separato, il modello può sovrappesare informazioni ridondanti o confuse.
Qui l’uso è interessante ma va gestito con cautela.
Se la pagina canonica contiene tutte le informazioni realmente utili, bene.
Se invece le varianti hanno informazioni importanti — materiali, disponibilità, compatibilità, prezzi, condizioni — il canonical potrebbe impoverire ciò che il crawler AI vede.
La domanda non è: “questa pagina è duplicata per Google?”.
La domanda diventa: “questa pagina non canonica contiene informazioni che vorrei far apprendere a un sistema AI?”.
Non sempre la risposta coincide.
4. Pagine categoria filtrate
Esempio:
/scarpe-running?brand=nike&prezzo=100-150
canonical → /scarpe-running/In SEO classica possiamo canonicalizzare filtri non strategici per evitare duplicazioni e spreco di crawl.
Ma in GEO, una pagina filtrata può contenere un’intenzione commerciale precisa:
migliori scarpe running nike sotto 150 euroSe mandi sempre tutto alla categoria generica, potresti perdere granularità semantica utile.
Quindi: non attivare questa logica a occhi chiusi su tutto l’e-commerce.
Prima devi distinguere:
- filtri inutili o combinatori;
- pagine filtro con domanda reale;
- landing SEO strategiche;
- pagine parametriche puramente tecniche;
- pagine generate dal faceted navigation senza valore.
Redirects for AI Training amplifica la tua architettura informativa. Se l’architettura è sbagliata, amplifica anche l’errore.
5. Siti editoriali con articoli aggiornati
Scenario:
/news/bonus-2024-requisiti/
canonical → /guide/bonus-requisiti-aggiornati/Un editore può avere vecchi articoli ancora raggiungibili, ma una guida evergreen aggiornata che rappresenta la versione attuale.
Per un utente umano ha senso leggere anche la cronologia.
Per un crawler AI di training, invece, il contenuto vecchio può diventare tossico.
Qui la funzione è utile se hai una politica editoriale chiara:
vecchio articolo informativo → canonical verso guida aggiornataMa attenzione: non usare canonical per cancellare la storia.
Se un articolo parla di “cosa è successo nel 2024”, non è duplicato della guida 2026. È un documento storico. Canonicalizzarlo verso una pagina aggiornata può essere sbagliato sia per SEO sia per AI.
Il canonical non serve a dire “questa pagina non mi piace più”.
Serve a dire “questa pagina è una variante duplicata o sostanzialmente sovrapposta di un’altra”.
6. Pagine prodotto obsolete
Esempio:
/prodotto/software-basic-2022/
canonical → /prodotto/software-basic/Se la vecchia versione del prodotto non è più venduta, ma la pagina resta online per supporto o documentazione, puoi voler mandare i training crawler alla pagina corrente.
Per SaaS, fintech, legaltech, software B2B e marketplace è un caso molto rilevante.
Perché un modello AI che apprende il vecchio listino, le vecchie feature o le vecchie limitazioni può generare risposte commercialmente dannose.
Qui il consiglio pratico è: creare una mappa tra pagine obsolete e pagine correnti, poi verificare che il canonical rifletta davvero quella mappa.
Come sfruttarla bene
1. Prima audit, poi toggle
La tentazione sarà: “attivo la funzione, tanto usa i canonical già esistenti”. Errore.
Prima devi auditare i canonical. Checklist minima:
- canonical self-referencing sulle pagine principali;
- canonical coerenti sulle pagine duplicate;
- niente canonical verso URL 404, 3xx o noindex non voluti;
- niente catene canonical;
- niente canonical incoerenti tra HTML e header HTTP;
- canonical nel <head> valido;
- canonical assolute dove possibile;
- canonical same-origin se vuoi che Cloudflare applichi il redirect;
- canonical entro i primi 256 KB dell’HTML non compresso.Il limite dei 256 KB è specifico della funzione Cloudflare: il tag deve comparire nei primi 256 KB della risposta HTML non compressa. Se il tuo <head> è enorme, generato male o pieno di script, puoi perdere l’effetto.
2. Parti da sezioni ad alto rischio
Non partirei dall’intero dominio.
Partirei da:
/docs/
/help/
/support/
/kb/
/guide/
/prodotti-obsoleti/
/archivio/Oppure da sottodomini:
docs.example.com
support.example.com
developer.example.comCloudflare consente di attivare la funzione anche su subdomain o path specifici tramite Configuration Rules, ad esempio con espressioni come:
http.host eq "docs.example.com"oppure:
starts_with(http.request.uri.path, "/docs/")Questo è l’approccio corretto: prima le aree dove l’obsolescenza è un rischio reale, poi eventualmente il resto.
3. Misura dai log, non dalle impressioni
Cloudflare registra il target canonical nel campo:
redirects_for_ai_training_targetPuoi interrogarlo via GraphQL Analytics API o Logpush.
Metriche utili:
- quante richieste AI Crawler ricevono 301;
- quali URL non canoniche vengono più richieste;
- quali canonical target ricevono più traffico AI;
- quali sezioni obsolete sono ancora molto crawlate;
- quali crawler vengono reindirizzati più spesso;
- quali pagine non vengono reindirizzate perché self-canonical;
- eventuali loop o pattern anomali.Per la GEO, questa è una nuova forma di osservabilità. Non misuri solo il traffico organico.
Misuri quale versione del tuo sito viene esposta ai crawler AI.
4. Non confonderla con robots.txt
robots.txt dice dove un crawler può o non può andare.
Redirects for AI Training dice: “se vieni qui e sei un training crawler verificato, ti mando alla versione canonica”.
Sono due livelli diversi.
Cloudflare ha anche introdotto strumenti legati ai Content Signals, che permettono di dichiarare preferenze come search, ai-input e ai-train dentro robots.txt; ad esempio, un sito può esprimere search=yes, ai-train=no. Ma questi segnali sono una dichiarazione di preferenza/diritti, non la stessa cosa di un redirect tecnico verso una URL canonica.
La strategia matura non è scegliere uno o l’altro.
È combinare:
robots.txt / Content Signals → policy di accesso e uso
canonical → gerarchia dei contenuti
Redirects for AI Training → enforcement verso crawler AI verificati
log analysis → verifica operativaErrori da evitare
Errore 1: canonicalizzare pagine non duplicate
Se una pagina ha valore autonomo, non deve puntare a una canonical generica solo perché è vecchia, scomoda o poco performante.
Il canonical non è un cestino.
È una relazione tra contenuti duplicati, quasi duplicati o in rapporto di versione preferita.
Errore 2: canonical cross-domain aspettandosi il redirect
RFC 6596 consente canonical su domini diversi, e Google può supportare scenari cross-domain. Ma Cloudflare Redirects for AI Training, per questa funzione, applica il redirect solo quando la canonical è same-origin. Le canonical cross-origin vengono ignorate dalla funzione.
Quindi:
<link rel="canonical" href="https://nuovodominio.com/pagina/" />potrebbe avere senso per Google, ma non aspettarti che questa funzione Cloudflare produca il 301 per i training crawler.
Errore 3: pensare che valga per tutti i bot AI
No. Vale per bot verificati nella categoria AI Crawler. Non vale per AI Assistant e AI Search bot. Non è una soluzione per scraper non verificati, user-agent spoofati o traffico malevolo non classificato.
Per quello servono altre regole: WAF, Bot Management, allow/block selettivi, rate limiting, log analysis.
Errore 4: attivarla senza sapere cosa fanno i canonical del CMS
Molti CMS generano canonical automaticamente.
A volte bene.
A volte male.
A volte in modo diverso tra template, plugin, parametri, lingua, paginazione, filtri e pagine AMP.
Prima di usare una funzione che trasforma canonical in redirect per una classe di crawler, devi sapere chi genera quel tag.
Non è un dettaglio frontend.
È governance del contenuto.
Configurazione operativa consigliata
Fase 1: mappa dei rischi
Crea una tabella:
| Sezione | Rischio AI | Tipo contenuto | Strategia |
|---|---|---|---|
/docs/v1/ |
Alto | documentazione deprecata | redirect AI verso docs attuali |
/help/old/ |
Alto | supporto obsoleto | canonical verso articoli aggiornati |
/blog/archivio/ |
Medio | contenuto storico | valutare caso per caso |
/product/?filter= |
Medio | faceted navigation | distinguere filtri utili/inutili |
/news/ |
Variabile | news temporali | non canonicalizzare storia reale |
Fase 2: audit canonical
Usa crawler SEO, log e query mirate.
Esempi di controlli:
URL richiesta → canonical dichiarata → status canonical → indexability → same-origin → template → sezioneDevi trovare:
- canonical mancanti;
- canonical multiple;
- canonical fuori dal <head>;
- canonical verso 404;
- canonical verso redirect;
- canonical incoerenti tra desktop/mobile;
- canonical verso URL parametrizzate;
- canonical cross-origin;
- canonical troppo tardi nel codice.Fase 3: attivazione limitata
Non attivarla subito ovunque.
Meglio una regola:
starts_with(http.request.uri.path, "/docs/")Oppure:
http.host eq "support.example.com"Così puoi misurare prima gli effetti su una porzione controllata.
Fase 4: logging
Dopo l’attivazione guarda:
redirects_for_ai_training_target
cf.verified_bot_category
user agent
path richiesto
status code
host
content-typeDomande utili:
- quali vecchie URL ricevono più richieste?
- quali crawler stanno consumando contenuti obsoleti?
- quali canonical target sono più importanti per i modelli?
- ci sono sezioni che pensavamo morte ma vengono ancora crawlate?
- i redirect stanno andando verso pagine davvero corrette?Fase 5: correzione editoriale
La parte tecnica serve a scoprire un problema editoriale.
Se un training crawler continua a richiedere documenti obsoleti, forse hai:
- link interni vecchi;
- sitemap sporche;
- documentazione legacy troppo esposta;
- canonical deboli;
- redirect mancanti;
- pagine archiviate senza contesto;
- duplicati generati dal CMS.Redirects for AI Training non sostituisce la pulizia del sito. La rende più urgente.
Impatto SEO: cosa cambia e cosa no
Cosa non cambia
Per come è documentata, la funzione non cambia il comportamento verso:
- utenti umani;
- browser;
- Googlebot;
- Bingbot;
- crawler search tradizionali;
- AI Assistant;
- AI Search bot.Cloudflare dichiara esplicitamente che browser, motori di ricerca e AI Assistants ricevono la pagina originale invariata.
Quindi non va presentata come “nuovo fattore ranking”. Non lo è.
Cosa cambia
Cambia quale contenuto ricevono i crawler AI di training quando arrivano su una pagina non canonica.
Questo ha tre impatti:
- Riduce l’ingestione di contenuti obsoleti.
- Rafforza la gerarchia editoriale già espressa dai canonical.
- Trasforma una scelta SEO tecnica in una scelta di governance AI.
Il terzo punto è il più importante.
Fino a ieri il canonical parlava soprattutto ai motori di ricerca.
Ora può parlare anche ai sistemi che alimentano, aggiornano o preparano i modelli AI.
La mia opinione
Questa è una delle prime funzioni GEO davvero tecniche. Non perché “ottimizza per ChatGPT” nel senso banale del termine.
Ma perché agisce sul livello più ignorato della GEO: la qualità del contenuto che i sistemi automatici possono acquisire.
Molti parlano di GEO come se bastasse scrivere FAQ, usare schema markup e mettere frasi più citabili.
Va bene, ma è superficie. La parte più interessante è un’altra:
quale versione del contenuto può vedere un crawler AI?
quale contenuto vecchio sto ancora esponendo?
quali duplicati sto lasciando ingerire?
quali pagine non voglio bloccare agli utenti ma non voglio far apprendere ai modelli?Cloudflare Redirects for AI Training non risolve tutta la questione AI crawler. Non blocca gli scraper non verificati. Non ti garantisce citazioni. Non corregge i modelli già addestrati. Non sostituisce una strategia legale sui diritti dei contenuti.
Però introduce un principio importante:
la canonicalizzazione non è più solo un problema di indice. È un problema di dataset.
E quando il contenuto diventa dataset, la SEO tecnica diventa infrastruttura di controllo.
Quando attivarla subito
La attiverei subito, dopo audit, su siti con:
- documentazione tecnica versionata;
- API docs;
- knowledge base;
- help center;
- pagine prodotto obsolete;
- cataloghi con molte URL parametriche;
- portali editoriali con guide evergreen e articoli superati;
- SaaS con vecchie feature documentate;
- siti legal/finance/medical con contenuti aggiornati nel tempo.Quando aspettare
Aspetterei se:
- i canonical sono generati male dal CMS;
- ci sono molte canonical cross-domain;
- le pagine non canoniche contengono informazioni importanti;
- il sito usa faceted navigation senza una strategia chiara;
- il team non ha accesso ai log;
- non è chiaro quali bot AI vadano bloccati, permessi o reindirizzati.Attivarla senza audit è come fare un redirect massivo senza mappa. Magari va bene. Ma se va male, te ne accorgi tardi.
Che dire?
Redirects for AI Training è una funzione piccola solo in apparenza.
Prende un tag che la SEO usa da anni e lo sposta nel mondo AI:
<link rel="canonical">Prima era un consiglio. Ora, per una categoria precisa di crawler, può diventare una regola HTTP.
La direzione è chiara: la SEO tecnica non sta morendo con l’AI. Sta diventando più infrastrutturale. Meno “come scrivo il titolo per posizionarmi”.
Più “quale versione della conoscenza sto rendendo disponibile ai sistemi automatici”.
E questa, per chi fa GEO sul serio, è una differenza enorme.
