302 redirect: guida ai redirect temporanei

TL;DR — Un redirect 302 invia temporaneamente i visitatori da un URL a un altro. Dice ai motori di ricerca che questo spostamento non è permanente: mantieni l’URL originale nei risultati. Usalo quando intendi davvero qualcosa di temporaneo, come un test A/B, una pagina promozionale o un avviso di manutenzione. Usa invece un 301 quando stai spostando una pagina in modo definitivo.

Che cos’è un redirect 302

Un redirect è un’istruzione che invia a un URL diverso chiunque ne richieda uno. Quando un server risponde a una richiesta, include un codice di stato HTTP, un numero di tre cifre che indica che cosa è successo. Un 302 è uno dei codici di redirect. Il suo nome ufficiale è “302 Found” e la sua personalità si riassume in una parola: temporary. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

La parte temporanea è il punto. Un 302 dice: questa pagina si è spostata per ora, ma l’URL originale tornerà. Perciò i motori di ricerca dovrebbero mantenere l’URL originale nei risultati e trattare la destinazione come un sostituto temporaneo, non come una sostituzione.

Confrontalo con il suo fratello permanente, il redirect 301, che dice “questo spostamento è definitivo: indicizza invece il nuovo URL”. L’esperienza del visitatore è la stessa, perché entrambi lo inviano alla nuova pagina; il messaggio ai motori di ricerca è opposto.

Quando useresti davvero un redirect 302

Un 302 è lo strumento giusto ogni volta che lo spostamento è davvero di breve durata:

• Stai eseguendo un test A/B e invii alcuni visitatori a una variante della pagina.
• Hai una pagina di vendita o promozione temporanea e tornerai indietro in seguito.
• Una pagina è temporaneamente offline per manutenzione e vuoi mostrare un avviso “torniamo presto” senza rinunciare alla posizione dell’URL reale nella ricerca.
• Instradi i visitatori in base alla località o al dispositivo, per esempio verso una versione specifica per paese o lingua, e la destinazione “giusta” cambia da visitatore a visitatore.

In tutti questi casi vuoi che l’URL originale rimanga nei risultati di Google: è esattamente ciò che richiede un 302.

L’errore più comune

Per anni gli specialisti SEO hanno trattato i 302 come radioattivi: “non trasferiscono alcun valore dei link, non usarli”. È un mito. Un 302 trasferisce segnali di link; ciò che lo differenzia da un 301 è soltanto quale URL i motori di ricerca preferiscono mostrare. John Mueller di Google ha detto che i 302 “have a bad reputation among SEOs, which I think is incorrect” (traduzione) «hanno una cattiva reputazione tra gli specialisti SEO, cosa che ritengo errata.»

Il vero errore non è usare un 302: è usare un 302 per uno spostamento permanente. Se ritiri definitivamente una pagina ma la reindirizzi con un 302, stai dicendo a Google “mantieni indicizzato il vecchio URL”; la nuova pagina che vuoi davvero far posizionare potrebbe non subentrare per un periodo lungo e imprevedibile. Per uno spostamento definitivo, usa un 301.

Vuoi conoscere i meccanismi precisi, il linguaggio di Google sul “weak signal vs. strong signal”, perché un 302 di lunga durata può cambiare comportamento e iniziare ad agire come un 301, e come lo gestisce Bing? Passa alla scheda Advanced.

TL;DR — Un 302 (“Found”) è un redirect temporaneo. La formulazione precisa di Google ha due fasi, non una: l’infrastruttura di crawling considera il redirect un segnale debole che la destinazione debba essere elaborata, contrapposto al segnale forte di un 301; separatamente, la pipeline di indicizzazione di Search dice che non considera un redirect temporaneo un segnale che renda la destinazione canonica (la destinazione può comunque essere indicizzata tramite altri segnali). Due meccanismi vengono continuamente confusi: il trasferimento dei segnali dei link/PageRank (Mueller e Illyes hanno detto che con un 302 non è pari a zero, ma questa è una loro dichiarazione pubblica, non una regola universale formalmente pubblicata) e la preferenza di canonizzazione/indicizzazione (che è la vera differenza: un 302 dice a Google di mantenere indicizzato l’URL sorgente). Se resta attivo abbastanza a lungo, un 302 può cambiare comportamento: è un pattern osservato dai professionisti, non un meccanismo documentato, e non esiste una tempistica pubblicata. Google raccomanda il 302 invece del 301 per i test A/B. L’unico vero errore è usare un 302 per uno spostamento permanente; inoltre, non costruire mai la destinazione del redirect da input utente non verificato.

Da “Moved Temporarily” a “Found”: breve storia

