logo
GeekFormat

Controlla Catena di Reindirizzamento

Controllo catena di reindirizzamenti

Controlla 301/302/307/308 salto per salto, identifica loop, reindirizzamenti cross-domain e problemi di downgrade HTTPS.

Quando inserisci un indirizzo web nel browser, dietro le quinte potrebbe verificarsi una serie di salti invisibili: HTTP→HTTPS, non-www→www, vecchio dominio→nuovo dominio, URL breve→URL lungo... Ogni reindirizzamento consuma tempo, influisce sul posizionamento SEO e potrebbe persino degradare silenziosamente HTTPS in HTTP. Il Controlla Catena di Reindirizzamento traccia il percorso completo di reindirizzamento dell'URL salto per salto dalla prospettiva del server, mostra il codice di stato (301/302/303/307/308), l'header Location e l'indirizzo di destinazione di ogni salto, rileva automaticamente problemi come loop di reindirizzamento, salti cross-domain, downgrade HTTPS e troncamento della catena, aiutandoti a scoprire i rischi nascosti di reindirizzamento durante la migrazione del dominio, la distribuzione HTTPS e l'ottimizzazione SEO.

Raccomandazioni correlate

Casi d'uso

  • Verifica migrazione dominio: dopo che il sito passa dal vecchio al nuovo dominio, conferma salto per salto se i vecchi URL sono correttamente reindirizzati in modo permanente 301 al nuovo indirizzo, evitando perdite di traffico dovute a reindirizzamenti a catena e codici di stato errati
  • Controllo distribuzione HTTPS: conferma se la catena di reindirizzamento HTTP→HTTPS è un singolo salto 301, verifica se esistono cicli di downgrade HTTP→HTTPS→HTTP, valuta se la configurazione HSTS è efficace
  • Rilevamento pagina di destinazione URL breve: traccia il percorso completo di reindirizzamento di URL brevi (t.cn/bit.ly, ecc.), link di marketing UTM o link condivisi sui social, conferma che la pagina finale di destinazione sia l'indirizzo previsto, verifica se i reindirizzamenti intermedi inseriscono parametri di tracciamento o reindirizzamenti dannosi
  • Normalizzazione www e non-www: verifica se il dominio www e il dominio radice si reindirizzano correttamente con 301 l'uno all'altro verso la versione normalizzata, evitando problemi di contenuto duplicato SEO causati dal funzionamento su doppio binario
  • Risoluzione loop di reindirizzamento: quando il browser segnala l'errore ERR_TOO_MANY_REDIRECTS, utilizza lo strumento per individuare con precisione il nodo in cui si verifica il loop, distinguendo se si tratta di un errore di configurazione Nginx/Apache, un conflitto di regole CDN o un loop causato da plugin WordPress
  • Debug CDN e reverse proxy: risolvi i conflitti di reindirizzamento in architetture multilivello come Cloudflare, CDN Alibaba Cloud, reverse proxy Nginx, identifica i problemi di reindirizzamento reciproco tra le regole CDN e le regole del server di origine
  • Audit salute SEO: controlla periodicamente la lunghezza della catena di reindirizzamento delle pagine principali del sito, valuta l'impatto dei reindirizzamenti a più salti sull'efficienza di passaggio del PageRank, ottimizza le catene di reindirizzamento troppo lunghe
  • Valutazione rischio reindirizzamento cross-domain: rileva scenari che coinvolgono reindirizzamenti cross-domain come salti di login, callback OAuth, salti di pagamento, conferma se Cookie e Session vengono trasmessi correttamente durante il cross-domain
  • Bilanciamento del carico e verifica multi-active: controlla le strategie di reindirizzamento in scenari di data center multi-active, bilanciamento del carico globale GSLB, conferma che gli utenti di diverse regioni siano correttamente reindirizzati al nodo disponibile più vicino
  • Debug cache reindirizzamento: verifica le impostazioni degli header Cache-Control e Expires per i reindirizzamenti permanenti 301 e temporanei 302, risolvi accessi anomali causati dal caching del browser di vecchie regole di reindirizzamento

