Codici di stato di reindirizzamento 3xx

Come funziona un reindirizzamento

Un reindirizzamento è due richieste, non una. Il client chiede l'URL A, il server risponde con uno stato 3xx e un header Location che nomina l'URL B, e il client fa allora una nuova richiesta a B. I browser lo seguono automaticamente, quindi un visitatore vede solo la pagina finale e l'URL finale nella barra degli indirizzi. La risposta intermedia costa comunque un round trip completo, motivo per cui le lunghe catene di reindirizzamento sono lente.

Due proprietà distinguono i codici 3xx tra loro. La prima è la permanenza: un reindirizzamento permanente dice a client e crawler che il vecchio URL è ritirato e quello nuovo dovrebbe sostituirlo in segnalibri, link e indici, mentre un reindirizzamento temporaneo dice che il vecchio URL è ancora quello reale e tornerà. La seconda è la preservazione del metodo. I codici più vecchi permettevano a un client di trasformare una POST in una GET quando segue il reindirizzamento, e quelli più nuovi lo vietano, quindi una POST resta una POST. È la differenza tra un invio di form che arriva intatto al nuovo URL e uno che arriva come una GET vuota.

Ogni codice 3xx e cosa significa

• 300 Multiple Choices. La risorsa esiste in diverse rappresentazioni e il server lascia scegliere al client. Non esiste un formato standard leggibile da macchina per l'elenco, quindi quasi nulla lo implementa. In pratica non vedrai un 300 in circolazione. Vedi la guida 300 Multiple Choices per il motivo per cui sopravvive soprattutto come termine di ricerca.
• 301 Moved Permanently. La risorsa ha una nuova casa permanente. I motori di ricerca trasferiscono i segnali di posizionamento verso la destinazione, e i client possono mettere in cache il reindirizzamento, a volte in modo aggressivo. Questo è il codice per un cambio di dominio, uno spostamento da HTTP a HTTPS o una ristrutturazione permanente degli URL.
• 302 Found. Un reindirizzamento temporaneo. L'URL originale mantiene la sua identità, quindi i motori di ricerca normalmente continuano a indicizzare l'originale invece della destinazione. Storicamente molti client passavano al metodo GET seguendo un 302, motivo per cui lo standard sconsiglia di fare affidamento sulla preservazione del metodo qui.
• 303 See Other. "La tua richiesta è stata elaborata; ora vai e fai GET su quest'altra risorsa." Al client viene detto esplicitamente di usare GET per il passo successivo indipendentemente dal metodo originale. Questa è la risposta corretta a una POST di form che dovrebbe atterrare su una pagina di risultato.
• 304 Not Modified. Non è affatto un reindirizzamento. Risponde a una richiesta condizionale e significa "la tua copia in cache è ancora attuale, riusala". Non c'è corpo e non c'è Location. Vedi 304 Not Modified.
• 305 Use Proxy e 306 sono obsoleti. Il 305 è stato deprecato per motivi di sicurezza e il 306 non è utilizzato. Ignora entrambi.
• 307 Temporary Redirect. Stesso significato di 302, ma il metodo e il corpo devono essere preservati. Una POST che segue un 307 arriva al nuovo URL come una POST.
• 308 Permanent Redirect. Stesso significato di 301, ma il metodo e il corpo devono essere preservati.

Cosa va storto con i reindirizzamenti

• Un codice temporaneo su uno spostamento permanente. L'errore più comune e più costoso. I motori di ricerca mantengono indicizzato il vecchio URL e quello nuovo non eredita il posizionamento del vecchio.
• Un codice permanente su uno spostamento temporaneo. Più difficile da annullare, perché un 301 in cache può continuare a inviare i visitatori di ritorno nel posto sbagliato molto tempo dopo che hai rimosso la regola.
• Catene di reindirizzamento. Da http a https, poi da non-www a www, poi dal vecchio percorso al nuovo percorso sono tre round trip prima che arrivi qualsiasi contenuto. Ogni salto aggiunge latenza e ogni salto è un punto dove la catena può rompersi.
• Loop di reindirizzamento. A manda a B e B rimanda ad A, di solito perché una regola a livello applicativo e una a livello di server o CDN non sono d'accordo sulla forma canonica. I browser rinunciano dopo un numero fisso di salti e mostrano un errore.
• Tutto puntato sulla homepage. Quando le pagine ritirate reindirizzano tutte alla radice invece che al loro equivalente più vicino, il reindirizzamento viene spesso trattato come un soft 404 e il visitatore resta a cercare.
• Corpi POST persi. Un endpoint API o di form spostato dietro un 301 o 302 può perdere il suo metodo e payload con alcuni client. Usa 307 o 308 per qualsiasi cosa che non sia una semplice GET.

Come verificare e correggere i tuoi reindirizzamenti

1. Vedi cosa restituisce un URL, senza seguirlo:

   curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location)"

   Questo stampa la riga di stato e la destinazione in un colpo solo.
2. Ora segui l'intera catena e conta i salti:

   curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page

3. Riduci le catene a un solo salto. Punta l'URL originale direttamente alla destinazione finale invece di lasciarlo attraversare regole intermedie.
4. Fai corrispondere il codice all'intento. Spostamento permanente: 301, o 308 se l'endpoint accetta richieste non-GET. Spostamento temporaneo, pagina di manutenzione o split A/B: 302, o 307 dove il metodo deve sopravvivere. Flusso post-poi-reindirizza: 303.
5. Correggi i loop decidendo la forma canonica una volta sola (protocollo, host e slash finale) e imponendola esattamente in un livello. I loop quasi sempre significano che due livelli stanno entrambi cercando di essere autoritativi.
6. Ritesta con una cache fredda. Un browser che ha già messo in cache un 301 continuerà a obbedirgli, quindi verifica con curl o una finestra privata prima di concludere che la correzione non abbia funzionato.

Intercettare un reindirizzamento rotto prima che cali il traffico

I reindirizzamenti si rompono senza alcun sintomo visibile. Una regola che inizia a fare loop, o un certificato che fallisce sulla destinazione del reindirizzamento, lascia comunque il vecchio URL rispondente, quindi niente sembra sbagliato finché traffico e posizionamenti non calano. Un controllo esterno che segue la catena e asserisce lo stato finale intercetta un reindirizzamento rotto nel momento in cui compare, e controllare da molte reti distingue un cambio di regola globale da un problema regionale di CDN. HostTracker esegue controlli da oltre 300 postazioni in 158 città e avvisa via email, SMS, chiamata vocale, Slack, Telegram e altro. Testa un URL e la sua catena di reindirizzamento con lo strumento di controllo HTTP, e leggi 301 vs 302 prima di scegliere un codice.