Il 302 è nato in modo ambiguo. In HTTP/1.0 si chiamava “Moved Temporarily” e la specifica diceva che i client dovessero riutilizzare il metodo della richiesta originale quando lo seguivano. Nella pratica i browser non lo facevano: molti passavano silenziosamente da POST a GET durante il redirect, contrariamente alla specifica. HTTP/1.1 ha riconosciuto la realtà rinominando il 302 “Found” e aggiungendo due alternative non ambigue: 303 (See Other), che passa sempre a GET, e 307 (Temporary Redirect), che non cambia mai il metodo. La specifica attuale, RFC 9110 (2022), osserva ancora che i client possono cambiare POST in GET su un 302: è esattamente il motivo per cui esiste il 307 nei casi in cui non devono farlo. Per i redirect di pagine basati quotidianamente su GET (il caso d’uso SEO), 302 e 307 si comportano allo stesso modo per i motori di ricerca; la distinzione sulla conservazione del metodo conta solo per i form e le chiamate API. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

Per la ricerca, Google raggruppa 302 (found), 303 (see other) e 307 (temporary redirect) sotto “Temporary”, opposti a 301 e 308, classificati come “Permanent”.

La decisione compatta, se devi scegliere tra questi codici:

• 302 — il client che segue il redirect può cambiare POST in GET (RFC 9110). Va bene per un redirect di pagina basato su semplice GET; evitalo se non puoi tollerare il cambio di metodo.
• 307 — non cambia mai il metodo e non reinvia una richiesta diversa. Usalo quando una sottomissione di form o una chiamata API deve essere riprodotta esattamente come è stata inviata.
• 303 — punta deliberatamente a una risorsa diversa e non equivalente, normalmente recuperata con GET/HEAD: il classico pattern “redirect dopo un POST verso una pagina di conferma”, non un sostituto equivalente della richiesta originale.
• Caching — un 302 non è memorizzabile heuristically solo per il suo codice di stato (RFC 9111); viene conservato e riutilizzato solo se imposti direttive esplicite di freschezza o cache. Non dare per scontato che una CDN o un browser tratti un 302 nudo come memorizzabile per impostazione predefinita.

Segnale debole e segnale forte: le parole precise di Google

Salta la tradizione SEO e leggi il linguaggio effettivo di Google. Nei documenti sull’infrastruttura di crawling, Google dice che un 302 è un segnale debole:

In sintesi, i crawler di Google seguono il redirect e i sistemi di Google lo considerano un segnale debole per elaborarne la destinazione.

La riga del 301 nella stessa tabella è identica, tranne che per una parola: strong:

Per il 301, invece, Google descrive lo stesso passaggio come un segnale forte per elaborare la destinazione.

“Weak” non significa “zero”, ma vale la pena essere precisi anche su che cosa sia debole. Qui parlano due sistemi Google diversi di due fasi diverse, non di un unico continuum:

• Infrastruttura di crawling (la citazione sul “segnale debole” qui sopra): riguarda se la destinazione del redirect viene elaborata, cioè se il crawler di Google si prende la briga di recuperarla e analizzarla.
• Pipeline di indicizzazione di Search: è una fase distinta e successiva, che enuncia direttamente la propria regola: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (traduzione) «Googlebot segue il redirect, ma la pipeline di indicizzazione non usa il redirect come segnale che la destinazione debba essere canonica. La pagina di destinazione può comunque essere indicizzata se sono presenti altri segnali di canonizzazione.» Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search Google: Website testing

Letti insieme: un 302 dà a Google una piccola spinta debole per andare a osservare la destinazione (crawling), ma la pipeline di indicizzazione di Search non tratta quello stesso redirect come un voto per rendere canonica la destinazione (indicizzazione). La destinazione può comunque finire indicizzata e canonica, ma grazie ad altri segnali, non al 302 in sé. Non riassumere questi concetti dicendo che “un 302 è un voto debole a favore della canonizzazione della destinazione”: non è ciò che dice nessuno dei due documenti; descrivono ambiti diversi.

Due meccanismi, non uno

È qui che la maggior parte dei contenuti dei concorrenti fa confusione, quindi tienili separati:

1. Il trasferimento dei segnali dei link/PageRank non è pari a zero su un 302. Gary Illyes disse nel 2016 che Google non applica più una diluizione del PageRank attraverso redirect 301, 302 o altri 30x, abbandonando il vecchio mito della “perdita di circa il 15% a ogni hop”; Mueller ha espresso lo stesso concetto proprio sui 302: “do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” (traduzione) «funzionano come i redirect normali… non è che non trasferiscano alcun PageRank o qualcosa del genere.» Trattalo come una dichiarazione pubblica di Google sulla questione, non come una garanzia universale formalmente pubblicata: la documentazione primaria attuale non definisce una regola precisa sul trasferimento dei segnali dei link per ogni tipo di redirect in ogni situazione.
2. La preferenza di canonizzazione/indicizzazione è il meccanismo che differisce davvero. Un 301 è un segnale forte per indicizzare la destinazione; un 302 è debole, quindi per impostazione predefinita Google continua a indicizzare la sorgente.