Funzionalità

  • Tracciamento completo salto per salto: segue ogni reindirizzamento dalla prospettiva del server, mostrando in sequenza l'URL originale, il codice di stato di ogni salto, il testo di stato, l'header di risposta Location e il percorso completo di reindirizzamento, senza perdere nessun nodo intermedio
  • Supporto completo codici di stato: copre i cinque codici di stato di reindirizzamento standard 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect, e indica le differenze semantiche di ogni codice di stato
  • Rilevamento loop di reindirizzamento: identifica automaticamente modelli di reindirizzamento ciclico come A→B→A, marca la posizione specifica del nodo in cui si verifica il loop e la lunghezza del ciclo, individuando con precisione la causa principale dell'errore ERR_TOO_MANY_REDIRECTS
  • Riconoscimento salti cross-domain: rileva i cambiamenti di Host/Dominio ad ogni salto, marca i nodi di reindirizzamento cross-domain, segnala il rischio di perdita di Cookie e problemi di preflight CORS
  • Avviso downgrade HTTPS: conta il numero di nodi HTTP (non HTTPS) nella catena di reindirizzamento, marca i salti di downgrade HTTPS→HTTP, segnala i rischi per la sicurezza e l'impatto negativo sulla SEO
  • Protezione da troncamento catena: imposta un limite massimo di profondità di salto (20 salti), tronca automaticamente e marca quando la catena è troppo lunga, evitando il timeout delle richieste dovuto a tracciamento infinito
  • Riepilogo statistiche reindirizzamento: fornisce una panoramica degli indicatori chiave come numero totale di salti, URL finale di destinazione, se è stato rilevato un loop, se c'è cross-domain, numero di nodi HTTP, se la catena è stata troncata
  • Valutazione impatto SEO: valuta automaticamente il livello di impatto sul passaggio del PageRank e sui Core Web Vitals in base al numero di salti, al tipo di codice di stato e alla copertura HTTPS
  • URL di test predefiniti: integra indirizzi di test comuni come geekformat.com, github.com, httpbin.org/redirect, servizi di URL brevi, riempimento con un clic per un'esperienza rapida
  • Cronologia query recenti: salva automaticamente i record delle ultime 8 query (memorizzati localmente nel browser), supporta la ripetizione del rilevamento con un clic, utile per confrontare l'effetto prima e dopo la correzione
  • Scheda suggerimenti diagnostici: fornisce suggerimenti di correzione specifici e guide alle migliori pratiche per problemi rilevati come loop di reindirizzamento, salti cross-domain, downgrade HTTP, catena troppo lunga
  • Doppia vista dettagli e riepilogo: mostra per impostazione predefinita la scheda di riepilogo della catena, espandendo è possibile visualizzare l'URL completo della richiesta, lo stato della risposta, la destinazione Location e il flag HTTPS di ogni salto

Come utilizzare

  1. Inserisci nella casella di input l'URL da rilevare (deve includere il prefisso del protocollo http:// o https://), oppure clicca sul pulsante URL predefinito (geekformat.com/github.com/httpbin.org/redirect, ecc.) per riempire rapidamente l'indirizzo di test
  2. Clicca sul pulsante «Traccia catena di reindirizzamento», lo strumento invierà una richiesta dal lato server e registrerà ogni salto seguendo l'header di risposta Location
  3. Visualizza la scheda di riepilogo dei salti in alto: numero totale di salti, URL finale di destinazione, se è stato rilevato un loop, se esistono salti cross-domain, numero di nodi HTTP, se la catena è stata troncata per troppi salti
  4. Visualizza le informazioni dettagliate di ogni salto nell'area di visualizzazione della catena: numero sequenziale, URL della richiesta, codice di stato della risposta e testo descrittivo, URL di destinazione nell'header di risposta Location, flag di sicurezza HTTPS
  5. Presta attenzione alle schede di avviso diagnostico: se vengono rilevati loop di reindirizzamento (rosso), downgrade HTTPS (arancione), salti cross-domain (giallo) o catena troppo lunga (giallo), lo strumento li evidenzierà nelle posizioni corrispondenti e fornirà una descrizione del problema
  6. Utilizza l'area di valutazione dell'impatto SEO per visualizzare il livello di impatto della catena di reindirizzamento corrente sull'efficienza di passaggio del PageRank, sulla velocità di caricamento della pagina e sui Core Web Vitals, nonché i suggerimenti di ottimizzazione
  7. Dopo il completamento del rilevamento, puoi fare clic su qualsiasi record nella cronologia delle query recenti per ripetere rapidamente il rilevamento e confrontare le modifiche della catena di reindirizzamento prima e dopo la correzione; puoi anche acquisire uno screenshot dei risultati del rilevamento o copiare il testo per la comunicazione del team e la registrazione dei ticket

Domande frequenti

Quanti salti sono considerati troppi per una catena di reindirizzamento? Qual è l'impatto sulla SEO?

Google consiglia ufficialmente di mantenere la catena di reindirizzamento a un singolo salto, massimo non oltre 3 salti. Secondo la documentazione di Google Search Central, Googlebot di solito segue fino a 5 salti di reindirizzamento poi interrompe il tracciamento, ma ciò non significa che 5 salti siano sicuri. Ogni salto di reindirizzamento aumenta il ritardo di caricamento della pagina (100-300 ms/salto), spreca il budget di scansione e potrebbe causare l'attenuazione del trasferimento del PageRank. 1 salto non ha quasi impatto SEO; 2 salti sono accettabili ma consigliati per l'ottimizzazione; oltre 3 salti iniziano a influenzare l'LCP e l'efficienza di scansione; oltre 5 salti c'è il rischio che la pagina non venga indicizzata. Utilizza questo strumento per rilevare la catena di reindirizzamento delle tue pagine principali, assicurandoti che gli URL chiave (home page, pagine prodotto principali, pagine interne ad alto traffico) siano tutti raggiungibili con un singolo salto.

Il reindirizzamento 301 danneggia la SEO? Il PageRank viene trasferito completamente?

