Verifica redirect 301: controlla ogni catena di reindirizzamenti

Un redirect checker mostra cosa succede davvero tra il clic su un link e l’arrivo su una pagina. Ogni URL che inserisci viene richiesto dal server di Marqly con i reindirizzamenti automatici disattivati, così ogni risposta viene registrata singolarmente: il codice di stato, l’header Location verso cui punta, il tempo impiegato e gli header che contano per la SEO. Lo strumento segue poi quella destinazione e ripete, fino a 10 redirect, lo stesso limite che i crawler di Google usano per impostazione predefinita. Ottieni la catena di redirect completa, l’URL e lo stato finali e avvisi in linguaggio semplice su loop, redirect temporanei, hop lenti, parametri di tracciamento persi e catene da accorciare.

Come verificare un redirect

1. Incolla un URL nella casella. Per un controllo in blocco incolla fino a 10 URL, uno per riga.
2. Scegli uno user agent se ti serve. Quello predefinito si presenta come checker Marqly; puoi anche inviare lo user agent di Chrome, di Safari su iPhone, di Googlebot smartphone o di Googlebot desktop per scovare le regole che trattano in modo diverso browser, telefoni e crawler.
3. Spunta Controlla anche le versioni http/https e www/senza www per testare insieme tutte e quattro le forme dello stesso indirizzo. È il modo più rapido per confermare che un sito abbia un solo nome host canonico e che ogni variante ci arrivi con un solo hop.
4. Premi Verifica i redirect. Ogni URL ha la sua scheda con l’esito, i suggerimenti e la catena hop per hop.
5. Usa Copia i risultati per un report in testo, Scarica CSV per un foglio di calcolo con una riga per hop, oppure Copia link di condivisione per inviare un link che ripete lo stesso controllo.

Come leggere i risultati

Ogni scheda si apre con il codice di stato finale, l’URL inserito, il numero di redirect, il tempo totale e l’URL finale. Sotto, i suggerimenti segnalano ciò che merita attenzione, dagli errori (loop, catene oltre il limite, una catena che finisce in un 404) agli avvisi (redirect temporanei, meta refresh, un passaggio da https a http, parametri di query persi, un X-Robots-Tag: noindex sulla pagina finale) fino alle note neutre (cambio di slash finale o di www, spostamento su un altro dominio, hop lenti). Per ora i testi di questi suggerimenti e alcuni messaggi di errore del server sono in inglese.

La tabella della catena elenca ogni richiesta in ordine. Stato è il codice di stato HTTP restituito dal server. URL è l’indirizzo richiesto e, sotto, quello verso cui l’hop manda il client, già risolto in indirizzo assoluto quando il server ha inviato una Location relativa.Tempo è quanto ha impiegato il server a restituire gli header per quell’hop. ApriHeader su qualsiasi riga per vedere Location, Cache-Control,Content-Type, X-Robots-Tag, Link (dove si può dichiarare un canonical),Strict-Transport-Security, X-Redirect-By (WordPress e alcuni plugin si firmano qui) eServer. I valori dei cookie non vengono mai mostrati, solo quanti ne sono stati impostati.

301, 302, 307 e 308: cosa significa ogni codice di redirect

HTTP definisce i codici di stato di reindirizzamento nellaRFC 9110, sezione 15.4. Due domande li distinguono: lo spostamento è permanente? E il client può cambiare il metodo della richiesta (per esempio trasformare un POST di un modulo in un GET) quando segue il redirect? Ladocumentazione di Google sui codici di stato HTTPspiega come i suoi crawler e l’indicizzazione trattano ciascun codice.

Per le pagine normali usa il 301 quando il contenuto si è spostato per sempre: uno slug rinominato, un articolo accorpato, una migrazione di dominio, il passaggio a HTTPS. Usa il 302o il 307 quando l’URL originale tornerà, come una pagina di manutenzione, una campagna breve o un test. Scegli il 308 quando il metodo conta, per esempio un endpoint di API o un modulo che riceve richieste POST, perché la RFC 9110 consente ai client di trasformare un POST reindirizzato in GET con 301 e 302, ma lo vieta con 307 e 308.