“Un 302 trasferisce PageRank?” e “un 302 cambia quale URL si posiziona?” sono due domande diverse. La risposta alla prima è sì; alla seconda è “non per impostazione predefinita”. Confonderle è il modo in cui è nato il mito “302 = zero equity”.

A questo proposito: quando reindirizzi un URL, Google tiene traccia di entrambe le estremità. “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. The other URL becomes an alternate name of the canonical URL.” (traduzione) «Google tiene traccia sia della sorgente del redirect, il vecchio URL, sia della destinazione, il nuovo URL. Uno dei due URL sarà quello canonico; quale dipende da segnali come il fatto che il redirect sia temporaneo o permanente. L’altro URL diventa un nome alternativo dell’URL canonico.» Per un 302, per ora la sorgente resta canonica.

Che cosa succede se un 302 resta attivo troppo a lungo: il “flip”

Ecco la parte che sorprende: un redirect temporaneo che non viene mai rimosso può smettere di essere trattato come temporaneo. Mueller: “if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (traduzione) «se mantieni redirect 302 a lungo termine, li trattiamo comunque esattamente come redirect 301».

Perché succede? Questa è la mia spiegazione di lavoro tratta dalla mia guida Ahrefs sulla canonizzazione: un modello mentale di professionista costruito sul comportamento osservato, non un meccanismo formalmente pubblicato da Google. Immaginalo come una bilancia che si inclina. I redirect permanenti inviano i segnali in avanti verso il nuovo URL; quelli temporanei li inviano all’indietro verso l’URL originale. Ma:

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.” (traduzione) «Se un redirect temporaneo resta attivo abbastanza a lungo, o l’URL verso cui reindirizza esiste già, può essere trattato come permanente e inviare invece i segnali in avanti. Servono abbastanza segnali per far pendere la bilancia della canonizzazione vista prima. Man mano che aumentano i link, cambiano i link interni, vengono aggiornati gli URL della sitemap e così via, più segnali puntano al nuovo URL invece che al vecchio e si verifica il cambio.»

Il punto critico è che nessuno sa quanto ci voglia. Come ho scritto nella mia guida sui redirect, “Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” (traduzione) «Nessuno sa per quanto tempo debba esistere un redirect 302 prima che Google inizi a trattarlo come un redirect 301; di solito sono da alcune settimane ad alcuni mesi, ma possono essere giorni, settimane o mesi.» Google può agire prima se ritiene che tu abbia commesso un errore: “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” (traduzione) «Solo se Google pensa che tu abbia usato per errore un redirect 302 per uno spostamento permanente questo non accade. In quel caso tratta il redirect come un 301… In alcune circostanze Google sembra perfino trattare i 302 come 301 fin dall’inizio.» Non citare un numero preciso di giorni: non ne esiste uno pubblicato e qualsiasi cifra che trovi, compreso il numero “2 giorni” che circola nella tradizione su Bing, non è stata confermata da Google.

Come tratta Bing un 302: osserva il comportamento, non solo l’header

Bing arriva allo stesso risultato seguendo una strada leggermente diversa, e lo dichiara esplicitamente. Nel suo storico approfondimento sui redirect, Bing descrive il monitoraggio del pattern osservato di un redirect attraverso crawl ripetuti, invece di fidarsi del solo codice di stato: i redirect che continuano a cambiare destinazione vengono trattati più come 302 anche se sono etichettati 301, mentre quelli che puntano sempre allo stesso luogo vengono trattati più come 301 anche se sono etichettati 302; il sistema di Bing comincia a “think about them more like 301s as we continue to crawl them again and again” (traduzione) «considerarli più simili a 301 mentre continuiamo a esplorarli più e più volte». È la stessa convergenza descritta da Google, raggiunta in modo indipendente: dato un comportamento abbastanza coerente nel tempo, entrambi i motori si fidano di ciò che un redirect fa più che di ciò che il suo header dichiara.

Le indicazioni più datate di Bing insistevano anche più di quelle attuali di Google sull’uso parsimonioso dei 302, avvertendo che un 302 usato male può lasciare il valore bloccato sui vecchi URL. La conclusione pratica è identica a quella di Google: fai corrispondere il tipo di redirect al tuo intento reale.

Quando un 302 è la scelta giusta