Il reindirizzamento permanente 301 utilizzato correttamente non danneggia la SEO. Gary Illyes e John Mueller di Google hanno confermato più volte che il reindirizzamento 301 dalla migrazione di dominio HTTP a dominio HTTPS, così come la migrazione permanente di pagine all'interno dello stesso dominio, ha un trasferimento del PageRank del 100%, senza perdite. Ma va notato che: 1) i reindirizzamenti temporanei 302 non trasferiscono PageRank (o l'efficienza di trasferimento è estremamente bassa); 2) se nella catena di reindirizzamento compaiono noindex, blocco da robots.txt, errori 4xx/5xx, il trasferimento del peso viene interrotto; 3) dopo la migrazione cross-domain 301, è necessario presentare una notifica di modifica del dominio in Google Search Console per accelerare la migrazione dell'indice; 4) 301 viene memorizzato nella cache dal browser a lungo termine, in fase di test si consiglia di verificare prima con 302 poi passare a 301.

Perché il mio sito salta automaticamente a HTTP invece che a HTTPS? Come si ripara?

Il reindirizzamento di downgrade HTTPS→HTTP è solitamente causato da: 1) il reverse proxy/CDN ritorna all'origine in HTTP, quando il server Nginx/Apache di origine utilizza la variabile $scheme per ottenere il protocollo ottiene http invece di https; 2) nel codice a livello applicativo sono hardcodati URL con prefisso http://; 3) l'URL Home o l'URL Site di CMS come WordPress sono impostati su http; 4) nel .htaccess ci sono residui di vecchie regole HTTP; 5) le impostazioni SSL/TLS di servizi di terze parti (CDN/WAF) sono impostate sulla modalità «flessibile» invece che «stretta». Passaggi per la correzione: prima utilizza questo strumento per determinare a quale salto si verifica il downgrade; imposta l'SSL CDN sulla modalità «Full (strict)»; in Nginx gestisci correttamente l'header X-Forwarded-Proto; in WordPress aggiungi $_SERVER['HTTPS']='on'; in wp-config.php; distribuisci l'header di risposta HSTS per evitare il downgrade a livello browser; controlla tutte le regole di reindirizzamento per assicurarti che la destinazione sia https://.

Come si ripara un ciclo di reindirizzamento in Nginx (ERR_TOO_MANY_REDIRECTS)?

Oltre il 90% dei cicli di reindirizzamento in Nginx sono causati da una gestione errata dell'header X-Forwarded-Proto in scenari reverse proxy/CDN. Metodi di riparazione: 1) assicurati che CDN/load balancer inviino l'header X-Forwarded-Proto al back-end: proxy_set_header X-Forwarded-Proto $scheme; 2) in Nginx utilizza X-Forwarded-Proto invece di $scheme per decidere se saltare a HTTPS. Si consiglia l'uso di un blocco map: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) evita di scrivere regole rewrite nel blocco server che corrispondono infinite a se stesse; 4) per i reindirizzamenti www e non-www configura il salto unidirezionale solo in un blocco server, non configurare in entrambe le direzioni.

Come si ripara un ciclo di reindirizzamento in Apache .htaccess?

I cicli in .htaccess di Apache sono solitamente causati da conflitti nelle regole RewriteRule. Passaggi per la correzione: 1) assicurati che RewriteEngine On compaia una sola volta; 2) metti la regola di salto HTTP→HTTPS prima di tutte le altre regole, utilizza: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) metti le regole www/non-www dopo il salto HTTPS, e fai solo salti unidirezionali (non-www→www o viceversa); 4) nota che il flag [L] significa «last» ma se la regola ha modificato l'URL ricomincerà a corrispondere dalla prima regola, il che potrebbe causare cicli, per regole complesse considera l'uso del flag [END] (Apache 2.3.9+); 5) controlla se ci sono più file .htaccess (anche i .htaccess nelle sottodirectory hanno effetto); 6) temporaneamente cambia R=301 in R=302 per i test, evitando l'interferenza della cache del browser.

Come si riparano i cicli di reindirizzamento causati da Cloudflare?

La causa più comune dei cicli Cloudflare è un'impostazione errata della modalità di crittografia SSL/TLS o conflitti nelle regole di pagina: 1) cambia la modalità SSL/TLS di Cloudflare da «Flexible» a «Full» o «Full (strict)» — in modalità Flexible Cloudflare utilizza HTTP per arrivare al server di origine, se il server di origine ha configurato il reindirizzamento forzato HTTPS si creerà un ciclo; 2) controlla se «Always Use HTTPS» in «Edge Certificates» di Cloudflare è abilitato, non configurare contemporaneamente il salto HTTPS sia sul server di origine che su Cloudflare; 3) controlla se ci sono regole di inoltro in conflitto nelle Page Rules; 4) se utilizzi il plugin Cloudflare WordPress, non configurare contemporaneamente il reindirizzamento HTTPS sia nel plugin che su Cloudflare; 5) controlla se le regole Forwarding URL puntano a indirizzi che vengono nuovamente reindirizzati da Cloudflare.

Qual è la differenza tra i reindirizzamenti 301, 302, 307, 308? Quale dovrei scegliere?

