Redirect HTTP: rilevare loop, catene e link sospetti

Di CaptainDNS
Pubblicato il 20 marzo 2026

Schema che mostra un loop di redirect HTTP con rilevamento e risoluzione

TL;DR

I loop di redirect (ERR_TOO_MANY_REDIRECTS) sono causati da configurazioni circolari tra server, CDN o CMS.
Le catene di redirect eccessive (più di 3 hop) diluiscono il SEO e aggiungono da 100 a 500 ms di latenza per hop.
I link abbreviati (bit.ly, t.co) nascondono la destinazione reale e possono portare a siti di phishing.
Il Redirect Checker di CaptainDNS rileva automaticamente questi tre problemi in una sola analisi.
Google segue un massimo di 10 redirect. Oltre, la pagina non viene indicizzata.

Fai clic su un link e il tuo browser mostra ERR_TOO_MANY_REDIRECTS. Oppure la pagina finisce per caricarsi, ma dopo un ritardo sospetto di diversi secondi. O ancora, un collega ti invia un link abbreviato bit.ly e esiti prima di cliccare. Queste tre situazioni hanno un punto in comune: implicano redirect HTTP che nessuno vede, ma che possono nascondere problemi gravi.

I redirect sono un meccanismo fondamentale del web. Permettono di spostare pagine, forzare HTTPS, gestire vanity URL. Ma quando sono mal configurati, creano tre categorie di problemi distinti. I loop impediscono completamente l'accesso alla pagina. Le catene eccessive degradano il SEO e le prestazioni senza che il visitatore se ne accorga. I link abbreviati nascondono la destinazione reale e servono come vettore di phishing in 1 caso su 10 secondo le ricerche di Palo Alto Networks sui domini registrati di recente (NRD).

Questa guida copre la diagnosi e la correzione di questi tre problemi. Ogni sezione spiega il meccanismo tecnico, i sintomi osservabili e i passi concreti per risolvere la situazione. L'obiettivo è renderti autonomo per identificare e correggere qualsiasi problema di redirect, che tu sia amministratore di sistema, sviluppatore o responsabile SEO.

Analizza i tuoi URL adesso

Testare con il Redirect Checker Verificare un link sospetto

Che cos'è un loop di redirect?

Un loop di redirect si verifica quando un URL A reindirizza a un URL B, che a sua volta reindirizza all'URL A. Il browser segue i redirect in cerchio, senza mai raggiungere una pagina di contenuto. Dopo un certo numero di tentativi, si arrende e mostra un messaggio di errore.

Il caso più semplice è il ciclo a due elementi: A reindirizza a B, B reindirizza ad A. Ma i loop possono coinvolgere tre, quattro o cinque URL intermedi prima di tornare al punto di partenza.

Come reagisce il browser a un loop?

Ogni browser impone un limite al numero di redirect che segue prima di arrendersi. Quando questo limite viene raggiunto, il browser mostra un messaggio di errore specifico.

Browser	Limite di redirect	Messaggio di errore
Chrome	20	`ERR_TOO_MANY_REDIRECTS`
Firefox	20	"La pagina non reindirizza in modo corretto"
Safari	16	"Safari non è in grado di aprire la pagina"
Edge	20	`ERR_TOO_MANY_REDIRECTS`

Il browser non fa distinzione tra un loop (ciclo) e una catena molto lunga (sequenza lineare). In entrambi i casi, se il limite viene raggiunto, la visualizzazione si blocca. La differenza è che una catena lunga finirà per arrivare a destinazione se si aumenta il limite, mentre un loop non terminerà mai.

Dal punto di vista di Googlebot, un loop è fatale per l'indicizzazione. Google rileva il ciclo, segna la pagina come inaccessibile e i backlink che puntano a essa perdono tutto il valore SEO.

Anatomia di un loop: il ciclo HTTP in dettaglio

Ecco il dettaglio di un loop a tre elementi a livello di rete.

1. GET https://captaindns.com/page-a
   → 301, Location: https://captaindns.com/page-b

2. GET https://captaindns.com/page-b
   → 302, Location: https://captaindns.com/page-c

3. GET https://captaindns.com/page-c
   → 301, Location: https://captaindns.com/page-a

4. GET https://captaindns.com/page-a   (ritorno al punto di partenza)
   → 301, Location: https://captaindns.com/page-b

... (il ciclo si ripete)

Ogni iterazione consuma una richiesta di rete. Chrome e Firefox interrompono dopo 20 richieste, cioè da 6 a 7 giri completi in un loop a 3 elementi. L'header Location è il filo conduttore: seguendolo è come gli strumenti di diagnosi ricostruiscono la catena e rilevano il punto di ritorno.

Schema di un loop di redirect a 3 elementi che mostra il ciclo A verso B verso C verso A con il numero di richieste prima dell'errore del browser

Le 7 cause più frequenti di ERR_TOO_MANY_REDIRECTS

I loop di redirect non sono quasi mai intenzionali. Derivano da conflitti tra più componenti che tentano ciascuno di forzare un redirect. Ecco le 7 cause più comuni, classificate per frequenza di comparsa.

1. Conflitto HTTP/HTTPS tra CMS e server

Sintomo: il sito mostra ERR_TOO_MANY_REDIRECTS dalla home page.

Meccanismo: il CMS (WordPress, Joomla) è configurato per forzare HTTPS nelle sue impostazioni interne. Contemporaneamente, il file .htaccess o la configurazione Nginx contiene una regola che reindirizza HTTP a HTTPS. Quando il CMS reindirizza a HTTPS e il server reindirizza quella richiesta a HTTP (o viceversa a causa di un proxy intermedio), si crea un loop.

