Catene e loop di redirect: come trovarli e correggerli

Le catene di redirect nascono quando una URL manda a una seconda URL, che manda a una terza, e a volte a una quarta prima di arrivare alla destinazione finale. I loop di redirect nascono quando il percorso non arriva mai a una destinazione stabile.

Sono problemi risolvibili. Sono anche più comuni di quanto dovrebbero.

Compaiono spesso durante cambi di dominio, inoltro dominio con preservazione del path e migrazioni CMS. Se sei in questa situazione, leggi anche come reindirizzare un dominio senza perdere path e UTM.

Una catena tipica:

/vecchia-pagina -> /pagina-legacy -> /nuova-pagina

Un loop:

/vecchia-pagina -> /nuova-pagina -> /vecchia-pagina

Se ti interessano SEO, performance o una migrazione pulita, l'architettura finale dovrebbe avvicinarsi il più possibile a: una richiesta, un redirect, una destinazione.

Perché catene e loop sono un problema

Rallentano gli utenti reali

Ogni hop aggiunge attesa. Anche quando il ritardo è piccolo, una catena inserisce latenza inutile nel percorso critico.

Rendono le migrazioni più difficili da capire

Una mappa redirect dovrebbe semplificare una migrazione. Le catene fanno il contrario: rendono meno chiaro quale sia la destinazione canonica.

Consumano crawl budget e tempo QA

I motori di ricerca possono seguire redirect, ma un sistema disordinato resta più difficile da scansionare, validare e mantenere rispetto a una mappatura diretta.

I loop rompono la richiesta

Un loop non è inefficiente. È un errore. Il browser non arriva mai a una destinazione utilizzabile.

Cause comuni delle catene

Le catene spesso nascono quando più regole "ragionevoli" vengono aggiunte nel tempo senza un proprietario che le ripulisca.

Pattern tipico:

1. prima viene aggiunto HTTP -> HTTPS
2. poi non-www -> www
3. poi vecchio slug -> nuovo slug
4. poi un plugin CMS aggiunge un altro livello
5. poi cambia di nuovo l'host canonico

Ogni regola sembra innocua da sola. Insieme creano una catena.

Esempio:

http://old-brand.it/docs
  -> https://old-brand.it/docs
  -> https://www.old-brand.it/docs
  -> https://new-brand.it/docs

Di solito dovrebbe diventare:

http://old-brand.it/docs
  -> https://new-brand.it/docs

Cause comuni dei loop

I loop arrivano da logiche in conflitto:

• una regola host manda traffico a un altro host
• una seconda regola lo rimanda indietro
• un redirect nell'app contraddice la regola edge
• regole localizzate o per dispositivo non hanno una destinazione finale stabile

Succede anche quando più sistemi sono attivi insieme:

• regole CDN
• middleware dell'app
• reverse proxy
• plugin CMS

Se più di un layer pensa di possedere il routing canonico, i loop diventano molto più probabili.

Come trovare catene di redirect

Parti dalle URL che contano:

• homepage
• landing page principali
• pagine organiche con più traffico
• URL campagna paid
• documentazione e supporto
• vecchi backlink da migrazioni precedenti

Poi testa il percorso reale degli hop.

Metodo 1: curl

curl -I https://old-brand.it/pricing

Per un'ispezione più profonda:

curl -IL https://old-brand.it/pricing

Così vedi ogni header Location nella sequenza.

Metodo 2: crawl in bulk

Se sei in mezzo a una migrazione, esporta la mappa redirect e scansiona le URL importanti in batch. È qui che i team scoprono catene nascoste non visibili con controlli manuali.

Metodo 3: analytics di produzione

Se il tuo layer di routing espone dati di traffico, monitora:

• richieste ripetute da vecchi path
• URL legacy ad alto volume
• pattern insoliti di status code
• richieste che non raggiungono la destinazione attesa

Per questo molti team abbinano redirect, analytics e monitoraggio link rotti.

Come trovare loop di redirect