Meta refresh e redirect JavaScript

La guida di Google ai reindirizzamenticonsiglia un redirect permanente lato server ogni volta che è possibile. Interpreta un meta refresh istantaneo come redirect permanente e uno ritardato come temporaneo, e suggerisce i redirect JavaScript solo quando non sono possibili né quelli lato server né i meta refresh, perché il rendering può non riuscire. Questo checker segue i tag meta refresh e l’header Refresh e li etichetta, ma non esegue JavaScript.

Che cos’è una catena di redirect e perché fa danni?

Una catena di redirect è qualsiasi percorso con più di un hop: http://example.com/pagina →https://example.com/pagina → https://www.example.com/pagina →https://www.example.com/pagina/. Le catene raramente nascono di proposito. Si accumulano mentre un sito passa a HTTPS, sceglie se usare il www, cambia CMS, rinomina le sezioni e reindirizza vecchi redirect invece di riscriverli. Ogni livello funziona da solo; messi insieme, si sommano.

• Velocità. Ogni hop è un’altra richiesta completa prima che la pagina inizi a caricarsi, e un hop verso un nuovo nome host aggiunge una risoluzione DNS e un handshake TLS. La colonna del tempo mostra quanto costa ogni hop.
• Scansione. Google dice che i suoi crawler seguono per impostazione predefinita fino a 10 hop di reindirizzamento, e il suo rapporto sull’indicizzazione delle pagine elenca comeerrori di reindirizzamentouna catena troppo lunga, un loop e un URL errato o vuoto nella catena. Laguida di Google allo spostamento dei siticonsiglia di reindirizzare direttamente alla destinazione finale e, quando non è possibile, di usare idealmente non più di 3 redirect e meno di 5, perché la concatenazione aumenta la latenza e non tutti gli user agent e i browser supportano catene lunghe.
• Altri client. La RFC 9110 ricorda che una specifica HTTP precedente raccomandava un massimo di cinque reindirizzamenti e che alcuni client potrebbero ancora applicare un limite fisso di questo tipo, quindi una catena che Googlebot tollera può comunque rompersi per altri software.
• Fragilità e dati persi. Ogni hop è un’altra regola che si può modificare, cancellare o scavalcare. Un hop che ricostruisce l’URL può eliminare in silenzio la query string, ed è così che i tag UTM spariscono prima che gli analytics li vedano; il checker avvisa quando un parametro dell’URL originale manca in quello finale.

Come sistemare una catena di redirect

1. Trova l’URL finale. Passa il vecchio URL nel checker e copia l’ultimo URL della catena.
2. Punta il primo redirect all’URL finale. Se A reindirizza a B e B reindirizza a C, cambia la regola di A perché vada dritta a C e mantieni B → C per chi ha ancora B. In una mappa dei redirect o in un plugin, cerca le regole la cui destinazione è a sua volta l’origine di un’altra regola.
3. Unisci le regole di protocollo e di nome host. La catena più comune è http → https seguito da senza www → www. Scrivi un’unica regola che porti ogni variante alla forma canonica in un solo passaggio, come in questo esempio per nginx:

# Un solo hop da ogni variante a https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # righe ssl_certificate omesse
    return 301 https://www.example.com$request_uri;
}

4. Aggiorna i link alla fonte. Cambia link interni, tag canonical, annotazioni hreflang e sitemap XML con gli URL finali; la guida di Google allo spostamento dei siti chiede di aggiornare i link interni ai nuovi URL. I redirect servono a recuperare i vecchi link che arrivano da fuori, non a reggere la tua navigazione.
5. Mantieni i redirect. Google suggerisce di mantenere i reindirizzamenti il più a lungo possibile, in genere almeno un anno. Accorciare una catena significa cambiare la destinazione delle regole, non cancellare quelle vecchie.
6. Ripeti il test. Controlla di nuovo gli stessi URL, meglio se con l’opzione delle varianti attiva, e verifica che ognuno arrivi a una pagina 200 con un solo hop.