Diagnosi: verifica l'URL del sito nelle impostazioni del CMS (siteurl e home in WordPress). Confronta con le regole di redirect del server web. Se entrambi forzano il protocollo in direzioni opposte, hai trovato la fonte.

Correzione: scegli un unico punto di controllo per il redirect HTTP a HTTPS. La buona pratica è gestire questo redirect a livello del server web (Nginx, Apache) o del reverse proxy, e configurare il CMS per usare HTTPS nel suo URL senza forzare il redirect autonomamente.

2. Redirect www/non-www circolare

Sintomo: ERR_TOO_MANY_REDIRECTS solo sulla variante www o non-www del dominio.

Meccanismo: il DNS punta www.captaindns.com al server A e captaindns.com al server B. Il server A reindirizza alla versione non-www, il server B reindirizza alla versione www. Il browser rimbalza indefinitamente tra i due.

Diagnosi: testa entrambe le varianti separatamente con curl -I http://www.captaindns.com e curl -I http://captaindns.com. Se ciascuna reindirizza all'altra, il loop è confermato.

Correzione: allinea la configurazione di entrambi i server su una sola versione canonica. Se scegli captaindns.com come versione canonica, configura www.captaindns.com per reindirizzare con 301 a captaindns.com, e assicurati che captaindns.com non reindirizzi a www.

3. Plugin di cache o di sicurezza WordPress

Sintomo: ERR_TOO_MANY_REDIRECTS dopo l'installazione o l'aggiornamento di un plugin.

Meccanismo: alcuni plugin di sicurezza (Really Simple SSL, Wordfence) o di cache (W3 Total Cache, WP Super Cache) aggiungono le proprie regole di redirect nel .htaccess o tramite filtri PHP. Queste regole possono entrare in conflitto con i redirect esistenti del tema, del CMS o del server.

Diagnosi: disattiva i plugin uno alla volta via FTP (rinomina la cartella del plugin in wp-content/plugins/). Quando il sito torna accessibile, l'ultimo plugin disattivato è il colpevole.

Correzione: riattiva il plugin e regola i suoi parametri per evitare il conflitto. Se il plugin forza HTTPS e il tuo server lo fa già, disattiva la funzionalità nel plugin. Se il plugin aggiunge regole .htaccess, verifica che non duplichino le regole esistenti.

4. Cloudflare Flexible SSL combinato con HTTPS forzato sul server

Sintomo: ERR_TOO_MANY_REDIRECTS dopo l'attivazione di Cloudflare.

Meccanismo: la modalità "Flexible SSL" di Cloudflare significa che la connessione tra il visitatore e Cloudflare è HTTPS, ma la connessione tra Cloudflare e il tuo server è HTTP. Se il tuo server è configurato per reindirizzare HTTP a HTTPS, reindirizza la richiesta di Cloudflare a HTTPS. Cloudflare riceve questo redirect, ma reinvia la richiesta in HTTP (modalità Flexible). Il server reindirizza di nuovo a HTTPS, e così via.

Diagnosi: verifica la modalità SSL/TLS nella dashboard di Cloudflare. Se è "Flexible" e il tuo server forza HTTPS, hai trovato la causa.