La differenza fondamentale sta in due dimensioni: «se permanente» e «se conserva il metodo di richiesta». Guida rapida alla scelta: per le normali richieste GET di pagine web (accesso utente alle pagine) — per le migrazioni permanenti usa 301 (migrazione dominio, passaggio HTTPS, modifica permanente URL), per i salti temporanei usa 302 (test A/B, manutenzione temporanea, salto login); per le richieste POST/PUT/DELETE (chiamate API, invio di moduli) — per le migrazioni permanenti usa 308, per i salti temporanei usa 307, garantendo che metodo e corpo della richiesta non vadano persi; 303 è specializzato per il reindirizzamento alla pagina dei risultati dopo l'invio di un modulo POST (forza GET, evita l'invio duplicato). Memoria semplice: 301=permanente GET sicuro, 302=temporaneo GET sicuro, 307=temporaneo tutti i metodi, 308=permanente tutti i metodi, 303=salto risultati dopo POST.

Il browser memorizza nella cache in modo permanente i reindirizzamenti 301? Come si cancella la cache 301?

I reindirizzamenti permanenti 301 vengono memorizzati nella cache del browser per impostazione predefinita, ma il tempo di memorizzazione dipende dalle impostazioni di Cache-Control e Expires nell'header di risposta. Se non vengono specificati esplicitamente header di cache, il comportamento di memorizzazione predefinito varia tra i browser: Chrome di solito memorizza i reindirizzamenti 301 per settimane o mesi (potrebbe essere memorizzato anche dopo il riavvio del browser); Firefox memorizza 301 per impostazione predefinita ma potrebbe ri-verificare dopo il riavvio; la strategia di cache di Safari è relativamente conservativa. Metodi per cancellare la cache 301: 1) Chrome: Impostazioni → Privacy e sicurezza → Cancella dati di navigazione → Intervallo di tempo seleziona «Tutto il tempo» → seleziona «Immagini e file memorizzati nella cache» → Cancella dati; 2) quando sono aperti gli strumenti per sviluppatori (F12), seleziona «Disable cache» nel pannello Network; 3) aggiungi parametri di query senza significato dopo l'URL (?nocache=1) per bypassare la cache; 4) gli sviluppatori Chrome possono Flush sockets in chrome://net-internals/#sockets, oppure Clear host cache in chrome://net-internals/#dns; 5) in fase di test utilizza reindirizzamenti temporanei 302 invece di 301, dopo aver confermato la correttezza passa a 301.

Qual è la differenza tra Meta Refresh e reindirizzamento HTTP? Qual è migliore?

Meta Refresh è un reindirizzamento implementato tramite il tag <meta> nel documento HTML (es. <meta http-equiv="refresh" content="0;url=https://example.com/new">), viene eseguito dopo che il browser ha analizzato l'HTML, mentre il reindirizzamento HTTP viene indicato direttamente dal server a livello di protocollo HTTP tramite codice di stato 3xx. Confronto delle differenze: 1) Velocità: il reindirizzamento HTTP inizia a saltare quando riceve l'header di risposta, Meta Refresh deve attendere il download e l'analisi dell'HTML prima di saltare, è più lento; 2) SEO: Google di solito riconosce Meta Refresh e trasferisce il peso (se delay=0), ma ufficialmente consiglia l'uso di reindirizzamenti HTTP 301/302, perché Meta Refresh è un reindirizzamento lato client, il segnale non è chiaro come quello lato server; 3) Ritardo: Meta Refresh può impostare un tempo di ritardo (es. content="5;url=..." significa salto dopo 5 secondi), ma il reindirizzamento HTTP non ha questa funzione; 4) Accessibilità: W3C non consiglia l'uso di Meta Refresh, perché le tecnologie assistive come gli screen reader lo gestiscono male, e potrebbe confondere gli utenti; 5) Pulsante indietro: Meta Refresh in alcuni browser potrebbe rompere il comportamento del pulsante indietro. Conclusione: dai sempre la priorità all'uso di reindirizzamenti HTTP 301/302/307/308, evita Meta Refresh, a meno che tu non possa controllare la configurazione del server (es. ospitato su piattaforme di pagine statiche che non consentono di configurare regole lato server).

Il reindirizzamento influisce sull'LCP nei Core Web Vitals?

Sì, e l'impatto è molto grande. Il reindirizzamento si verifica prima che il browser ottenga il documento HTML, il che significa che ogni salto di reindirizzamento ritarda l'ora di inizio del download del documento HTML. L'LCP (Largest Contentful Paint) viene calcolato a partire dall'ora di inizio della navigazione, e il browser deve iniziare ad analizzare il DOM, caricare i CSS e renderizzare l'elemento LCP solo dopo aver ottenuto l'HTML finale. Supponendo che ogni salto di reindirizzamento aggiunga 150 ms di ritardo di rete (DNS+TCP+TLS+richiesta risposta), 3 salti di reindirizzamento faranno aumentare l'LCP di almeno 450 ms, il che è sufficiente per spingere l'LCP da «buono» (≤2,5s) all'intervallo «da migliorare» (2,5-4s). La documentazione sui Core Web Vitals di Google elenca esplicitamente l'«evitare reindirizzamenti multipli» come uno dei suggerimenti chiave per ottimizzare l'LCP. Migliori pratiche: assicurati che le pagine principali abbiano zero reindirizzamenti (link diretti all'URL finale), i reindirizzamenti necessari come HTTP→HTTPS e la normalizzazione www siano controllati a un singolo salto.

