Che cos’è un redirect? Spiegazione dei redirect (301 vs 302)

TL;DR: Reindirizzare significa che un URL inoltra automaticamente visitatori e motori di ricerca a un altro URL. Usa una 301 per una migrazione permanente e una 302 per una temporanea. I redirect non comportano di per sé una perdita di PageRank, ma catene, loop, destinazioni non funzionanti e redirect della homepage non pertinenti possono comunque creare problemi reali di SEO e usabilità.

Redirect	Significato	Usalo quando	Cosa indicizza in genere Google
301	Moved Permanently	Una pagina, un protocollo, un hostname o un dominio è cambiato permanentemente	L’URL di destinazione
302	Found	La pagina originale tornerà	L’URL originale
303	See Other	Una richiesta POST deve portare a una pagina di risultato separata tramite GET	L’URL originale perché lo spostamento è temporaneo
307	Temporary Redirect	Lo spostamento è temporaneo e il metodo HTTP deve essere preservato	L’URL originale
308	Permanent Redirect	Lo spostamento è permanente e il metodo HTTP deve essere preservato	L’URL di destinazione

Che cosa significa reindirizzare?

Un redirect è un’istruzione che dice: “Quell’URL si è spostato. Vai invece a questo URL.”

Dal punto di vista tecnico, il browser richiede un indirizzo e il server può rispondere con un codice di stato HTTP 3xx e un header Location che contiene un indirizzo diverso. A quel punto, il browser richiede automaticamente la destinazione. Anche i crawler dei motori di ricerca possono seguire la stessa istruzione.

Il significato pratico del reindirizzamento è più semplice: il vecchio URL non serve più il proprio contenuto; inoltra la richiesta a un nuovo URL.

I redirect sono necessari perché gli URL cambiano. Le pagine vengono rinominate, i prodotti vengono rimossi, i siti passano da HTTP a HTTPS, articoli sovrapposti vengono consolidati e i domini vengono sostituiti. Senza un redirect, chi segue il vecchio indirizzo finisce di solito in un 404. I backlink continuano a puntare a un URL abbandonato e Google non riceve un’istruzione esplicita di routing che colleghi la vecchia pagina alla sua sostituzione.

Abbiamo gestito tutto questo direttamente quando io e Lida abbiamo migrato SEOJuice da seojuice.io a seojuice.com a gennaio 2026. Una migrazione di dominio rende lo scopo dei redirect sorprendentemente chiaro: ogni vecchio percorso deve avere una destinazione definita, non soltanto una regola che mandi il dominio da qualche parte “sensata”. Con un team di due persone, non c’era nessuno a cui delegare il ragionamento; la mappa dei redirect doveva essere trattata come parte della migrazione (non come un compito amministrativo successivo).

Questa distinzione conta davvero. Reindirizzare un vecchio articolo alla sua controparte sul nuovo dominio preserva il percorso. Reindirizzare ogni vecchio indirizzo alla nuova homepage, invece, nasconde semplicemente i percorsi mancanti.

301 vs 302: la vera decisione è la “permanenza”

La differenza tra una 301 e una 302 non è che una sia “più SEO-friendly” e l’altra invece no. Ogni codice comunica un’aspettativa diversa su cosa succederà dopo.

Una redirect 301 significa che lo spostamento è permanente. Una redirect 302 significa che lo spostamento è temporaneo e che ci si aspetta che l’URL originale torni. Google segue entrambe, ma non interpreta i loro segnali canonici nello stesso modo.

“Googlebot segue il redirect e la pipeline di indicizzazione usa il redirect come segnale che la destinazione del redirect deve essere canonica.”

Per i redirect temporanei: “Googlebot segue il redirect, ma la pipeline di indicizzazione non usa il redirect come segnale che la destinazione del redirect debba essere canonica.”

Sono descrizioni proprie di Google Search Central nella documentazione Redirects and Google Search.