Correzione: passa la modalità SSL/TLS di Cloudflare a "Full" o "Full (Strict)". Con la modalità Full, Cloudflare comunica in HTTPS con il tuo server, eliminando il conflitto. Assicurati che il tuo server abbia un certificato TLS valido (Let's Encrypt è sufficiente).

Sintomo: ERR_TOO_MANY_REDIRECTS solo per certi utenti, o solo in modalità connessa.

Meccanismo: l'applicazione reindirizza gli utenti non connessi alla pagina di login. La pagina di login verifica un cookie di sessione, rileva che l'utente non è connesso (cookie corrotto, scaduto o mal formattato) e reindirizza alla pagina di login stessa. Oppure, dopo il login, l'applicazione reindirizza a una pagina protetta che non riconosce il cookie e rimanda al login.

Diagnosi: testa il sito in navigazione privata (senza cookie). Se il problema scompare, i cookie sono la causa. Chiedi all'utente interessato di cancellare i cookie per il dominio.

Correzione: se il problema è generalizzato, verifica la configurazione dei cookie di sessione (dominio, percorso, attributo Secure, attributo SameSite). Un cookie con Secure=true non verrà inviato su una connessione HTTP. Un cookie con un dominio errato (.www.captaindns.com invece di .captaindns.com) non verrà letto sulla variante senza www.

6. File .htaccess con regole in conflitto

Sintomo: ERR_TOO_MANY_REDIRECTS su un server Apache, spesso dopo una modifica manuale del .htaccess.

Meccanismo: il file .htaccess contiene più blocchi RewriteRule che si contraddicono. Per esempio, una regola reindirizza /page a /page/, e un'altra reindirizza /page/ a /page. Oppure una regola generica (catch-all) cattura URL che dovevano essere esclusi da una regola precedente, ma l'ordine delle regole è sbagliato.

Diagnosi: esamina il file .htaccess alla radice del sito e in tutte le sottodirectory. Cerca i blocchi RewriteRule che puntano a pattern simili.

Correzione: semplifica il .htaccess. Raggruppa tutti i redirect in un solo blocco, ordinali dal più specifico al più generico e aggiungi il flag [L] (last) alle regole terminali.

Esempio di .htaccess pulito che gestisce HTTP a HTTPS e www a non-www senza conflitto:

RewriteEngine On
# Forza HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
# Forza non-www
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

L'ordine è importante: prima forzare HTTPS, poi gestire il www. Il flag [L] garantisce che ogni regola è terminale: una volta attivata, Apache non prosegue con le regole successive.

7. CDN o reverse proxy mal configurato

Sintomo: ERR_TOO_MANY_REDIRECTS dopo l'implementazione di un CDN (Cloudflare, Fastly, AWS CloudFront) o di un reverse proxy (Nginx, HAProxy).

Meccanismo: il CDN o il reverse proxy modifica gli header della richiesta (protocollo, host, percorso) prima di trasmetterla al server di origine. Il server di origine prende una decisione di redirect basata su questi header modificati e restituisce una risposta che innesca un nuovo redirect a livello del CDN. Il ciclo si ripete.

Il caso classico: il CDN termina la connessione TLS e trasmette la richiesta in HTTP al server di origine. Il server vede HTTP e reindirizza a HTTPS. Il CDN intercetta questo redirect, ma invia di nuovo in HTTP.

Diagnosi: testa il sito bypassando il CDN (accedi direttamente all'IP del server). Se il sito funziona senza CDN ma non con esso, il problema è nella configurazione del proxy.

Correzione: configura il server di origine per riconoscere gli header di proxy (X-Forwarded-Proto). Su Nginx, usa $http_x_forwarded_proto al posto di $scheme. Su Apache, verifica %{HTTP:X-Forwarded-Proto} nei RewriteCond.

Esempio Nginx con supporto proxy:

server {
    listen 80;
    server_name captaindns.com;

    # Reindirizza a HTTPS solo se la richiesta non arriva già via HTTPS dal CDN
    if ($http_x_forwarded_proto != "https") {
        return 301 https://$server_name$request_uri;
    }
}

Come diagnosticare un loop di redirect?

Una volta che sai che un loop esiste (il browser mostra l'errore), bisogna localizzarlo con precisione. Tre metodi complementari permettono di ricostruire la catena di redirect e identificare il punto di ritorno.

Metodo 1: il Redirect Checker di CaptainDNS

Il metodo più rapido. Inserisci l'URL nel Redirect Checker e avvia l'analisi. Lo strumento segue ogni redirect, registra il codice HTTP, l'URL di destinazione, gli header di risposta e il tempo di risposta di ogni hop. Quando rileva che un URL appare due volte nella catena, segnala il loop e indica esattamente a quale hop inizia.

Il vantaggio: lo strumento segue fino a 30 hop (contro 20 dei browser), il che permette di rilevare loop lunghi. Mostra anche gli header HTTP completi, essenziali per diagnosticare conflitti di protocollo e problemi di X-Forwarded-Proto.

Metodo 2: curl da riga di comando

Per gli amministratori che preferiscono il terminale, curl con l'opzione -v (verbose) e -L (follow redirects) mostra ogni passo della catena:

curl -v -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -E "^(< HTTP|< Location|> GET)"

Questo comando mostra il codice HTTP e l'header Location di ogni risposta, nonché la richiesta GET inviata a ogni passo. Quando l'URL della richiesta GET corrisponde a un URL già visto più in alto nell'output, hai trovato il loop.

L'opzione --max-redirs 25 aumenta il limite predefinito di curl (50) a un livello sufficiente per rilevare la maggior parte dei loop senza generare un output troppo lungo.

Per un output più conciso, limitati agli header:

curl -sI -L --max-redirs 25 https://captaindns.com/page-a 2>&1 | grep -iE "^(HTTP/|Location:)"

Metodo 3: i DevTools del browser

Apri gli strumenti di sviluppo (F12), vai nella scheda "Network" (Rete) e carica l'URL problematico. Il browser mostra ogni richiesta HTTP in ordine cronologico. Vedrai una serie di richieste con codici 301 o 302, ciascuna con un URL diverso, fino a quando il browser raggiunge il suo limite e mostra l'errore.

Il vantaggio dei DevTools: mostrano i cookie inviati e ricevuti a ogni richiesta, indispensabile per diagnosticare i loop di autenticazione (causa 5). Il limite: il browser mostra solo le prime 20 richieste (16 su Safari).

Tabella comparativa dei tre metodi

Criterio	Redirect Checker	curl	DevTools
Facilità d'uso	Alta (interfaccia web)	Media (terminale)	Media (browser)
Numero massimo di hop	30	Configurabile	Da 16 a 20
Rilevamento automatico del loop	Sì	No (analisi manuale)	No (analisi manuale)
Visualizzazione dei cookie	No	Sì (con `-v`)	Sì
Visualizzazione dei tempi di risposta	Sì (per hop)	Sì (con `-w`)	Sì
Richiede installazione	No	Sì (presente su Linux/macOS)	No
Condivisione dei risultati	Sì (URL del report)	No	No (screenshot)

Per una diagnosi rapida, inizia con il Redirect Checker. Completa con i DevTools se il problema coinvolge cookie, o con curl per l'automazione in pipeline CI/CD.

Le catene di redirect: impatto SEO e prestazioni

Una catena di redirect è una sequenza lineare di redirect successivi. A differenza del loop, la catena porta a una pagina di contenuto, ma passa attraverso uno o più URL intermedi prima di arrivarci. Il problema non è l'inaccessibilità (la pagina finisce per caricarsi), ma il degrado progressivo del SEO e delle prestazioni.

Quanti hop prima che diventi un problema?

Un singolo hop di redirect è perfettamente normale. È il caso standard di un vecchio link che reindirizza al nuovo URL. Il problema inizia quando gli hop si accumulano.

Numero di hop	Valutazione	Impatto
1	Normale	Nessun impatto misurabile
2	Accettabile	Impatto minimo, nessuna azione necessaria
3	Avvertimento	Latenza percepibile, possibile diluizione SEO
Da 4 a 5	Problema	Da 400 a 2500 ms di latenza aggiunta, perdita SEO probabile
6 o più	Critico	Google può abbandonare il tracciamento, pagina potenzialmente non indicizzata

Google segue ufficialmente fino a 10 redirect in una catena. Tuttavia, John Mueller del team Google Search ha precisato che il trasferimento di segnale SEO può degradarsi ben prima di raggiungere questo limite. La raccomandazione pratica è non superare mai 2 hop tra l'URL sorgente e la destinazione finale.

Impatto SEO: diluizione del PageRank e perdita di indicizzazione

Ogni redirect intermedio in una catena crea un'opportunità di perdita di segnale SEO. Anche se Google afferma che un redirect 301 unico trasferisce il 100% del PageRank, il comportamento con catene multiple è meno documentato e meno affidabile.

Il problema concreto: quando Googlebot incontra una catena di 5 redirect, esegue 6 richieste HTTP. Ciascuna consuma crawl budget. Per i siti voluminosi con migliaia di catene, Google passa tempo a seguire redirect invece di scansionare contenuto nuovo.

Inoltre, se un redirect intermedio è una 302 invece di una 301, il trasferimento di PageRank si interrompe a quel punto. Una sola 302 in una catena di 301 basta per bloccare il trasferimento di autorità.

Impatto sulle prestazioni: la latenza si somma

Ogni hop di redirect aggiunge un viaggio di andata e ritorno completo tra il browser e il server. In pratica, questo rappresenta da 100 a 500 ms per hop, a seconda della latenza di rete e della posizione geografica del visitatore.

Per un visitatore in Europa che accede a un server in Nord America, ogni hop aggiunge da 150 a 200 ms. Una catena di 4 hop aggiunge da 600 a 800 ms prima che il contenuto inizi a caricarsi.

Questo impatto si concentra sul LCP (Largest Contentful Paint), la metrica Core Web Vitals che misura il tempo di visualizzazione del contenuto principale. Un LCP superiore a 2,5 secondi è classificato come "scarso" da Google. Se la tua pagina carica normalmente in 1,8 secondi ma una catena di 3 redirect aggiunge 600 ms, passi nella zona rossa.

Buona notizia: i redirect 301 memorizzati nella cache dal browser non hanno più impatto dopo la prima visita. È un argomento in più per preferire le 301 alle 302 nelle catene.

Come si formano le catene: il caso della migrazione in più fasi

Le catene di redirect raramente vengono create intenzionalmente. Si accumulano nel tempo, a ogni migrazione, riprogettazione o cambiamento di struttura.

Scenario tipico:

2022: il sito è su http://captaindns.com. Passaggio a HTTPS. Redirect 301 da http:// a https://.
2023: riprogettazione del sito. Cambio di struttura degli URL. Redirect 301 da /tools/dns-check a /it/tools/dns/test-propagation.
2025: consolidamento del sottodominio. Redirect 301 da https://outils.captaindns.com/dns-check a https://captaindns.com/tools/dns-check.

Un backlink pubblicato nel 2022 che punta a http://outils.captaindns.com/dns-check attraversa ora 3 redirect:

http://outils.captaindns.com/dns-check
→ 301 → https://outils.captaindns.com/dns-check
→ 301 → https://captaindns.com/tools/dns-check
→ 301 → https://captaindns.com/it/tools/dns/test-propagation

Ogni migrazione individuale era corretta. Ma l'accumulo crea una catena di 3 hop che consuma crawl budget e aggiunge latenza.

La soluzione: dopo ogni migrazione, aggiorna i vecchi redirect per puntare direttamente alla destinazione finale. In questo esempio, il primo redirect dovrebbe essere aggiornato a https://captaindns.com/it/tools/dns/test-propagation, eliminando i due intermediari.

Schema che mostra una catena di 4 redirect con la latenza cumulata e la correzione verso un solo hop diretto

Come rilevare le catene sul tuo sito?

Il metodo più efficace è testare i tuoi URL critici (pagine a traffico elevato, pagine con più backlink) con il Redirect Checker. Lo strumento indica il numero di hop per ogni URL e segnala le catene di più di 2 hop.

Per un audit su larga scala, esporta la lista dei tuoi URL da Google Search Console (rapporto "Pagine") e testali a lotti. Dai priorità agli URL con più traffico organico e più backlink.

Puoi anche usare il Page Crawl Checker per analizzare le catene di redirect nel contesto di una scansione completa della pagina, incluse le risorse caricate (CSS, JavaScript, immagini) che possono anch'esse attraversare catene.

Link abbreviati: dove portano davvero?

I servizi di abbreviazione URL (bit.ly, t.co, tinyurl.com, ow.ly, goo.gl) sostituiscono un URL lungo con un URL breve che reindirizza alla destinazione. Questa operazione è trasparente per l'utente legittimo: clicca, il servizio reindirizza, la pagina si carica. Ma questa trasparenza è anche un importante vettore di attacco.

Il problema di sicurezza dei link abbreviati

Un link abbreviato nasconde completamente la destinazione. L'utente non può sapere, prima di cliccare, se il link porta a un documento Google legittimo o a un sito di phishing che imita la pagina di accesso della sua banca.

Gli aggressori sfruttano questa opacità in modo sistematico. Un'email di phishing contenente https://bit.ly/3xYz123 è molto più difficile da rilevare di un'email contenente un URL sospetto in chiaro. I filtri anti-phishing faticano ad analizzare i link abbreviati, perché il dominio visibile (bit.ly) è legittimo. È la destinazione finale che è malevola.

Secondo le ricerche di Palo Alto Networks (Unit 42), oltre il 70% dei domini malevoli sono registrati da meno di 32 giorni (Newly Registered Domains). I link abbreviati sono il vettore principale per distribuire questi domini recenti.

Tecniche di offuscamento avanzate

Gli aggressori non si limitano ad abbreviare un link malevolo. Combinano più tecniche per rendere il rilevamento ancora più difficile.

Catena di abbreviatori: un link bit.ly reindirizza a tinyurl, che reindirizza a ow.ly, che porta al sito di phishing. Ogni livello aggiunge una barriera per gli strumenti di rilevamento. Il Redirect Checker segue la catena completa e rivela la destinazione finale.

Redirect condizionali: il servizio reindirizza a un sito diverso a seconda del paese, del browser o del momento della giornata. I visitatori bersaglio vedono la pagina di phishing, gli altri vengono reindirizzati a un sito legittimo.

Domini scaduti riutilizzati: l'aggressore acquista un dominio che aveva buona reputazione, vi installa contenuto malevolo e poi distribuisce link abbreviati verso quel dominio. La reputazione storica inganna i filtri di sicurezza.

Come il Redirect Checker smaschera i link abbreviati

Quando inserisci un link abbreviato nel Redirect Checker, lo strumento segue ogni redirect fino alla destinazione finale, registrando il codice HTTP, l'URL di destinazione, gli header e il tempo di risposta di ogni hop. Segnala automaticamente diversi indicatori di rischio:

Domini registrati di recente (NRD): se la destinazione finale è un dominio registrato da meno di 30 giorni, lo strumento emette un avvertimento. I domini NRD sono statisticamente molto più propensi a essere malevoli rispetto ai domini consolidati.

Numero eccessivo di redirect: un link legittimo abbreviato implica generalmente 1 o 2 redirect (dall'abbreviatore alla destinazione). Se la catena contiene 4 redirect o più, è un segnale di allarme.

Cambio di protocollo sospetto: se un redirect nella catena passa da HTTPS a HTTP, è un indicatore di rischio. I siti legittimi usano HTTPS. Un ritorno a HTTP nel mezzo della catena può indicare un tentativo di downgrade per intercettare il traffico.

Omografi IDN: quando il dominio sembra un altro

Gli attacchi per omografo IDN (Internationalized Domain Name) sfruttano caratteri Unicode che somigliano visivamente a lettere latine. Per esempio, il carattere cirillico "a" (U+0430) è visivamente identico alla "a" latina (U+0061), ma si tratta di un carattere diverso.

Un aggressore può registrare cаptaindns.com (con una "a" cirillica) che appare esattamente uguale a captaindns.com nella barra degli indirizzi. Dietro un link abbreviato, questa differenza è totalmente invisibile.

Il Redirect Checker mostra l'URL di destinazione in ASCII Punycode quando contiene caratteri IDN. L'URL cаptaindns.com appare allora nella sua forma tecnica xn--cptaindns-r6a.com, rivelando immediatamente che non è il dominio atteso.

Per proteggere il tuo marchio, verifica regolarmente che le varianti omografe del tuo dominio non siano registrate da terzi. Il Phishing URL Checker analizza specificamente i rischi di omografia e typosquatting sugli URL che gli sottoponi.

Come correggere i problemi di redirect?

La diagnosi è fatta, il problema è identificato. Ecco i passi di correzione per ogni tipo di problema.

Correggere un loop di redirect

Passo 1: identificare il punto di ingresso e il punto di ritorno. Usa il Redirect Checker per ricostruire la catena completa. Annota a quale hop l'URL riappare.

Passo 2: identificare il componente responsabile del ritorno. È il server, il CDN, il CMS o il plugin che genera il redirect verso l'URL già visto. Consulta la sezione "Le 7 cause" qui sopra per identificare il pattern.

Passo 3: spezzare il ciclo. Modifica la configurazione del componente responsabile affinché non generi più il redirect circolare. Nella maggior parte dei casi, questo significa eliminare o modificare una regola di redirect in uno dei componenti coinvolti.

Passo 4: testare immediatamente. Dopo la correzione, svuota la cache del browser (i 301 possono essere in cache) e testa con il Redirect Checker. Verifica che la catena termini con un codice 200 e non con un ciclo.

Esempio concreto: loop tra Cloudflare (Flexible SSL) e un server Apache che forza HTTPS.

Prima della correzione:
https://captaindns.com → Cloudflare (HTTP verso server) → Apache (reindirizza a HTTPS)
→ Cloudflare (HTTP verso server) → Apache (reindirizza a HTTPS) → loop

Correzione: passare Cloudflare in modalità "Full (Strict)"

Dopo la correzione:
https://captaindns.com → Cloudflare (HTTPS verso server) → Apache (nessun redirect, codice 200)

Correggere una catena di redirect

Principio: accorciare la catena a un solo hop. Ogni URL sorgente deve puntare direttamente alla destinazione finale, senza intermediari.

Passo 1: elencare tutti i redirect della catena. Usa il Redirect Checker per ottenere la sequenza completa.

Passo 2: identificare la destinazione finale. È l'ultimo URL della catena, quello che restituisce un codice 200.

Passo 3: aggiornare ogni redirect intermedio. Modifica la configurazione di ogni server o servizio coinvolto affinché gli URL intermedi reindirizzino direttamente alla destinazione finale.

Esempio:

Prima della correzione:
http://captaindns.com/old-page
→ 301 → https://captaindns.com/old-page
→ 301 → https://captaindns.com/it/old-page
→ 301 → https://captaindns.com/it/tools/new-page

Dopo la correzione:
http://captaindns.com/old-page → 301 → https://captaindns.com/it/tools/new-page
https://captaindns.com/old-page → 301 → https://captaindns.com/it/tools/new-page
https://captaindns.com/it/old-page → 301 → https://captaindns.com/it/tools/new-page

Ogni URL sorgente punta ora direttamente alla destinazione finale in un solo hop. Il browser e Googlebot hanno un solo redirect da seguire.

Verifica post-correzione

Dopo ogni correzione, testa sistematicamente con il Redirect Checker:

Verifica che la catena termini con un codice 200.
Verifica che il numero di hop sia inferiore o uguale a 2.
Verifica che tutti i redirect intermedi usino il codice 301 (salvo caso specifico di redirect temporaneo).
Verifica che il protocollo finale sia HTTPS.
Testa le 4 varianti dell'URL: http://, https://, http://www., https://www..

Se hai corretto più catene, attendi da 48 a 72 ore, poi verifica in Google Search Console che gli errori di redirect siano scomparsi dal rapporto "Pagine".

Buone pratiche per evitare problemi futuri

Usare un unico punto di controllo per i redirect. Non configurare lo stesso redirect in due posti diversi (server web e CDN, CMS e .htaccess). Scegli un solo componente per gestire ogni tipo di redirect.

Usare sempre 301 per i redirect permanenti. Le 302 non trasferiscono il PageRank e non vengono memorizzate nella cache dal browser. Salvo caso specifico (redirect condizionale, test A/B), la 301 è la scelta predefinita.

Aggiornare i vecchi redirect dopo ogni migrazione. Non lasciare che le catene si accumulino. Dopo ogni cambio di struttura degli URL, rivedi i vecchi redirect e aggiornali per puntare direttamente alla destinazione finale.

Documentare tutti i redirect attivi. Mantieni una tabella riepilogativa di tutte le regole di redirect attive, con l'origine, la destinazione, il codice HTTP e la data di creazione. Questa tabella è indispensabile per evitare conflitti nelle modifiche future.

Testare prima di mettere in produzione. Prima di mettere in produzione una nuova regola di redirect, testala in un ambiente di staging o con curl -I. Verifica che il redirect funzioni e che non crei conflitto con le regole esistenti.

Piano d'azione raccomandato

Ecco una checklist in 5 passi per verificare e correggere i problemi di redirect sul tuo sito.

Passo 1: scansionare gli URL critici

Identifica i tuoi 20-50 URL più importanti: home page, pagine prodotto, articoli del blog ad alto traffico, pagine di conversione. Testa ciascuno con il Redirect Checker.

Per ogni URL, annota:

Il numero di hop
La presenza eventuale di un loop
Il codice HTTP della destinazione finale (deve essere 200)
Il protocollo della destinazione finale (deve essere HTTPS)

Passo 2: identificare loop e catene di più di 3 hop

Tra gli URL testati, isola quelli che presentano un problema:

Loop rilevato: priorità massima, la pagina è inaccessibile
5 hop o più: priorità alta, impatto SEO e prestazioni significativo
Da 3 a 4 hop: priorità media, da correggere nel prossimo ciclo di manutenzione
Da 1 a 2 hop: nessuna azione necessaria

Passo 3: correggere le configurazioni del server

Per ogni problema identificato, applica la correzione appropriata:

Loop: identifica il componente responsabile (vedi le 7 cause) e spezza il ciclo
Catena: aggiorna ogni redirect intermedio per puntare alla destinazione finale
Conflitto CDN/server: allinea la configurazione SSL/TLS tra il CDN e il server di origine
Conflitto .htaccess: semplifica le regole, aggiungi i flag [L], ordina dalla più specifica alla più generica

Passa in rassegna i link abbreviati presenti nei tuoi template di newsletter, nelle tue firme email e nelle tue campagne marketing attive. Per ogni link abbreviato:

Testa la destinazione con il Redirect Checker
Verifica che la destinazione sia il tuo sito (e non un dominio terzo)
Sostituisci i link abbreviati con link diretti quando possibile
Se il link abbreviato è necessario (tracking, QR code), verifica che la catena non superi 2 hop

Passo 5: testare di nuovo dopo la correzione

Dopo ogni correzione, torna sugli URL corretti e verifica che:

Il loop sia risolto (codice 200 a fine catena)
La catena sia accorciata (2 hop al massimo)
Le 4 varianti dell'URL (HTTP/HTTPS, www/non-www) funzionino correttamente
Non sia stato introdotto nessun nuovo problema

Pianifica un audit di follow-up a 30 giorni per verificare che le correzioni tengano e che non si sia formata nessuna nuova catena.

Casi pratici: diagnosi comuni e soluzioni

Caso 1: sito WordPress inaccessibile dopo l'attivazione di Really Simple SSL

Sintomo: ERR_TOO_MANY_REDIRECTS immediatamente dopo l'attivazione del plugin.

Diagnosi con il Redirect Checker:

Hop 1: https://captaindns.com → 301 → http://captaindns.com (il plugin forza HTTP?)
Hop 2: http://captaindns.com → 301 → https://captaindns.com (il server forza HTTPS)
Hop 3: https://captaindns.com → 301 → http://captaindns.com
→ Loop rilevato all'hop 3

Causa: il file wp-config.php contiene define('FORCE_SSL_ADMIN', false) oppure l'URL del sito nel database è in HTTP, in conflitto con il plugin che tenta di forzare HTTPS.

Soluzione: disattiva il plugin via FTP (rinomina la sua cartella), aggiorna le opzioni siteurl e home in wp_options per usare HTTPS, aggiungi define('FORCE_SSL_ADMIN', true) in wp-config.php, poi riattiva il plugin.

Caso 2: link abbreviato in un'email che porta a un sito di phishing

Sintomo: un dipendente riceve un'email con un link https://bit.ly/3Ab4Cd5 che dichiara di portare a un documento condiviso.

Diagnosi con il Redirect Checker:

Hop 1: https://bit.ly/3Ab4Cd5 → 301 → https://tinyurl.com/y7x8z9
Hop 2: https://tinyurl.com/y7x8z9 → 301 → https://docs-google-verification.com/login
→ Destinazione finale: https://docs-google-verification.com/login
→ ALLARME: dominio registrato 3 giorni fa (NRD)
→ ALLARME: il dominio imita "docs.google.com" (omografia potenziale)

Indicatori di rischio: due abbreviatori in catena (tecnica di offuscamento), dominio di destinazione registrato da 3 giorni (NRD), nome di dominio che imita un servizio legittimo (Google Docs), URL che contiene "/login" (tentativo di furto di credenziali).

Azione: non cliccare. Segnalare l'email come phishing. Avvisare il team di sicurezza. Se il link è stato cliccato, cambiare immediatamente la password del servizio imitato e attivare l'autenticazione a due fattori.

Redirect e sicurezza: gli attacchi basati sui redirect

I redirect non sono solo un problema di configurazione. Sono anche un vettore di attacco sfruttato attivamente dai criminali informatici.

Open redirect: quando il tuo stesso sito diventa un vettore di attacco

Una vulnerabilità "open redirect" esiste quando il tuo sito accetta un parametro URL che controlla la destinazione di un redirect senza validare quel parametro. Esempio: https://captaindns.com/login?redirect=https://sito-malevolo.com. Se la tua applicazione reindirizza ciecamente al valore del parametro redirect, un aggressore può usare il tuo dominio legittimo come primo passo di una catena di phishing.

Protezione: valida sempre gli URL di redirect lato server. Accetta solo i redirect verso il tuo dominio o verso una lista bianca di domini autorizzati.

Attacco tramite catena di redirect

Un aggressore può sfruttare redirect legittimi per costruire catene che aggirano i filtri di sicurezza. La catena tipica: un'email contiene un link a un abbreviatore legittimo (bit.ly), l'abbreviatore reindirizza a un sito affidabile che ha una falla open redirect, l'open redirect invia al sito di phishing. Ogni passaggio supera i filtri individualmente. È la combinazione che è malevola. Solo uno strumento che segue la catena completa fino alla destinazione finale può rilevare l'attacco.

Buone pratiche di sicurezza per i redirect

Mai cliccare su un link abbreviato senza verificarlo. Usa il Redirect Checker per rivelare la destinazione prima di cliccare.
Verificare il proprio sito per gli open redirect. Cerca tutti gli endpoint che accettano un parametro URL come destinazione di redirect.
Verificare i domini NRD nelle email. Un dominio di meno di 30 giorni in un link email è un forte segnale di allarme.
Sensibilizzare i team. I link abbreviati nelle email interne dovrebbero sempre essere accompagnati dall'URL completo di destinazione in testo chiaro.

FAQ

Che cosa significa ERR_TOO_MANY_REDIRECTS?

Questo messaggio di errore significa che il browser ha raggiunto il suo limite di redirect successivi (20 per Chrome e Firefox, 16 per Safari) senza raggiungere una pagina di contenuto. La causa è un loop di redirect (due o più URL che si reindirizzano a vicenda) o una catena di redirect eccessivamente lunga. Per identificare la causa esatta, testa l'URL con il Redirect Checker, che segue la catena completa e segnala automaticamente i loop.

Come correggere un loop di redirect su WordPress?

I loop su WordPress sono generalmente causati da un conflitto tra un plugin (Really Simple SSL, Wordfence, W3 Total Cache) e la configurazione del server. La correzione in 4 passi: 1) disattiva i plugin uno alla volta via FTP (rinomina la cartella in wp-content/plugins/) per identificare il colpevole; 2) verifica che gli URL siteurl e home nella tabella wp_options usino il protocollo corretto (HTTPS); 3) pulisci il file .htaccess dalle regole di redirect duplicate; 4) riattiva il plugin e regola i suoi parametri per non duplicare i redirect del server.