Come si controlla dove salta finalmente un URL breve?

Gli URL brevi (t.cn, bit.ly, dwz.cn, url.cn, ecc.) di solito raggiungono l'URL finale attraverso 1-3 salti di reindirizzamento, nel mezzo potrebbero esserci parametri di tracciamento UTM, reindirizzamenti di rilevamento dispositivo, reindirizzamenti geografici, ecc. Utilizzando questo strumento puoi: 1) inserire l'URL breve (incluso http:// o https://); 2) fare clic su traccia per visualizzare il percorso completo di ogni salto; 3) visualizzare l'URL finale di destinazione, il numero di salti, il tipo di codice di stato; 4) controllare se ci sono downgrade HTTP o cross-domain anomali nei reindirizzamenti intermedi. Nota: alcuni URL brevi restituiscono diverse destinazioni finali in base allo User-Agent o alla regione IP, questo strumento utilizza l'IP del server per le richieste, i risultati potrebbero differire leggermente da quelli visualizzati direttamente nel tuo browser (specialmente per i servizi di URL brevi stranieri). Per gli URL brevi url.cn di WeChat/QQ, potrebbe essere necessario accedere all'interno dell'ambiente WeChat per saltare correttamente alla pagina di destinazione.

Per il reindirizzamento forzato HTTPS si usa 301 o 302? È necessario aggiungere HSTS?

Il reindirizzamento forzato HTTPS dovrebbe utilizzare il reindirizzamento permanente 301, perché il passaggio da HTTP a HTTPS è una modifica permanente, non un salto temporaneo. Dopo aver configurato 301, dovresti anche distribuire l'header di risposta HSTS. Lo schema completo di forzatura HTTPS si divide in tre fasi: 1) Prima fase (periodo di test): configura prima il reindirizzamento 301 HTTP→HTTPS, non abilitare HSTS, osserva per 1-2 settimane per confermare che tutte le risorse e i sottodomini funzionino correttamente; 2) Seconda fase (periodo stabile): aggiungi l'header di risposta Strict-Transport-Security, inizialmente imposta max-age per un tempo più breve (es. max-age=300 cioè 5 minuti), aumenta gradualmente fino a max-age=31536000 (1 anno); 3) Terza fase (Preload): dopo aver confermato che tutti i sottodomini supportano HTTPS, aggiungi includeSubDomains e la direttiva preload, poi invia all'HSTS Preload List (hstspreload.org), in modo che il browser integri la strategia HSTS del tuo dominio, eliminando la finestra HTTP del primo accesso. Nota che una volta che HSTS viene memorizzato nella cache del browser, non può essere revocato dal lato server prima della scadenza di max-age, quindi assicurati di testare a fondo.

Qual è la differenza tra il salto window.location di JavaScript e il reindirizzamento HTTP?

Il salto JavaScript (es. window.location.href='https://example.com') e il reindirizzamento HTTP 3xx hanno differenze essenziali: 1) Livello di esecuzione: il reindirizzamento HTTP viene restituito dal server con codice di stato a livello di protocollo, il browser salta immediatamente quando riceve l'header di risposta; il salto JS richiede il download dell'HTML, l'analisi e l'esecuzione di JS prima di saltare, è più lento; 2) SEO: i crawler dei motori di ricerca possono riconoscere e tracciare correttamente i reindirizzamenti HTTP 301/302 e trasferire il peso, ma l'effetto SEO dei salti JS dipende dal fatto che il crawler esegua o meno JS e dal momento dell'esecuzione, il segnale è debole e instabile; 3) Passaggi intermedi: prima del salto JS la pagina ha già iniziato a caricarsi (potrebbe apparire uno schermo bianco o un lampeggio di parte del contenuto), il reindirizzamento HTTP porta l'utente direttamente alla pagina di destinazione, l'esperienza è più fluida; 4) Affidabilità: JS potrebbe essere bloccato dal browser, da plugin o da Content Security Policy, il reindirizzamento HTTP è gestito dal core del browser, l'affidabilità è la più alta. Conclusione: quando è necessario reindirizzare URL in modo permanente/temporaneo, utilizza sempre reindirizzamenti HTTP 301/302 lato server, i salti JS vengono utilizzati solo per la navigazione delle pagine nella logica interattiva (es. salto dopo la validazione del modulo, salto dopo il clic del pulsante, ecc.).

La catena di reindirizzamento causa risultati imprecisi nei test A/B?

Sì, la catena di reindirizzamento ha un impatto multiforme sui test A/B: 1) se il test A/B viene implementato tramite reindirizzamento (50% degli utenti 302 alla versione A, 50% alla versione B), il ritardo di reindirizzamento farà sì che la velocità di caricamento delle pagine delle due versioni sia diversa, la velocità stessa potrebbe influenzare il tasso di conversione (la versione più veloce ha naturalmente un tasso di conversione più alto), causando una deviazione del test; 2) durante il reindirizzamento potrebbero andare persi i parametri UTM o i marcatori di origine, causando dati di attribuzione imprecisi; 3) se il reindirizzamento 302 dura troppo a lungo, Google potrebbe autonomamente giudicarlo come 301 e trasferire il peso, influenzando la SEO delle pagine di test; 4) se in una catena di reindirizzamento a più salti un salto imposta un Cookie, potrebbe influenzare la logica di raggruppamento degli utenti. Si consiglia di utilizzare il rendering lato server o il split JS lato client (es. Google Optimize, Optimizely) per i test A/B, evitando l'uso di split tramite reindirizzamento. Se è obbligatorio usare il reindirizzamento (es. test di percorsi URL completamente diversi), usa 302 (non 301) e assicurati di raggiungere in un solo salto, rimuovi tempestivamente il reindirizzamento al termine del test.

