Tipi di reindirizzamenti URL: 301, 302, 307, 308 e altri

I tipi di reindirizzamento URL sono più numerosi di quanto suggerisca il dibattito 301 contro 302, e scegliere quello sbagliato può costare silenziosamente velocità o posizionamento. Si dividono in due famiglie. I reindirizzamenti HTTP lato server sono codici di stato restituiti dal server prima che la pagina venga caricata - 301, 302, 303, 307, 308. I reindirizzamenti lato client avvengono nel browser dopo il caricamento della pagina - un tag meta refresh o un salto tramite JavaScript. Lato server è più veloce e pulito sia per gli utenti sia per i crawler; lato client è più lento e debole, e vi si ricorre solo quando il server è fuori dal proprio controllo.

Mi occupo del percorso di reindirizzamento, quindi sarò concreto: cosa fa ciascun tipo sulla rete, come lo leggono i motori di ricerca e quale usare effettivamente. Se vuoi un approfondimento sui due che userai di più, reindirizzamenti 301 vs 302 copre quella coppia in dettaglio; questo articolo è la mappa completa.

La versione breve in anticipo: per uno spostamento permanente usa un 301, per uno temporaneo un 302, aggiungi 308/307 che preservano il metodo quando un POST deve sopravvivere, ed evita le opzioni lato client a meno che non ci sia un server da configurare.

Le due famiglie di reindirizzamenti#

Un reindirizzamento è semplicemente un'istruzione ad andare altrove, ma dove si trova quell'istruzione cambia tutto il suo comportamento.

Un reindirizzamento lato server è il server che risponde "non qui, vai là" prima che venga inviato qualsiasi contenuto della pagina. Il browser riceve un codice di stato e un'intestazione Location e si sposta immediatamente - nessun contenuto viene caricato all'URL originale, quindi è rapido e non ambiguo. Un reindirizzamento lato client è l'opposto: la pagina originale si carica completamente, e solo allora un meta tag o uno script invia il visitatore avanti. Ciò significa un caricamento di pagina sprecato, un lampeggio visibile e un segnale più debole per i motori di ricerca, che devono caricare e a volte eseguire la pagina per notare il reindirizzamento. Le definizioni formali dei codici lato server si trovano in RFC 9110, e il comportamento pratico del browser è documentato nella guida MDN ai reindirizzamenti HTTP.

Questa singola distinzione - prima della pagina o dopo - è il motivo per cui il resto di questo articolo torna continuamente su "usa un reindirizzamento lato server quando puoi".

I reindirizzamenti con codice di stato HTTP#

Questi sono i veri reindirizzamenti, restituiti dal server nell'intervallo 3xx. Cinque sono rilevanti.

I due assi che organizzano la tabella sono la permanenza e la gestione del metodo. La permanenza è l'asse SEO: 301 e 308 sono permanenti, quindi i motori di ricerca trasmettono i segnali di ranking e trattano la destinazione come canonica, mentre 302, 303 e 307 sono temporanei e mantengono indicizzato l'URL originale. La gestione del metodo è l'asse tecnico: 307 e 308 preservano rigorosamente il metodo HTTP, quindi un POST rimane un POST, mentre 301 e 302 storicamente permettevano che derivasse verso un GET. Il 303 è quello anomalo, creato specificamente per forzare un GET dopo l'invio di un modulo in modo che un aggiornamento della pagina non reinvii i dati. La documentazione sui reindirizzamenti di Google conferma che tratta i codici permanenti come segnali di canonicalizzazione.

Per i normali link web, che sono richieste GET, l'asse del metodo scompare e la scelta è davvero tra permanente e temporaneo - che è esattamente la decisione 301 vs 302.

Reindirizzamenti lato client: meta refresh e JavaScript#

Quando non puoi configurare il server, rimangono due opzioni a livello di browser, ed entrambe sono compromessi.