Quanti redirect può seguire Google?

Google segue ufficialmente fino a 10 redirect in una catena. Oltre, Googlebot abbandona e la pagina finale non viene scansionata né indicizzata. In pratica, John Mueller raccomanda di non superare mai 2 hop. Ogni redirect consuma crawl budget e può diluire il segnale SEO, specialmente se una 302 si inserisce in una catena di 301.

I link abbreviati sono pericolosi?

I link abbreviati non sono intrinsecamente pericolosi, ma nascondono la destinazione reale, il che li rende un vettore privilegiato per il phishing e la distribuzione di malware. Secondo le ricerche di Palo Alto Networks, oltre il 70% dei domini malevoli sono registrati da meno di 32 giorni, e i link abbreviati sono il mezzo principale per distribuire questi domini via email. La buona pratica è verificare sempre la destinazione di un link abbreviato prima di cliccare, usando uno strumento che segua la catena di redirect fino alla fine.

Come sapere dove porta un link bit.ly?

Esistono diversi metodi. Il più affidabile è usare il Redirect Checker di CaptainDNS: inserisci il link bit.ly e lo strumento segue tutti i redirect fino alla destinazione finale, mostrando ogni hop intermedio. Puoi anche aggiungere un "+" alla fine dell'URL bit.ly (per esempio https://bit.ly/3xYz123+) per accedere alla pagina delle statistiche di bit.ly che mostra la destinazione, ma questo metodo non funziona con tutti gli abbreviatori e non segue i redirect multipli.