Come si controlla in batch la catena di reindirizzamento dell'intero sito?

Il controllo batch della catena di reindirizzamento del sito richiede la combinazione di strumenti di crawler: 1) utilizza strumenti di crawler come Screaming Frog SEO Spider per scansionare l'intero sito, visualizza tutti gli URL di reindirizzamento e la lunghezza della catena nel report Redirect Chains; 2) utilizza le funzioni di audit del sito di strumenti SEO come Ahrefs, Semrush o Sitebulb, che rilevano automaticamente catene e cicli di reindirizzamento; 3) per l'elenco delle pagine principali, puoi scrivere script per chiamare l'API back-end di questo strumento per il rilevamento batch; 4) nel report «Indice delle pagine» di Google Search Console visualizza i suggerimenti per «errori di reindirizzamento» e «catena di reindirizzamento troppo lunga»; 5) utilizza l'audit Lighthouse di Chrome DevTools, la sezione Performance indicherà i problemi di reindirizzamento. Si consiglia di controllare in via prioritaria: home page, pagine di navigazione principali, pagine di destinazione ad alto traffico, pagine recentemente migrate/ristrutturate, tutti gli URL HTTP dopo il passaggio a HTTPS, tutti gli URL sotto il vecchio dominio.

术语表

Reindirizzamento (Redirect)
Meccanismo tramite il quale il server indica al client di accedere automaticamente a un altro URL restituendo un codice di stato 3xx e un header di risposta Location. Il reindirizzamento è solitamente trasparente per l'utente, il browser segue automaticamente il salto.
301 Moved Permanently
Codice di stato di reindirizzamento permanente. Indica che la risorsa è stata spostata permanentemente in una nuova posizione, i motori di ricerca trasferiscono il PageRank del vecchio URL al nuovo URL, il browser memorizza nella cache questo reindirizzamento a lungo termine. Consigliato per le migrazioni di dominio, i passaggi a HTTPS e altre modifiche permanenti in scenari di richieste GET.
302 Found
Codice di stato di reindirizzamento temporaneo (originariamente chiamato Moved Temporarily). Indica che la risorsa si trova temporaneamente in un'altra posizione, i motori di ricerca non trasferiscono il peso, il browser non la memorizza nella cache a lungo termine. Nota: dopo aver ricevuto 302, la maggior parte dei browser trasforma una richiesta POST in una richiesta GET per il reindirizzamento, il corpo della richiesta potrebbe andare perso.
303 See Other
Codice di stato di visualizzazione di un'altra posizione. Solitamente utilizzato per il reindirizzamento alla pagina dei risultati dopo l'invio di un modulo POST, richiede esplicitamente al client di richiedere il nuovo URL con il metodo GET, per evitare l'invio duplicato del modulo. Le risposte 303 non dovrebbero essere memorizzate nella cache.
307 Temporary Redirect
Codice di stato di reindirizzamento temporaneo (introdotto in HTTP/1.1). Stessa semantica di 302, ma richiede rigorosamente di conservare il metodo e il corpo della richiesta — una richiesta POST che riceve 307 deve ancora richiedere il nuovo URL con il metodo POST, non perdendo i dati del modulo. Adatto per reindirizzamenti temporanei in scenari API e di moduli.
308 Permanent Redirect
Codice di stato di reindirizzamento permanente (definito in RFC 7538). Stessa semantica di 301, ma richiede rigorosamente di conservare il metodo e il corpo della richiesta — una richiesta POST che riceve 308 viene ancora reindirizzata con il metodo POST. È la versione «sicura per il metodo» di 301, completamente supportata dai browser moderni.
Header Location
Campo dell'header di risposta HTTP, utilizzato per specificare l'URL di destinazione nelle risposte di reindirizzamento 3xx. Può essere un URL assoluto (consigliato) o un URL relativo, dopo averlo ricevuto il client avvia automaticamente una nuova richiesta a quell'URL. I caratteri non ASCII nell'header Location devono essere codificati in URL.
Catena di reindirizzamento (Redirect Chain)
Serie di reindirizzamenti consecutivi tra l'URL iniziale e l'URL finale di destinazione. Ad esempio A→B→C→D forma una catena di reindirizzamento a 3 salti. Le catene di reindirizzamento troppo lunghe rallentano la velocità di caricamento e consumano peso SEO, si consiglia di mantenerle a un singolo salto, massimo non oltre 3 salti.
Loop di reindirizzamento (Redirect Loop)
Un URL si ripete nella catena di reindirizzamento, formando un ciclo infinito di salti (es. A→B→A). Dopo aver raggiunto il numero massimo di salti (di solito 20 volte), il browser visualizza l'errore ERR_TOO_MANY_REDIRECTS. Le cause comuni includono salti reciproci HTTP↔HTTPS, salti reciproci www↔non-www e perdita del protocollo reverse proxy.
Migrazione dominio (Domain Migration)
Processo in cui un sito passa permanentemente da un dominio a un altro, come il cambio di dominio del marchio, l'acquisizione o la fusione di aziende. Durante la migrazione, tutti gli URL del vecchio dominio devono essere reindirizzati in modo permanente con 301 alle pagine corrispondenti del nuovo dominio, e presentare una notifica di modifica del dominio in Google Search Console.
Normalizzazione URL (URL Canonicalization)
Processo di unificazione di più varianti di URL per lo stesso contenuto (www/non-www, con/senza barra finale, HTTP/HTTPS, differenze di maiuscole/minuscole) in un unico URL standard, solitamente implementato tramite reindirizzamento 301. La normalizzazione evita problemi di contenuto duplicato e concentra il peso SEO.
Reindirizzamento forzato HTTPS
Configurazione per reindirizzare tutte le richieste HTTP (porta 80) a HTTPS (porta 443) tramite 301, passaggio necessario dopo la distribuzione di certificati SSL/TLS. Di solito viene utilizzato insieme all'header di risposta HSTS per eliminare la finestra di primo accesso in chiaro HTTP.
HSTS
HTTP Strict Transport Security, tramite l'header di risposta Strict-Transport-Security dice al browser che nel tempo specificato può accedere a quel dominio solo tramite HTTPS, il browser aggiorna automaticamente HTTP a HTTPS internamente, senza bisogno di reindirizzamento del server. Difende efficacemente dagli attacchi SSL Stripping.
URL breve (Short URL)
Servizio che converte URL lunghi in URL brevi (es. bit.ly, t.cn), all'accesso reindirizza all'URL originale tramite 301/302. Dietro gli URL brevi spesso si nascondono catene di reindirizzamento a più salti, che possono contenere parametri di tracciamento o saltare a destinazioni diverse in determinate condizioni.
PageRank
Algoritmo di ranking delle pagine web inventato dai fondatori di Google Larry Page e Sergey Brin, valuta l'autorità della pagina attraverso le relazioni di link. I reindirizzamenti permanenti 301 trasferiscono il PageRank del vecchio URL al nuovo URL, mentre i reindirizzamenti temporanei 302 di solito non lo trasferiscono o lo trasferiscono pochissimo.
Core Web Vitals
Indicatori chiave dell'esperienza web definiti da Google, inclusi LCP (Largest Contentful Paint, misura delle prestazioni di caricamento, buono ≤2,5s), FID/INP (reattività interattiva, buono ≤100ms/200ms) e CLS (stabilità visiva, buono ≤0,1). La catena di reindirizzamento ritarda il download dell'HTML, deteriorando direttamente l'indicatore LCP.
Reindirizzamento cross-domain (Cross-origin Redirect)
L'URL di destinazione del reindirizzamento ha un dominio diverso dall'URL originale (inclusi domini completamente diversi o sottodomini diversi). Il reindirizzamento cross-domain è limitato dalla politica di origine uguale, che può causare il mancato invio dei Cookie, il blocco dei Cookie di terze parti, il fallimento del preflight CORS e altri problemi.
Troncamento catena (Chain Truncation)
Quando il numero di salti della catena di reindirizzamento supera il limite massimo di profondità impostato dallo strumento o dal browser (questo strumento 20 salti, Chrome 20 salti), il tracker smette di seguire i reindirizzamenti successivi e marca la catena come troncata. Il troncamento della catena di solito indica la presenza di cicli infiniti o configurazioni di reindirizzamento anomale e complesse.