Google non si limita a tollerare i 302: per un caso d’uso li raccomanda. Dalle sue indicazioni sui test A/B:

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.” (traduzione) «Se stai eseguendo un test che reindirizza gli utenti dall’URL originale a un URL variante, usa un redirect 302 temporaneo, non un redirect 301 permanente. Questo comunica ai motori di ricerca che il redirect è temporaneo, resterà attivo solo per la durata dell’esperimento e che devono mantenere l’URL originale nell’indice invece di sostituirlo con la destinazione del redirect, cioè la pagina di test. Anche i redirect basati su JavaScript vanno bene.»

I casi d’uso legittimi (tutti davvero temporanei):

• Test A/B — è la raccomandazione esplicita di Google riportata sopra. Ma non prolungarlo troppo: Google avverte che “if we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (traduzione) «Se scopriamo un sito che esegue un esperimento per un tempo inutilmente lungo, potremmo interpretarlo come un tentativo di ingannare i motori di ricerca e agire di conseguenza.» Eseguilo per il tempo necessario a raggiungere la significatività, poi rimuovilo.
• Instradamento geografico, per dispositivo e per lingua — quando la destinazione “giusta” dipende dal visitatore e nessun URL dovrebbe sostituire permanentemente la sorgente. Qui non basta scegliere un codice di stato: verifica verso cosa viene instradato Googlebot (in genere non porta con sé i segnali di località/dispositivo di un visitatore reale, quindi controlla ciò che la regola serve a lui), se l’instradamento usa cookie o header che un crawler non invierà, se le chiavi di cache e l’header Vary separano correttamente le varianti (così una cache non serve la pagina di un paese a un altro), se un visitatore con screen reader o senza JavaScript può comunque raggiungere il contenuto e se può ignorare l’instradamento automatico invece di restare bloccato in un loop. Abbinalo a un hreflang corretto sulle versioni localizzate: redirect e hreflang devono concordare, non combattersi.
• Pagine temporanee di manutenzione/servizio non disponibile — l’esempio di Google: “if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what’s happening, without compromising the original URL in search results.” (traduzione) «Se un servizio offerto dal sito è temporaneamente non disponibile, puoi impostare un redirect temporaneo verso una pagina che spieghi che cosa sta succedendo, senza compromettere l’URL originale nei risultati di ricerca.» Chiarisci quale delle due situazioni hai davvero. Se l’URL non può semplicemente essere servito in questo momento, per esempio il backend è inattivo o sei nel mezzo di un deploy, una risposta 503 Service Unavailable con header Retry-After sullo stesso URL è spesso più precisa: dice “temporaneamente non posso soddisfare questa richiesta, riprova più tardi” senza reindirizzare altrove. Usa un 302 quando vuoi instradare deliberatamente i visitatori verso un URL diverso e davvero utile, come una pagina di stato o una pagina “torneremo presto” più dettagliata, invece di limitarti a dichiarare indisponibile l’originale.
• Promozioni a tempo — invia i visitatori a una pagina della campagna per tutta la sua durata, poi torna indietro.
• Bilanciamento del carico/failover — instrada il traffico altrove quando un’origine o un data center è temporaneamente non disponibile.

Per questi esempi annotati affiancati, guarda la scheda Examples; per un controllo preliminare, guarda la scheda Checklists.

L’unico vero errore

Usare un 302 quando intendi uno spostamento permanente. Stai dicendo a Google di mantenere indicizzato il vecchio URL, quindi la nuova pagina che vuoi far posizionare potrebbe non subentrare per un periodo indefinito e imprevedibile: un costo reale in visibilità persa, non teorico. Se una pagina è sparita per sempre, usa un 301 (o 308). Errori correlati: mescolare 301 e 302 in modo incoerente nella stessa catena e, il rischio di qualsiasi redirect, puntare accidentalmente due URL l’uno verso l’altro creando un loop di redirect.

Come implementare un 302

Conta l’header: la riga di stato 302 Found insieme a un Location. Ecco l’esempio PHP di Google:

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache (.htaccess): il flag R=302 è ciò che lo rende temporaneo (un R=301 o un semplice R sarebbe permanente per impostazione predefinita):

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx: redirect emette un 302 (permanent emetterebbe un 301):

location = /old-path {
    return 302 https://www.example.com/newurl;
}

Qualunque sia lo stack, dai plugin di redirect di WordPress a una regola CDN/edge o a un handler a livello applicazione, la regola è la stessa: sono preferibili i redirect lato server e devi scegliere deliberatamente il codice temporaneo. La maggior parte degli strumenti usa 301 per impostazione predefinita, quindi un 302 è di solito un’impostazione esplicita.

