Dimensione CoreDash: Redirect Count

Misura quanti redirect HTTP colpiscono gli utenti prima di raggiungere la tua pagina e il loro costo diretto sul TTFB.

Prova gratuita

Trusted by market leaders · Client results

workivaperionsnvloopearplugsvpnkpndpg medianina careharvarderasmusmcmarktplaatsnestlefotocasaadevintaaleteiahappyhorizoncomparemonarchmy work featured on web.devwhowhatwearebaysaturn

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.

coredash redirect count

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 direttamente https://.
  • 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-primavera che 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

  1. Filtra per redir ≥ 1: Vedi quale percentuale del tuo traffico totale colpisce almeno un redirect. Qualsiasi valore superiore al 15% merita un'indagine.
  2. 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.
  3. 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.
  4. 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.