Qual è la differenza tra un loop e una catena di redirect?

Un loop è un ciclo: l'URL A reindirizza a B, che reindirizza a C, che reindirizza di nuovo ad A. Il browser gira in tondo e non raggiunge mai una pagina di contenuto. Il risultato è un errore ERR_TOO_MANY_REDIRECTS. Una catena è una sequenza lineare: A reindirizza a B, che reindirizza a C, che restituisce un codice 200 (pagina di contenuto). La catena arriva a destinazione, ma ogni hop intermedio aggiunge latenza e può diluire il segnale SEO. I loop sono bloccanti (la pagina è inaccessibile), le catene sono degradanti (la pagina si carica, ma peggio).

Il Redirect Checker funziona con i link abbreviati?

Sì. Il Redirect Checker segue tutti i redirect HTTP, qualunque sia il dominio sorgente. Quando inserisci un link bit.ly, tinyurl.com, t.co o qualsiasi altro abbreviatore, lo strumento segue la catena completa fino alla destinazione finale. Mostra ogni hop intermedio con il codice HTTP, l'URL di destinazione e il tempo di risposta. Segnala anche i domini registrati di recente (NRD) e le catene anormalmente lunghe che possono indicare un tentativo di offuscamento.

Come rilevare un link di phishing nascosto?