Tabella di confronto completa dei codici di stato di reindirizzamento HTTP

301Moved PermanentlySì (permanente)Può cambiare (POST→GET)Migrazione dominio, passaggio HTTPS, normalizzazione www/non-www, modifica permanente URL
302FoundNo (temporaneo)Può cambiare (POST→GET)Pagine di manutenzione temporanea, salti di login, test A/B, pagine di promozioni a breve termine
303See OtherNo (temporaneo)Sì (forza GET)Reindirizzamento alla pagina dei risultati dopo l'invio di un modulo POST, per evitare l'invio duplicato
307Temporary RedirectNo (temporaneo)No (mantiene rigorosamente il metodo originale)Reindirizzamento temporaneo API, reindirizzamenti temporanei che devono conservare i dati POST
308Permanent RedirectSì (permanente)No (mantiene rigorosamente il metodo originale)Migrazione permanente API RESTful, reindirizzamenti permanenti che devono conservare i metodi PUT/DELETE

Tabella di confronto dell'impatto della catena di reindirizzamento sulla SEO

0 salti (accesso diretto)Nessun impatto, stato ottimaleNessun ritardo aggiuntivoMantieni la situazione attuale, i link interni puntano direttamente all'URL finale
1 saltoPassaggio PageRank normale, impatto SEO trascurabileAggiunge circa 100-300 ms di ritardo (un round trip)Accettabile, numero comune di salti per HTTP→HTTPS e normalizzazione del dominio
2 saltiIl trasferimento del peso potrebbe avere una leggera attenuazione, i crawler possono tracciare normalmenteAggiunge circa 200-600 ms di ritardoSi consiglia di ottimizzare a un singolo salto, controlla se i link interni puntano a URL di reindirizzamento intermedio
3 saltiEfficienza di trasferimento del peso ridotta, alcuni crawler potrebbero abbandonare il tracciamentoAggiunge circa 300-900 ms di ritardo, l'LCP potrebbe essere influenzatoDeve essere ottimizzato, unisci le regole di reindirizzamento direttamente all'URL finale
4-5 saltiPageRank notevolmente attenuato, l'indicizzazione potrebbe essere influenzata, spreco di budget di scansioneAggiunge 500 ms-1,5 s di ritardo, l'LCP probabilmente supera la sogliaCorrezione urgente, controlla la sovrapposizione di reindirizzamenti multilivello CDN/server di origine/applicazione
6 salti o piùRischio grave, i motori di ricerca potrebbero interrompere il tracciamento causando la deindicizzazione della paginaRitardo superiore a 1 secondo, esperienza utente pessimaRisolvi immediatamente cicli o errori di configurazione, ricostruisci le regole di reindirizzamento
Ciclo (ERR_TOO_MANY_REDIRECTS)Pagina completamente inaccessibile, i motori di ricerca la rimuovono dall'indicePagina impossibile da caricare, il browser mostra un erroreCorrezione con massima priorità, utilizza questo strumento per individuare i nodi del ciclo