I loop sono spesso evidenti nel browser, ma vanno testati in modo sistematico.

Cerca:

• URL che non risolvono mai
• errori del browser su troppi redirect
• due host o path che si alternano
• regole lingua, host o protocollo che si riscrivono a vicenda

Se il sito ha locale redirect, canonical host e redirect auth nell'app, testa le combinazioni invece del solo percorso felice.

La correzione pulita per le catene

La soluzione non è togliere redirect a caso finché la pagina funziona.

La soluzione è:

1. definire la URL finale vera
2. mandare ogni variante vecchia direttamente a quella URL
3. aggiornare i link interni per ridurre i redirect reali
4. rimuovere le regole intermedie obsolete

In altre parole, la mappa deve riflettere lo stato attuale, non la storia della migrazione.

La correzione pulita per i loop

Per correggere un loop:

1. identifica quale layer crea il secondo rimbalzo
2. scegli un solo sistema come fonte di verità
3. rimuovi o restringi la regola in conflitto
4. ritesta host, protocollo, locale e dispositivo

[!WARNING] I loop sopravvivono perché spesso si testa una sola URL finale in un solo browser. Testa varianti, non solo l'happy path.

Consigli per migrazioni

Durante una migrazione, catene e loop compaiono spesso in quattro aree:

Consolidamento host

http, https, www e root domain si combinano male se non vengono pianificati insieme.

Rinomina path

Un vecchio slug punta a uno slug intermedio, che poi punta allo slug finale.

CMS e app rewrite

Una regola CDN manda traffico a un path che l'app prova a canonicalizzare di nuovo.

Localizzazione

I redirect lingua possono rimbalzare se logica di selezione lingua e regole canoniche non concordano.

Se stai pianificando un cambio dominio, usa una checklist invece di improvvisare regola per regola. La checklist redirect per migrazioni sito serve proprio a questo.

E quando scegli le regole, verifica anche l'intento permanente o temporaneo con redirect 301 vs 302 vs 307 vs 308.

Processo QA essenziale

Un workflow snello che intercetta la maggior parte dei problemi:

1. esporta i redirect pianificati
2. seleziona le 50-200 URL più importanti
3. testale per risoluzione a un solo hop
4. controlla root domain, www e HTTPS
5. testa mobile e desktop se esistono regole dispositivo
6. aggiorna i link interni dopo il lancio
7. monitora 404 e redirect per i primi 7-14 giorni

Non serve perfezione astratta. Serve evitare brutte sorprese sulle URL che portano traffico e ricavi.

Dove aiuta UrlEdge

UrlEdge tiene il comportamento redirect in un solo layer di routing invece di spargerlo tra:

• middleware app
• plugin CMS
• file server config
• feature forwarding del provider DNS

Questo rende più semplice:

• comprimere catene in mappature dirette
• ispezionare redirect con Redirect Checker
• monitorare path falliti con Broken Link Monitor
• validare traffico post-lancio con analytics

FAQ

Un hop extra è sempre un disastro?

No. L'obiettivo non è la perfezione per principio. L'obiettivo è rimuovere hop inutili, soprattutto su URL ad alto valore e percorsi canonici molto trafficati.

Devo aggiornare i link interni se il redirect funziona?

Sì. I redirect sono una rete di sicurezza, non lo stato ideale. I link interni dovrebbero puntare direttamente alla destinazione finale.

I loop sono sempre colpa della CDN?

No. Spesso nascono da disaccordo tra layer: CDN, app, proxy, localizzazione o CMS.

Le catene possono danneggiare anche campagne paid?

Sì. Ogni hop aggiunge complessità e punti in cui attribuzione, anteprima o timeout possono rompersi.

Guide correlate UrlEdge

• Redirect Checker
• Broken Link Monitor
• Inoltro dominio con preservazione del path
• Checklist redirect per migrazioni sito

Riferimenti autorevoli

• MDN: Redirections in HTTP
• Google Search Central: site move with URL changes