Diversi indizi permettono di rilevare un link di phishing dietro un abbreviatore. Verifica la destinazione con il Redirect Checker e cerca questi segnali di allarme: 1) il dominio di destinazione è registrato da meno di 30 giorni (NRD); 2) la catena contiene più di 2 redirect (tecnica di offuscamento); 3) il dominio imita un servizio noto (omografo IDN o typosquatting); 4) l'URL finale contiene parole come "login", "verify", "secure" o "update"; 5) il protocollo passa da HTTPS a HTTP nel corso della catena. La presenza di 2 o più di questi indicatori suggerisce fortemente un link malevolo.

I redirect meta refresh creano loop?

Sì, i redirect meta refresh possono creare loop esattamente come i redirect HTTP. La pagina A contiene un tag <meta http-equiv="refresh"> che reindirizza alla pagina B, e la pagina B contiene un tag simile che reindirizza ad A. La differenza è che i meta refresh sono più lenti (il browser deve scaricare e analizzare l'HTML prima di reindirizzare) e più difficili da diagnosticare perché non sono visibili negli header HTTP. Gli strumenti da riga di comando come curl non li rilevano senza un'opzione specifica.

Come evitare che le catene di redirect si accumulino nel tempo?

La migliore pratica è aggiornare i vecchi redirect dopo ogni migrazione. Quando aggiungi un nuovo livello di redirect (cambio di dominio, cambio di struttura degli URL, passaggio a HTTPS), rivedi i redirect precedenti e aggiornali per puntare direttamente alla destinazione finale. Documenta tutti i redirect attivi in una tabella centralizzata con l'origine, la destinazione, il codice HTTP e la data. Pianifica un audit trimestrale dei tuoi URL principali con il Redirect Checker per rilevare le catene prima che diventino problematiche.

Glossario

Loop di redirect: ciclo in cui due o più URL si reindirizzano a vicenda. Il browser mostra ERR_TOO_MANY_REDIRECTS dopo 16-20 tentativi.
Catena di redirect: sequenza lineare di redirect successivi. La catena arriva a destinazione, ma degrada il SEO e le prestazioni.
ERR_TOO_MANY_REDIRECTS: messaggio di errore dei browser Chromium quando viene raggiunto il limite di redirect. Equivalente a "La pagina non reindirizza in modo corretto" su Firefox.
NRD (Newly Registered Domain): dominio registrato da meno di 32 giorni. Statisticamente più propenso a essere malevolo.
Omografo IDN: dominio internazionalizzato che utilizza caratteri Unicode visivamente simili a lettere latine per imitare un dominio legittimo.
Meta refresh: tag HTML <meta http-equiv="refresh"> che attiva un redirect lato client. Sconsigliato da Google per il SEO.
Link abbreviato: URL breve (bit.ly, t.co, tinyurl.com) che reindirizza a una destinazione più lunga nascondendo l'URL reale.
Open redirect: vulnerabilità in cui un'applicazione accetta un parametro URL come destinazione di redirect senza validazione, permettendo il phishing.

Fonti

RFC 7231, sezione 6.4: HTTP Redirection: definizione ufficiale dei codici di redirect HTTP 301, 302, 303 e 307
Google Search Central: URL redirections: documentazione ufficiale di Google sul trattamento dei redirect da parte del motore di ricerca
Palo Alto Networks Unit 42: Newly Registered Domains: ricerca sull'utilizzo malevolo dei domini registrati di recente