Un redirect 301 indica che una pagina si è spostata in modo definitivo; un 302 indica che lo spostamento è temporaneo e che il vecchio indirizzo tornerà. I motori di ricerca tengono conto di questa differenza: dopo un 301 indicizzano il nuovo indirizzo al posto del vecchio, dopo un 302 di solito mantengono quello vecchio. Usa un 301 (o un 308) per tutto ciò che è permanente, come una pagina rinominata, un nuovo dominio o il passaggio a HTTPS, e un 302 (o un 307) solo quando l’indirizzo originale tornerà davvero. Fai in modo che ogni redirect abbia un solo passaggio e verificalo con uno strumento che mostri ogni step.
I codici di stato dei redirect
Un redirect è una risposta della classe 3xx con un header Location che indica il nuovo indirizzo. In pratica contano cinque codici:
CodiceSignificatoMantiene il metodoQuando usarlo301 Moved PermanentlySpostato in modo definitivoNon garantito: i browser trasformano un POST in un GETPagine rinominate, nuovi domini, da HTTP a HTTPS302 FoundTemporaneamente altroveNon garantito: i browser trasformano un POST in un GETSpostamenti di breve durata, invio dei visitatori a una pagina di login303 See OtherIl risultato si trova a un altro indirizzoNo, sempre un GETDopo l’invio di un modulo, così un ricaricamento non lo invia due volte307 Temporary RedirectTemporaneamente altroveSì, metodo e bodySpostamenti temporanei di endpoint API e moduli308 Permanent RedirectSpostato in modo definitivoSì, metodo e bodySpostamenti permanenti di endpoint API e moduli
Per le pagine normali, che i browser richiedono con GET, 301 e 308 si comportano allo stesso modo, così come 302 e 307. La differenza emerge quando un client invia un POST: dopo un 301 o un 302 la maggior parte dei client lo ripete come GET senza il body, mentre 307 e 308 lo costringono a inviare di nuovo la stessa richiesta. Per questo le API che spostano un endpoint dovrebbero usare 308 o 307. L’elenco completo dei codici è nel riferimento dei codici di stato HTTP.
Cosa fanno i redirect alla SEO
La documentazione di Google sui redirect considera permanenti 301 e 308 e temporanei 302, 303 e 307. Un redirect permanente è un segnale forte che nei risultati di ricerca va mostrata la destinazione al posto del vecchio indirizzo. Un redirect temporaneo è un segnale debole, quindi di solito il vecchio indirizzo resta indicizzato.
Da qui nascono tre errori comuni:
Un 302 per uno spostamento permanente. Molti framework e plugin reindirizzano con 302 per impostazione predefinita. Dopo una migrazione del sito, verifica che i redirect rispondano davvero con 301 o 308.
Reindirizzare tutto alla homepage. Quando una vecchia pagina non ha un equivalente, Google può trattare un redirect alla homepage come un soft 404. Manda ogni vecchia pagina alla corrispondente più vicina, oppure lascia che risponda 404 o 410.
Vecchi link che puntano a redirect. Un redirect è una rete di sicurezza, non una destinazione. Aggiorna link interni, tag canonical e sitemap all’indirizzo finale, così né i visitatori né i crawler pagano il passaggio in più.
I redirect lato server sono il segnale più chiaro. I tag meta refresh e i redirect in JavaScript funzionano per i visitatori, ma i motori di ricerca li vedono solo dopo aver caricato la pagina, e altri client potrebbero non vederli affatto.
Quale usare
Una pagina è stata rinominata o accorpata a un’altra: 301.
Il sito è passato a un nuovo dominio, a HTTPS o da www al dominio senza www (o viceversa): 301 da ogni vecchia variante direttamente all’indirizzo finale.
Una pagina si trova temporaneamente altrove, per una campagna o mentre viene rifatta: 302.
Un visitatore deve prima accedere: 302 alla pagina di login, poi di nuovo indietro.
È stato inviato un modulo: 303 alla pagina del risultato.
Un endpoint API si è spostato: 308 se in modo definitivo, 307 se per ora, così i client mantengono metodo e body.
Il sito è offline per manutenzione: nessun redirect. Rispondi 503 Service Unavailable sull’indirizzo originale, così i motori di ricerca tornano più tardi invece di indicizzare una pagina di manutenzione.
I browser ricordano i redirect permanenti
I browser memorizzano nella cache le risposte 301 e 308, spesso a lungo, e le seguono senza interpellare di nuovo il server. Un redirect permanente sbagliato continua quindi a mandare i visitatori di ritorno nel posto sbagliato anche dopo che hai corretto il server. Quando imposti una nuova regola, provala prima come 302 e passala a 301 quando è corretta. Se un 301 sbagliato è già andato online, un header Cache-Control: no-store sui redirect futuri aiuta i nuovi visitatori, ma le copie già presenti nei browser scadono secondo i loro tempi.
Catene e loop di redirect
Una catena è un redirect verso un indirizzo che reindirizza di nuovo: da http://example.com a https://example.com a https://www.example.com a https://www.example.com/en/. Ogni passaggio è un ulteriore round trip prima che la pagina inizi a caricarsi, e Google segue al massimo 10 passaggi. Le catene crescono in anni di migrazioni, ognuna delle quali aggiunge la sua regola sopra l’ultima. Si risolvono mandando ogni vecchia variante direttamente all’indirizzo finale, con un solo passaggio.
Un loop è una catena che non finisce mai: due regole rimandano i visitatori avanti e indietro finché il browser si arrende con “troppi reindirizzamenti”. Le cause tipiche:
HTTP e HTTPS. Una CDN comunica con il tuo server via HTTP, mentre il server reindirizza ogni richiesta HTTP a HTTPS. Dietro Cloudflare è l’impostazione SSL Flexible; Full (strict) risolve il problema.
www e dominio senza www. Il web server aggiunge www e l’applicazione lo toglie, o viceversa. In WordPress, verifica che l’Indirizzo WordPress e l’Indirizzo sito concordino con la regola del server.
Slash finali e regole di lingua. Una regola aggiunge uno slash o un prefisso di lingua, un’altra lo rimuove.
Come verificare un redirect
Da terminale, curl mostra ogni passaggio con il suo codice di stato e l’header Location:
curl -sIL http://example.com/old-page | grep -iE “^(HTTP|location)”
HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
HTTP/2 200
Due passaggi: la seconda regola avrebbe dovuto essere la prima. Nel browser, apri gli strumenti per sviluppatori, spunta Preserve log nella scheda Network e carica il vecchio indirizzo: ogni redirect compare su una riga a sé. Ricorda che il browser può rispondere a un 301 dalla propria cache, quindi una finestra privata dà un quadro più pulito.
Oppure usa il nostro redirect checker gratuito: inserisci un URL per vedere ogni passaggio con il suo codice di stato, dove finisce la catena e se va in loop, è troppo lunga o usa un redirect temporaneo dove probabilmente ne volevi uno permanente. Segue fino a 5 passaggi, verificati in tempo reale da Stoccolma.
Impostare un 301
La maggior parte degli hosting e delle CDN ha un’impostazione per i redirect nella dashboard. Nella configurazione del server:
# nginx: one page
location = /old-page { return 301 /new-page; }
# nginx: a whole domain, keeping the path
server {
server_name old-example.com www.old-example.com;
return 301 https://example.com$request_uri;
}
# Apache (.htaccess): one page
Redirect 301 /old-page /new-page
Poi verifica il vecchio indirizzo, le sue varianti HTTP e www e un indirizzo con una query string, e assicurati che ognuno raggiunga la pagina finale con un solo passaggio.
Monitorare i redirect con Uptimecheck
Un monitor HTTP(S) nel monitoraggio uptime di Uptimecheck segue per impostazione predefinita fino a 10 redirect e valuta la pagina finale, che risulta up quando risponde con uno stato da 200 a 399. Un loop, o una catena più lunga, viene segnalato come down con “Too many redirects”, e l’incidente indica quando la catena rimbalza tra HTTP e HTTPS o tra www e il dominio senza www. I controlli girano fino a ogni minuto da Stoccolma, Londra e New York, e un secondo controllo conferma un errore prima che tu riceva un avviso.
Per sorvegliare il redirect stesso, per esempio dopo il cambio di dominio, disattiva Follow redirects così il monitor valuta il codice di stato del redirect, imposta Expected status codes su 301 e aggiungi un controllo dell’header che verifichi che Location corrisponda al nuovo indirizzo. Se qualcuno in seguito trasforma il redirect in un 302 o lo punta altrove, lo vieni a sapere. Leggi come aggiungere il tuo primo monitor e la guida ai codici di stato HTTP nel monitoraggio.
Scopri quando una migrazione si rompe. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.