Una nota di sicurezza che vale per qualsiasi redirect, non solo per i 302: se la destinazione nel tuo header Location viene mai costruita da input controllato dall’utente, per esempio un parametro di query ?next= o ?returnUrl=, hai gli ingredienti di un open redirect: un attaccante crea un link sul tuo dominio che in realtà rimbalza i visitatori verso un sito dannoso. Non inviare i visitatori a qualunque URL compaia in un parametro della richiesta; inserisci in allowlist le destinazioni verso cui reindirizzerai davvero, cioè un insieme fisso di percorsi o origini noti e sicuri, e verifica come la logica gestisce input codificati e relativi allo schema (//evil.example, %2F%2Fevil.example e trucchi simili) prima di usarla in produzione. Verifica la sintassi esatta degli snippet di ogni piattaforma rispetto alla sua versione attuale prima del rilascio: gli esempi sopra sono illustrativi, non sostituiscono i test sul tuo server/CDN.

Per il corrispettivo dello spostamento permanente e per il confronto completo, consulta gli articoli fratelli sul redirect 301, 301 vs 302 e 302 vs 307 di questo cluster.

Riepilogo AI

Una sintesi della versione Advanced:

• Un 302 (“Found”) è un redirect temporaneo (codice di stato HTTP 302). Invia gli utenti a un nuovo URL segnalando che l’URL originale dovrebbe rimanere nei risultati di ricerca.
• La formulazione precisa di Google distingue due fasi, non un continuum. L’infrastruttura di crawling considera un 302 un segnale debole che la destinazione debba essere elaborata (esplorata/osservata), rispetto al segnale forte di un 301. Separatamente, la pipeline di indicizzazione di Search dice che non usa un redirect temporaneo come segnale che la destinazione debba essere canonica, anche se questa può essere indicizzata tramite altri segnali. Debole ≠ zero ed “elaborato” ≠ “reso canonico”.
• 302 vs 303 vs 307, in breve: il client può cambiare il metodo POST→GET su un 302; il 307 non cambia mai il metodo; il 303 punta intenzionalmente a una risorsa diversa e non equivalente. Nessuno dei tre è memorizzabile euristicamente per impostazione predefinita: la cache richiede direttive esplicite.
• Il trasferimento dei segnali dei link non è pari a zero su un 302 — lo hanno detto sia Mueller sia Illyes — ma è una loro dichiarazione pubblica, non una regola universale di trasferimento formalmente pubblicata per ogni scenario. Il meccanismo che differisce davvero è la preferenza di canonizzazione/indicizzazione: un 301 spinge l’indicizzazione verso la destinazione; un 302 la mantiene sulla sorgente per impostazione predefinita.
• I 302 di lunga durata possono cambiare comportamento. È un pattern osservato dai professionisti (Mueller, la mia stessa esperienza), non un meccanismo documentato con una tempistica pubblicata: giorni, settimane o mesi, senza un numero fisso.
• Bing osserva il comportamento, non solo l’header: i redirect che si comportano in modo coerente attraverso crawl ripetuti vengono riclassificati indipendentemente dal codice di stato, la stessa convergenza descritta da Google.
• Google raccomanda il 302 (non il 301) per i test A/B. Altri usi legittimi: instradamento geografico/per dispositivo/per lingua (controlla il comportamento reale di Googlebot, cookie, cache/Vary, accessibilità e abbinalo a hreflang), pagine di manutenzione temporanee (confronta con 503 + Retry-After quando lo stesso URL non può essere servito), promozioni a tempo e bilanciamento del carico/failover. Non eseguire un test A/B per “an unnecessarily long time” (un tempo inutilmente lungo): Google potrebbe leggerlo come ingannevole.
• Sicurezza: non costruire mai la destinazione Location direttamente dall’input utente: usa un’allowlist per evitare l’abuso di open redirect.
• L’unico vero errore: usare un 302 per uno spostamento permanente: può lasciare il vecchio URL posizionato invece del nuovo per un tempo indefinito. Usa un 301 per gli spostamenti definitivi.

Documentazione ufficiale

Documentazione da fonti primarie dei motori di ricerca e della specifica HTTP.

Google

• Redirect e Google Search — la tabella dei tipi di redirect (permanente e temporaneo), la raccomandazione di mantenere il vecchio URL nei risultati di Search, il tracciamento degli URL alternativi e l’esempio di implementazione PHP.
• Come i codici di stato HTTP influenzano i crawler di Google — la tabella 3xx con il linguaggio esatto sul “weak signal” (302) rispetto al “strong signal” (301).
• Buone pratiche per i test A/B nella ricerca — la raccomandazione esplicita di Google di usare un 302, non un 301, per i test e l’avvertenza sui test eseguiti per “an unnecessarily long time”.

Bing / Microsoft

• Gestire i redirect: 301, 302 e canonical (Bing Webmaster Blog) — l’approfondimento di Bing sulla distinzione 301/302 e sulla posizione “we watch the behavior, not just the header” (traduzione) «osserviamo il comportamento, non solo l’header». (Il post live è renderizzato in JavaScript; il testo letterale è conservato nell’archivio Wayback Machine.)

Specifica HTTP / riferimento

• MDN — 302 Found e 307 Temporary Redirect — la particolarità della conservazione del metodo e il motivo per cui esistono 303/307.
• RFC 9110 §15.4.3 (302 Found) — la specifica corrente HTTP Semantics; osserva che i client possono ancora cambiare POST→GET su un 302.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google e Bing. Ogni link ai documenti di ricerca è un deep link che porta direttamente al passaggio citato nella pagina sorgente.

Google: la distinzione tra debole e forte (la spina dorsale dell’accuratezza)

• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (traduzione) «Per impostazione predefinita, i crawler di Google seguono il redirect e i sistemi Google lo usano come segnale debole che la destinazione del redirect debba essere elaborata.» — sul 302. Vai alla citazione
• “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 sistemi Google lo usano come segnale forte che la destinazione del redirect debba essere elaborata.» — la riga di confronto del 301 nella stessa tabella. Vai alla citazione
• La citazione completa sulla pipeline di indicizzazione è riportata nella scheda Advanced con il glossario italiano immediato; qui resta il collegamento diretto al passaggio ufficiale. Vai alla citazione

Google: quando usare un redirect temporaneo

• “If you just want to send users to a different page temporarily, use a temporary redirect. This will also ensure that Google isn’t influenced by the redirect which may help keep the old URL in its Search results.” (traduzione) «Se vuoi soltanto inviare temporaneamente gli utenti a una pagina diversa, usa un redirect temporaneo. In questo modo il redirect non influenzerà Google e potrà aiutare a mantenere il vecchio URL nei risultati di Search.» 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). 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 della sorgente del redirect, il vecchio URL, sia della destinazione, il nuovo URL. Uno dei due URL sarà quello canonico; quale dipende da segnali come il fatto che il redirect sia temporaneo o permanente.» Vai alla citazione