Tradotto in pratica SEO, un redirect permanente chiede a Google di sostituire l’URL vecchio con la destinazione nel suo indice. Un redirect temporaneo manda gli utenti alla destinazione mantenendo normalmente l’URL originale come canonico. Se la parte più confusa è la canonicalizzazione, la nostra guida su come funziona l’indicizzazione di Google spiega come si incastrano crawling, selezione del canonico e indicizzazione.

Usa una 301 per cambi permanenti di URL

Una 301 è la scelta convenzionale per un URL contenuto che è stato spostato definitivamente. I casi tipici includono:

• Rinominare una pagina o cambiare il suo slug di URL
• Passare da HTTP a HTTPS
• Standardizzare su www oppure non-www
• Passare a un dominio diverso
• Unire pagine duplicate o sovrapposte
• Sostituire una vecchia pagina con un successore davvero equivalente

Google raccomanda di usare un redirect server-side permanente quando possibile, ogni volta che in risultati di ricerca deve cambiare un URL. Questo, secondo Google, è il modo migliore per assicurarsi che persone e Google Search arrivino alla pagina corretta.

Ecco lo stesso redirect permanente in due tra i web server più comuni:

# Nginx — reindirizza un vecchio URL alla sua nuova “home”
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

# Apache (.htaccess) — la regola equivalente su una riga
Redirect 301 /old-page/ https://example.com/new-page/

La parola equivalente qui sta facendo davvero il suo lavoro. Un prodotto eliminato non diventa equivalente alla tua homepage solo perché entrambi gli URL appartengono alla stessa azienda.

Usa una 302 quando l’URL originale sta per tornare

Una 302 è adatta a una pagina di manutenzione temporanea, a un esperimento, a una “presa in carico” stagionale di breve durata oppure a un routing che ti aspetti di invertire. Dice a Google che la destinazione non è pensata per diventare la sostituzione permanente.

Se una pagina si è spostata “per sempre” ma resta dietro una 302, Google potrebbe continuare a indicizzare l’indirizzo vecchio. Il redirect può sembrare perfettamente funzionante in un browser, mentre comunica ancora l’intento di indicizzazione sbagliato (un promemoria utile: “si carica” non è un test di redirect completo).

Scegli in base a se prevedi di annullare il cambiamento. Permanente significa 301; temporaneo significa 302. Il nostro confronto dedicato su 301 vs 302 redirects copre anche i casi di migrazione e canonicalizzazione meno evidenti.

Che cosa mi dici di redirect 303, 307 e 308?

La maggior parte dei siti editoriali e di marketing può usare redirect 301 e 302 per anni senza bisogno degli altri codici. Le differenze diventano rilevanti quando si hanno form, API e altre richieste non basate su GET.

Come documentato nella guide to HTTP redirections di MDN Web Docs, le 301 e 302 hanno un’ambiguità storica legata ai metodi di richiesta. Alcuni client possono trasformare una richiesta POST in una GET mentre le seguono.

Questo comportamento spesso è innocuo per una semplice visualizzazione di pagina. Non lo è se un endpoint si aspetta un body della richiesta.

307 preserva temporaneamente la richiesta

Un 307 Temporary Redirect esprime la stessa intenzione temporanea di una 302, ma garantisce che il metodo HTTP e il body siano preservati. Un POST resta un POST anche dopo il redirect.

308 preserva permanentemente la richiesta

Un 308 Permanent Redirect è la variante che preserva il metodo, equivalente a una 301. MDN spiega che “308 è stato creato per rimuovere l’ambiguità del comportamento quando si usano metodi diversi da GET”.

Per una pagina contenuto richiesta con GET, gli utenti vedranno poche differenze pratiche tra 301 e 308. Lo stesso vale per 302 e 307. La preservazione del metodo diventa importante per richieste POST e PUT, form e API (a quel punto, io coinvolgerei chi gestisce il backend invece di scegliere un status da un report SEO).

303 cambia deliberatamente la richiesta in GET

Una redirect 303 See Other è temporanea e rende deliberatamente la richiesta successiva una GET. Un uso comune è inviare qualcuno da un form inviato a una pagina di conferma o risultati separata, evitando un refresh che ri-invierebbe il POST originale.