Errori comuni nella configurazione del reindirizzamento e soluzioni

Errore di ciclo ERR_TOO_MANY_REDIRECTS, salti ripetuti HTTP↔HTTPSCDN/load balancer ritorna all'origine in HTTP, il server di origine non gestisce correttamente l'header X-Forwarded-Proto, reindirizza sempre a HTTPSAggiungi nella configurazione Nginx: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } oppure utilizza la variabile $scheme insieme alla configurazione proxy_set_header X-Forwarded-Proto
www e non-www si reindirizzano reciprocamente formando un cicloIl livello CDN configura il salto www→non-www, l'Nginx del server di origine configura il salto non-www→www, le regole si conflittanoScegli una versione normalizzata (consigliato non-www o www, mantieni la coerenza), configura il reindirizzamento solo a un livello (CDN o server di origine), elimina le regole corrispondenti negli altri livelli
La catena di reindirizzamento impiega 4-5 salti per raggiungere la pagina finaleSalto HTTP→HTTPS → salto non-www→www → salto aggiunta barra finale → salto vecchio percorso→nuovo percorso, sovrapposizione di regole multilivelloUnisci le regole di reindirizzamento, salta direttamente dall'URL iniziale all'URL finale in un solo passaggio. In Nginx utilizza la direttiva return per saltare direttamente all'indirizzo finale completo
Nel sito HTTPS compare un nodo HTTP nella catena di reindirizzamento (downgrade)Nella configurazione del server sono hardcodate le destinazioni di reindirizzamento con prefisso http://, oppure l'applicazione genera l'URL di reindirizzamento senza riconoscere che la corrente è HTTPSConfigura l'applicazione per fidarsi del reverse proxy, leggi correttamente X-Forwarded-Proto; in Nginx utilizza URL assoluti https:// o la variabile $scheme (a condizione che il proxy abbia impostato correttamente lo scheme); distribuisci HSTS
Dopo la modifica del reindirizzamento 301 il browser salta ancora al vecchio indirizzoIl browser memorizza nella cache a lungo termine le regole di reindirizzamento permanente 301, l'aggiornamento F5 non ha effettoIn fase di test utilizza prima reindirizzamenti temporanei 302 per confermare la correttezza, poi passa a 301; svuota la cache del browser (Chrome: Impostazioni → Privacy → Cancella dati di navigazione → Immagini e file memorizzati nella cache); utilizza l'opzione Disable cache di DevTools
Dopo il reindirizzamento della richiesta POST i dati del modulo vanno persiÈ stato utilizzato un reindirizzamento 301 o 302, il browser trasforma automaticamente POST in GET, il corpo della richiesta viene scartatoPer le richieste non GET come POST/PUT/DELETE, passa invece a reindirizzamenti 307 (temporaneo) o 308 (permanente), mantieni rigorosamente il metodo e il corpo della richiesta
Dopo il reindirizzamento nell'URL compaiono caratteri codificati doppi come %2520I parametri URL sono già stati codificati una volta con codifica URL, il server li codifica di nuovo durante il reindirizzamentoControlla la logica di reindirizzamento, assicurati che l'URL venga codificato una sola volta; in Nginx utilizza $request_uri (URI originale, non decodificato) invece di $uri (decodificato)
Richieste AJAX/fetch dopo reindirizzamento cross-domain segnalano errore CORSIl server di destinazione del reindirizzamento cross-domain non ha configurato gli header di risposta CORS (Access-Control-Allow-Origin, ecc.)Assicurati che i server di ogni salto nella catena di reindirizzamento abbiano gli header CORS configurati correttamente; oppure evita di usare reindirizzamenti cross-domain nelle richieste AJAX, passa invece a richieste dirette dopo che il front-end ottiene l'URL di destinazione

Troubleshooting