Google: test A/B (302 raccomandato, ma senza prolungarlo)

• “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (traduzione) «Se stai eseguendo un test che reindirizza gli utenti dall’URL originale a un URL variante, usa un redirect 302 temporaneo, non un redirect 301 permanente.» Vai alla citazione
• “If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (traduzione) «Se scopriamo un sito che esegue un esperimento per un tempo inutilmente lungo, potremmo interpretarlo come un tentativo di ingannare i motori di ricerca e agire di conseguenza.» Vai alla citazione

John Mueller, Google: sfatare il mito che “302 è negativo”

• “302 redirects have a bad reputation among SEOs, which I think is incorrect. Because they do work the same as normal redirects as well. It’s not that they don’t pass any PageRank or anything like that. And if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (traduzione) «I redirect 302 hanno una cattiva reputazione tra gli specialisti SEO, ma ritengo che sia un’idea errata. Funzionano infatti come i redirect normali: non è vero che non trasferiscano alcun PageRank o altro. E se mantieni i redirect 302 a lungo termine, li trattiamo comunque esattamente come i redirect 301.» Leggi la trascrizione

Bing / Microsoft: osservare il comportamento, non solo l’header

• Bing ha detto di riclassificare i redirect in base al pattern osservato attraverso crawl ripetuti: i 301 la cui destinazione continua a cambiare vengono considerati più simili a 302, mentre i 302 che puntano sempre allo stesso luogo vengono trattati più come 301 “as we continue to crawl them again and again” (traduzione) «mentre continuiamo a esplorarli più e più volte». Fonte archiviata

301 o 302? Checklist preliminare

Esegui questo controllo prima di pubblicare qualsiasi redirect, per verificare che il codice corrisponda al tuo intento:

• Lo spostamento è permanente? Se il vecchio URL non tornerà mai → 301 (o 308), non 302.
• È davvero temporaneo? (Test A/B, promozione, manutenzione, instradamento geografico/per dispositivo, failover) → 302 è corretto.
• Hai impostato il codice in modo esplicito? La maggior parte degli strumenti usa 301 per impostazione predefinita: conferma che il 302 sia intenzionale, non un incidente, e viceversa.
• Test A/B? Usa 302 (raccomandazione di Google) e prevedi di rimuoverlo quando il test raggiunge la significatività: non lasciarlo attivo per “an unnecessarily long time” (un tempo inutilmente lungo).
• Interruzione temporanea sullo stesso URL? Valuta invece un 503; usa un 302 quando instradi verso una pagina esplicativa diversa.
• Nessuna catena di redirect che mescoli 301 e 302 in modo incoerente: reindirizza direttamente alla destinazione finale.
• Nessun loop: ricontrolla che due URL non si reindirizzino a vicenda.
• Se un 302 “temporaneo” è diventato silenziosamente permanente, sostituiscilo con un 301 affinché il segnale corrisponda alla realtà (e non affidarti al “flip” dai tempi indefiniti di Google).
• Verifica il codice di stato effettivo restituito (-I, strumenti per sviluppatori del browser o redirect checker): l’etichetta di un plugin non dimostra quale header invii.