Questo è prima un comportamento HTTP e poi un comportamento SEO. Non rendere i redirect delle pagine ordinarie più “esotici” del necessario.

I redirect server-side battono le scorciatoie del browser

I redirect basati su status HTTP avvengono server-side. Esistono anche due alternative lato client: meta refresh HTML e redirect JavaScript.

Un meta refresh si esegue dopo l’avvio del caricamento di un documento HTML. MDN dice di impostare il delay a zero per la conformità all’accessibilità e avverte che le regole di redirect HTTP e HTML che vanno fuori sincrono possono generare un loop infinito o “altri incubi”. La frase resta impressa perché il problema è reale: due layer di routing gestiti separatamente possono iniziare a contraddirsi dopo un cambiamento al CMS altrimenti comune.

Un redirect JavaScript dipende dal fatto che il client esegua JavaScript. Google Search Central afferma: “Usa i redirect JavaScript solo se non puoi fare redirect server-side o meta refresh. Anche se Google prova a renderizzare ogni URL che Googlebot ha eseguito in crawling, il rendering può fallire per vari motivi.”

Il mio ordine di preferenza è:

1. Un redirect HTTP server-side con lo stato corretto, permanente o temporaneo
2. Un meta refresh a zero secondi se la configurazione server non è disponibile
3. Un redirect JavaScript solo se nessuna delle due opzioni sopra è possibile

Alcuni host statici e piattaforme CMS “vincolate” non espongono lo strato server ideale. Questo limite è reale. Detto ciò, il fatto che un browser arrivi prima o poi alla destinazione non è la stessa cosa di un redirect pulito che ogni client può interpretare in modo coerente.

I redirect fanno perdere PageRank?

Una vecchia regola SEO sosteneva che ogni redirect facesse perdere una percentuale fissa di “link juice”. Le percentuali continuano a circolare, ma non dovrebbero guidare le decisioni di implementazione. Non sono supportate dalla posizione attuale di Google.

“I redirect 30x non perdono più PageRank.”

Gary Illyes di Google ha fatto questa dichiarazione nel 2016, come riportato da Search Engine Land. La conclusione sensata è ristretta ma importante: la semplice presenza di una 301, 302 o di un altro redirect 30x non impone una penalità automatica di PageRank.

Non segue però che 301 e 302 siano intercambiabili.

Una 301 dice a Google di trattare la destinazione come sostituzione canonica permanente. Una 302 di solito lascia canonico l’URL originale perché lo spostamento è temporaneo. Gestione del PageRank e intento canonico sono collegati, ma non sono la stessa domanda.

Inoltre, non mi sentirei di promettere che una migrazione di dominio preservi tutti i ranking senza alcuna fluttuazione. I redirect inviano un segnale importante, ma Google deve comunque fare ricrawl degli URL, processare i canonici e aggiornare l’indice. Un routing pulito elimina una delle principali fonti di ambiguità; non “blocca” i risultati di ricerca al loro posto.

Gli errori sui redirect che causano danni reali

Catene di redirect

Una catena di redirect invia una richiesta attraverso più URL:

URL A → URL B → URL C → URL D

Il percorso più pulito è far andare URL A direttamente verso URL D. Se B e C sono ancora collegati internamente, aggiorna anche quei link verso D.

Ogni passaggio aggiunge un’altra richiesta, consuma risorse del crawler e crea un’altra regola che può fallire. Anche dal punto di vista dei crawl, catene lunghe aumentano il rischio che la destinazione finale non venga raggiunta durante uno specifico crawling. Ripetuto su migliaia di pagine, questo diventa un vero problema di crawl budget invece che un semplice avviso di audit “di facciata”.

Non c’è bisogno di inventarsi una percentuale di perdita di PageRank per ogni hop. Più richieste, routing più lento, crawling sprecato e ulteriori punti di failure bastano già a giustificare di collassare la catena.

Loop di redirect

