Un 302 redirect è un codice di stato HTTP che dice al browser e ai motori di ricerca che una pagina si trova temporaneamente a un altro indirizzo, e che l’URL di partenza resta quello valido. Il nome ufficiale del codice è Found, e la definizione sta nella RFC 9110, paragrafo 15.4.3, la specifica IETF che dal giugno 2022 ha sostituito la RFC 7231 ancora citata da molti articoli: la risorsa risiede temporaneamente sotto un URI diverso, quindi il client dovrebbe continuare a usare l’indirizzo originale per le richieste future.
La conseguenza pratica è una sola, e conviene tenerla a mente prima di tutto il resto: nei risultati di ricerca continua a comparire l’URL di partenza, non quello di destinazione. Se è quello che vuoi, il 302 è il codice giusto. Se ti aspettavi di veder salire la pagina nuova, hai scelto il codice sbagliato e serve un 301 redirect.
Che cosa succede nei risultati di ricerca
La documentazione di Google è esplicita su questo punto e non lascia margine di interpretazione. Nella pagina Reindirizzamenti e Ricerca Google, aggiornata il 14 aprile 2026, i reindirizzamenti temporanei mostrano la pagina di origine nei risultati, quelli permanenti mostrano la destinazione. Google aggiunge una cosa che in italiano si legge di rado: quando reindirizzi un URL, tiene traccia sia della sorgente sia della destinazione, e decide quale delle due diventa canonica in base a segnali che includono la natura temporanea o permanente del redirect. L’altra diventa un nome alternativo dello stesso URL canonico.
Vale la pena smontare una frase che circola su parecchi articoli italiani: il 302 non passerebbe il PageRank. La domanda è formulata male. Il punto non è quanto valore viene travasato da un URL all’altro, è quale dei due URL Google tiene in indice. Con un 302 impostato bene i segnali restano dove sono sempre stati, sulla pagina di partenza, perché è quella che deve continuare a posizionarsi. Non c’è niente da recuperare, perché niente si è mosso.
I 302 che non hai configurato tu
Quasi nessuno arriva a cercare questo codice perché ha deciso di impostare un reindirizzamento temporaneo. Ci arriva perché ha lanciato una scansione con Screaming Frog o ha aperto un report di Search Console, ha trovato una colonna piena di 302 e vuole sapere se deve preoccuparsi. Nella maggior parte dei casi quei redirect li ha generati qualcos’altro: il CMS, un plugin, il livello di hosting, una regola di sicurezza.
| Da dove arriva | Esempio tipico | Va corretto? |
|---|---|---|
| Area riservata e login | WordPress risponde 302 Found su /wp-admin/ e manda a wp-login.php | No, è il comportamento previsto e quelle URL non vanno indicizzate comunque |
| Plugin multilingua | Reindirizzamento dalla radice del dominio verso /it/ o /en/ in base alla lingua del browser | No, purché ogni lingua abbia un URL stabile e raggiungibile in modo diretto |
| E-commerce, prodotti esauriti | Il tema rimanda la scheda fuori stock alla categoria di appartenenza | Dipende: se il prodotto rientra va bene, se è uscito di catalogo servono un 301 o un 410 |
| CDN e firewall applicativi | Regole di forwarding in cui il codice si sceglie da un menu e nessuno lo rilegge | Sì, se lo spostamento è definitivo |
| Ambienti di staging | Protezione che dirotta i visitatori su una pagina di autenticazione | No, ma verifica che la stessa regola non sia finita in produzione |
| Carrello e checkout | Passaggi di sessione che rimbalzano l’utente da un passo all’altro | No, a patto che la catena non superi un paio di salti |
Il caso di WordPress è verificabile in dieci secondi su qualsiasi installazione. Una richiesta a /wp-admin/ senza sessione attiva torna un 302 con l’header Location puntato a wp-login.php. La stessa installazione, invece, usa un 301 per normalizzare la barra finale mancante in fondo agli URL. Due codici diversi nello stesso software, scelti in base a quanto è definitiva la destinazione.
Come verificare un 302 in due minuti
Il browser non serve a niente, perché segue il reindirizzamento prima che tu possa leggerlo. Da terminale bastano quattro caratteri:
curl -I https://esempio.it/pagina-vecchia/La prima riga della risposta contiene il codice, la riga Location contiene la destinazione. Se vuoi vedere l’intera catena di salti, curl -IL li stampa uno dopo l’altro: è il modo più rapido per accorgersi che un redirect apparentemente singolo in realtà passa da tre URL prima di arrivare a destinazione, con il costo in tempo di risposta che ne consegue.
Dal lato Google, lo strumento è il controllo URL di Search Console: mostra l’URL che Google considera canonico, che è esattamente l’informazione che ti interessa quando hai il dubbio di aver usato il codice sbagliato. Se hai messo un 302 su uno spostamento definitivo, il canonico dichiarato da Google resterà il vecchio indirizzo molto più a lungo di quanto ti aspetti.
Il dettaglio che rompe i form
C’è un comportamento del 302 che non riguarda il posizionamento e che salta fuori quando meno serve. La RFC 9110 avverte che, per ragioni storiche, davanti a un 302 lo user agent può cambiare il metodo della richiesta successiva da POST a GET. MDN Web Docs conferma che è proprio quello che prescrive il Fetch Standard: ricevuto un 302 in risposta a una POST, il browser rifà la richiesta in GET.
Su una pagina di contenuto non cambia niente. Su un endpoint che riceve i dati di un form di contatto, di un checkout o di un’integrazione, la richiesta arriva a destinazione senza il payload e l’invio si perde senza errori visibili. Per quei casi la specifica prevede il 307, che vieta al client di toccare il metodo. Se invece vuoi forzare il passaggio a GET, per esempio dopo un caricamento, il codice corretto è il 303.
Quando il 302 è la scelta giusta
- Una pagina in manutenzione che tornerà online con lo stesso indirizzo.
- Un test A/B fra due versioni della stessa pagina ottimizzata, dove la versione originale deve restare quella indicizzata.
- Una promozione stagionale che dirotta una categoria su una landing temporanea.
- Una scheda prodotto momentaneamente non disponibile che rientrerà a magazzino, caso ricorrente nella SEO per e-commerce.
- Una pagina bloccata per un problema legale o editoriale in attesa di revisione.
Il filo comune è la reversibilità. Se sai già che l’indirizzo vecchio non tornerà mai, il 302 è la scelta sbagliata anche quando nell’immediato sembra innocua.
Quando invece va sostituito
Il caso da correggere subito è il 302 usato per una migrazione, un cambio di dominio o una ristrutturazione degli slug. Lì il codice temporaneo tiene in vita nell’indice un indirizzo che non esiste più, mentre la pagina nuova aspetta il suo turno. Il segnale che serve a Google per spostare la canonicità sulla destinazione è proprio quello che un 302 non manda.
L’altro caso è meno evidente: due URL che restano entrambi raggiungibili e rispondono 200, con un 302 che ne collega uno all’altro. Lì il reindirizzamento non risolve niente e il problema diventa di contenuto duplicato, da gestire con il tag canonical o con un 301 vero. Un canonical, va detto, è un suggerimento che Google può ignorare: un reindirizzamento è un’istruzione a livello di server, e pesa molto di più.
C’è poi una via di mezzo che quasi nessuno conosce, ed è utile quando non hai accesso alla configurazione del server. Google interpreta un meta refresh istantaneo come un reindirizzamento permanente e un meta refresh ritardato come temporaneo. È una scappatoia, non un metodo: la stessa documentazione mette i redirect lato server in cima alla lista per probabilità di essere interpretati correttamente.
Un 302 dimenticato non fa rumore. Non genera un errore in Search Console, non rompe la pagina, non avvisa nessuno: continua semplicemente a tenere in indice un indirizzo che magari hai abbandonato mesi fa. Per questo conviene trattare i reindirizzamenti temporanei come le voci di un inventario, con una data di scadenza scritta da qualche parte, invece che come impostazioni da mettere e dimenticare. In un progetto SEO è una delle prime cose che si guardano quando il traffico di una sezione non riparte dopo un restyling, e una delle più veloci da sistemare.
Domande frequenti
No. È una risposta regolare del server, prevista dalla specifica HTTP, e nella maggior parte dei casi indica un comportamento voluto come il rimando a una pagina di login. Diventa un problema solo quando segnala come temporaneo uno spostamento che in realtà è definitivo.
Il 301 dichiara uno spostamento permanente: la destinazione diventa l'URL canonico e prende il posto del vecchio indirizzo nei risultati di ricerca. Il 302 dichiara uno spostamento temporaneo e nei risultati resta l'URL di partenza. La scelta dipende da una domanda sola: quell'indirizzo tornerà a essere valido?
Non di per sé. Se lo spostamento è davvero temporaneo, la pagina di partenza mantiene indicizzazione e segnali, che è esattamente il risultato voluto. Le perdite arrivano quando il 302 viene usato al posto di un 301 durante una migrazione: in quel caso la pagina nuova resta indietro finché il codice non viene corretto.
Quanto dura la condizione temporanea che lo ha reso necessario, e non un giorno di più. Non esiste una soglia dichiarata da Google, ma un reindirizzamento temporaneo che resta al suo posto per mesi è quasi sempre il sintomo di una decisione mai presa. Conviene annotarne la scadenza insieme alla regola.
Per una pagina di contenuto i due codici sono equivalenti agli occhi dei motori di ricerca. La differenza conta sugli endpoint che ricevono dati: davanti a un 302 il browser può trasformare una richiesta POST in GET e perdere il payload, mentre il 307 vieta di cambiare il metodo. Su form, checkout e integrazioni usa il 307.
