Dimensione CoreDash: Redirect Count
Misura quanti redirect HTTP colpiscono gli utenti prima di raggiungere la tua pagina e il loro costo diretto sul TTFB.
Dimensione: Navigazione: Redirect Count (redir)
La dimensione redir conta i redirect HTTP prima di raggiungere la pagina finale. I valori sono 0, 1, 2 o 3+. Ogni redirect è un intero round trip di rete che avviene prima ancora che il tuo server inizi a generare l'HTML.
Su una connessione con 100ms di RTT, un redirect aggiunge 100ms al TTFB. Su una connessione mobile da 200ms, il valore raddoppia. Due redirect su mobile: 400ms di pura attesa prima che il browser riceva un singolo byte della tua pagina. Questa latenza è invisibile nei test di laboratorio che colpiscono direttamente l'URL finale, ma gli utenti reali che seguono link, segnalibri o risultati di ricerca la assorbono ad ogni visita.

I valori
0 redirect
Lo stato obiettivo. Il browser ha colpito l'URL finale alla prima richiesta. Tutte le navigazioni interne dovrebbero produrre questo valore. Se i link del tuo sito, le sitemap e i tag canonical sono corretti, il traffico interno rimane a 0.
1 redirect
Comune per il traffico esterno: upgrade da HTTP a HTTPS, normalizzazione www o URL di campagne marketing. Accettabile per i link in entrata che non controlli. Non accettabile per i tuoi link interni. Se CoreDash mostra 1 redirect sulle navigazioni interne, i tuoi link puntano a URL vecchi o incoerenti.
2+ redirect
Catene di redirect (Redirect chains). Un URL abbreviato reindirizza a un dominio di tracciamento, che reindirizza al tuo endpoint HTTP, che reindirizza a HTTPS. Tre salti, tre round trip. Raggruppa per URL per trovare quali punti di ingresso creano queste catene, quindi elimina gli intermediari.
Da dove provengono i redirect
- Da HTTP a HTTPS: Link interni obsoleti che puntano ancora a
http://. Aggiorna tutti i link, le sitemap e i tag canonical per usare direttamentehttps://. - Normalizzazione www: Incoerenza tra www e non-www. Imponi una scelta a livello DNS e aggiorna tutti i riferimenti.
- Cambiamenti di slug nel CMS: Vecchi percorsi che reindirizzano ai nuovi tramite 301. Va bene per i backlink esterni, ma aggiorna ogni link interno perché punti direttamente al nuovo slug.
- Vanity URL di marketing: Percorsi personalizzati come
/saldi-primaverache reindirizzano a/prodotti/stagionali. Ogni visitatore paga il costo della latenza ad ogni clic. - URL shortener in email e social: Link che passano attraverso Bitly, pixel di tracciamento o provider di servizi email prima di raggiungere il tuo dominio. Ogni servizio aggiunge un round trip che non puoi controllare, ma puoi minimizzare i tuoi redirect in modo che il totale rimanga basso.
Workflow di debug
- Filtra per redir ≥ 1: Vedi quale percentuale del tuo traffico totale colpisce almeno un redirect. Qualsiasi valore superiore al 15% merita un'indagine.
- Raggruppa per URL: Trova quali landing page sono le peggiori. Le pagine di marketing e i vecchi post del blog con slug modificati tendono a dominare.
- Separa interno vs esterno: Filtra per navigation origin. Il traffico dallo stesso dominio con redirect significa che i tuoi link sono sbagliati. I redirect cross-origin sono più difficili da correggere ma meno urgenti.
- Correggi la fonte, non il redirect: Non ottimizzare il redirect in sé (risposta del server più veloce). Eliminalo aggiornando il link che l'ha causato.
Regole empiriche per l'ingegneria
- 0 redirect su tutta la navigazione interna. Nessun redirect dal tuo sito è accettabile quando controlli il link di origine.
- Controlla dopo ogni migrazione di URL. Quando cambi slug o sposti pagine, cerca (grep) nel tuo codebase e nel CMS i vecchi percorsi. I redirect sono una rete di sicurezza per i link esterni, non un sostituto per l'aggiornamento dei tuoi riferimenti.
- Prevedi 150ms per redirect su mobile. Se il tuo obiettivo di TTFB è 800ms e gli utenti colpiscono due redirect, hai già speso 300ms prima che il tuo server faccia qualsiasi lavoro.
I redirect sono la vittoria più facile da trovare e correggere per il TTFB. Nessuna modifica al codice, nessuna sintonizzazione del server, nessuna ottimizzazione degli asset. Basta aggiornare l'URL che punta al posto sbagliato.