Come risolvere un loop di redirect

Un loop è una catena che torna a un URL già visitato, quindi non finisce mai; i browser mostrano un errore di troppi reindirizzamenti. Le cause tipiche sono due livelli in disaccordo: una CDN che parla con l’origine in HTTP mentre l’origine forza HTTPS, una regola sullo slash finale nel web server che combatte quella opposta nell’applicazione, o regole sul www impostate sia nell’inoltro a livello DNS sia nel sito. Guarda l’hop in cui l’URL torna indietro: i suoi header Server e X-Redirect-By spesso dicono quale livello l’ha inviato. Alcuni loop si verificano solo senza cookie (redirect di consenso o di login) e non toccano i visitatori che quei cookie li hanno già; il checker non invia cookie, quindi fa emergere anche questi.

Verificare i redirect in blocco

Incolla fino a 10 URL, uno per riga, per controllarli in un’unica esecuzione; i duplicati vengono rimossi e ogni URL ha il suo risultato. L’export CSV ha una riga per hop con l’URL di partenza ripetuto, così puoi filtrare per stato, ordinare per numero di hop o passare il file a chi gestisce le regole di redirect. Se i link da controllare sono vecchi preferiti del browser, portali prima in una libreria conl’importazione dei preferiti, così sai cosa possiedi prima di sistemare cosa si è spostato. Per un sito intero, usa un crawler o i log del server per trovare gli URL reindirizzati, poi controlla qui a campione quelli importanti con lo user agent di Googlebot.

HTTPS, www e slash finale

La maggior parte dei siti dovrebbe rispondere su un’unica combinazione di protocollo e nome host, con ogni altra forma che reindirizza a quella in modo permanente e con un solo hop. L’opzione delle varianti controllahttp://example.com, https://example.com, http://www.example.com ehttps://www.example.com con lo stesso percorso e riporta se tutte e quattro finiscono sullo stesso URL e quanti hop servono a ciascuna. I suggerimenti segnalano un passaggio a HTTPS che avviene tardi nella catena, una catena che salta tra www e senza www più di una volta e gli hop che si limitano ad aggiungere o togliere lo slash finale o a cambiare maiuscole e minuscole: tutte cose facili da accorpare nel primo redirect.

Perché i risultati possono essere diversi da quelli del browser

Se il tuo browser finisce altrove, di solito sta ricordando qualcosa. La RFC 9110 consente di mettere in cache un 301, quindi un browser può saltare un vecchio redirect, o continuare a seguirne uno che hai già rimosso. Una volta che un browser ha visto l’header HSTS di un sito (o il sito è nella lista di precaricamento HSTS), trasforma internamente http:// in https:// prima che qualsiasi richiesta lasci il tuo computer. Anche cookie, lingua e posizione possono attivare redirect propri. Il checker parte pulito ogni volta e riporta ciò che il server invia, cioè la vista che conta per i crawler e per chi visita il sito la prima volta.

Come funziona il checker

Ogni hop è una richiesta GET dal server di Marqly su Cloudflare con i redirect impostati su manuale, quindi nulla viene seguito finché il checker non l’ha registrato. Ogni nome host viene risolto e deve puntare a un indirizzo pubblico; reti private, localhost e indirizzi di metadati cloud vengono rifiutati, anche quando un redirect punta a uno di questi a metà catena. Ogni hop ha un timeout di 6 secondi, una catena intera si ferma dopo 20 secondi o 10 redirect, e il corpo delle pagine viene scartato tranne i primi 64 KB di una pagina HTML finale, analizzati alla ricerca di un meta refresh. Non viene salvato nulla: i risultati esistono solo nella scheda del tuo browser.

Se stai creando link di campagna, il generatore di UTM li costruisce e questo checker conferma che i parametri sopravvivono a ogni hop. Chi lavora nel marketing trova altri modi per tenere in ordine link, landing page e materiali nella paginaMarqly per il marketing, e quando una pagina che ti serve cambia indirizzo, unorganizzatore di segnalibri con la ricerca ti evita di perderla.