Un meta refresh è un tag HTML nell'intestazione della pagina che indica al browser di caricare un nuovo URL dopo un ritardo - il classico "sarai reindirizzato tra 5 secondi". Funziona, ma la pagina è già stata caricata prima che si attivi, quindi è lento, e i motori di ricerca lo leggono in modo incoerente: un meta refresh istantaneo è solitamente trattato come un reindirizzamento permanente, mentre uno ritardato è ambiguo e può essere interpretato come un soft 404. Un reindirizzamento JavaScript è ancora più debole, perché si attiva solo se il crawler esegue lo script. Google esegue il rendering di JavaScript, ma con un ritardo, e molti altri crawler non lo eseguono affatto, quindi il reindirizzamento può essere completamente mancato.

La classificazione onesta delle opzioni è semplice: un 3xx lato server prima di tutto, un meta refresh solo se controlli l'HTML ma non il server, e un reindirizzamento JavaScript come ultima risorsa quando non controlli nient'altro. Niente di tutto ciò si applica a un link breve gestito, che usa sempre un reindirizzamento lato server - le tecniche lato client sono per situazioni come un host statico senza configurazione dei reindirizzamenti.

Quale reindirizzamento dovresti usare#

Riducilo a una decisione che puoi prendere in un solo passaggio.

• Spostamento permanente, link ordinario: 301. Trasferimento completo del ranking, trattato come canonico.
• Spostamento temporaneo, link ordinario: 302. Mantiene indicizzato l'originale e il link modificabile.
• Lo spostamento riguarda un POST o una chiamata API: usa 308 per permanente o 307 per temporaneo, in modo che il metodo sopravviva.
• Dopo l'invio di un modulo: 303, in modo che un aggiornamento della pagina non reinvii il modulo.

La meta-regola dietro tutti e quattro: fai corrispondere il codice di stato alla verità sullo spostamento - è permanente? Il metodo è importante? Sbagliare questa corrispondenza è il modo in cui i reindirizzamenti perdono silenziosamente ranking o rompono un modulo.

Se vuoi che entrambi funzionino correttamente senza configurare manualmente un web server, [inizia gratuitamente con Elido](/pricing) e lascia che il livello di link gestisca il reindirizzamento.

Cosa usano i link brevi#

Un link breve gestito è un reindirizzamento lato server, e per una buona ragione - appartiene alla famiglia veloce e compatibile con i crawler. La scelta interessante è quale codice, e la risposta per la maggior parte dei link brevi è un 302.

Questo sembra sbagliato per la SEO finché non si ricorda a cosa serve un link breve. Un 302 mantiene il link modificabile, così puoi reindirizzarlo dopo che è stato stampato o condiviso, e mantiene ogni clic che raggiunge il server, così le tue analisi rimangono precise - entrambe le cose che un 301 memorizzato nella cache ti costerebbe. Il ragionamento completo, inclusa la trappola della cache del browser, è in reindirizzamenti 301 vs 302, e i meccanismi di come il reindirizzamento si risolve al edge sono in come funzionano gli accorciatori di URL. L'unica regola che si applica indipendentemente dal codice: mantienilo a un singolo salto. Un reindirizzamento che punta a un altro reindirizzamento spreca budget di scansione e latenza, ed è il modo più rapido per annullare la SEO che i link brevi altrimenti preservano.

L'intera mappa si riassume in una frase: codici lato server per i veri reindirizzamenti, permanente versus temporaneo per la SEO, varianti che preservano il metodo per le richieste non-GET, e trucchi lato client solo quando il server è inaccessibile. Scegli in base alla verità dello spostamento, mantieni la catena a un solo salto, e i tuoi reindirizzamenti faranno ciò che intendevi.

Correlati sul blog#

• Reindirizzamenti 301 vs 302: quale dovrebbero usare i link brevi
• Gli accorciatori di URL danneggiano la SEO? La risposta onesta
• Come funzionano gli accorciatori di URL sotto il cofano
• Raggiungere p95 sotto 15ms per i reindirizzamenti da FRA, ASH e SGP
• Strategia di cache per i reindirizzamenti URL: L1 LRU + L2 Redis