Casi d’uso legittimi del 302, con annotazioni

Cinque situazioni in cui un 302 è la scelta giusta e perché il segnale “temporaneo” conta in ciascuna.

1. Test A/B

GET /pricing/           → 302 → /pricing/variant-b/

Invii una parte del traffico a una variante per misurarla. Vuoi che /pricing/, l’originale, resti indicizzato e continui a posizionarsi; la variante è usa e getta. Questo è il caso per cui Google raccomanda esplicitamente un 302. Rimuovilo non appena il test termina: un test lasciato attivo indefinitamente può apparire ingannevole.

2. Vendita/promozione temporanea

GET /shoes/             → 302 → /promo/summer-sale-shoes/

Per la durata della campagna, i visitatori arrivano alla pagina della vendita, ma /shoes/ è il tuo URL evergreen e dovrebbe riprendersi la sua posizione appena termina la promozione. Qui un 301 sarebbe un errore: trasferiresti il ranking di /shoes/ a una pagina che stai per eliminare.

3. Manutenzione/temporaneamente non disponibile

GET /booking/           → 302 → /status/booking-back-soon/

Un servizio è temporaneamente inattivo e instradi gli utenti verso una pagina esplicativa: è un caso d’uso citato da Google. L’URL originale conserva la sua posizione nei risultati mentre sistemi il problema. (Se lo stesso URL è semplicemente offline invece di instradare altrove, 503 Service Unavailable è spesso il segnale più chiaro.)

4. Instradamento geografico/per dispositivo/per lingua

GET /               → 302 → /us/     (visitor in the US)
GET /               → 302 → /de/     (visitor in Germany)

La destinazione dipende da chi fa la richiesta, quindi nessun target dovrebbe sostituire permanentemente l’URL sorgente. Un redirect temporaneo è adatto perché la risposta “giusta” cambia a ogni richiesta. (Abbinalo a un hreflang corretto per le versioni localizzate.)

5. Bilanciamento del carico/failover

GET /app/               → 302 → /app-eu-west/     (primary origin down)

Quando un’origine o un data center è temporaneamente non disponibile, il traffico passa altrove, ma questo instradamento dovrebbe terminare quando l’origine primaria torna disponibile. Temporaneo per definizione.

L’anti-pattern, per confronto:

GET /old-product/       → 302 → /new-product/     ❌ (permanent move!)

Questo è un ritiro permanente mascherato da temporaneo. Risultato: Google può mantenere indicizzato e posizionato /old-product/ invece di consolidarlo su /new-product/, per un periodo imprevedibile. Qui serve un 301.

Due meccanismi, non uno

Usa questo schema per evitare che i miti sui redirect mescolino domande separate.

Applicalo in tre passaggi:

1. Dichiara l’intento. Un 302 dice che lo spostamento è temporaneo e che l’URL originale dovrebbe restare l’indirizzo stabile.
2. Esamina i segnali canonici. Link interni, voci della sitemap, canonical, link esterni e durata del redirect possono rafforzare la sorgente o far prevalere la destinazione.
3. Interpreta correttamente un 302 di lunga durata. Se Google inizia a trattarlo come uno spostamento permanente, il redirect non ha improvvisamente iniziato a “trasferire valore”. È cambiato l’equilibrio dei segnali canonici che determina quale URL possiede il contenitore.

La domanda diagnostica non è “un 302 trasferisce PageRank?”, ma “quale URL dovrebbe essere canonico e il redirect, insieme agli altri nostri segnali, dice la stessa cosa?”

Strumenti per controllare i redirect temporanei

Strumenti gratuiti di Patrick

• Redirect Checker — verifica che il primo hop sia davvero 302, esamina il Location e individua una catena che mescola codici temporanei e permanenti.
• Bulk HTTP Status Code Checker — controlla fino a 500 URL di test, promozione, instradamento o manutenzione ed esporta ogni risposta che non corrisponde al comportamento temporaneo previsto.

Controlla il comportamento canonico e la durata

• Google Search Console URL Inspection — confronta l’URL sorgente e quello variante e controlla quale Google ha scelto come canonico.
• Log del server/CDN — dimostra che il redirect è limitato al pubblico e al periodo previsti e che Googlebot non riceve accidentalmente un percorso diverso.
• Log/configurazione della piattaforma di esperimenti — registra inizio e fine del test, allocazione e regola di redirect, così una risposta temporanea non diventa infrastruttura dimenticata.

Dimostra che un redirect temporaneo è rimasto temporaneo

Test 1: l’esperimento emette un vero 302

