Verifica redirect: scopri dove reindirizza qualsiasi URL o link
Un verificatore di reindirizzamenti segue un URL di salto in salto e riporta lo stato HTTP di ciascuno finché la catena non termina. Se inserisci http://github.com, registra due salti: il salto 1 risponde 301 Moved Permanently e punta a https://github.com/, che risponde 200 OK. È un solo redirect, ed è una situazione sana: ogni redirect in più aggiunge un altro round trip. Questo strumento segue le risposte 301, 302, 303, 307 e 308 oltre ai tag meta refresh HTML, segnala loop e catene lunghe e può inviare la richiesta come Googlebot o come uno smartphone.
Un URL per riga, fino a 10. Ogni URL viene tracciato separatamente e poi puoi esportare l’intero blocco.
Risultati del blocco
| URL iniziale | Redirect | Stato finale | URL finale | Tempo (ms) | Nota |
|---|---|---|---|---|---|
Destinazione finale
Catena di redirect
Questo URL passa per più di un redirect prima di arrivare alla pagina finale. Ogni salto in più costa un round trip: fai puntare il primo URL direttamente alla destinazione finale.
Rilevato loop di redirect
Questo URL rimanda a una pagina già presente nella catena, quindi non arriva mai a una destinazione finale.
Catena di redirect troppo lunga
Dopo 10 salti la catena reindirizzava ancora, quindi il controllo si è fermato lì.
Interrotto dopo 20 secondi
La catena era ancora in corso quando è scaduto il tempo limite per un singolo controllo. Qui sotto trovi l’ultimo URL raggiunto.
Catena di redirect
Strumenti popolari
Informazioni su Verificatore reindirizzamenti
Questo verificatore di reindirizzamenti ricostruisce ciò che succede davvero tra l’URL che digiti e la pagina che alla fine viene caricata. Dal nostro server invia una richiesta GET per ogni salto, senza cookie, registra il codice di stato, l’header Location e il tempo impiegato da ciascun salto e passa all’URL successivo, finché non ottiene una risposta che non sia un redirect — o finché non arriva a 10 salti, tanti quanti ne seguono al massimo i crawler di Google e più o meno la metà dei circa 20 che un browser tollera prima di arrendersi con ERR_TOO_MANY_REDIRECTS.
Quando un salto risponde 200 con una pagina HTML, ne legge al massimo i primi 64 KB alla ricerca di un tag meta refresh, perché quel tipo di redirect si trova nella pagina e non negli header. Nulla di ciò che contiene la pagina viene eseguito, ed è anche per questo che i redirect JavaScript sono fuori portata: esistono solo quando un browser esegue gli script della pagina.
Il risultato è volutamente letterale. Il salto 1 è l’URL che hai inserito e ogni riga successiva è l’URL esatto verso cui ti ha mandato il salto precedente, con il cambio di protocollo, il www aggiunto o tolto, lo slash finale e la query string; un salto raggiunto tramite meta refresh viene indicato come tale, insieme al suo ritardo. È proprio questo che rende lo strumento utile nelle migrazioni: una regola che sembra corretta in una configurazione nginx spesso si comporta diversamente quando entrano in gioco insieme HSTS, una regola edge della CDN e un redirect canonico a livello di applicazione, e l’unico modo affidabile per vedere il risultato è seguirlo dall’esterno. Dato che alcuni siti mandano smartphone, crawler e browser desktop in posti diversi, la richiesta può partire come il nostro crawler, come Chrome su Windows, come Safari su iPhone, come Googlebot (smartphone o desktop) o come Bingbot.
La modalità in blocco accetta fino a dieci URL alla volta, li traccia uno dopo l’altro e ti restituisce una tabella, esportabile in CSV o da incollare direttamente in un foglio di calcolo o in un ticket, con il numero di redirect, lo stato finale, l’URL finale e il tempo totale. Il pulsante delle varianti genera le quattro combinazioni di http e https, con e senza www, per l’indirizzo che hai inserito e le traccia in un colpo solo: è il modo più rapido per verificare che ogni punto di ingresso confluisca in un unico URL canonico.
Domande tipiche a cui risponde in pochi secondi: il vecchio URL di un prodotto porta ancora a quello nuovo con un solo 301? La regola da HTTP a HTTPS è sopravvissuta all’ultimo deploy? Un link di affiliazione conserva la query string fino in fondo? E dove va a finire, esattamente, un link abbreviato? Indirizzi privati, localhost ed endpoint di metadati cloud vengono rifiutati, e ogni controllo si ferma dopo 20 secondi, quindi lo strumento non può essere usato per sondare una rete interna.
Casi d'uso
Come verificare dove reindirizza un URL
Incolla l’URL o il link che vuoi testare, ad esempio http://github.com, oppure fai clic su uno degli esempi sotto la casella.
Se vuoi, scegli da chi parte la richiesta: il nostro crawler predefinito, Chrome, un iPhone, Googlebot o Bingbot. I siti che trattano in modo diverso smartphone o bot mostreranno una catena diversa.
Premi Invio o fai clic su Controlla i redirect. Ogni salto viene richiesto dal nostro server e seguito attraverso le risposte 301, 302, 303, 307 e 308 e i tag meta refresh, fino a un massimo di 10 salti.
Leggi il riepilogo: quanti redirect sono stati trovati, lo stato HTTP finale, il tempo totale e l’URL finale. Se l’URL entra in un loop o passa per più di un redirect, compare un avviso.
Segui la catena numerata per vedere ogni salto con il suo URL, il badge di stato (ad esempio 301 Moved Permanently), se era un meta refresh e quanto tempo ha richiesto quel salto.
Per testare più indirizzi, passa alla modalità in blocco (fino a 10 URL) oppure fai clic sul pulsante delle varianti per tracciare in un colpo solo le versioni http, https, con e senza www, poi esporta i risultati in CSV.
Suggerimenti Pro
- Punta a un unico 301 diretto all’URL finale. Ogni salto in più costa un round trip completo, un salto che passa a HTTPS aggiunge un handshake TLS e uno che cambia host aggiunge anche una risoluzione DNS: in totale, di solito 100-300 ms su una connessione mobile prima che venga visualizzato qualcosa.
- Usa il 308 invece del 301 quando la richiesta reindirizzata potrebbe essere un POST. Con 301 e 302 i client possono riscrivere il metodo in GET; con 307 e 308 devono mantenere il metodo e il corpo della richiesta.
- Testa anche le versioni http:// e www, oltre a quella https://; il pulsante delle varianti le prova tutte e quattro insieme. Molti siti reindirizzano correttamente su HTTPS mentre una vecchia regola per l’HTTP in chiaro punta ancora a un host dismesso.
- Controlla lo stato dell’ultimo salto, non solo il numero di redirect. Una catena che termina con un 404 o un 405 è rotta anche se ogni redirect lungo il percorso era un 301 corretto.
- Dopo una migrazione, controlla con la modalità in blocco i tuoi URL principali presi da Search Console, scarica il CSV e confrontalo con quello della stessa lista una settimana dopo, per individuare le regole che un deploy ha silenziosamente annullato.
Risoluzione dei problemi
Il controllo restituisce 403 quando scelgo Googlebot.
Molti grandi siti verificano che un visitatore che si presenta come Googlebot provenga davvero dalla rete di Google e respingono tutti gli altri, compreso questo strumento. Confronta il risultato con lo user agent predefinito o con Chrome; per vedere cosa ha ricevuto Google stesso, usa lo strumento Controllo URL di Search Console.
La catena termina con 403, 405 o 503, ma nel mio browser la pagina si apre.
Probabilmente il sito filtra i client: una protezione anti-bot o una challenge della CDN che richiede cookie e JavaScript, oppure un blocco sugli intervalli IP dei server. Prova lo user agent Chrome o iPhone; se la risposta non cambia, il filtro agisce a livello di rete o di comportamento, e un controllo lato server non può superarlo.
Il browser mi dà ERR_TOO_MANY_REDIRECTS, ma lo strumento mostra una catena normale.
Probabilmente il loop dipende da qualcosa che questo strumento non invia: un cookie, una sessione autenticata o la voce HSTS memorizzata dal tuo browser. Cancella i cookie del sito o apri una finestra di navigazione privata, poi confronta le versioni http:// e https:// con il pulsante delle varianti per trovare la regola che rimanda indietro i visitatori.
Un salto fallisce con un errore del certificato SSL invece che con un codice di stato.
Il certificato di quell’host è scaduto, autofirmato o emesso per un altro nome, quindi la connessione viene rifiutata prima che si possa leggere qualsiasi redirect. Anche i browser si fermano nello stesso punto. Rinnova o correggi il certificato, oppure fai puntare il salto precedente a un host con un certificato valido.
Domande frequenti
Mostra dove un URL manda davvero visitatori e motori di ricerca. Ottieni ogni salto tra l’indirizzo che hai digitato e la pagina che alla fine risponde, con il codice di stato e il tempo di ciascuno. Così rispondi a tre domande in una volta: se il redirect scatta, se punta alla destinazione giusta e quanti salti vengono sprecati lungo il percorso. È anche il modo sicuro per vedere dove porta un link abbreviato o di affiliazione prima di cliccarlo.
Un 301 indica che lo spostamento è permanente: i browser lo memorizzano nella cache e Google consolida i segnali di ranking del vecchio URL nel nuovo indirizzo, conservando il vecchio solo come nome alternativo; così di solito smette di comparire nei risultati, ma può ancora emergere quando una query fa pensare che gli utenti si fidino proprio di quell’URL. Un 302 indica che lo spostamento è temporaneo, quindi l’URL originale di norma resta indicizzato e la risposta non viene memorizzata nella cache, a meno che gli header non lo consentano. Usa il 301 per migrazioni e passaggi a HTTPS, il 302 solo per test A/B e pagine di manutenzione.
L’obiettivo è uno solo, due sono tollerabili, da tre in su vanno accorpati. I browser si arrendono dopo circa 20 salti e i crawler di Google seguono fino a 10 salti di redirect prima di considerare l’URL un errore. Ogni salto in più costa un round trip, un salto che cambia protocollo aggiunge un handshake TLS e uno che cambia host aggiunge anche una risoluzione DNS, quindi una catena di tre redirect può aggiungere su mobile diverse centinaia di millisecondi prima che arrivi il primo byte di contenuto vero e proprio.
Inserisci il tuo dominio e fai clic sul pulsante delle varianti. Lo strumento traccia http://, https://, http://www. e https://www. per lo stesso percorso in un’unica passata. In una configurazione corretta tutte e quattro le versioni finiscono sullo stesso URL finale con un 200: quella canonica non mostra alcun redirect e ognuna delle altre tre un solo 301 o 308. Due redirect sulla versione http://www. di solito significano che protocollo e host vengono corretti da regole separate, che si possono unire in una sola.
Sì. Scegli lo user agent prima di avviare il controllo: Chrome su Windows, Safari su iPhone, Googlebot per smartphone o per desktop, oppure Bingbot. I siti che mandano i visitatori da mobile su un sottodominio m. o che trattano i crawler in modo diverso mostreranno una catena diversa per ciascuno. Un’avvertenza: molti grandi siti verificano che un visitatore che si dichiara Googlebot provenga davvero dalla rete di Google e altrimenti rispondono 403, quindi un 403 con lo user agent Googlebot spesso significa proprio questo. Per vedere esattamente cosa ha ricevuto Google, usa lo strumento Controllo URL di Search Console.
I meta refresh sì. Quando un salto risponde 200 con una pagina HTML, lo strumento ne legge i primi 64 KB, cerca un tag meta refresh che contenga un URL e lo segue come salto successivo, segnalandolo come meta refresh con il relativo ritardo in secondi. I redirect JavaScript no: avvengono solo quando un browser esegue gli script della pagina, e questo strumento non esegue mai nulla. Se l’ultimo salto è un 200 ma il tuo browser finisce altrove, la causa probabile è uno script; la scheda Network di DevTools lo mostra come una navigazione avviata da uno script.
Le cause abituali sono quattro. Il tuo browser ha il sito nella cache HSTS, quindi converte http:// in https:// prima ancora che una richiesta esca dal tuo computer. Il sito cambia risposta in base a cookie, header della lingua o paese, e il nostro server gli appare diverso da te. Il sito manda smartphone e desktop in posti diversi, cosa che puoi riprodurre cambiando lo user agent. Oppure un redirect JavaScript completa il percorso dopo il caricamento della pagina, e un tracciamento lato server non lo vede mai.
Sì. Passa alla modalità in blocco e incolla fino a dieci URL, uno per riga. Ognuno viene tracciato separatamente e i risultati finiscono in un’unica tabella con il numero di redirect, lo stato finale, l’URL finale e il tempo totale. Scarica la tabella in CSV oppure copiala come testo separato da tabulazioni, che si incolla così com’è in Sheets, Excel o in un ticket Jira, senza doverlo riformattare. Il pulsante delle varianti riempie la stessa tabella con le quattro versioni http/https e www di un unico indirizzo.
Apri DevTools con F12, vai alla scheda Network, spunta Preserve log e poi carica l’URL. Ogni salto compare su una riga a sé con stato 301 o 302; fai clic su una riga e leggi l’header Location sotto Response Headers. Il limite è che DevTools mostra ciò che ha fatto il tuo browser, con tanto di cookie, cache HSTS ed estensioni, quindi un collega su un altro computer potrebbe vedere una catena diversa.
Un singolo 301 o 308 trasmette i segnali di ranking e non è un problema. Le catene invece lo sono, per due motivi: i crawler di Google seguono fino a 10 salti di redirect e segnalano qualsiasi catena più lunga come errore di reindirizzamento, e ogni salto ritarda il primo byte, cosa che si riflette direttamente sui Core Web Vitals. I loop sono peggio, perché la pagina non è mai raggiungibile ed esce del tutto dall’indice. Accorpa le catene in modo che il primo URL punti direttamente all’ultimo.