Come verificare i redirect di un URL (e leggere la catena)

Spesso la pagina su cui arrivi non è quella del link che hai cliccato. Nel mezzo possono esserci il passaggio a HTTPS, un cambio di host, un servizio di tracciamento, un URL shortener e una regola del CMS che aggiunge lo slash finale, e ognuno di essi è una richiesta separata che il browser effettua senza dirti nulla.

Questa guida spiega come vedere questi passaggi con TrueURL, curl e gli strumenti per sviluppatori del browser (DevTools), cosa significa ogni parte di una catena di reindirizzamenti e come risolvere i problemi più comuni.

Che cos’è una catena di redirect

Si ha un reindirizzamento quando un server risponde con un codice di stato 3xx e un’intestazione Location che indica un altro URL. Il client, cioè un browser o un crawler, richiede allora quell’URL e ripete il procedimento finché non riceve una risposta che non è un reindirizzamento.

Ogni richiesta, insieme alla relativa risposta, costituisce un salto (in inglese hop). L’intera sequenza, dal primo URL alla risposta finale, è la catena di reindirizzamenti (redirect chain):

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

Sono tre reindirizzamenti e quattro richieste per raggiungere una sola pagina. L’intestazione Location del salto 3 è relativa: come prescrive la RFC 9110, i client la risolvono rispetto all’URL appena richiesto, quindi equivale a https://www.example.com/shoes/. Idealmente, ognuno di questi indirizzi dovrebbe arrivare all’URL finale con un solo salto.

Una pagina può anche reindirizzare dopo aver risposto 200 OK, con un tag <meta http-equiv="refresh"> o con JavaScript. Anche questi reindirizzamenti lato client fanno parte della catena, ma gli strumenti che leggono solo le intestazioni HTTP, come curl, si fermano a quella pagina.

Perché è importante verificare i redirect

SEO: segnali di canonicalizzazione e crawl budget

I motori di ricerca interpretano un reindirizzamento come un’indicazione su quale URL indicizzare. Google considera i reindirizzamenti permanenti (301 e 308) un segnale forte del fatto che la destinazione debba essere l’URL canonico, e quelli temporanei (302, 303 e 307) un segnale debole. Una pagina spostata in modo definitivo ma con un 302 può quindi continuare a comparire nei risultati di ricerca con il vecchio URL.

Conta anche la lunghezza. Googlebot segue fino a 10 salti di reindirizzamento: se a quel punto non ha ancora ricevuto contenuti, Search Console segnala un errore di reindirizzamento. Anche la guida di Google sul crawl budget (il “budget di scansione”) consiglia di evitare le catene di reindirizzamenti lunghe, che secondo Google hanno un effetto negativo sulla scansione.

Velocità della pagina

La pagina finale non può iniziare a caricarsi finché l’ultimo reindirizzamento non ha ricevuto risposta. Ogni salto costa un round trip di rete, e un salto verso un nuovo host richiede anche una risoluzione DNS, una nuova connessione e, per HTTPS, un handshake TLS. Sulle connessioni mobili, tre o quattro reindirizzamenti possono aggiungere diverse centinaia di millisecondi prima del primo byte della pagina vera e propria. Il Test latenza redirect mostra quanto costa ogni salto.

Sicurezza dei link abbreviati e sconosciuti

I link abbreviati e molti link di tracciamento presenti nelle email nascondono la loro destinazione. Le campagne di phishing sfruttano inoltre gli open redirect di domini noti, per cui un link che parte da un sito affidabile può finire in tutt’altro posto. L’Espansore di link abbreviati ti mostra, prima di cliccare, tutti i domini attraversati e se qualche salto passa da HTTPS a HTTP in chiaro.

Link di affiliazione e di tracciamento

I link di marketing passano spesso per diversi servizi prima di arrivare alla landing page, e ognuno deve inoltrare la query string: altrimenti parametri UTM, click ID e tag di affiliazione vanno persi silenziosamente. L’URL finale mostra se sono arrivati a destinazione e se il link porta ancora alla pagina prevista.

Migrazioni, HTTPS e host canonico

Dopo un restyling, un cambio di dominio o il passaggio a HTTPS, ogni vecchio URL dovrebbe raggiungere il nuovo equivalente con un solo reindirizzamento permanente. Le quattro varianti di base di un sito (http:// e https://, con e senza www) dovrebbero portare tutte allo stesso indirizzo canonico. Queste regole si rompono senza fare rumore: una nuova regola della CDN, l’aggiornamento di un plugin o un cambio di server possono aggiungere un salto o un loop senza che nessuno se ne accorga.

Come verificare un redirect con TrueURL

TrueURL esegue ogni verifica sulla rete edge di Cloudflare, quindi puoi analizzare i link di cui non ti fidi senza aprirli nel browser. Il redirect checker della home page, la Verifica redirect URL, analizza un singolo URL; la Verifica catena di redirect e gli altri strumenti specializzati usano lo stesso motore.

Passaggio 1: inserisci l’URL

Incolla l’URL e avvia la verifica. Se ometti il protocollo, viene usato https://; digita http:// per testare HTTP in chiaro.

Passaggio 2: modifica le Impostazioni avanzate se serve

Per impostazione predefinita lo strumento invia una richiesta GET con lo User-Agent di una versione recente di Chrome desktop, senza cookie e con un limite di 20 reindirizzamenti. Con le Impostazioni avanzate puoi cambiare questi valori:

• Metodo HTTP: GET, HEAD o POST. HEAD è più leggero, ma alcuni server lo gestiscono in modo diverso e, senza il corpo della risposta, i reindirizzamenti lato client non si possono rilevare. POST invia il corpo della richiesta che inserisci, utile per i gestori di moduli e le API. I salti successivi seguono le regole dei browser: dopo un POST, un 301 o un 302 prosegue come GET, un 303 lo fa sempre, mentre 307 e 308 mantengono metodo e corpo.
• Numero massimo di salti: quanti reindirizzamenti seguire, da 1 a 50. Il valore predefinito, 20, è il limite previsto dal Fetch Standard e adottato da Chrome e Firefox. Impostalo su 10 per vedere se una catena rientra nel limite di Googlebot.
• User-Agent personalizzato: se lo lasci vuoto, viene usato Chrome desktop. Tra i profili predefiniti ci sono Safari su iPhone, Chrome su Android, Googlebot (smartphone e desktop), Bingbot, i bot che generano le anteprime dei link di Facebook e X, e curl.
• Intestazioni di richiesta personalizzate: intestazioni aggiuntive inviate a ogni salto, ad esempio Accept-Language: fr-FR per far scattare un reindirizzamento in base alla lingua.
• Cookie: inserisci name=value; other=value per riprodurre uno stato di accesso, di consenso o di regione. I cookie impostati lungo la catena vengono conservati per i salti successivi, come in un browser.
• Reindirizzamenti lato client: scegli se seguire i tag meta refresh e i semplici reindirizzamenti JavaScript o limitarti a segnalarli.
• Ignora errori SSL: la rete edge di Cloudflare convalida sempre i certificati, quindi questa opzione non può aggirare un certificato non valido. Un errore TLS viene segnalato sul salto in cui si è verificato.

Passaggio 3: leggi il risultato

Il risultato si apre con l’URL finale e il relativo codice di stato. Sotto, la catena mostra una riga per ogni salto, con:

• l’URL richiesto e il metodo HTTP usato;
• il codice di stato con la relativa descrizione (la guida di riferimento ai codici di stato HTTP spiega ogni codice);
• il tempo di risposta, dall’invio della richiesta all’arrivo delle intestazioni, incluse l’eventuale risoluzione DNS e l’apertura della connessione;
• l’indirizzo indicato in Location;
• le intestazioni della risposta e i nomi degli eventuali cookie impostati in quel salto.

Ogni reindirizzamento è etichettato in base al modo in cui è avvenuto: codice di stato HTTP, meta refresh (con il ritardo in secondi) o JavaScript. Vengono segnalati anche i reindirizzamenti lato client individuati ma non seguiti. Altrettanto importante è il modo in cui si è conclusa la verifica:

Gli avvisi segnalano un reindirizzamento temporaneo nella catena, un downgrade da HTTPS a HTTP, più di tre reindirizzamenti, un URL finale su un altro dominio, reindirizzamenti lato client e richieste HEAD che non hanno potuto leggere il corpo della pagina.

Un avviso in particolare richiede cautela. Alcuni siti mostrano al traffico automatizzato o proveniente da data center una verifica anti-bot, come la pagina “Just a moment...” di Cloudflare. TrueURL segnala le risposte che sembrano una pagina di questo tipo, perché in quel caso la verifica si è fermata al livello di protezione del sito, non alla destinazione. Un visitatore reale potrebbe arrivare altrove.

Come verificare i redirect dalla riga di comando

curl è preinstallato su macOS, Windows 10 e 11 e sulla maggior parte delle distribuzioni Linux, e mostra esattamente ciò che invia il server, senza alcuna cache del browser di mezzo. Gli esempi usano una shell Unix; in Windows PowerShell 5.1 scrivi curl.exe, perché lì curl è un alias di Invoke-WebRequest, e usa NUL al posto di /dev/null.

Esamina un singolo salto

curl -I https://example.com/old-page

-I invia una richiesta HEAD e stampa le intestazioni della risposta, comprese la riga di stato e l’eventuale intestazione Location. curl non segue i reindirizzamenti, a meno che non glielo chieda tu. Poiché alcuni server gestiscono HEAD in modo diverso, se il risultato sembra strano ripeti la verifica con una richiesta GET: -o /dev/null scarta il corpo e -D - stampa le intestazioni:

curl -sS -o /dev/null -D - https://example.com/old-page

Segui l’intera catena

-L segue i reindirizzamenti e, con -I o -D -, curl stampa le intestazioni di ogni salto. Filtrando con grep si ottiene una vista compatta:

curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'

HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

Per impostazione predefinita curl segue fino a 50 reindirizzamenti; --max-redirs 10 applica il limite di Googlebot.

Stampa solo l’URL finale

L’opzione -w (write-out) stampa alcuni dettagli al termine del trasferimento e trasforma curl in un espansore di URL essenziale:

curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} è l’ultimo URL scaricato, %{num_redirects} il numero di reindirizzamenti seguiti e %{http_code} il codice di stato finale. %{time_redirect} indica i secondi spesi nei reindirizzamenti prima della richiesta finale. Senza -L, %{redirect_url} mostra dove porterebbe il primo reindirizzamento.

Testa le richieste POST

-d invia un corpo e trasforma la richiesta in un POST. Quando segue i reindirizzamenti, curl si comporta allora come un browser: passa a GET dopo un 301, 302 o 303 e reinvia il POST con il suo corpo dopo un 307 o 308.

curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Evita di combinare -X POST con -L. -X impone il metodo su ogni richiesta, quindi curl continua a inviare POST dopo un 301, 302 o 303, dove un browser passerebbe a GET, e finisci per testare una catena che nessun client reale produce.

Cambia User-Agent, intestazioni e cookie

# User-Agent di uno smartphone
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Intestazione di richiesta aggiuntiva
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Invia un cookie e conserva i cookie impostati lungo la catena
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A imposta lo User-Agent, -H aggiunge un’intestazione e -b invia i cookie. -c salva in un file i cookie ricevuti e attiva il motore dei cookie di curl, così un cookie impostato in un salto viene inviato in quello successivo.

curl non esegue JavaScript e non tiene conto dei tag meta refresh. Se l’ultima risposta è una pagina HTML 200 OK ma il tuo browser finisce altrove, il reindirizzamento avviene lato client.

Come verificare i redirect nei DevTools del browser

I DevTools mostrano la catena così come la vede il tuo browser, con i tuoi cookie, le tue estensioni e la tua posizione:

1. Apri i DevTools (F12, oppure Cmd+Option+I su Mac) e seleziona la scheda Network.
2. Attiva Preserve log in Chrome ed Edge, oppure Persist Logs nel menu delle impostazioni di rete di Firefox. Altrimenti l’elenco viene svuotato a ogni caricamento di pagina e i reindirizzamenti lato client spariscono dalla vista.
3. Attiva Disable cache, in modo che un reindirizzamento memorizzato nella cache non nasconda ciò che il server invia oggi.
4. Inserisci l’URL nella barra degli indirizzi.

Ogni salto compare in una riga a sé con il suo codice 3xx; selezionala e apri Headers per vedere l’intestazione di risposta location. In Chrome, “(disk cache)” o “(memory cache)” nella colonna Size indica che il reindirizzamento è arrivato dalla cache e non dal server.

A volte Chrome mostra un 307 Internal Redirect da http:// a https://. Il server non l’ha mai inviato: è il browser ad aver convertito da solo la richiesta in HTTPS, di solito perché ha memorizzato una policy HSTS per quel sito. Per vedere cosa fa il server con HTTP in chiaro, usa curl o TrueURL.

Problemi comuni con i redirect e come risolverli

Catene con più di un salto

Le catene crescono per stratificazione: una regola di una vecchia migrazione punta a un URL che una migrazione successiva ha reindirizzato di nuovo. Fai puntare ogni regola direttamente alla destinazione finale e aggiorna link interni, tag canonical, annotazioni hreflang e sitemap, in modo che il tuo sito non generi mai un reindirizzamento. Con la Verifica redirect in blocco scopri quali vecchi URL richiedono ancora più di un salto.

Loop di redirect

Chrome segnala un loop con il messaggio “… ti ha reindirizzato troppe volte” (ERR_TOO_MANY_REDIRECTS); Firefox con “La pagina non reindirizza in modo corretto”. Le cause più comuni:

• HTTPS dietro un proxy o una CDN. Il server di origine reindirizza da HTTP a HTTPS, ma il proxy lo contatta in HTTP in chiaro, quindi l’origine non vede mai HTTPS e continua a reindirizzare all’infinito. Su Cloudflare è il classico effetto della modalità SSL/TLS Flexible: usa Full (strict) oppure fai controllare all’origine l’intestazione X-Forwarded-Proto.
• Due livelli in disaccordo, ad esempio una regola della CDN che rimuove il www mentre il server lo aggiunge, oppure un framework che aggiunge uno slash finale che la CDN toglie.
• Reindirizzamenti che dipendono dai cookie. Una pagina di login o di consenso rimanda i visitatori all’URL originale, che li reindirizza di nuovo alla pagina di login perché il cookie non è stato salvato.

La Verifica loop di redirect mostra quale salto chiude il loop. A quel punto affida ogni regola a un solo livello.

301 e 302 misti nella stessa catena

Una catena 301, poi 302, poi 200 è uno spostamento permanente con un passaggio temporaneo nel mezzo. Spesso dipende da un valore predefinito: sia res.redirect() di Express sia header('Location: ...') di PHP inviano un 302, se non specifichi altro. Usa un codice permanente a ogni salto e verificalo con la Verifica redirect 301. La nostra guida ai codici di stato HTTP dei redirect spiega quando usare ciascun codice.

Doppio salto da HTTP a HTTPS a www

Una catena molto comune è http://example.com → https://example.com → https://www.example.com: due salti dove ne basterebbe uno. Reindirizza ogni variante non canonica direttamente all’URL HTTPS finale, poi testale tutte e quattro con la Verifica redirect HTTPS.

C’è un’eccezione voluta. Se il tuo host canonico è www e aggiungi il dominio alla lista di preload HSTS, hstspreload.org richiede che http://example.com reindirizzi prima a https://example.com, in modo che i browser registrino la policy HSTS per il dominio senza www.

Slash finale incoerente

/pricing e /pricing/ sono URL diversi. Se entrambi restituiscono 200 OK, hai contenuti duplicati; se due livelli reindirizzano l’uno verso l’altro, hai un loop. Scegli una forma, reindirizza l’altra verso di essa con un unico 301 e usa sempre la stessa nei link. La Verifica slash finale testa entrambe le forme in un colpo solo.

Redirect solo su mobile

Siti mobile separati, inviti a installare un’app e sistemi di rilevamento del dispositivo a volte mandano gli smartphone altrove, spesso alla home page mobile invece che alla pagina equivalente. Con l’indicizzazione mobile-first, Google esegue la scansione principalmente con il suo crawler per smartphone, quindi ai fini dell’indicizzazione conta soprattutto la catena mobile. Confronta le due catene con lo strumento Redirect mobile vs desktop.

Redirect nelle sitemap

Una sitemap dovrebbe elencare gli URL canonici che vuoi nei risultati di ricerca, e questi restituiscono 200 OK. Le voci che reindirizzano sprecano richieste di scansione e inviano segnali di canonicalizzazione contrastanti. Dopo ogni migrazione, controlla la sitemap con la Verifica redirect della sitemap e sostituisci ogni voce che reindirizza con il relativo URL finale.

Redirect JavaScript e meta refresh

Google considera un meta refresh immediato un reindirizzamento permanente e uno ritardato un reindirizzamento temporaneo. I reindirizzamenti JavaScript li vede solo dopo il rendering della pagina, una fase che segue la scansione e può non riuscire. Molti altri crawler, i bot che generano le anteprime dei link e gli strumenti da riga di comando non eseguono affatto JavaScript, e alcuni ignorano anche il meta refresh. Usa reindirizzamenti lato server ovunque tu controlli il server e individua quelli lato client con la Verifica meta refresh.

Checklist dei redirect

Ripercorri questo elenco dopo una migrazione o un cambio di CDN, oppure prima del lancio di una campagna:

1. Ogni vecchio URL raggiunge la destinazione finale con un solo salto.
2. Gli spostamenti permanenti usano 301 o 308 a ogni salto.
3. Tutte e quattro le varianti di protocollo e host arrivano all’URL HTTPS canonico.
4. Nessun salto passa da HTTPS a HTTP.
5. Le query string, compresi i parametri UTM e gli ID di affiliazione, arrivano intatte in fondo alla catena.
6. Ogni URL ha un’unica forma, con o senza slash finale, e l’altra forma reindirizza a questa.
7. Le richieste da desktop, da smartphone e di Googlebot finiscono su pagine equivalenti.
8. I reindirizzamenti lato server sostituiscono meta refresh e JavaScript ovunque sia possibile.
9. Link interni, tag canonical, hreflang e sitemap puntano agli URL finali.
10. Le pagine rimosse senza un sostituto restituiscono 404 o 410 invece di reindirizzare alla home page.
11. I reindirizzamenti di uno spostamento del sito restano attivi; Google consiglia di mantenerli per almeno un anno.