Un loop fa girare la richiesta in cerchio, ad esempio A → B → A. Alla fine i browser si fermano e mostrano l’errore “troppi redirect”. Il contenuto diventa irraggiungibile per utenti e crawler.

I loop spesso derivano da regole in conflitto: una regola HTTPS che “litiga” con la regola dell’hostname, una regola di trailing slash che ribalta un altro redirect o una meta refresh che non è d’accordo con quanto stabilito dal server. L’errore finale del browser nasconde il percorso, quindi controlla ogni risposta invece di ricaricare la pagina in modo ripetuto (o, più spesso di quanto vorrei, cancellare cache e sperare).

Reindirizzare ogni URL eliminato alla homepage

Questa non è una strategia di pulizia. Sostituisce una risposta chiara di pagina mancante con una destinazione irrilevante.

La guida di Google sulle soft-404 spiega che i redirect verso pagine non pertinenti possono essere interpretati come soft 404. Reindirizza un vecchio URL solo quando esiste davvero una sostituzione pertinente. Se non c’è sostituzione, restituisci un 404 o 410 corretto.

Un prodotto dismesso può ragionevolmente reindirizzare al successore diretto o, in alcuni casi, a una categoria strettamente correlata. Non dovrebbe inviare automaticamente gli utenti a una homepage generica che non riesce a rispondere alla richiesta.

Versioni miste di protocollo e hostname

Se HTTP, HTTPS, www e non-www servono tutti contenuti, più indirizzi competono per rappresentare la stessa pagina. Scegli un host e un protocollo canonici, poi reindirizza in modo permanente tutte le alternative direttamente verso quello.

Testa tutte le combinazioni. Una regola HTTP può funzionare correttamente da sola, ma aggiungere un secondo hop o creare un loop quando viene combinata con la regola dell’hostname.

Redirect che finiscono su un errore

Un redirect non è “riuscito” solo perché la prima risposta è una 301. La destinazione finale deve restituire una risposta funzionante.

Una 301 che porta a un 404 resta rotta per la persona che ha seguito quel link. Un redirect che finisce su una risposta della serie 500 è ugualmente inutile. Ecco perché controllare solo il codice di stato iniziale manca di una parte sostanziale del percorso.

Come trovare e correggere i problemi sui redirect

Inizia con un crawler come Screaming Frog, Ahrefs Site Audit o l’audit di SEOJuice. Esegui il crawl degli URL sorgente e segui ogni percorso fino alla risposta finale. Cerca:

• Catene di redirect con più hop
• Loop di redirect
• Redirect che terminano con una risposta 4xx o 5xx
• Link interni ancora puntati su URL reindirizzati
• Spostamenti permanenti implementati con redirect temporanei

Dalle osservazioni che facciamo sui siti in SEOJuice, i link interni che puntano a URL già reindirizzati meritano più attenzione di quanta ne ricevano. Il redirect potrebbe funzionare, quindi il problema sembra innocuo. Ma il tuo sito sta comunque mandando ogni utente e ogni crawler attraverso una richiesta inutile e, in futuro, cambi di redirect possono trasformare quel vecchio link interno in parte di una catena.

Questo è diventato particolarmente rilevante durante la migrazione .io-to-.com. Le regole a livello di dominio possono far sembrare che il sito sia migrato, mentre i vecchi link assoluti restano sepolti in pagine, template o contenuti strutturati. Un redirect globale funzionante li maschera; un crawl li mette in evidenza.

Google Search Console fornisce la vista di Google sul risultato. Il report di indicizzazione delle pagine può mostrare stati come “Page with redirect” e “Redirect error”. L’ispezione URL mostra il canonico dichiarato dall’utente e quello selezionato da Google, utile quando Google non ha accettato la destinazione che ti aspettavi.

Per un singolo URL sospetto, usa il pannello Network in browser DevTools. Controlla ogni status e ogni risposta Location finché la pagina finale non si carica o il percorso fallisce. È più veloce di lanciare un crawl completo quando stai facendo debug di una singola regola.

Dai priorità alle correzioni in quest’ordine:

1. Rimuovi i loop, perché rendono le pagine irraggiungibili.
2. Ripara i redirect che terminano su risposte 4xx o 5xx.
3. Collassa le catene, così i vecchi URL puntano direttamente alle destinazioni finali.
4. Sostituisci i redirect irrilevanti con destinazioni pertinenti o con risposte reali 404/410.
5. Aggiorna i link interni per bypassare i redirect.
6. Verifica che gli spostamenti permanenti usino uno stato permanente.

L’SEO audit di SEOJuice mette in evidenza catene di redirect, redirect rotti e link interni che puntano a URL reindirizzati, così hai una lista pratica su cui lavorare. Non riscrive da sola le regole di redirect di nginx, .htaccess, CDN o CMS; quei cambi restano comunque nelle infrastrutture che controllano la risposta.

Una checklist redirect per le migrazioni del sito

Controllo	Risultato atteso
Ogni URL vecchio di valore è mappato	Ogni URL punta a una sostituzione davvero pertinente
Gli spostamenti permanenti usano 301 o 308	La destinazione riceve un segnale canonico permanente
Gli spostamenti temporanei usano 302 o 307	La versione originale resta il canonico atteso
I redirect usano un solo hop	Il vecchio URL punta direttamente alla URL finale
Si testano le varianti di protocollo e hostname	Tutte le varianti risolvono verso una sola versione canonica senza loop
Si verificano le destinazioni finali	Nessun redirect termina su una risposta 4xx o 5xx
I link interni sono aggiornati	I link puntano direttamente agli URL finali
Le pagine eliminate senza corrispondenza sono gestite in modo chiaro	Restituiscono 404 o 410 invece di un redirect irrilevante

Tratta i redirect come regole di routing, non come “magia” SEO. Scegli una destinazione pertinente, dichiara se lo spostamento è permanente e rimuovi gli hop evitabili. La maggior parte delle decisioni sui redirect diventa semplice quando quei tre punti sono espliciti.

Domande frequenti

Che cosa significa “reindirizzare”?

Reindirizzare significa che un URL non serve più il proprio contenuto e invece inoltra visitatori e motori di ricerca verso un altro URL. Un redirect lato server normalmente restituisce uno stato HTTP 3xx insieme all’indirizzo di destinazione, che il browser richiede automaticamente.

Qual è la differenza tra un redirect 301 e un 302?

Una 301 indica che lo spostamento è permanente, permettendo a Google di trattare la destinazione come canonica. Una 302 indica che lo spostamento è temporaneo, quindi Google in genere mantiene l’URL originale indicizzato. Usa una 301 se la vecchia pagina non tornerà e una 302 se tornerà.

I redirect danneggiano la SEO?

Se implementati correttamente, i redirect non danneggiano di per sé la SEO. Google raccomanda redirect server-side permanenti per gli spostamenti permanenti e Gary Illyes ha dichiarato che i redirect 30x non fanno perdere PageRank. I problemi SEO nascono da catene, loop, destinazioni non funzionanti, redirect irrilevanti e codici di stato che comunicano un intento sbagliato.

Che cos’è una catena di redirect?

Una catena di redirect si verifica quando URL A reindirizza a URL B, che a sua volta reindirizza di nuovo a URL C. Aggiunge richieste inutili e lavoro per i crawler. Risolvila facendo puntare URL A direttamente a URL C e aggiornando i link interni per usare l’indirizzo finale.

Che cosa causa l’errore “troppi redirect”?

Un loop di redirect causa questo errore. Due o più regole inviano la richiesta in un cerchio, spesso perché le regole per HTTPS, www, trailing slash, lato server o meta-refresh sono in conflitto. Alla fine il browser smette di seguire il ciclo.

Quando dovrei usare un redirect 307 o 308?

Usa 307 per uno spostamento temporaneo e 308 per uno spostamento permanente quando metodo HTTP e body della richiesta originali devono essere preservati. Questo è più importante per form e richieste API che usano metodi come POST o PUT. Per pagine contenuto ordinarie richieste con GET, 301 e 302 restano le scelte convenzionali.