• Test da eseguire — Controlla l’URL originale con il Redirect Checker mentre sei assegnato alla variante che reindirizza; ripeti da una sessione pulita se l’assegnazione dipende dai cookie. Esegui una vera richiesta GET, non soltanto una richiesta HEAD: server, CDN o applicazione possono gestire i due metodi in modo diverso, quindi un controllo HEAD da solo non dimostra che cosa riceva un visitatore reale (o Googlebot). Acquisisci la riga di stato grezza, il valore esatto di Location e gli eventuali header cache-control della risposta, non solo “ha fatto redirect”.
• Risultato atteso — La sorgente restituisce 302 con la variante prevista in Location e la variante si risolve senza loop né hop extra non correlati.
• Interpretazione del fallimento — 301/308 invia un segnale permanente; 200 seguito da una navigazione indica un redirect lato client invece della risposta server prevista; se HEAD e GET restituiscono codici di stato diversi per lo stesso URL, il server o la CDN gestiscono i due metodi in modo incoerente e serve un’analisi più approfondita.
• Finestra di monitoraggio — Immediatamente dopo l’attivazione del test, poi una volta per ogni deploy o modifica dell’instradamento.
• Trigger di rollback — L’originale restituisce un codice permanente, la destinazione è errata o una coorte entra in un loop.

Test 2: l’originale resta l’URL canonico

• Test da eseguire — Ispeziona in Google Search Console sia l’URL originale sia quello variante e verifica che link interni, voci della sitemap e tag canonical continuino a favorire l’originale.
• Risultato atteso — L’originale resta il canonico previsto; la variante non lo sostituisce come pagina di test indicizzata separatamente.
• Interpretazione del fallimento — Segnali di canonizzazione in conflitto o un redirect lasciato attivo inutilmente a lungo spingono Google verso la variante.
• Finestra di monitoraggio — Controlla dopo che Google abbia riesplorato gli URL e di nuovo durante un test lungo: non esiste un giorno fisso in cui un 302 cambia comportamento.
• Trigger di rollback — La variante diventa il canonico scelto da Google o inizia a comparire autonomamente per le query della pagina originale.

Test 3: la regola temporanea viene rimossa alla fine del test

• Test da eseguire — Dopo lo spegnimento, richiedi l’URL originale in una sessione pulita e passalo nel Redirect Checker.
• Risultato atteso — L’originale restituisce di nuovo il normale contenuto 200 e nessuna assegnazione di test reindirizza alla variante.
• Interpretazione del fallimento — È rimasta attiva una regola obsoleta nella CDN, nell’edge, nell’applicazione o nell’esperimento.
• Finestra di monitoraggio — Immediatamente dopo lo spegnimento, più un controllo dopo la scadenza della cache.
• Trigger di rollback — Una coorte di produzione continua a raggiungere la variante ritirata: disattiva la regola obsoleta e svuota la cache pertinente.

Test 4: la catena completa, il comportamento del metodo e i casi limite sono coperti

• Test da eseguire — Traccia l’intera catena di redirect dall’inizio alla fine (non solo il primo hop) e conferma che la destinazione finale restituisca una risposta corretta; ripeti qualsiasi test con un parametro di query e verifica che venga conservato (o rimosso intenzionalmente) invece di essere eliminato in silenzio; prova richieste con body POST se la route può riceverle, per vedere se il metodo sopravvive o cambia; e se la destinazione del redirect proviene mai da input utente, conferma che venga verificata rispetto a un’allowlist invece di accettare una destinazione arbitraria.
• Risultato atteso — La catena si risolve in pochi hop prevedibili verso una pagina funzionante; parametri e metodo si comportano come previsto dall’applicazione; le destinazioni fuori allowlist vengono rifiutate, non reindirizzate.
• Interpretazione del fallimento — Una catena lunga o in loop, un parametro eliminato che rompe la pagina di destinazione, un metodo cambiato in silenzio quando non dovrebbe o un redirect che segue un parametro arbitrario in stile ?next= (rischio di open redirect) sono tutti rilievi bloccanti per il rilascio, non difetti cosmetici.
• Finestra di monitoraggio — Prima del lancio e di nuovo dopo qualsiasi modifica alla gestione della regola, della CDN o della versione del framework.
• Trigger di rollback — Qualsiasi dei fallimenti precedenti nel traffico di produzione.
• Nota sugli strumenti — Lo strumento URL Inspection di Search Console ha limitazioni proprie per questo tipo di controllo (riflette il crawl di Google e non mostra necessariamente gli header grezzi live): trattalo come un segnale di ciò che Google ha visto, non come sostituto del controllo diretto della risposta HTTP.

Mettiti alla prova: redirect 302

Cinque domande rapide su che cos’è un 302 e quando usarlo. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche