Redirect HTTP
Che cos’è davvero un redirect HTTP — un codice di stato 3xx più un header Location — il panorama 301/302/303/307/308, come implementarli e la differenza tra redirect e canonical: l’hub del sottocluster sui redirect.
1 segnale di evidenza in questa pagina
- Strumento live correlato HTTP Status & Redirect Checker
Un redirect è una risposta HTTP con un codice di stato 3xx e un header Location che invia browser e crawler da un vecchio URL a uno nuovo. Google li divide in due categorie: i permanenti (301/308) trasmettono un forte segnale di canonicalizzazione e spostano in avanti i segnali di ranking; i temporanei (302/303/307) trasmettono soltanto un segnale debole. All’interno di ciascuna categoria, i codici differiscono per la conservazione del metodo HTTP: 307/308 lo mantengono, 301/302 potrebbero non farlo. Implementali lato server (.htaccess/nginx), sul CDN o all’edge, oppure tramite un plugin del CMS; i redirect JavaScript e meta refresh sono più deboli perché dipendono dal rendering. Un redirect non è un tag canonical: usa il redirect quando in futuro deve esistere un solo URL, il canonical quando più URL devono restare attivi. Questo hub traccia l’intero panorama e rimanda agli approfondimenti.
In breve — Un redirect invia chiunque richieda un vecchio URL verso uno nuovo. Il tipo più comune è il 301 (“spostato definitivamente”), che segnala a Google di trasferire al nuovo URL i segnali di ranking della vecchia pagina. Il 302 è “temporaneo”. Scegli correttamente tra permanente e temporaneo e preferisci veri redirect a livello server a quelli JavaScript: avrai coperto il 90% di ciò che conta.
Che cos’è un redirect
I redirect HTTP usano risposte 3xx e un campo Location per indirizzare un client verso un altro URI. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: RFC 9110: Redirection Google considera i redirect permanenti segnali canonici forti, ma non garantisce l’indicizzazione della destinazione. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: Google: Redirects and Search
Quando una pagina cambia indirizzo, non vuoi che i visitatori, o Google, trovino un vicolo cieco al vecchio URL. Un redirect è l’istruzione che li inoltra automaticamente a quello nuovo. Qualcuno fa clic sul vecchio link e il server gli consegna senza clamore la nuova pagina.
Dietro le quinte, un redirect è soltanto un tipo specifico di risposta del server: un codice
di stato nella famiglia 300s — più spesso 301 o 302 — accompagnato da un header
Location che indica dove proseguire. Non serve conoscere questa meccanica per usarlo,
ma è il motivo per cui un redirect è affidabile mentre un messaggio “questa pagina è stata
spostata, fai clic qui” non lo è.
I due codici più importanti
- 301 — Moved Permanently (spostato definitivamente). Usalo quando lo spostamento è permanente. Comunica ai motori di ricerca che la pagina ha una nuova sede, così ranking e link della vecchia pagina si trasferiscono al nuovo URL. È il codice che userai più spesso.
- 302 — Found (temporaneo). Usalo quando lo spostamento vale soltanto per il momento: una breve campagna, un test A/B o una pagina che ripristinerai. Segnala a Google di non trasferire i segnali di ranking, perché il cambiamento non è permanente.
Esistono altri codici, tra cui 303, 307 e 308, ma per la maggior parte dei siti la decisione pratica è semplice: lo spostamento è permanente (301) o temporaneo (302)?
Come configurarlo
- Sul server — tramite il file
.htaccessdi Apache o una regola di configurazione nginx: l’approccio classico. - Con un plugin del CMS — su WordPress un plugin per i redirect, di solito, modifica il
file
.htaccessal posto tuo. - Sul CDN o all’edge — Cloudflare e servizi analoghi permettono di applicare il redirect prima ancora che la richiesta raggiunga il server.
Quando puoi, evita i redirect JavaScript, nei quali uno script inoltra il browser. Google può rispettarli, ma soltanto dopo aver eseguito correttamente il rendering della pagina, un passaggio aggiuntivo che talvolta fallisce. Sono quindi più lenti e meno affidabili di un vero redirect del server.
L’errore più comune
Un redirect non equivale a un tag canonical. Usa un redirect quando il vecchio URL deve cessare di esistere e tutti devono arrivare a quello nuovo. Usa un tag canonical quando più URL devono restare attivi, ma vuoi che Google ne consideri uno la versione “principale”, come nelle pagine prodotto con parametri di tracciamento. Redirect = sopravvive un solo URL; canonical = ne sopravvivono diversi, ma uno è preferito.
Vuoi i dettagli del protocollo, il confronto completo tra 301, 302, 303, 307 e 308, per quanto tempo mantenere un redirect e le insidie di catene e loop? Passa alla scheda Avanzato.
In breve — Un redirect è una risposta HTTP con un codice di stato 3xx e un header
Location: prima viene il protocollo, poi la SEO. Google raggruppa i codici in due categorie di canonicalizzazione: permanenti (301/308) = segnale forte, con consolidamento in avanti dei segnali; temporanei (302/303/307) = segnale debole, con segnali che di solito restano sull’origine, anche se un redirect temporaneo mantenuto a lungo può cambiare trattamento. All’interno di ciascuna categoria, 307 e 308 preservano metodo e corpo HTTP, mentre 301 e 302 potrebbero non farlo. Implementali sul server, sul CDN o all’edge — la mia preferenza — oppure tramite un plugin del CMS; i redirect JavaScript e i meta refresh ritardati sono più deboli perché dipendono dal rendering. Un singolo redirect corretto non disperde PageRank: i veri rischi sono le catene, da evitare, e i loop, che i motori di ricerca ignorano. Mantieni i redirect per almeno un anno. E ricorda che un redirect non è un tag canonical.
Che cos’è davvero un redirect a livello di protocollo
I codici di stato dei redirect hanno una semantica standardizzata per la gestione del metodo. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: RFC 9110: Redirection Le linee guida per la ricerca distinguono segnali permanenti e temporanei e consigliano redirect diretti lato server per gli spostamenti. Prova a sostegno di questa affermazione Primary standard or official documentation supporting the adjacent article claim. Ambito: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Attendibilità: alta · Verificato: Google: Redirects and Search
Molti contenuti SEO saltano subito a “301 significa permanente” senza spiegare che cosa
sia un redirect. Vale la pena partire dalle fondamenta, perché il meccanismo chiarisce tutto
ciò che viene dopo. Secondo MDN,
“redirection is triggered by a server sending a special redirect response to a
request. Redirect responses have status codes that start with 3, and a Location
header holding the URL to redirect to.” (traduzione): «il reindirizzamento viene attivato
quando un server invia una speciale risposta di redirect a una richiesta. Le risposte di
redirect hanno codici di stato che iniziano con 3 e un header Location contenente
l’URL verso cui reindirizzare».
Un redirect è quindi formato da due elementi che viaggiano insieme: un codice di stato
3xx — 301, 302, 303, 307, 308… — e un header Location che indica la destinazione.
Il browser o il crawler legge la risposta e richiede di nuovo l’URL contenuto in Location.
Il codice di stato esprime la semantica — permanente o temporaneo, con conservazione o meno
del metodo — mentre l’header Location fornisce l’indirizzo. Tutto ciò che interessa a
chi fa SEO dipende dal codice 3xx inviato.
La lettura SEO di questo meccanismo, come l’ho formulata nel mio articolo 11 Types Of Redirects & Their SEO Impact per Ahrefs, è la seguente: “A redirect is a way to send people and bots to a new URL when they request the old URL, but the page has changed locations.” (traduzione): «un redirect è un modo per inviare persone e bot a un nuovo URL quando richiedono quello vecchio, ma la pagina ha cambiato indirizzo».
Perché i redirect contano per la SEO
La documentazione di Google sui redirect ne descrive lo scopo con chiarezza: “Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” (traduzione): «reindirizzare gli URL significa risolvere un URL esistente verso uno diverso, comunicando di fatto ai visitatori e alla Ricerca Google che una pagina ha un nuovo indirizzo». Le conseguenze SEO si dividono nettamente in base alla durata dello spostamento:
- I redirect permanenti mostrano nei risultati di ricerca la nuova destinazione.
- I redirect temporanei mantengono nei risultati di ricerca la pagina di origine.
Esiste anche la dimensione dell’equità dei link. Google tiene traccia di entrambe le estremità di un redirect: “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent.” (traduzione): «quando reindirizzi un URL, Google tiene traccia sia dell’origine del redirect, cioè il vecchio URL, sia della destinazione, cioè il nuovo URL. Uno dei due sarà canonico; quale dipende da segnali come la natura temporanea o permanente del redirect». I redirect permanenti consolidano i segnali in avanti, sul nuovo URL; quelli temporanei di solito li lasciano sul vecchio.
Il panorama dei redirect: 301, 302, 303, 307 e 308
Ecco l’intera famiglia in sintesi. Ogni codice ha un proprio approfondimento in questo sottocluster; consulta “Dove proseguire”:
- 301 (Moved Permanently) — il redirect permanente più comune. È un segnale di canonicalizzazione forte e consolida in avanti i segnali di ranking. Nella documentazione per i crawler, Google afferma: “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (traduzione): «Google segue il redirect e i suoi sistemi lo usano come segnale forte affinché venga elaborata la destinazione».
- 302 (Found) — il redirect temporaneo standard. Google lo segue: “and Google systems use the redirect as a weak signal.” (traduzione): «e i sistemi di Google usano il redirect come segnale debole». Debole non significa nullo: mantenendo un 302 abbastanza a lungo, potrebbe finire per essere trattato come un 301.
- 303 (See Other) — l’eccezione. Rientra nella categoria temporanea ed è il codice alla base
del modello Post/Redirect/Get: invii un modulo e vieni inoltrato a una pagina dei risultati
tramite
GET. È raro nella SEO e il suo trattamento è davvero poco chiaro; come ho già osservato, per Google i 303 hanno un trattamento non definito e possono comportarsi come un 301 o un 302 a seconda della loro funzione. - 307 (Temporary Redirect) — ha lo stesso significato SEO di un 302, ma preserva metodo e corpo HTTP. La documentazione di Google è esplicita: 307 è “equivalent to 302.” (traduzione): «equivalente a 302». I 307 possono inoltre comparire automaticamente sui siti HTTPS che usano HSTS.
- 308 (Permanent Redirect) — ha lo stesso significato SEO di un 301, ma preserva metodo e corpo. Google lo definisce “equivalent to 301.” (traduzione): «equivalente a 301».
Il dettaglio sulla conservazione del metodo — 307 e 308 mantengono metodo e corpo originali,
mentre 301 e 302 consentono al client di trasformare un POST in GET durante il passaggio —
non cambia il ranking di Google, ma conta molto quando reindirizzi l’invio di moduli o chiamate
API. Google stesso invita a non scegliere superficialmente: “While Google treats these status codes the same way, keep in mind that
they’re semantically different. Use the status code that’s appropriate for the
redirect so other clients (for example, e-readers, other search engines) may benefit
from it.” (traduzione): «anche se Google tratta questi codici di stato allo stesso modo,
ricorda che sono semanticamente diversi. Usa il codice adatto al redirect affinché altri client,
come lettori elettronici o altri motori di ricerca, possano trarne vantaggio». Trovi il
confronto completo nella scheda Schede riassuntive.
Effetti dei redirect su scansione, indicizzazione ed equità dei link
Due categorie, una distinzione. La documentazione di Google descrive i redirect permanenti
— 301, 308, meta refresh immediato e location JavaScript — come casi in cui “the indexing
pipeline uses the redirect as a signal that the redirect target should be canonical,”
(traduzione): «la pipeline di indicizzazione usa il redirect come segnale che la destinazione
debba essere canonica»; per quelli temporanei — 302, 303, 307 e meta refresh ritardato —
afferma invece che “the indexing pipeline doesn’t use the redirect as a signal that the redirect target
should be canonical.” (traduzione): «la pipeline di indicizzazione non usa il redirect come
segnale che la destinazione debba essere canonica».
Il mito del PageRank è morto. La vecchia convinzione secondo cui i redirect “perdono il 10-15% dell’equità dei link” non è vera da anni. Nel 2016 Gary Illyes di Google ha dichiarato che “30x redirects don’t lose PageRank anymore,” (traduzione): «i redirect 30x non perdono più PageRank»; John Mueller osservò che non era nemmeno un’informazione nuova. Un singolo redirect implementato correttamente trasferisce sostanzialmente tutto il valore dei segnali della pagina. I costi derivano da catene e loop, non dall’esistenza del redirect.
Per quanto tempo mantenere un redirect. Le linee guida di Google sulle migrazioni consigliano di “keep the redirects for as long as possible, generally at least 1 year” (traduzione): «mantenere i redirect il più a lungo possibile, in genere almeno un anno», così da trasferire tutti i segnali ai nuovi URL. Gary Illyes avanzò l’idea che “after 1 y all signals had time to pass on from A to B.” (traduzione): «dopo un anno tutti i segnali avevano avuto il tempo di passare da A a B». Ho messo alla prova questa ipotesi: ho rimosso i redirect 301 da quattro articoli di Ahrefs verso i quali erano stati reindirizzati contenuti più vecchi e ho osservato che cosa accadeva. Si è verificato “a clear drop in referring domains after I did this,” (traduzione): «un netto calo dei domini di riferimento dopo la rimozione», ma “not much drop in traffic to these posts.” (traduzione): «un calo minimo del traffico verso questi articoli». La mia conclusione onesta è: “I’m not willing to conclusively say that permanent redirects pass value even after one year, but what Gary said seems to mostly hold true.” (traduzione): «non sono disposto ad affermare in modo definitivo che i redirect permanenti continuino a trasferire valore dopo un anno, ma quanto detto da Gary sembra valere nella maggior parte dei casi». La scelta prudente resta questa: non rimuovere con leggerezza i vecchi redirect.
Catene e loop di redirect
- Una catena di redirect contiene più di un passaggio tra l’URL richiesto e la destinazione finale, per esempio Pagina 1 → Pagina 2 → Pagina 3. Google segue fino a 10 passaggi di redirect: “By default, Google’s crawlers follow up to 10 redirect hops” (traduzione): «per impostazione predefinita, i crawler di Google seguono fino a 10 passaggi di redirect». Tuttavia, le attuali linee guida sulle migrazioni consigliano di evitare le catene e, se inevitabili, di limitarle idealmente a non più di 3 e comunque a meno di 5 passaggi. Dieci è il limite massimo del crawler; da 3 a 5 è una raccomandazione pratica, non un limite in conflitto. Le catene aumentano la latenza, sprecano crawl budget e rendono meno chiari i dati analitici.
- Un loop di redirect è una catena che si morde la coda: un URL reindirizza verso se stesso o verso un punto precedente della catena, quindi non si risolve mai. I browser mostrano un errore per troppi redirect e i motori di ricerca rinunciano. Come ha spiegato John Mueller: “a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” (traduzione): «un loop di redirect è un URL che non funziona, quindi in sostanza è un link interrotto. Lo ignoriamo per la ricerca». I loop intrappolano anche i crawler e consumano risorse del server.
Dietro il noto valore di cinque passaggi esistono anche dichiarazioni datate di un rappresentante Google. In un webmaster hangout del 2014, al minuto 46:03, John Mueller descrisse Googlebot come capace di seguire fino a cinque redirect in una singola scansione e, se ne restavano altri, di proseguire alla scansione successiva. Nel 2020 disse separatamente che Google seguiva fino a cinque passaggi per tentativo di scansione. Queste dichiarazioni storiche aiutano a spiegare quel numero, ma non sostituiscono la documentazione attuale né garantiscono che ogni lunga catena venga ripresa secondo una pianificazione precisa.
La mia osservazione indipendente da professionista è che Google spesso riprende le catene più lunghe e io uso circa cinque passaggi come soglia di priorità per la correzione. È un giudizio operativo basato su ciò che ho visto, non un limite della piattaforma Google. Quando controlli i redirect, l’obiettivo resta un unico passaggio diretto.
Entrambi i problemi hanno un articolo dedicato più avanti.
Come implementare i redirect
Non esiste un unico posto “giusto” in cui configurare un redirect: scegli quello che riesci a mantenere nel tempo.
- Configurazione lato server. File
.htaccessdi Apache, regole nginx o script lato server. È l’impostazione predefinita per la maggior parte dei siti e la più affidabile. Su WordPress, “most WordPress installs will be running Apache and the plugins used for redirecting will actually be editing a website’s.htaccessfile” (traduzione): «la maggior parte delle installazioni WordPress usa Apache e i plugin per i redirect modificano in realtà il file.htaccessdel sito»: il plugin è soltanto un’interfaccia più accessibile. - CDN o edge. Le regole Cloudflare, gli edge worker e soluzioni analoghe intervengono prima che la richiesta raggiunga l’origine. È la soluzione che preferisco: “I typically prefer to have redirects on the edge (CDN-level) over having them on the server.” (traduzione): «in genere preferisco applicare i redirect all’edge, a livello CDN, anziché sul server». Detto questo, per la maggior parte delle persone “always recommend going with what is easiest for you to implement. For many people that is server-level redirects.” (traduzione): «consiglio sempre ciò che è più facile da implementare; per molti sono i redirect a livello server».
- Lato client: meta refresh. Un tag
<meta http-equiv="refresh">. Google interpreta un meta refresh immediato, dopo 0 secondi, come permanente e uno ritardato come temporaneo. È più lento e macchinoso di un redirect del server, ma a volte è l’unica leva disponibile. - Lato client: JavaScript. Uno script imposta
window.location. Google può rispettarlo, ma soltanto se il rendering riesce, una fase separata della pipeline che talvolta fallisce. Il consiglio di Google è: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (traduzione): «usa i redirect JavaScript soltanto se non puoi usare redirect lato server o meta refresh». Per i redirect permanenti, il mio ordine consigliato rispecchia questa scala di affidabilità: 308 / 301 → meta refresh 0 → JavaScript → crypto.
Redirect o tag canonical
Risolvono problemi diversi, ma vengono continuamente confusi.
- Redirect — usalo quando il vecchio URL deve smettere completamente di restituire i propri contenuti. In futuro deve esistere un solo URL. Il vecchio indirizzo inoltra la richiesta e non pubblica più una pagina propria.
- Tag canonical — usalo quando più URL devono restare attivi e accessibili in modo
indipendente, ma vuoi che Google ne consideri uno la versione preferita. Pensa alle
varianti della navigazione a faccette, agli URL con parametri di tracciamento o alle versioni
di stampa: sono tutti raggiungibili e puntano con
rel=canonicalalla versione principale.
Bing descrive la stessa distinzione con chiarezza nel suo articolo sui contenuti duplicati di dicembre 2025: “Use 301 redirects to consolidate variants into a single preferred URL. Apply canonical tags when multiple versions must remain accessible.” (traduzione): «usa i redirect 301 per consolidare le varianti in un unico URL preferito. Applica i tag canonical quando più versioni devono restare accessibili». Se un’indicazione canonical viene ignorata e vuoi davvero consolidare, puoi passare a un redirect, ma soltanto quando l’URL duplicato non deve continuare a pubblicare contenuti propri.
Una nota su Bing
In linea generale, Bing concorda con Google: per gli spostamenti permanenti si usano i 301, per quelli temporanei i 302. Fabrice Canel di Bing ha dichiarato che è “preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended,” (traduzione): «preferibile usare un redirect 302 se l’URL di destinazione potrebbe cambiare entro due giorni; altrimenti è consigliato un 301». Il collega Frédéric Dubut ha chiarito che i “due giorni” non erano una soglia rigida: “anytime a redirect is temporary… you should use 302s.” (traduzione): «ogni volta che un redirect è temporaneo, dovresti usare un 302». Lo stesso modello mentale, formulato in base alla rapidità con cui potrebbe cambiare la destinazione.
Dove proseguire: il sottocluster sui redirect
Questo hub è la mappa. Ciascun argomento seguente ha un approfondimento dedicato, annidato sotto questo hub e presente nella barra laterale:
I singoli codici di redirect
- Redirect 301 — il principale redirect permanente: come consolida i segnali in avanti e quando utilizzarlo.
- Redirect 302 — il redirect temporaneo standard, perché è un segnale debole ma non nullo e come può finire per essere trattato come un 301.
- Redirect 303 (See Other) — il codice Post/Redirect/Get, perché è raro nella SEO e perché il suo trattamento da parte di Google è davvero indefinito.
- Redirect temporaneo 307 — ha lo stesso significato SEO di un 302, ma preserva rigorosamente il metodo HTTP; scopri dove compare, tra HSTS e redirect di moduli o API.
- Redirect permanente 308 — ha lo stesso significato SEO di un 301, ma preserva rigorosamente metodo e corpo HTTP.
I confronti diretti
- Redirect 301 e 302 a confronto — permanente contro temporaneo, consolidamento dei segnali in avanti o all’indietro e quale codice scegliere.
- Redirect 301 e 308 a confronto — stesso significato SEO, ma il 308 preserva metodo e corpo HTTP.
- Redirect 302 e 307 a confronto — la stessa distinzione sul lato temporaneo: equivalenti per la SEO, ma il 307 mantiene metodo e corpo per moduli e API.
Le implementazioni lato client
- Redirect JavaScript — perché sono l’opzione più debole, come la pipeline di rendering di Google li tratta rispetto a un 301 lato server e quando sono un’ultima risorsa accettabile.
- Redirect meta refresh — aggiornamenti immediati o ritardati, perché nella scala di preferenza di Google si collocano tra server e JavaScript e perché sono sconsigliati.
Le insidie
- Catene di redirect — perché conviene reindirizzare direttamente all’URL finale, il limite di 10 passaggi e il modo in cui le catene sprecano crawl budget.
- Loop di redirect — il redirect che non si risolve mai, perché i motori di ricerca lo ignorano e come interrompere il ciclo.
In Google Search Console
- Pagina con reindirizzamento — che cosa significa questo stato di Indicizzazione delle pagine, perché è normale e non è un errore e i rari casi che richiedono un intervento.
- Errore di reindirizzamento — le quattro cause indicate da Google, cioè catena troppo lunga, loop, URL oltre la lunghezza massima e URL non valido o vuoto, e la differenza rispetto al normale stato “Pagina con reindirizzamento”.
Per il quadro completo dei codici di stato HTTP in cui rientra questo sottocluster — le famiglie 2xx, 3xx, 4xx e 5xx e i codici diversi dai redirect — consulta l’indice del cluster /technical-seo/http-status-codes/.
Riepilogo IA
Una sintesi della versione avanzata:
- Un redirect = un codice di stato 3xx + un header
Location. Il codice esprime la semantica — permanente o temporaneo, con conservazione o meno del metodo — eLocationindica la destinazione. Prima il protocollo, poi la SEO. - Due categorie di canonicalizzazione: permanenti 301/308 = segnale forte, con consolidamento in avanti sul nuovo URL; temporanei 302/303/307 = segnale debole, con segnali che di solito restano sul vecchio URL, anche se un temporaneo mantenuto a lungo può cambiare trattamento.
- All’interno di ciascuna categoria: 307 e 308 preservano metodo e corpo HTTP; 301 e 302 potrebbero non farlo. Non cambia il ranking, ma conta per moduli e API.
- Il 303 è l’eccezione: è il codice Post/Redirect/Get, raro nella SEO e con un trattamento Google davvero indefinito.
- Il mito del PageRank è morto: un singolo redirect corretto non disperde equità, come spiegato da Illyes nel 2016. I costi derivano dalle catene — Google segue fino a 10 passaggi ma consiglia di evitarle — e dai loop, che i motori ignorano come link interrotti.
- Mantieni i redirect per almeno un anno. Nel test di Patrick, rimuovere 301 attivi da un anno ha ridotto i domini di riferimento ma poco il traffico: l’ipotesi “vale per lo più”, quindi non rimuoverli con leggerezza.
- Implementa lato server, tramite .htaccess o nginx, sul CDN o all’edge — la preferenza di
Patrick — oppure con un plugin CMS, che di solito modifica semplicemente
.htaccess. JavaScript e meta refresh ritardati sono più deboli perché dipendono dal rendering. - Redirect ≠ canonical: usa un redirect quando in futuro deve esistere un solo URL; canonicalizza quando più URL restano attivi ma uno è preferito.
Documentazione ufficiale
Documentazione da fonti primarie sui redirect.
- Redirect e Ricerca Google — il documento di riferimento: distinzione tra permanente e temporaneo, tabelle dei tipi di redirect — 301, 308, 302, 303, 307, meta refresh, JavaScript e crypto — e concetti di URL alternativo ed equità dei link.
- Effetti dei codici di stato HTTP sui crawler di Google — comportamento dei 3xx, limite di 10 passaggi e trattamento di 301, 302, 307 e 308 da parte dei crawler.
- Spostare un sito modificando gli URL — evitare le catene di redirect e “mantenere i redirect… in genere almeno un anno”.
- Consolidare gli URL duplicati — perché una preferenza canonical è “un’indicazione, non una regola” e come interagisce con i redirect.
- Search Off the Record — il team Search Relations di Google dedica un episodio ai tipi di redirect: 301 rispetto a 302, scopi di 307 e 308 e fusioni di domini.
Bing / Microsoft
- I contenuti duplicati danneggiano la SEO e la visibilità nella ricerca IA? — Fabrice Canel e Krishna Madhavan spiegano quando usare i 301 per consolidare le varianti e quando applicare i tag canonical perché le versioni devono restare attive.
Riferimento tecnico
- Reindirizzamenti in HTTP — la definizione a livello di protocollo di MDN, cioè codice 3xx più header
Location, e la gestione di metodo e corpo per ogni codice.
Citazioni dalle fonti
Dichiarazioni pubbliche di Google, Bing e MDN. Ogni collegamento porta direttamente al passaggio citato nella pagina di origine.
Google — lo scopo dei redirect e la distinzione tra permanente e temporaneo
- “Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” (traduzione): «Reindirizzare gli URL consiste nel risolvere un URL esistente verso un altro, indicando in pratica ai visitatori e alla Ricerca Google che la pagina si trova a un nuovo indirizzo». — Documentazione di Google Search Central. Vai alla citazione
- “we recommend that you use a permanent server-side redirect whenever possible.” (traduzione): «Consigliamo di usare, quando possibile, un redirect permanente lato server». Vai alla citazione
- “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL).” (traduzione): «Quando reindirizzi un URL, Google conserva sia l’origine del redirect, il vecchio URL, sia la destinazione, il nuovo URL». Vai alla citazione
- “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (traduzione): «Ricorri ai redirect JavaScript soltanto se non puoi implementare redirect lato server o meta refresh». Vai alla citazione
Google — trattamento dei codici da parte dei crawler
- “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (traduzione): «Google segue il redirect e i suoi sistemi lo considerano un segnale forte per elaborarne la destinazione» (301). Vai alla citazione
- “Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (traduzione): «I crawler di Google seguono il redirect e i sistemi lo considerano un segnale debole per elaborarne la destinazione» (302). Vai alla citazione
- “While Google treats these status codes the same way, keep in mind that they’re semantically different.” (traduzione): «Anche se Google tratta questi codici di stato nello stesso modo, tieni presente che hanno semantiche differenti» (307 ≈ 302, 308 ≈ 301). Vai alla citazione
- “By default, Google’s crawlers follow up to 10 redirect hops.” (traduzione): «Per impostazione predefinita, i crawler di Google seguono fino a 10 passaggi di redirect». Vai alla citazione
Google — catene e durata dei redirect
- “Avoid chaining redirects.” (traduzione): «Evita di concatenare i redirect». Vai alla citazione
- “ideally no more than 3 and fewer than 5.” (traduzione): «Idealmente non più di 3 e comunque meno di 5». Vai alla citazione
- “Keep the redirects for as long as possible, generally at least 1 year.” (traduzione): «Mantieni i redirect il più a lungo possibile, di norma per almeno un anno». Vai alla citazione
John Mueller, Google — dichiarazioni datate sui cinque passaggi
- In un webmaster hangout del 2014, Mueller descrisse Googlebot come capace di seguire fino a cinque redirect in una scansione e di continuare quelli rimanenti alla scansione successiva. Guarda dal minuto 46:03
- “up to 5 hops in the chain per crawl attempt” (traduzione): «fino a 5 passaggi della catena per tentativo di scansione». (Commento Reddit del 2020, ripreso da Search Engine Journal.) Leggi l’articolo
John Mueller, Google — loop di redirect
- “In general, a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” (traduzione): «In generale, un loop di redirect è un URL non funzionante, quindi equivale sostanzialmente a un link interrotto. Lo ignoriamo nella ricerca». Vai alla citazione
Fabrice Canel, Microsoft Bing — tempistiche di 301 e 302
- “When the future is uncertain… preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended.” (traduzione): «Quando il futuro è incerto, è preferibile usare un redirect 302 se l’URL di destinazione potrebbe cambiare entro due giorni; altrimenti è consigliato un 301». Vai alla citazione
MDN — la definizione a livello di protocollo
- “redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with
3, and aLocationheader holding the URL to redirect to.” (traduzione): «Il reindirizzamento scatta quando il server invia una speciale risposta di redirect a una richiesta. Queste risposte hanno codici di stato che iniziano per3e un headerLocationche contiene l’URL di destinazione». Leggi il documento
Checklist per implementare i redirect
Prima e dopo la pubblicazione di un redirect:
- Codice adatto alla situazione — spostamento permanente →
301/308; temporaneo →302/307; conservazione di unPOSTdel modulo →307/308. - Reindirizza verso l’URL più equivalente, non inoltrare indiscriminatamente tutto alla homepage: per Google sarebbe un soft 404.
- Vai direttamente alla destinazione finale, senza catene. Aggiorna la regola dell’origine ogni volta che la destinazione viene a sua volta spostata.
- Nessun loop — verifica che la destinazione non reindirizzi verso un punto precedente
della catena; esegui
curl -ILsul vecchio URL e leggi l’intera sequenza. - A livello server o edge, non in JavaScript, quando possibile.
- Uniforma le varianti più comuni — www o non-www, HTTP o HTTPS, barra finale e maiuscole o minuscole — in un’unica forma canonica.
- Aggiorna i link interni affinché puntino direttamente al nuovo URL, senza affidare al redirect la navigazione interna.
- Mantienilo attivo per almeno un anno, secondo le linee guida di Google, e più a lungo per le pagine di grande valore; non rimuovere con leggerezza i vecchi redirect.
- Prevedi un rollback — prima di attivare il redirect, annota la destinazione precedente o conserva i contenuti della vecchia pagina se viene ritirata, così potrai annullare rapidamente una destinazione errata o un calo inatteso.
- Verifica dopo il rilascio — controlla codice di stato e destinazione finale con
curl -IL, la scheda Rete del browser o un crawler del sito; cerca catene e loop su larga scala.-Iinvia una richiestaHEAD: se sospetti che il server gestiscaHEADeGETdiversamente, ripeti il controllo con un semplicecurl -L, che usaGET, oppure con la modalità GET del crawler.
I tipi di redirect a confronto
I cinque codici di redirect 3xx in sintesi
| Codice | Nome | Permanente o temporaneo? | Metodo HTTP preservato? | Segnale per Google | Quando usarlo |
|---|---|---|---|---|---|
301 | Moved Permanently (spostato definitivamente) | Permanente | Può trasformare POST→GET | Forte (consolida in avanti) | Una pagina è stata spostata definitivamente: è il redirect permanente predefinito |
302 | Found (trovato) | Temporaneo | Può trasformare POST→GET | Debole (di solito resta sul vecchio URL) | Uno spostamento breve: campagna, test A/B o sostituzione temporanea |
303 | See Other (vedi altro) | Temporaneo | No (impone sempre GET) | Debole / indefinito | Post/Redirect/Get dopo l’invio di un modulo; raro nella SEO |
307 | Temporary Redirect (redirect temporaneo) | Temporaneo | Sì | Debole (= 302) | Uno spostamento temporaneo che deve preservare metodo e corpo, come moduli e API; compare anche con HSTS |
308 | Permanent Redirect (redirect permanente) | Permanente | Sì | Forte (= 301) | Uno spostamento permanente che deve preservare metodo e corpo |
I due fattori che determinano davvero la scelta
- Permanente o temporaneo → determina il segnale di canonicalizzazione, forte o debole, e se nei risultati compare il nuovo o il vecchio URL.
- Metodo preservato o meno → 307 e 308 mantengono metodo e corpo originali; 301 e 302
consentono al client di sostituire un
POSTcon unGETdurante il passaggio, una compatibilità ereditata per i client meno recenti secondo il Fetch Standard; il 303 impone sempreGET. È irrilevante per il ranking, ma fondamentale per moduli e API: usa307o308quando metodo e corpo devono superare il passaggio.
Metodi di implementazione, dal più forte al più debole per i redirect permanenti
| Metodo | Dove viene eseguito | Affidabilità |
|---|---|---|
308 / 301 (server o edge) | Server / CDN | Migliore: non dipende dal rendering |
Meta refresh 0 | Browser | Interpretato come permanente, ma macchinoso e lento |
JavaScript (window.location) | Browser (dopo il rendering) | Più debole: dipende dal buon esito del rendering |
| Crypto / alternativa basata soltanto sui link | — | Solo come ultima risorsa |
Dati essenziali
- Un singolo redirect corretto non perde PageRank, secondo Illyes nel 2016.
- Google documenta un limite massimo di 10 passaggi, ma quando una catena è inevitabile raccomanda non più di 3 e comunque meno di 5.
- I commenti di Mueller del 2014 e del 2020 descrivono circa cinque passaggi per scansione; quello del 2014 parla anche di proseguire gli altri in seguito. Considerali dichiarazioni storiche di un rappresentante, non una garanzia attuale sulla pianificazione.
- Mantieni i redirect per almeno un anno.
- Per Google, 307 ≈ 302 e 308 ≈ 301: la differenza è la conservazione del metodo.
- Redirect = sopravvive un solo URL; tag canonical = ne sopravvivono diversi, ma uno è preferito.
Risorse che meritano il tuo tempo
I miei articoli
- 11 tipi di redirect e il loro impatto sulla SEO — il mio approfondimento completo su ogni tipo di redirect — 301, 302, 303, 307, 308, meta refresh, JavaScript, crypto, catene e loop — sintetizzato in questo hub.
- Codici di stato HTTP e impatto sulla SEO — il posto dei redirect nel quadro complessivo dei codici 1xx–5xx, dalle risposte informative agli errori 5xx del server.
- È corretto rimuovere i redirect 301 dopo un anno? Il nostro test — il mio test controllato sulla rimozione di redirect attivi da un anno: i domini di riferimento sono diminuiti, il traffico in gran parte ha tenuto.
- Redirect 301 e 302 per la SEO: quale usare? — il confronto diretto, compreso il mio esperimento in cui un 302 ha indotto Google a sostituire il vecchio dominio con quello nuovo.
- Per una migrazione del sito non basta una checklist — i redirect nel contesto di uno spostamento completo del sito.
Dal settore
- Redirect e Ricerca Google (Google) — il documento di riferimento su cui si basa gran parte delle affermazioni di questo hub.
- Effetti dei codici di stato HTTP sui crawler di Google (Google) — trattamento dei 3xx da parte dei crawler e limite di 10 passaggi.
- I contenuti duplicati danneggiano SEO e visibilità nella ricerca IA? (Bing) — la posizione pubblica e attuale di Microsoft sui redirect rispetto ai tag canonical.
- Reindirizzamenti in HTTP (MDN) — il riferimento a livello di protocollo per i codici 3xx e la gestione di metodo e corpo.
- Google: i redirect 301, 302 e 30x non disperdono più PageRank (Search Engine Land) — l’origine della correzione al mito del PageRank.
- La Ricerca Google ignora i loop di redirect (Search Engine Roundtable) — la citazione di Mueller secondo cui un loop equivale sostanzialmente a un link interrotto.
- Bing: usa un 302 per URL che potrebbero cambiare entro due giorni, altrimenti un 301 (Search Engine Roundtable) — le indicazioni di Fabrice Canel sulle tempistiche di 301 e 302.
- Guida ai redirect per la SEO (Conductor Academy) — una solida panoramica concorrente del panorama dei redirect.
Redirect o canonical? Applica il test di sopravvivenza
I due segnali possono puntare allo stesso URL preferito, ma risolvono problemi diversi.
Usa un redirect quando l’URL di origine deve smettere di pubblicare contenuti propri
Scegli un redirect lato server quando utenti e crawler che richiedono il vecchio URL devono
essere inviati altrove. Usa un codice permanente — 301 o 308 — per uno spostamento
duraturo e un codice temporaneo — 302, 303 o 307 — quando prevedi di ripristinare
l’origine.
Casi tipici: URL modificato, pagine unite, passaggio da HTTP a HTTPS o migrazione di dominio. La destinazione deve essere davvero equivalente; reindirizzare in massa vecchi URL non correlati alla homepage può essere trattato come un soft 404.
Usa il canonical quando più URL devono restare accessibili
Scegli rel="canonical" quando varianti duplicate o quasi duplicate devono continuare a
restituire risposte 200 proprie, ma un URL deve essere considerato preferito per
l’indicizzazione. Un canonical è un’indicazione, non una navigazione: l’utente resta sull’URL
richiesto. Anche per Google è un’indicazione, non una regola. Google afferma
che “indicating a canonical preference is a hint, not a rule,” (traduzione): «indicare una
preferenza canonical è un suggerimento, non una regola» e può scegliere come canonica una
pagina diversa in base ad altri segnali.
Casi tipici: varianti utili di ordinamento o filtro, versioni distribuite in syndication o parametrizzate e duplicati che non è ancora possibile rimuovere.
Non esiste una sostituzione pertinente
Non forzare un redirect verso una pagina non correlata soltanto per avere una destinazione per il vecchio URL: un redirect generico o verso la homepage per contenuti privi di un vero successore appare a Google come un soft 404. Se non esiste un equivalente autentico, scegli consapevolmente una risposta 404 o 410 anziché inventare una destinazione.
Non inviare istruzioni in conflitto
Se l’URL A reindirizza a B, B non deve avere un canonical che torna ad A. Allinea link interni e sitemap alla destinazione che sopravvive. Il modello è semplice: sopravvive un solo URL → redirect; più URL devono restare attivi → canonical.
Prompt: controllare una mappa di redirect alla ricerca di destinazioni deboli
Incolla un CSV della mappa di redirect con vecchio URL, destinazione proposta, motivo, vecchio titolo o argomento, titolo o argomento della destinazione, durata prevista e, se disponibili, segnali di traffico o link.
Review this proposed redirect map for relevance and implementation risk.
For each row:
1. Classify the destination as strong equivalent, plausible but needs review,
irrelevant/catch-all, self-redirect, chain risk, loop risk, missing destination,
or insufficient evidence.
2. Explain the classification using only the supplied old/destination topics and
URL evidence.
3. Flag many-to-one mappings to a homepage or broad category for manual review.
4. Check whether the intended permanence matches the proposed 3xx code when a code
column is present.
5. Do not invent a replacement URL. If no equivalent is supplied, recommend manual
mapping or an intentional 404/410 decision.
Return a table with old URL, destination, verdict, evidence, recommended action, and
priority. End with a summary of repeated rule patterns that could create chains or
loops.
DATA:
[PASTE REDIRECT MAP HERE]Fai esaminare da una persona ogni giudizio sull’equivalenza dei contenuti prima di pubblicare la mappa.
Strumenti per pianificare e verificare i redirect
- Redirect Checker — verifica rapidamente stato finale, singoli passaggi e destinazione di un URL o di un piccolo insieme dopo il rilascio.
- Redirect Chain Mapper — diagnostica percorsi con più passaggi, mostra che cosa cambia a ciascuno ed esporta regole appiattite per ripulire le piattaforme server più comuni.
- Bulk HTTP Status Code Checker — convalida un inventario più ampio, filtra risultati temporanei o multipli ed esporta le prove.
- Redirect Map Builder — pianifica le corrispondenze dal vecchio al nuovo URL, rende espliciti gli URL senza corrispondenza e una lista di eliminazione 410 ed esporta regole orientate alla piattaforma. I suggerimenti richiedono comunque una revisione dell’equivalenza dei contenuti.
- DevTools del browser → Rete — verifica il codice 3xx della risposta del documento e
l’header
Locationmentre riproduci un comportamento specifico del browser.
Mettiti alla prova: redirect HTTP
Cinque domande rapide sul funzionamento dei redirect e sul modo in cui vengono trattati dai motori di ricerca. Scegli una risposta per ciascuna, poi verifica il risultato.
Cronologia modifiche
Aggiornato il 20 set 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Ripristinato l'intervallo protetto dei codici di stato nella risorsa localizzata.
Dettagli delle modifiche
-
Specificato l'intervallo 1xx–5xx senza modificare il collegamento fonte.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.
Aggiornato il 20 set 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Resa in forma descrittiva la panoramica delle famiglie di stato per evitare un token tecnico aggiunto dalla traduzione.
Dettagli delle modifiche
-
OpenAI / GPT-5 / reasoning effort not exposed / Codex in-session subagent ha riallineato il testo alla fonte bloccata senza alterare link o struttura MDX.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.
Aggiornato il 8 set 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Creata la prima bozza italiana source-locked; la numerazione locale delle revisioni inizia dall’ordinale 1.
Dettagli delle modifiche
-
Materializzati 145 blocchi in italiano, mantenendo la cronologia della fonte come provenienza.
-
Materializzati 48 campi di testo dei componenti nella sidecar italiana, preservando gli hash SHA-256 della fonte.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.
Aggiornato il 19 lug 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Ripristinate le dichiarazioni documentate e datate sui passaggi di redirect, che la revisione precedente aveva erroneamente considerato inventate, mantenendole separate sia dalla documentazione attuale di Google sia dalle osservazioni di Patrick.
Dettagli delle modifiche
-
Conciliati l’attuale limite massimo di 10 passaggi di Google e la raccomandazione pratica di non superarne 3 e restare sotto 5 con le dichiarazioni datate di John Mueller del 2014 e del 2020 su circa cinque passaggi per tentativo di scansione.
-
Ripristinata la dichiarazione del 2014 secondo cui una scansione successiva può continuare i redirect rimanenti, etichettandola come indicazione storica di un rappresentante anziché come garanzia attuale e mantenendo attribuite separatamente le osservazioni professionali di Patrick.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.
Aggiornato il 18 lug 2026.
Riepilogo editoriale e dettagli registrati delle modifiche.Riepilogo
Rimosso un dettaglio non documentato sui tempi dei passaggi di redirect, precisato il comportamento di 301/302/303/307/308 nella conservazione del metodo in base a MDN e Fetch Standard, fondati sulla RFC 9110, aggiunta l’avvertenza di Google secondo cui il canonical è “un’indicazione, non una regola” e sincronizzati indice e checklist del sottocluster con gli articoli correlati ora disponibili.
Dettagli delle modifiche
-
Rimosso dalla scheda Avanzato il dettaglio non documentato secondo cui Google seguirebbe “di norma cinque passaggi per sessione, riprendendo gli altri in seguito”; la documentazione sulla scansione indica soltanto “fino a 10 passaggi di redirect”, senza un valore per sessione.
-
Precisato nella tabella delle schede riassuntive e in due spiegazioni della scheda Avanzato il comportamento di 301/302 nella conservazione del metodo: al posto delle formule vaghe “non garantito” e “può sostituire”, è riportato il dato verificato secondo cui i client possono trasformare POST in GET per 301/302, in base al Fetch Standard; 303 impone sempre GET e 307/308 preservano rigorosamente metodo e corpo.
-
Aggiunta l’avvertenza documentata di Google secondo cui il tag canonical è “un’indicazione, non una regola” e una terza diramazione nella scheda Framework per i casi senza una sostituzione pertinente, nei quali usare 404/410 invece di forzare un redirect.
-
Sincronizzati l’indice “Dove proseguire” e la scheda Documentazione ufficiale con gli articoli correlati ora disponibili — redirect 307, redirect 308, redirect JavaScript, meta refresh, Pagina con reindirizzamento, Errore di reindirizzamento e documentazione sulla canonicalizzazione — e rimossa una nota obsoleta secondo cui il 308 sostituiva un articolo sul 307 non ancora scritto.
-
Aggiunti alla checklist di implementazione un passaggio per predisporre il rollback e un’avvertenza sulla verifica HEAD rispetto a GET.
Confronto completo non disponibile — non è stata archiviata alcuna istantanea precedente per questa revisione.
È stato utile?
Ti è piaciuto questo contenuto? Aggiungi questo sito alle tue fonti preferite su Google.
Aggiungi questo sito su GoogleContinua la conversazione